php游戏网站建设谷歌搜索引擎google

在互联网时代，我们面临着三个与沟通交流相关的重要挑战：

• 分布式研发：日常工作中相对隔离的微服务研发模式；
• 沟通障碍：分散在全球或全国多地的研发团队，以及由此带来的语言、文化和沟通障碍；
• 认知差异：由于职能、工作背景不同而造成的认知差异，尤其是由于视角局限而带来的认知差异。

这意味着架构师需要克服上述挑战，推动参与者对架构活动形成共识。具体来说，这些共识包括目标、决策环境、架构语言、各自的责任边界和交付时间、交付内容和交付质量以及资源分配。

共识，在架构活动的上下文里，就是尽可能让多的人在限定时间里达成一致。很多人误以为共识就是投票，让少数服从多数。其实不然。投票是个表面公平，但其实非常暴力的决策方式。它是在参与者无法达成共识的情况下，依然要获得一个决策的办法。而共识的目标并不是达成一个决策，而是让尽可能多的参与方认可一个决策。

达成一致的关键在于找到架构活动参与方的认知差异点，然后再想办法消除。认知差异点的来源主要有三个方面。

首先是利益不同。假设你负责一个国际化的电商中台项目，其中有一个钱包重构的环节。那么你需要重新划分责任边界，将之前印度业务所属团队的钱包服务，变成一个通用的服务。然后再交给一个新加坡的钱包中台团队，分享给全球其他的国家。这样一来，新加坡的钱包中台团队、印度的钱包团队和其他国家的交易支付团队，这三者的服务边界就发生了变化，相关研发人员的利益也会受到影响。

其次是视角不同。架构师往往是从整个架构活动的视角出发，但其他参与者只会从各自团队的视角出发。比如一个国际化中台团队会认为，中台值得每个前台业务和中台研发人员呕心沥血来保障交付。但是对于每个参与者来说，你的架构项目只是他们诸多需求中的一个。

最后是其他的内在差异。比如因为职能、工作背景和语言文化的不同，也会带来认知上的差异。

简单来说，我们必须理解参与者的核心利益诉求，最终在一个相对公平且可以长期维持的机制下做利益边界的划分。

建设共识其实是个体力活。如果只做表面工作，拿一套 PPT 或者价值观来侃侃而谈，可能只需要半天时间。但如果想真正了解一个人的内心利益诉求，就需要在日常工作中下大量的功夫，建立信任关系。而且场景越复杂，人越多，那么需要投入的成本就越大。所以建设共识这件事，功夫要下在平时，而不是架构活动开始的时候。

此文章为5月Day1 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。