共识，在架构活动的上下文里，就是尽可能让多的人在限定时间里达成一致。很多人误以为共识就是投票，让少数服从多数。其实不然。投票是个表面公平，但其实非常暴力的决策方式。它是在参与者无法达成共识的情况下，依然要获得一个决策的办法。而共识的目标并不是达成一个决策，而是让尽可能多的参与方认可一个决策。
我们必须理解参与者的核心利益诉求，最终在一个相对公平且可以长期维持的机制下做利益边界的划分。
建设共识其实是个体力活。如果只做表面工作，拿一套 PPT 或者价值观来侃侃而谈，可能只需要半天时间。但如果想真正了解一个人的内心利益诉求，就需要在日常工作中下大量的功夫，建立信任关系。而且场景越复杂，人越多，那么需要投入的成本就越大。所以建设共识这件事，功夫要下在平时，而不是架构活动开始的时候。
架构师要面对互联网企业在不确定性的商业环境、日常工作缺乏流程、团队成员高强度工作节奏和日常反射式研发所带来的混乱和质量问题。所以在架构活动的全生命周期里，架构师都需要持续收集、发现、评估和控制风险，把风险控制在可以接受的范围内。具体怎么做呢？有三个关键动作：逐渐形成量化认知，可以冒险，但不能不说。
明智的冒险会带来价值的回报。冒险是有代价的，但我们作为架构师就是要对这个代价了然于胸。
此文章为5月Day17学习笔记，内容来源于极客时间《郭东白的架构课》
