在互联网时代,我们面临着三个与沟通交流相关的重要挑战:
- 分布式研发:日常工作中相对隔离的微服务研发模式;
- 沟通障碍:分散在全球或全国多地的研发团队,以及由此带来的语言、文化和沟通障碍;
- 认知差异:由于职能、工作背景不同而造成的认知差异,尤其是由于视角局限而带来的认知差异。
这意味着架构师需要克服上述挑战,推动参与者对架构活动形成共识。具体来说,这些共识包括目标、决策环境、架构语言、各自的责任边界和交付时间、交付内容和交付质量以及资源分配。
共识,在架构活动的上下文里,就是尽可能让多的人在限定时间里达成一致。很多人误以为共识就是投票,让少数服从多数。其实不然。投票是个表面公平,但其实非常暴力的决策方式。它是在参与者无法达成共识的情况下,依然要获得一个决策的办法。而共识的目标并不是达成一个决策,而是让尽可能多的参与方认可一个决策。
达成一致的关键在于找到架构活动参与方的认知差异点,然后再想办法消除。认知差异点的来源主要有三个方面。
首先是利益不同。假设你负责一个国际化的电商中台项目,其中有一个钱包重构的环节。那么你需要重新划分责任边界,将之前印度业务所属团队的钱包服务,变成一个通用的服务。然后再交给一个新加坡的钱包中台团队,分享给全球其他的国家。这样一来,新加坡的钱包中台团队、印度的钱包团队和其他国家的交易支付团队,这三者的服务边界就发生了变化,相关研发人员的利益也会受到影响。
其次是视角不同。架构师往往是从整个架构活动的视角出发,但其他参与者只会从各自团队的视角出发。比如一个国际化中台团队会认为,中台值得每个前台业务和中台研发人员呕心沥血来保障交付。但是对于每个参与者来说,你的架构项目只是他们诸多需求中的一个。
最后是其他的内在差异。比如因为职能、工作背景和语言文化的不同,也会带来认知上的差异。
简单来说,我们必须理解参与者的核心利益诉求,最终在一个相对公平且可以长期维持的机制下做利益边界的划分。
建设共识其实是个体力活。如果只做表面工作,拿一套 PPT 或者价值观来侃侃而谈,可能只需要半天时间。但如果想真正了解一个人的内心利益诉求,就需要在日常工作中下大量的功夫,建立信任关系。而且场景越复杂,人越多,那么需要投入的成本就越大。所以建设共识这件事,功夫要下在平时,而不是架构活动开始的时候。
此文章为5月Day1 学习笔记,内容来源于极客时间《郭东白的架构课》,推荐该课程。