69 团队的共识管理 69 | 团队的共识管理你好，我是七牛云许式伟。

软件工程是一项团体活动，大家有分工更有协同。不同的个体因为能力差别，可以形成十倍以上的生产力差距。而不同团体更是如此，他们的差距往往可以用天壤之别来形容。

这差距背后的原因，关乎的是协同的科学。

团队共识

有的团体像一盘散沙，充其量可以叫团伙。有的团体则有极强的凝聚力，整个团队上下同心，拧成一股绳，这种团体才是高效率组织，是真正意义上的团队。

团队靠什么上下同心？靠的是共识。

那么，什么是团队的共识？

团队的共识分很多层次。其一，团队是不是有共同的目标。其二，团队是不是有共同的行事做人的准则。其三，对产品与市场的要与不要，以及为什么要或为什么不要，是否已达成一致。其四，对执行路径有没有共同的认知。其五，有没有团队默契，是否日常沟通交流很多地方不必赘述，沟通上一点即透。

一个团体如果缺乏共同的目标，那么它最多能够算得上是一个团伙，而不能称之为团队。

团队的目标也分很多层次。为什么很多企业都会谈他们的使命和愿景，是因为它是这个企业作为一个团队存在的意义，是企业所有人共同的长远目标。

人是愿景型动物，需要看到未来。越高级的人才越在乎团队存在的意义。所以高科技公司的人才通常只能去影响，而不是像一些人心中理解的那样，认为管理是去控制。

愿景是一种心力。人有很强的主观能动性。一旦人相信企业的使命与愿景，员工就变得有很强烈的使命感，有强烈的原动力。员工的行为方式也就会潜移默化发生变化。

不过，有共同的远景目标的团队仍然有可能走向分裂。

中国有句古话说得好：“道不同，不相为谋”。团队有没有相同的价值观，有没有相同的行事做人的准则，这些更根本性的基础共识，极有可能会成为压垮团队的稻草。

共识大于能力。如果一个人有很强的个人能力，但是却和团队没有共同的愿景，或者没有共同的价值观，那么能力越大产生的破坏性也就越大。

怎么达成共识？

团队有了共同的使命、愿景与价值观，就有了共同努力把一件事情干成的最大基础。然而，这并不代表这个团队就不会遇到共识问题。

团队仅有远期的目标是不够的，还要有中短期的目标。企业的使命和愿景需要由一个个的战略行动来落地。我们的产品定位怎么样，选择哪些细分市场去切入，这些同样需要团队达成共识。

怎么去达成共识？

越 “聪明” 的团队负责人，往往越容易忽视达成共识的难度。他们通常会召开会议，然后把自己的想法说给大家听。半个小时后，兄弟们迷茫地回去了。

在团队还小的时候，这种简单共识的方式很可能是可以奏效的，尤其是当团队负责人还能够一一去检查每个人的工作内容时，所有的理解偏差都能够得到比较及时的纠正。

但是团队规模稍微变大一些，这种简单共识突然就失效了。“我明明已经告诉他们要做什么了。” 负责人有时候困惑于团队成员为什么并没有理解他的话。

这是因为他还并不理解真正的共识意味着什么。也没有对达成共识的难度有足够的认知。

让更多人参与到决策形成的过程现场，是更好的共识达成的方式。通过同步足够充分的信息，通过共创而非传达决策的方式让结论自然产生。

这个共创过程不必团队所有人都参与，但要确保所有影响落地的关键角色都在，并确保参与这个过程的人都能够产生思想的碰撞，而非做个吃西瓜群众。

契约与共识效率

目标与执行路径达成了共识，这还不够。我们还需要把共识表达出来，形成文字。

为什么这很重要？

因为共识之所以为共识，是因为它不是空中楼阁，不是口号，而是指导我们做战略选择的依据，指导我们平常行为的依据。

所以，共识就是团队协作的契约。契约的表达越是精确而无歧义，团队协作中主观能动性就越高，执行的效率也就越高。

对于架构过程同样如此。

架构过程实际上是团队共识形成与确认的过程。架构设计需要回答两个基本的问题：

  • 系统要做成什么样？
  • 怎么做？

架构设计为什么叫架构设计，是因为架构师的工作中除了架构，还有设计。设计其实谈的就是 “系统要做成什么样”。 设计高于架构。

设计强调规格，架构强调实现。规格设计是架构过程的最高共识。所以，规格高于实现。我们用架构的全局性和系统性思维去做设计。

一些架构师乐衷于画架构图，把它当作是架构师最重要的工作内容。但架构图在共识的表达上并不太好。因为共识是需要精确的、无歧义的。而架构图显然并不精确。

对于一个工程团队来说，没有精确的共识很可怕。它可能导致不同模块的工作牛头不对马嘴，完全无法连接起来，但是这个风险没有被暴露，直到最后一刻里程碑时间要到了，要出版本了，大家才匆匆忙忙联调，临时解决因为架构不到位产生的 “锅”。

这时候人们的动作通常会走形。追求的不再是架构设计的好坏，而是打补丁，怎么把里程碑的目标实现了，别影响了团队绩效。

我们作个类比，这种不精确的架构，就好比建筑工程中，设计师画了一个效果图，没有任何尺寸和关键细节的确认，然后大家就分头开工了。最后放在一起拼接（联调），发现彼此完全没法对上，只能临时修修改改，拼接得上就谢天谢地了。是不是能够和当初效果图匹配？让老天爷决定吧。

更精确描述架构的方法是定义每个模块的接口。接口可以用代码表达，这种表达是精确的、无歧义的。架构图则只是辅助模块接口，用于说明模块接口之间的关联。

尊重契约，尊重共识精确的、无歧义的表达，非常非常重要。

绝大部分哪怕是非常优秀的架构师，在系统设计（也叫概要设计）阶段通常也只会形成系统的概貌，把子系统的划分谈清楚，把子系统的接口规格谈清楚。

但实际上概要设计阶段最好的状态并不是只有设计文档。

为了降低风险，系统设计阶段也应该有代码产出。

这样做有两个方面的目的。其一，系统的初始框架代码。也就是说，系统的大体架子已经搭建起来了。其二，原型性的代码来验证。一些核心子系统在这个阶段提供了 mock 的系统。

这样做的好处是，一上来我们就关注了全局系统性风险的消除，并且给了每个子系统或模块的负责人一个更具象且确定性的认知。

代码即文档。代码是理解一致性更强的文档。

结语

这一讲我们谈的是协同的科学。为什么有的团队效率极高，有的团队却进展缓慢，从背后的协同效率来说，共识管理是根因中的根因。

共识有非常多的层次。不同层次的共识处于完全不同的维度。它们都极其重要，且相互不可替代。当某个层次的共识出问题的时候，我们需要在相应的层次去解决它。

如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们谈谈 “怎么写设计文档”。原计划我们下一讲是 “如何阅读别人的代码”，但是我想先顺着共识这个话题谈问题谈清楚。

如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e8%ae%b8%e5%bc%8f%e4%bc%9f%e7%9a%84%e6%9e%b6%e6%9e%84%e8%af%be/69%c2%a0%e5%9b%a2%e9%98%9f%e7%9a%84%e5%85%b1%e8%af%86%e7%ae%a1%e7%90%86.md