69 | 团队的共识管理

Dec 31, 2019

69 | 团队的共识管理-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

69 | 团队的共识管理

2019-12-31 许式伟来自北京

《许式伟的架构课》

课程介绍



讲述：丁伟

时长08:51大小8.09M



你好，我是七牛云许式伟。
软件工程是一项团体活动，大家有分工更有协同。不同的个体因为能力差别，可以形成十倍以上的生产力差距。而不同团体更是如此，他们的差距往往可以用天壤之别来形容。
这差距背后的原因，关乎的是协同的科学。
团队共识有的团体像一盘散沙，充其量可以叫团伙。有的团体则有极强的凝聚力，整个团队上下同心，拧成一股绳，这种团体才是高效率组织，是真正意义上的团队。
团队靠什么上下同心？靠的是共识。
那么，什么是团队的共识？
团队的共识分很多层次。其一，团队是不是有共同的目标。其二，团队是不是有共同的行事做人的准则。其三，对产品与市场的要与不要，以及为什么要或为什么不要，是否已达成一致。其四，对执行路径有没有共同的认知。其五，有没有团队默契，是否日常沟通交流很多地方不必赘述，沟通上一点即透。
一个团体如果缺乏共同的目标，那么它最多能够算得上是一个团伙，而不能称之为团队。
团队的目标也分很多层次。为什么很多企业都会谈他们的使命和愿景，是因为它是这个企业作为一个团队存在的意义，是企业所有人共同的长远目标。
人是愿景型动物，需要看到未来。越高级的人才越在乎团队存在的意义。所以高科技公司的人才通常只能去影响，而不是像一些人心中理解的那样，认为管理是去控制。
愿景是一种心力。人有很强的主观能动性。一旦人相信企业的使命与愿景，员工就变得有很强烈的使命感，有强烈的原动力。员工的行为方式也就会潜移默化发生变化。
不过，有共同的远景目标的团队仍然有可能走向分裂。
中国有句古话说得好：“道不同，不相为谋”。团队有没有相同的价值观，有没有相同的行事做人的准则，这些更根本性的基础共识，极有可能会成为压垮团队的稻草。
共识大于能力。如果一个人有很强的个人能力，但是却和团队没有共同的愿景，或者没有共同的价值观，那么能力越大产生的破坏性也就越大。
怎么达成共识？团队有了共同的使命、愿景与价值观，就有了共同努力把一件事情干成的最大基础。然而，这并不代表这个团队就不会遇到共识问题。
团队仅有远期的目标是不够的，还要有中短期的目标。企业的使命和愿景需要由一个个的战略行动来落地。我们的产品定位怎么样，选择哪些细分市场去切入，这些同样需要团队达成共识。
怎么去达成共识？
越 “聪明” 的团队负责人，往往越容易忽视达成共识的难度。他们通常会召开会议，然后把自己的想法说给大家听。半个小时后，兄弟们迷茫地回去了。
在团队还小的时候，这种简单共识的方式很可能是可以奏效的，尤其是当团队负责人还能够一一去检查每个人的工作内容时，所有的理解偏差都能够得到比较及时的纠正。
但是团队规模稍微变大一些，这种简单共识突然就失效了。“我明明已经告诉他们要做什么了。” 负责人有时候困惑于团队成员为什么并没有理解他的话。
这是因为他还并不理解真正的共识意味着什么。也没有对达成共识的难度有足够的认知。
让更多人参与到决策形成的过程现场，是更好的共识达成的方式。通过同步足够充分的信息，通过共创而非传达决策的方式让结论自然产生。
这个共创过程不必团队所有人都参与，但要确保所有影响落地的关键角色都在，并确保参与这个过程的人都能够产生思想的碰撞，而非做个吃西瓜群众。
契约与共识效率目标与执行路径达成了共识，这还不够。我们还需要把共识表达出来，形成文字。
为什么这很重要？
因为共识之所以为共识，是因为它不是空中楼阁，不是口号，而是指导我们做战略选择的依据，指导我们平常行为的依据。
所以，共识就是团队协作的契约。契约的表达越是精确而无歧义，团队协作中主观能动性就越高，执行的效率也就越高。
对于架构过程同样如此。
架构过程实际上是团队共识形成与确认的过程。架构设计需要回答两个基本的问题：
系统要做成什么样？
怎么做？
架构设计为什么叫架构设计，是因为架构师的工作中除了架构，还有设计。设计其实谈的就是 “系统要做成什么样”。
设计高于架构。
设计强调规格，架构强调实现。规格设计是架构过程的最高共识。所以，规格高于实现。我们用架构的全局性和系统性思维去做设计。
一些架构师乐衷于画架构图，把它当作是架构师最重要的工作内容。但架构图在共识的表达上并不太好。因为共识是需要精确的、无歧义的。而架构图显然并不精确。
对于一个工程团队来说，没有精确的共识很可怕。它可能导致不同模块的工作牛头不对马嘴，完全无法连接起来，但是这个风险没有被暴露，直到最后一刻里程碑时间要到了，要出版本了，大家才匆匆忙忙联调，临时解决因为架构不到位产生的 “锅”。
这时候人们的动作通常会走形。追求的不再是架构设计的好坏，而是打补丁，怎么把里程碑的目标实现了，别影响了团队绩效。
我们作个类比，这种不精确的架构，就好比建筑工程中，设计师画了一个效果图，没有任何尺寸和关键细节的确认，然后大家就分头开工了。最后放在一起拼接（联调），发现彼此完全没法对上，只能临时修修改改，拼接得上就谢天谢地了。是不是能够和当初效果图匹配？让老天爷决定吧。
更精确描述架构的方法是定义每个模块的接口。接口可以用代码表达，这种表达是精确的、无歧义的。架构图则只是辅助模块接口，用于说明模块接口之间的关联。
尊重契约，尊重共识精确的、无歧义的表达，非常非常重要。
绝大部分哪怕是非常优秀的架构师，在系统设计（也叫概要设计）阶段通常也只会形成系统的概貌，把子系统的划分谈清楚，把子系统的接口规格谈清楚。
但实际上概要设计阶段最好的状态并不是只有设计文档。
为了降低风险，系统设计阶段也应该有代码产出。
这样做有两个方面的目的。其一，系统的初始框架代码。也就是说，系统的大体架子已经搭建起来了。其二，原型性的代码来验证。一些核心子系统在这个阶段提供了 mock 的系统。
这样做的好处是，一上来我们就关注了全局系统性风险的消除，并且给了每个子系统或模块的负责人一个更具象且确定性的认知。
代码即文档。代码是理解一致性更强的文档。
结语这一讲我们谈的是协同的科学。为什么有的团队效率极高，有的团队却进展缓慢，从背后的协同效率来说，共识管理是根因中的根因。
共识有非常多的层次。不同层次的共识处于完全不同的维度。它们都极其重要，且相互不可替代。当某个层次的共识出问题的时候，我们需要在相应的层次去解决它。
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们谈谈 “怎么写设计文档”。原计划我们下一讲是 “如何阅读别人的代码”，但是我想先顺着共识这个话题谈问题谈清楚。
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 9

提建议

68 | 软件工程的宏观视角

70 | 怎么写设计文档？

 写留言

精选留言(11)

沉睡的木木夕
2020-03-27
架构共识真的太重要了，这个跟个人素养有直接关系。为了赶所谓的进度，写的 curd，是我至今为止看到最惨不忍睹的。插入，修改，删除没有任何验证，插入没有判断重复，字段业务逻辑关系（逻辑外建）都没有。还是从业10来年的人，而且这些 api 还是公司平台的，我指出了问题所在，居然还跟我说这事先放放，没时间改。我司同事天天说忙，又不见加班修复这些问题。项目再赶我都不会这么放宽自己，这就是原则问题，那样做相当于没做。真的希望我能早日成为带动整个团队素养的一员。（如果还不见有所改动，只能自己抽时间改一点是一点）
展开
12
Jxin
2019-12-31
1.个人意愿上的共识。应以愿景，使命以及文化为落地方向。 2.业务理解上的共识。正如ddd里面提出的，通用术语的概念，应以打破筒仓相互了解为方向。
5
py
2019-12-31
系统设计阶段也应该有代码产出。这句不太理解，如果各个子系统根据功能需求差异可能用不同的语言实现，这样就是简单地代码也比较费事啊，感觉把每个模块的主要api文档写出来不挺好的么
作者回复: 理想情况下要有代码，没有但如果能够把api精确表达，已经是极其优秀的了
5
有铭
2019-12-31
所有的学科到了一定阶段就是在谈哲学，比如这章
3
丁丁历险记
2019-12-31
早上晨读，如沐春风。设计强调规格，架构强调实现。规格设计是架构过程的最高共识。所以，规格高于实现。我们用架构的全局性和系统性思维去做设计。
2
Longerian
2020-02-27
这两天正好在给团队出方案、出设计，也恰好看到了这几章架构思维。真是深有感触，我自己也学着按照作者的方法论去要求自己。关于团队共识、以原型代码来给出精确描述，这几点真是深有感触，非常重要。这几篇值得反复品、细细品。
2
WadeYu
2019-12-31
共识是团队凝聚力的基础，怎么提高团队共识呢，靠制定各种规范以及规章制度?
作者回复: 共识是为了更高的决策效率，所以共识可以是使命愿景价值观，可以是决策原则，等等。
共 2 条评论
1
Jeyrce.Lu
2022-04-06
技术人员有时候其实很偏执，基本上都有自己的洁癖，因此想要说服别人其实不是一件简单的事情
哲
2021-11-14
共识不能沉迷于自己把问题讲的很清楚了，可能团队的成员还处于一团雾水。在没有直接反馈的情况下，形成共识文档就显得至关重要，文档的要求要足够的精确的细致且具有可操作性。而架构图个人理解在于理清思路，关注点更上层一些。
何磊
2020-07-23
这种约定对于新项目非常适合，对于历史悠久的老项目，很难做到代码即文档，因为太多的历史包袱代码已经没有办法阐述清楚并形成干扰！
Aaron Cheung
2019-12-31
醍醐灌顶人是愿景型动物，需要看到未来。越高级的人才越在乎团队存在的意义。所以高科技公司的人才通常只能去影响，而不是像一些人心中理解的那样，认为管理是去控制。

