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