我的同事王健最近写了一篇文章——《从汽车贴膜看专业团队》。看了之后感触良多，特别是文中提到的现场管理和全功能团队两点。
我有一个观点，说到专业性，传统行业比我们 IT 行业要强得多。从这篇文章可以看出，不管是管理人员的现场管理能力，还是全功能团队中一线人员的全栈能力，传统行业都比我们要强一些。相信有人会有些不服，不管什么现场管理，全功能团队我们也在做呀。
说的没有错，但是，在 IT 行业里还真不容易找到这么专业的一个团队。而在传统行业里，这种水平的一个团队已经越来越常见了。这是为什么呢？按说大家都是人，通常来讲，IT 行业的人能力素质不是还高一点吗？在我们这个行业中，专业团队不是应该更常见吗？虽然我们不一定要比你强，但是也不会比你弱得这么明显啊。
当然，一方面是由于我们这个行业的工作比较复杂，不容易做到全栈，但我觉得更重要的是，IT 行业属于知识工作，知识工作者的现场非常不明显，极难做到现场管理。
我们 IT 行业的管理者，不管是项目经理，产品经理，还是技术领导者，大家也基本都和团队坐在一起。但是坐在一起，并不意味着就能够真的在现场。
我们看到在那个贴膜团队里，团队领导只需要看一眼，发现有气泡，就知道质量有问题。也就是说，在传统行业进行现场管理的时候，问题都是非常直观的，非常容易发现。在软件行业想做到一点就难的多，记得几年前我的同事熊节也曾经写过一篇文章，文章的核心洞见就是软件开发的现场在代码里。
这个想法在 ThoughtWorks 有很多拥护者，公司里有很多人提出过类似的观点，于是我们的很多方法就是构建于这些类似的观点之上。
然而，如果我们想要追求 IT 工作者开发效率的极限，这个洞见还不够极致。经过几年的工作，我发现，代码只是软件开发工作的第二现场，软件开发工作的第一现场，在语言里。
这里说的语言，不是编程语言，也不是广义的人类语言，比如汉语、英语。指的是我们在从事软件开发工作中所使用的一系列术语和相关的一系列呈现方式和沟通工具。借用一个技术术语，我们所说的语言是一套仅供软件开发所有相关人员使用的、组合的 DSL，DSL 全称：Domain specific language，中文名叫做：领域特定语言。
DSL 就 DSL，还组合的 DSL，为什么要说的这么拗口呢？什么叫组合的 DSL?我们知道在软件开发的过程当中，需要各种不同的角色参与。每个角色有自己特定的领域，泛泛的讲可以分为三类：我们把产品经理和设计人员所使用的领域特定语言叫做设计语言；把开发和测试使用的语言叫做技术语言；把业务人员、组织管理者使用的语言，叫做业务语言。
所以我们使用的这套领域特定语言是把这三类语言组合在一起而形成的一套语言。这就意味着我们这套语言非常容易充满歧义，造成每个角色自说自话却难以被发现。
软件工程里的核心观点是：一个问题被发现的越晚，修正的成本就越高。比代码更早的是沟通，比沟通更早的就是语言。我们用语言去描述沟通的错误，去描述代码中的错误，我们用什么来描述语言的错误呢？还是语言，这就使得整个工作困难重重，难以达成共识。所以我们更需要非常严肃的对待软件开发工作的第一现场。
之前一些方法试图建立纯粹的统一语言，所有人都说一套语言，事实上这个方法已经被行业放弃了，我们要承认，各自不同的语言有些部分可以简单统一成一种表达以消除歧义，有些部分只能结合。也就是说相关人员要懂多门语言。这个现实是我们必须接受的，软件正在吞噬世界，语言只会越来越复杂。就像我们再努力消除污染，也不能幻想世界回到工业文明以前了。无论我们多么努力的去建立统一语言，也不可能形成一门简单的语言，只能是多门 DSL 的一个杂合体。
不过由于历史的原因，在行业放弃的过程中，由于“反对预先设计”走的过了头，“不谈建模，不谈标准化”成了一种奇怪的政治正确，导致很多优秀的工具和方法被边缘化了。其实我们憎恨的只是预先设计造成的反馈速度变慢，只是在这个过程中连带上了憎恨预先设计时代的一些工具，这就有点上纲上线了。
幸而最近几年，各种领域建模的设计方法又重新回归。最近大行其道的领域驱动设计，就是在很严肃的对待业务语言的设计和使用。而在前端领域，Design System 试图解决前端开发和设计师之间的语言分歧问题。我个人在从事软件开发工程师的培养方面发现，很多传统的可视化工具，比如说 UML。如果不以繁重的预先设计为目的，来使用这些工具，仅把它们用作提高沟通效率的工具，他们的威力是十分惊人的。
以我本人的团队为例，我们使用 ant design 为基础，设计了 design system。使得我们可以在三天之内得到一个可以点击的软件原型，并在此基础上，进行各利益相关方之间的需求交流和反馈。在交流的过程当中，我们也刻意的统一了语言，使得我们尽管是一个远程团队，但是在交流的时候，能够很清楚的知道我们在对信息架构在哪一层进行反馈。这不但使得业务方可以反馈技术方，其实技术方也在引导业务方。语言的影响是双向的。
在技术领域里，我们也选择了隔离性更好的技术架构，使得 MVP 的代码不会变成我们演进道路上必须长期背负的负累。而之所以在一篇聊“语言”的文章里提技术架构，是因为我们认为真正的架构不是纸上的，也不是代码里的，而是每个团队成员心里的架构。实施一个架构必然也是要进行大量沟通，也需要统一语言。
而在交流业务的时候，我们刻意的划分了各种不同的子领域，又在每个领域当中统一了名词。统一名词还是比较简单的，最难的是划分领域，我们为此投入了大量的工作，也犯了一些错误，但这些付出是值得的，这之后，我们的沟通变得非常流畅。
具体的实践有机会再跟大家分享。在这里仅仅聊一下沟通顺畅带来的价值，沟通顺畅的威力并不仅仅表现在沟通的时候可以很顺畅的传递信息，最重要的是当有团队成员对信息理解出现错误的时候，可以很容易的发现和给予反馈。
这个优势在 IT 行业至关重要。IT 行业的人员流动率接近 25%，这意味着每年我们团队中至少有1/4 的新人加入。即便我们想尽方法让我们的团队保持稳定，随着敏捷和精益创业的相关思想慢慢成为我们的工作常识，每个项目存在的时间都不会太长，这使得 IT 团队经常性的重组，有时是团队被打散，有时是同一个系统从一个团队交给了另一个团队。如果缺乏一种有效的反馈机制，那么无论是人员流动还是组织重组，所造成的切换成本都是一个很大的。尽管这个切换成本无法消除，但是尽量减少切换成本是我们每个专业人员应该追求的，尤其是团队中的技术领导者。
技术领导者重音在“领导”，而不在“技术”。尤其在 Tech@Core 的今天，技术就是业务。优秀的技术领导者更不能把自己变成一个救火队员，只是被动的响应，尽管救火队员常常因为很容易被人看到而获得一些关注和赞扬，但在中国的文化里，我们都知道还有更高一层的境界，这个境界存在于很多典故中，比如上医治未病，善战者无赫赫之功。同理，软件开发领域的技术领导者们也应该努力使大多数问题发生的基础消灭于无形，这就需要我们走出舒适区，深入到软件开发的第一现场，进行现场管理。
相关文章
