你好，我是郭东白。在模块导读中我们提到了，架构师在架构活动中所发挥的关键作用主要有四个：建设共识、控制风险、保障交付和沉淀知识。这也是架构师创造价值所必备的四项基本能力。
这节课，我们先来讲前两项能力，看看架构师该如何帮助团队迅速达成共识、如何控制与面对风险。
建设共识
在互联网时代，我们面临着三个与沟通交流相关的重要挑战：
- 分布式研发：日常工作中相对隔离的微服务研发模式；
- 沟通障碍：分散在全球或全国多地的研发团队，以及由此带来的语言、文化和沟通障碍；
- 认知差异：由于职能、工作背景不同而造成的认知差异，尤其是由于视角局限而带来的认知差异。
这意味着架构师需要克服上述挑战，推动参与者对架构活动形成共识。具体来说，这些共识包括目标、决策环境、架构语言、各自的责任边界和交付时间、交付内容和交付质量以及资源分配。
共识，在架构活动的上下文里，就是尽可能让多的人在限定时间里达成一致。很多人误以为共识就是投票，让少数服从多数。其实不然。投票是个表面公平，但其实非常暴力的决策方式。它是在参与者无法达成共识的情况下，依然要获得一个决策的办法。而共识的目标并不是达成一个决策，而是让尽可能多的参与方认可一个决策。
我曾经为甲骨文、微软和亚马逊三家公司，在不同领域参与了十年的国际标准制定工作，参加过多场标准制定的相关会议。国际标准的制定过程，实际上是多个竞争对手之间进行博弈和合作的过程，是一个艰难的建设共识的过程。在这个过程中，我掌握了一些方法和技巧，也发现这些方法几乎可以完全平移应用到架构活动中。接下来我就来分享一下。
达成一致的关键在于找到架构活动参与方的认知差异点，然后再想办法消除。认知差异点的来源主要有三个方面。
首先是利益不同。假设你负责一个国际化的电商中台项目，其中有一个钱包重构的环节。那么你需要重新划分责任边界，将之前印度业务所属团队的钱包服务，变成一个通用的服务。然后再交给一个新加坡的钱包中台团队，分享给全球其他的国家。这样一来，新加坡的钱包中台团队、印度的钱包团队和其他国家的交易支付团队，这三者的服务边界就发生了变化，相关研发人员的利益也会受到影响。
其次是视角不同。架构师往往是从整个架构活动的视角出发，但其他参与者只会从各自团队的视角出发。比如一个国际化中台团队会认为，中台值得每个前台业务和中台研发人员呕心沥血来保障交付。但是对于每个参与者来说，你的架构项目只是他们诸多需求中的一个。
最后是其他的内在差异。比如因为职能、工作背景和语言文化的不同，也会带来认知上的差异。
这三种差异点的应对办法完全不同，其中利益差异最难解决。我们就从这里开始讲起。
简单来说，我们必须理解参与者的核心利益诉求，最终在一个相对公平且可以长期维持的机制下做利益边界的划分。
还是刚才的例子。表面上，印度的研发同学可能是对自己亲手研发的钱包服务割舍不下。不够这里可能还有其他更深层的理由，比如他觉得自己的职业发展受到了伤害。虽然你的决策也有合理的解释，但他会更看重企业未来到底靠什么机制来保障他的权益。
其实解决方案也很简单，就是将利益分配与价值创造相匹配。
一般来说，发明创造者应该是最大利益的获得者。当然可能有多个团队共同孵化了同一个服务，也有可能发明者并不是处于未来价值创造的核心团队。这个时候，就需要你做一个取舍。不过这个取舍机制，应该能同时保障创新和价值创造可以长期持续。
比如说基于市场选择的赛马机制或者基于顶层战略决策的机制。不论最终选择什么机制，必须要公开公平，要保障发明者和企业的利益。而忽略机制公平性的做法，结果就会像我们在法则二里描述的那样，最终会成为一个没有人性的机制。
我的经验是，多数产品研发人员是理智的。他们能接受一个全局最优、但伤害到他暂时利益的解释。尤其是你以某种方式，对他的受损利益给予补偿的时候。而且大多数时候，这种补偿只需要在公司层面对他的贡献进行公开认可就行了。有了这种认可，接下来再跟其他参与者建设共识就轻而易举得多了。
接下来再来说视角差异怎么解决。架构师作为企业层面的架构活动的组织者，肯定会从企业层面去看每个参与者的决策优先级。很多架构师经常抱怨某个研发人员或团队主管缺乏全局视角。但试问，又有几个架构师能看到团队的局部视角呢？
如果期望合作团队能从全局视角开发，那么作为架构师，就必须看到对方的局部视角。只有充分考虑到局部视角，你才有机会设计出一个包容的架构规划，才有可能让更多的人达成共识。
举个例子，国际化电商业务经常碰到的统一架构问题，就属于这种全局视角和局部视角之间的冲突。经常有国家本地化团队开发一套自己的前端组件，导致企业没有一致的品牌形象、没有统一埋点和数据标准，浪费研发资源。
在这种场景中，我们在建设全球团队的共识之前，必须要理解局部视角。你可以尝试向团队了解一下这几个问题：
- 当初泰国的业务团队为什么会选择自建，而不是依赖全球化的组件呢？组件原生支持泰文吗？
- 文字太长怎么办？设计中留了显示重音和声调符号的空间了吗？如果显示不正确，组件怎么修复呢？
- 全球化团队愿意承接定制化的需求吗？有读懂泰文的测试同学吗？
如果不能回答这些问题，那么你试图说服泰国团队采用一个没有本地化成功经验的全球组件，就是件非常艰难的事情。
如果一个架构师缺乏这样的局部视角，直接宣称国家团队的前端组件都是重复造轮，那他将很难推动大家达成共识。而当你有了这些局部视角，并努力为这些问题寻找满意的答案。哪怕你无法跟泰国前端团队达成共识，但是负责泰国业务的CEO、有巨大成本压力的泰国CFO，肯定会跟你站在同一立场上的。
最后我们讲讲如何在有内在差异的情况下达成共识。一般来说， 由于职能和工作背景导致观点不同，这种情况比较常见。最好的解决办法就是跟每个参与者都进行一次深度对谈，并针对对方的疑惑做专门的解答。如果时间紧张，也可以把一组背景相似的人组织起来，做专门的沟通。
由于语言和文化不同也会带来认知上的差异，相对来说比较难解决。架构活动的交付时间压力一般都非常大，不足以将语言和文化背景不同的人融合到一起。
我见过有个公司，花费巨额成本将不同国家研发中心的人召集到一个地方去完成项目。事实上，效果远没有想象中的好。在巨大交付压力下，把本来就缺乏了解和尊重的人放在一个密闭的小空间，冲突更容易爆发。实际情况也确实如此。这个项目进行到后期，有超过75％的弱势群体都离职了。所以我的建议是，先在少数意见领袖中建立共识，让他们去影响和说服其他人。
讲到这里你可能认识到了：建设共识其实是个体力活。如果只做表面工作，拿一套PPT或者价值观来侃侃而谈，可能只需要半天时间。但如果想真正了解一个人的内心利益诉求，就需要在日常工作中下大量的功夫，建立信任关系。而且场景越复杂，人越多，那么需要投入的成本就越大。所以建设共识这件事，功夫要下在平时，而不是架构活动开始的时候。
我还见过一种人，他们的目的不是达到共识，而是骗取共识。也就是用虚假承诺让利益损失方接受方案，然后在架构活动结束后再抛弃他们。这么做，他们的架构目标的确达到了。但是容忍他们这么做的企业，最终在市场上只能惨淡经营。这可能是个概率上的偶然事件，不过我更想把它看作是个必然事件。一个没有道义的企业会选择错误的人，做错误的事，最终只能被自己的客户所抛弃。
当然架构活动中的参与方不同于制定国际标准的竞争者。参与者的基本利益还是一致的，因为大家都希望企业能发展壮大。所以相对国际标准来说，架构活动就不需要流程和制度的约束，达成共识的过程中也不需要大量的投票。
控制风险
风险，在架构活动的上下文里，指的是有可能带来损失的不确定事件。
举个例子，安全攻击就是一种风险。首先，攻击不一定会发生。而且一旦发生，有可能现有的防范措施就已经足够了，不会造成大的损失。但是，攻击也有可能会造成雪崩或者用户信息泄露，带来直接的经济损失和巨大的品牌损失。所以我们一般说风险足够大，是指不确定性事件发生的概率和一旦发生之后带来的损失同时都很大。
架构师要面对互联网企业在不确定性的商业环境、日常工作缺乏流程、团队成员高强度工作节奏和日常反射式研发所带来的混乱和质量问题。所以在架构活动的全生命周期里，架构师都需要持续收集、发现、评估和控制风险，把风险控制在可以接受的范围内。
具体怎么做呢？有三个关键动作：逐渐形成量化认知，可以冒险，但不能不说。
第一个关键动作是逐渐形成量化认知。发现和评估风险是个极其耗时间的过程。在互联网企业，不仅每天都有新风险，而且现有的风险还在不断变化。要是把风险评估作为一次性的前置环节，不仅会占用大量宝贵时间，也不能有效控制风险。
所以成本更低的做法是搭车制。意思就是架构师要在架构活动中持续预留一部分的带宽，比如5%的精力。任何时候都先关注已知的最大风险，然后随着时间的推移，不断对这些风险形成更深刻的认知。而这些更深刻的认知，最终也将转化成一个能够准确量化的风险控制成本和企业的预期损失。
举个例子，电商平台大促会面临各种营销风控的风险。我们不需要一上来就做大面积的梳理，而是先对不同类目的风险等级做区分，再针对高危类目的投诉、PR、诉讼等风险做梳理，最后挑出风险最大的几个做预案和量化评估。这么一来，我们很快就能对整体风险的数量级形成准确评估了。
这样的风险控制才是可持续的。在有限的带宽下，我们始终都要把团队有限注意力引导在最大的几个风险点上，而不是分散注意力。
第二个关键动作，可以冒险。在架构活动中，如果我们发现了一个风险，也对损失有了一定的预估，并准备好了预案以响应不确定性事件。这个时候，就可以“冒一次有准备之险”。
为什么要这么做呢？如果企业能接受预估的损失，如果风险预案的成本与预估损失差别不大。那么当我们选择忽视这个不确定性事件的话，既可以省下宝贵的研发资源，投入到更紧急的需求中去。还能让我们获得宝贵的时间资源，有机会以更快的速度去做业务迭代。
纵观早期的互联网公司，都是在速度上抢先于监管和竞争对手，所以才积累下了海量的用户、行为数据和财富，进而获得了更高的增速。可以说，冒险是互联网公司的重要共同特征。
第三个关键动作是不能不说。架构师的权责，还没有大到可以代替公司去决定风险政策的地步，所以必须向上及时传递重大风险和冒险行为，而不是直接采取冒险行为。。
一旦决定采取逐渐形成量化认知的策略，那么就要准确感知即将到来的风险变化。大多数时候风险是连续的，但是监管政策的大幅调整、公司上市、经济环境的变化、黑天鹅事件等等，都会让风险产生大幅变化。一旦风险升级，你就可以试图控制风险，寻找有效的控制手段和响应预案。并对效果做一定程度的验证，提升团队对风险变化的响应能力。
如果没有找到有效的控制手段，而风险又很大，那么最好的办法就是及时向决策者、赞助人汇报，告知风险。同时也要向合作方传递风险预警。
你可能会问：在互联网企业做大规模的架构活动，本来就是高风险、高强度的。这么高的不确定性之下，肯定会有各种突发情况。公司的项目目标和不合理排期都是自上而下的，我作为架构师，为什么要承担这种传递风险的压力呢？再说了，如果整个公司都是报喜不报忧。要是我第一个传递了，公司第一个淘汰的就是我啊！
如果真是这样，如果你选择不说，那么第一天淘汰的肯定还是你。因为老板们这么做也有正当理由：你作为架构师，就处在风险的汇聚点。知道风险却还隐瞒风险，真的对吗？
小结
今天我们讲了建设共识这个软技能，这是职场上非常关键的一项软技能，也是成为领导者的基本能力。
在日常工作中，架构师会有很多建设共识的训练机会。这是你的职能福利，一定要利用好。关于这个话题，市面上有很多相关的书籍。不过在建设共识这件事上，读书，远远比不上你在实际项目中的实际锻炼。
除此之外，我还想强调一个观点，那就是明智的冒险会带来价值的回报。冒险是有代价的，但我们作为架构师就是要对这个代价了然于胸。在互联网时代，竞争的压力意味着我们永远都不会有充足的时间去量化风险和设计预案。所以对风险的判断，是一项非常有价值的个人能力。而架构活动的过程，就是你提升这项能力的重要机会。我相信，随着你的不断实践，对风险的判断力一定会大幅提升的。
思考题
三个思考题，任选一个：
- 架构活动中某个人或团队的利益被忽视，你是否有类似的经历呢？最终的结果如何呢？是什么原因导致的呢？如果你是这个项目的架构师，你会怎么做呢？
- 在日常生活中，你有没有积累一些建设共识的小技巧呢？适用于架构活动吗？
- 冒险有两种情况。一种是值当的，就是风险本身是暂时的。随着企业的成长，风险带来的损失逐步降低。所以一旦冒险成功，那么这个风险的损失就可以被忽略掉。这意味着你冒一次险就行了，之后一帆风顺。反过来，有些冒险是艰难的，就是风险本身是增长型的。随着企业的成长，风险带来的损失逐步增多, 就像达摩克里斯之剑一样。针对这两种情况，你能举一些例子吗？从中能得出什么结论吗？
如果这节课对你有帮助，欢迎你把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！