16 通用技能（上）：如何帮助团队达成共识与控制风险？
你好，我是郭东白。在模块导读中我们提到了，架构师在架构活动中所发挥的关键作用主要有四个：建设共识、控制风险、保障交付和沉淀知识。这也是架构师创造价值所必备的四项基本能力。
这节课，我们先来讲前两项能力，看看架构师该如何帮助团队迅速达成共识、如何控制与面对风险。
建设共识
在互联网时代，我们面临着三个与沟通交流相关的重要挑战：
- 分布式研发：日常工作中相对隔离的微服务研发模式；
- 沟通障碍：分散在全球或全国多地的研发团队，以及由此带来的语言、文化和沟通障碍；
- 认知差异：由于职能、工作背景不同而造成的认知差异，尤其是由于视角局限而带来的认知差异。
这意味着架构师需要克服上述挑战，推动参与者对架构活动形成共识。具体来说，这些共识包括目标、决策环境、架构语言、各自的责任边界和交付时间、交付内容和交付质量以及资源分配。
共识，在架构活动的上下文里，就是尽可能让多的人在限定时间里达成一致。很多人误以为共识就是投票，让少数服从多数。其实不然。投票是个表面公平，但其实非常暴力的决策方式。它是在参与者无法达成共识的情况下，依然要获得一个决策的办法。而共识的目标并不是达成一个决策，而是让尽可能多的参与方认可一个决策。
我曾经为甲骨文、微软和亚马逊三家公司，在不同领域参与了十年的国际标准制定工作，参加过多场标准制定的相关会议。国际标准的制定过程，实际上是多个竞争对手之间进行博弈和合作的过程，是一个艰难的建设共识的过程。在这个过程中，我掌握了一些方法和技巧，也发现这些方法几乎可以完全平移应用到架构活动中。接下来我就来分享一下。
达成一致的关键在于找到架构活动参与方的认知差异点，然后再想办法消除。认知差异点的来源主要有三个方面。
首先是利益不同。假设你负责一个国际化的电商中台项目，其中有一个钱包重构的环节。那么你需要重新划分责任边界，将之前印度业务所属团队的钱包服务，变成一个通用的服务。然后再交给一个新加坡的钱包中台团队，分享给全球其他的国家。这样一来，新加坡的钱包中台团队、印度的钱包团队和其他国家的交易支付团队，这三者的服务边界就发生了变化，相关研发人员的利益也会受到影响。
其次是视角不同。架构师往往是从整个架构活动的视角出发，但其他参与者只会从各自团队的视角出发。比如一个国际化中台团队会认为，中台值得每个前台业务和中台研发人员呕心沥血来保障交付。但是对于每个参与者来说，你的架构项目只是他们诸多需求中的一个。
最后是其他的内在差异。比如因为职能、工作背景和语言文化的不同，也会带来认知上的差异。
这三种差异点的应对办法完全不同，其中利益差异最难解决。我们就从这里开始讲起。
简单来说，我们必须理解参与者的核心利益诉求，最终在一个相对公平且可以长期维持的机制下做利益边界的划分。
还是刚才的例子。表面上，印度的研发同学可能是对自己亲手研发的钱包服务割舍不下。不够这里可能还有其他更深层的理由，比如他觉得自己的职业发展受到了伤害。虽然你的决策也有合理的解释，但他会更看重企业未来到底靠什么机制来保障他的权益。
其实解决方案也很简单，就是将利益分配与价值创造相匹配。
一般来说，发明创造者应该是最大利益的获得者。当然可能有多个团队共同孵化了同一个服务，也有可能发明者并不是处于未来价值创造的核心团队。这个时候，就需要你做一个取舍。不过这个取舍机制，应该能同时保障创新和价值创造可以长期持续。
比如说基于市场选择的赛马机制或者基于顶层战略决策的机制。不论最终选择什么机制，必须要公开公平，要保障发明者和企业的利益。而忽略机制公平性的做法，结果就会像我们在法则二里描述的那样，最终会成为一个没有人性的机制。
我的经验是，多数产品研发人员是理智的。他们能接受一个全局最优、但伤害到他暂时利益的解释。尤其是你以某种方式，对他的受损利益给予补偿的时候。而且大多数时候，这种补偿只需要在公司层面对他的贡献进行公开认可就行了。有了这种认可，接下来再跟其他参与者建设共识就轻而易举得多了。
接下来再来说视角差异怎么解决。架构师作为企业层面的架构活动的组织者，肯定会从企业层面去看每个参与者的决策优先级。很多架构师经常抱怨某个研发人员或团队主管缺乏全局视角。但试问，又有几个架构师能看到团队的局部视角呢？
如果期望合作团队能从全局视角开发，那么作为架构师，就必须看到对方的局部视角。只有充分考虑到局部视角，你才有机会设计出一个包容的架构规划，才有可能让更多的人达成共识。
举个例子，国际化电商业务经常碰到的统一架构问题，就属于这种全局视角和局部视角之间的冲突。经常有国家本地化团队开发一套自己的前端组件，导致企业没有一致的品牌形象、没有统一埋点和数据标准，浪费研发资源。
在这种场景中，我们在建设全球团队的共识之前，必须要理解局部视角。你可以尝试向团队了解一下这几个问题：
- 当初泰国的业务团队为什么会选择自建，而不是依赖全球化的组件呢？组件原生支持泰文吗？
- 文字太长怎么办？设计中留了显示重音和声调符号的空间了吗？如果显示不正确，组件怎么修复呢？
- 全球化团队愿意承接定制化的需求吗？有读懂泰文的测试同学吗？
如果不能回答这些问题，那么你试图说服泰国团队采用一个没有本地化成功经验的全球组件，就是件非常艰难的事情。
如果一个架构师缺乏这样的局部视角，直接宣称国家团队的前端组件都是重复造轮，那他将很难推动大家达成共识。而当你有了这些局部视角，并努力为这些问题寻找满意的答案。哪怕你无法跟泰国前端团队达成共识，但是负责泰国业务的CEO、有巨大成本压力的泰国CFO，肯定会跟你站在同一立场上的。
最后我们讲讲如何在有内在差异的情况下达成共识。一般来说， 由于职能和工作背景导致观点不同，这种情况比较常见。最好的解决办法就是跟每个参与者都进行一次深度对谈，并针对对方的疑惑做专门的解答。如果时间紧张，也可以把一组背景相似的人组织起来，做专门的沟通。
由于语言和文化不同也会带来认知上的差异，相对来说比较难解决。架构活动的交付时间压力一般都非常大，不足以将语言和文化背景不同的人融合到一起。
我见过有个公司，花费巨额成本将不同国家研发中心的人召集到一个地方去完成项目。事实上，效果远没有想象中的好。在巨大交付压力下，把本来就缺乏了解和尊重的人放在一个密闭的小空间，冲突更容易爆发。实际情况也确实如此。这个项目进行到后期，有超过75％的弱势群体都离职了。所以我的建议是，先在少数意见领袖中建立共识，让他们去影响和说服其他人。
讲到这里你可能认识到了：建设共识其实是个体力活。如果只做表面工作，拿一套PPT或者价值观来侃侃而谈，可能只需要半天时间。但如果想真正了解一个人的内心利益诉求，就需要在日常工作中下大量的功夫，建立信任关系。而且场景越复杂，人越多，那么需要投入的成本就越大。所以建设共识这件事，功夫要下在平时，而不是架构活动开始的时候。
我还见过一种人，他们的目的不是达到共识，而是骗取共识。也就是用虚假承诺让利益损失方接受方案，然后在架构活动结束后再抛弃他们。这么做，他们的架构目标的确达到了。但是容忍他们这么做的企业，最终在市场上只能惨淡经营。这可能是个概率上的偶然事件，不过我更想把它看作是个必然事件。一个没有道义的企业会选择错误的人，做错误的事，最终只能被自己的客户所抛弃。
当然架构活动中的参与方不同于制定国际标准的竞争者。参与者的基本利益还是一致的，因为大家都希望企业能发展壮大。所以相对国际标准来说，架构活动就不需要流程和制度的约束，达成共识的过程中也不需要大量的投票。
控制风险
风险，在架构活动的上下文里，指的是有可能带来损失的不确定事件。
举个例子，安全攻击就是一种风险。首先，攻击不一定会发生。而且一旦发生，有可能现有的防范措施就已经足够了，不会造成大的损失。但是，攻击也有可能会造成雪崩或者用户信息泄露，带来直接的经济损失和巨大的品牌损失。所以我们一般说风险足够大，是指不确定性事件发生的概率和一旦发生之后带来的损失同时都很大。
架构师要面对互联网企业在不确定性的商业环境、日常工作缺乏流程、团队成员高强度工作节奏和日常反射式研发所带来的混乱和质量问题。所以在架构活动的全生命周期里，架构师都需要持续收集、发现、评估和控制风险，把风险控制在可以接受的范围内。
具体怎么做呢？有三个关键动作：逐渐形成量化认知，可以冒险，但不能不说。
第一个关键动作是逐渐形成量化认知。发现和评估风险是个极其耗时间的过程。在互联网企业，不仅每天都有新风险，而且现有的风险还在不断变化。要是把风险评估作为一次性的前置环节，不仅会占用大量宝贵时间，也不能有效控制风险。
所以成本更低的做法是搭车制。意思就是架构师要在架构活动中持续预留一部分的带宽，比如5%的精力。任何时候都先关注已知的最大风险，然后随着时间的推移，不断对这些风险形成更深刻的认知。而这些更深刻的认知，最终也将转化成一个能够准确量化的风险控制成本和企业的预期损失。
举个例子，电商平台大促会面临各种营销风控的风险。我们不需要一上来就做大面积的梳理，而是先对不同类目的风险等级做区分，再针对高危类目的投诉、PR、诉讼等风险做梳理，最后挑出风险最大的几个做预案和量化评估。这么一来，我们很快就能对整体风险的数量级形成准确评估了。
这样的风险控制才是可持续的。在有限的带宽下，我们始终都要把团队有限注意力引导在最大的几个风险点上，而不是分散注意力。
第二个关键动作，可以冒险。在架构活动中，如果我们发现了一个风险，也对损失有了一定的预估，并准备好了预案以响应不确定性事件。这个时候，就可以“冒一次有准备之险”。
为什么要这么做呢？如果企业能接受预估的损失，如果风险预案的成本与预估损失差别不大。那么当我们选择忽视这个不确定性事件的话，既可以省下宝贵的研发资源，投入到更紧急的需求中去。还能让我们获得宝贵的时间资源，有机会以更快的速度去做业务迭代。
纵观早期的互联网公司，都是在速度上抢先于监管和竞争对手，所以才积累下了海量的用户、行为数据和财富，进而获得了更高的增速。可以说，冒险是互联网公司的重要共同特征。
第三个关键动作是不能不说。架构师的权责，还没有大到可以代替公司去决定风险政策的地步，所以必须向上及时传递重大风险和冒险行为，而不是直接采取冒险行为。。
一旦决定采取逐渐形成量化认知的策略，那么就要准确感知即将到来的风险变化。大多数时候风险是连续的，但是监管政策的大幅调整、公司上市、经济环境的变化、黑天鹅事件等等，都会让风险产生大幅变化。一旦风险升级，你就可以试图控制风险，寻找有效的控制手段和响应预案。并对效果做一定程度的验证，提升团队对风险变化的响应能力。
如果没有找到有效的控制手段，而风险又很大，那么最好的办法就是及时向决策者、赞助人汇报，告知风险。同时也要向合作方传递风险预警。
你可能会问：在互联网企业做大规模的架构活动，本来就是高风险、高强度的。这么高的不确定性之下，肯定会有各种突发情况。公司的项目目标和不合理排期都是自上而下的，我作为架构师，为什么要承担这种传递风险的压力呢？再说了，如果整个公司都是报喜不报忧。要是我第一个传递了，公司第一个淘汰的就是我啊！
如果真是这样，如果你选择不说，那么第一天淘汰的肯定还是你。因为老板们这么做也有正当理由：你作为架构师，就处在风险的汇聚点。知道风险却还隐瞒风险，真的对吗？
小结
今天我们讲了建设共识这个软技能，这是职场上非常关键的一项软技能，也是成为领导者的基本能力。
在日常工作中，架构师会有很多建设共识的训练机会。这是你的职能福利，一定要利用好。关于这个话题，市面上有很多相关的书籍。不过在建设共识这件事上，读书，远远比不上你在实际项目中的实际锻炼。
除此之外，我还想强调一个观点，那就是明智的冒险会带来价值的回报。冒险是有代价的，但我们作为架构师就是要对这个代价了然于胸。在互联网时代，竞争的压力意味着我们永远都不会有充足的时间去量化风险和设计预案。所以对风险的判断，是一项非常有价值的个人能力。而架构活动的过程，就是你提升这项能力的重要机会。我相信，随着你的不断实践，对风险的判断力一定会大幅提升的。
思考题
三个思考题，任选一个：
- 架构活动中某个人或团队的利益被忽视，你是否有类似的经历呢？最终的结果如何呢？是什么原因导致的呢？如果你是这个项目的架构师，你会怎么做呢？
- 在日常生活中，你有没有积累一些建设共识的小技巧呢？适用于架构活动吗？
- 冒险有两种情况。一种是值当的，就是风险本身是暂时的。随着企业的成长，风险带来的损失逐步降低。所以一旦冒险成功，那么这个风险的损失就可以被忽略掉。这意味着你冒一次险就行了，之后一帆风顺。反过来，有些冒险是艰难的，就是风险本身是增长型的。随着企业的成长，风险带来的损失逐步增多, 就像达摩克里斯之剑一样。针对这两种情况，你能举一些例子吗？从中能得出什么结论吗？
如果这节课对你有帮助，欢迎你把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！
- 术子米德 👍（14） 💬（4）
🤔☕️🤔☕️🤔 * 🤔：建立共识，特别难，一起跳到坑里，再一起爬出来，就会先建立大家都不容易的共识，然后才会对新目标，更容易产生共识，尤其是大家会觉得，要不一起先干一把，再回头看到底是怎么回事。 * 🤔：一直在推进嵌入式设备的软件模块进行UT的事情，一开始根本没人搭理，怎么说都觉得怎么可能。一方面没有直接经验，另一方面拿着设备调试惯了，经常要出现所谓联调，尽管效率低，这么多年还不是这么过来。后来我自己开始实践，写完模块写UT，发现UT不难写，但是设计怎样的UT，从哪些维度思考的UT，才能让模块真的在联调前达到预期质量，真需要实践和思考，才会掌握到位。可是我说给大家听，还是仅点头，不会自己动手。后来抓住机会，在某个项目里实践起来，真正体感到，原来自己UT通过，只要UT设计合适，就是能够一把冒烟测试通过。有了这种惊奇的直接经验，才会到处去传播。 * 🤔：所以说，共识，要自己认识到，要自己体验到，要别人认识到，要别人体验到，那才能真正产生共识。
2022-03-01 - 罗均 👍（10） 💬（2）
感谢老师精彩的课程，看到老师的最后一个问题，非常感触，感觉这不仅是企业组织的问题，更是社会的问题。最被忽视的群体，往往是固步自封的个人或组织，例如改革开发导致了无数的小国企倒闭，无数国企工人下岗。能够做的，或许只能学习小平同志，首先自己“解放思想，实事求是”，然后帮助暂时落后的群体“解放思想，实事求是。” 例如在传统车厂，特斯拉时代的到来导致车内大量的开关（按键）零件被取消——由中控娱乐主机的显示屏软件化集成。这就不仅需要企业在方方面面帮助原来这些被淘汰的零件的责任工程师转型，更需要面临危机的工程师自寻破局之路。
2022-02-24 - 术子米德 👍（7） 💬（2）
🤔☕️🤔☕️🤔 * 🤔：利益被忽视，太常见，常见到都不敢去正视。个人觉得，虽然这里用了被字，但实际上也有活该，甚至可以说该死才忽略。作为个人，一直勤奋工作，当然得竖起大拇指，但如果不思考自己的价值，不思考自己的成长，不思考所处的环境跟自己的匹配，可以用比较实在来形容，但是更应该用责任感差来形容。每个人都不会一辈子只有一把键盘和一盒泡面，一定会经历上有老下有小的生活。尤其是已经在这个过程里，还让自己躲在老实人的外壳下，那被忽视不是他还是谁。所以我反而觉得，被忽视一次正常，反复被忽视，迟早会被当头棒喝。
2022-03-01 - BIZ_UI_3 👍（6） 💬（1）
这篇其实主要讲的是与人沟通，是道，而不是术。我认为它更像是一节情商课。同样，可能也只有有情商的人才能落地这节课的内容。。。
2022-02-23 - Geek_sa2mt4 👍（5） 💬（1）
结合思考题说下个人感受吧 思考题1：说下之前公司金融域重构的事情。 要重构的是整个金融域，规模还是很大的。要重构的目的除了语言上融入新公司，还有就是业务需要，之前的架构已经不太好应对日益增长的单量了，需要更新更事实的架构。 这个项目最终上线了，不过由于老人几乎走光，给项目带来了很大的阻力。 走的原因是，架构师招了一批Java同学来重构系统，新老系统并行开发，python的同学觉得自己在这边得不到发展，而且当时python在上海还是有市场的，就差不多走了。 当时对这位架构师最不满的是招了Java同学，后来私下里问过这位架构师当初招Java同学的决策，说是感觉到python同学要走，想加快进度，没想到走得更快。 我也能感觉到当时的大环境很难留住这些python同学了，但在上面的压力下重构又不得不做，不知道东白老师碰到这种情况会怎么处理？ 思考题2 我理解的建设共识的过程是一个利益交换的过程，一个leader说的话给我的印象很深，他教我要发现身边同学的欲望，从欲望触发做利益交换，这人只要有欲望，就有办法做利益交换。我觉得这事也适用于架构活动建立共识，如果这人的欲望不在工作中，也可以是生活中的，比如迁根红线，违法犯罪违背道德的事情不能干。这样没准后面还能成为好哥们，相关事情也会更好推。 补充下这事的背景，就是当时这位leader想推UT，我问他怎么推动事情时，他跟我说的，我问他如果一个人没有欲望怎么办？他说这种人他不会招。不过UT这事还是推失败了。 思考题3 看到题目我就想到了之前的打车市场的优惠券大战。各公司参战时都觉得是一时的冒险，但后来大家都这么干了，就成了增长型的冒险了。冒险的性质不是不变的，可能及时识别风险，控制风险，及时止损更重要些
2022-09-19 - ， 👍（3） 💬（1）
相较于老师讲的场景与方法,老师做人的道德更令我敬佩,确实,成为一个可信赖的人是做成事的基础,老师的课是我今年最大的收获,这课我买赚了。
2022-04-27 - 亚林 👍（2） 💬（1）
所谓善人，人皆敬之，天道佑之，福禄随之，众邪远之，神灵卫之；所作必成，神仙可冀。
2022-04-28 - Geek_42abae 👍（1） 💬（1）
建设共识这块，我根据可观测项目进行的总结 https://mp.weixin.qq.com/s/jCnzsrcqwXOkK7zfRzV0Og
2022-10-30 - Geek_42abae 👍（1） 💬（1）
我目前负责可观测系统建设，其中一个目的就是当线上某个业务不正常时，能够通过数据观测到哪里出了问题。早先是各个部门各搭烟囱，自扫门前雪，一个问题需要几个部门的人挨个利用自己的工具分析排除，信息不共享，效率低。我想形成all-in-one的共识。我会充分考虑参与者的利益，合作后参与者有什么好处，为参与者着想。这样会稍微顺畅一些
2022-10-09 - CheungQ 👍（1） 💬（1）
捉个虫，“不够(过)这里可能还有其他更深层的理由” 另外，刚开始看，个人理解，“建设共识、控制风险、保障交付和沉淀知识” 这4个部分感觉分别对应， “建设共识”：项目开始前统一目标，确定方向 “控制风险”：项目开始前也有风险，需要确定规避，更多的是过程中的风险 “保障交付”：保证项目完美交付上线 “沉淀知识”：项目交付完成后需要累积经验，除了前面的代码服务，还要有知识库的内容完善 其实感觉和PMP的体系也非常相像
2022-03-15 - 术子米德 👍（1） 💬（1）
🤔☕️🤔☕️🤔 * 📖：互联网时代三个沟通类挑战：分布式研发、沟通障碍、认知差异 * 🤔：技术因素（硬功夫）、距离因素（硬限制）、经验因素（硬缺失） * 🤔：功夫软可以练习，在犯错中不断总结反思，在技术的可用、实用和好用之间得到自己的体感，才能加深技术的理解，也才能真正掌握技术。这时候沟通，眼看着成长起来。 * 🤔：距离远可以改进，在冷淡和摩擦中寻找和确定共同目标，围绕着越来越清晰的目标，信任和好感也会滋养起来。这时候沟通，持续在往期望的方向发展。 * 🤔：经验缺最是难办，工程类的经验倒还有机会弥补，认知类的经验，真的就像砖石版的玻璃罩子，眼巴巴得无法突破。其实知道自己头皮已经顶住罩子，努力想突破已经算踏出关键一步，更多是背靠着罩子，来个垂直版躺平，那真是恨铁就是铁，只会慢慢生锈。这时候沟通，人家什么都懂，就是左耳右耳都听不进去。 * 🤔：共识未达成，想尽办法找出差异点，逐步达成共识，这时候的共识反而比较牢靠。本来比较信任，对某件事情快速达成共识，期间忽然因某个利益点产生分歧，就像装水的气球，一钉就破，而且难以修复。这么说来，对未达成的共识，要报以耐心，对于快速达成的共识，要提高警惕。
2022-03-01 - Alex 👍（1） 💬（1）
把相关人员提前拉入共识决策得过程。先明确目标在大家一起讨论方案。相对于突然拿出个方案去建立共识更容易些
2022-02-27 - 磊 👍（1） 💬（1）
个人工作中遇到的和团队建立共识的方式： 1，首先，要有一个自上而下的宣导动作，让团队成员对项目的背景和决策过程有一个统一的认知，一般情况下项目的决定如果符合公司预期的战略目标，在宣导的时候，就会有一部分人达成了共识。当然正如郭老师所说，考虑各方的利益是必须的，不然就一定会有阻力。 2，其次，在接下来的一段时间，就可以跟各利益相关方详细沟通，各个击破。 3，最后，如果真的无法建立共识，那只能各自好走。
2022-02-23 - 欧阳绍聪 👍（1） 💬（2）
在推广多媒体中台的时候，能看到有很多复用的东西，也有心打造自研技术进一步降低成本。可是整体上忽视了各业务部门的差异性，只考查秀场模式，整体框架只服务成形稳定的主版业务，不能很好支持创新业务的快速试错，泛化能力太差，最后的结果是失败，中台部门只留下维护的几个人。 这里应该是一开始就是目标错误，完全忽视了创新业务的利益，在落地推广的过程中，也没达成共识，自上而下强推，没有创造价值反而拖了时间成本，中台业务的架构展开视角没能从全局出发。中台应该是抽象成同类型业务的，而公司层面上就不会展开与主版相似相同的业务，探索创新业务也尽量避免直接竞争，换做是我处理，那是一开始就不会做这个事情，而是专注于多媒体组件化，流质量提升上。
2022-02-23 - peter 👍（1） 💬（2）
请教郭老师两个问题： Q1：现在“中台”是不是不行了？前一段很火，近期看到几篇文章，说“中台已死”一类的话。 Q2：大型互联网公司的最前面入口是什么？ 在讲互联网架构的书籍和专栏中，会提到用户请求到达的第一个设备，比如Nginx、F5等等。 即便快如F5，其处理能力也是有限的，根本无力承担阿里这样的流量。那么，最前面的入口是怎么解决大流量的？ 难道说有多个入口？如果是多个入口，是怎么实现的？
2022-02-22