达成共识的一些方法

在工作中经常会看到这样的场景：几个人对一件事情的做法产生了分歧，长时间争执不下，谁也无法说服谁，最后不欢而散，事情也没有解决。

这种场景实在太常见，以至于有些人会因此受挫，放弃讨论与思考，带着情绪和怨气无脑地执行。

在一家崇尚创意和独立思考的创业公司里，当然还是希望大家能好好沟通、达成共识，每个人都尽可能充分地表达观点，然后一起选出最佳的解决方案。经过我自己的观察，多数能靠讲逻辑讲清楚的事情都可以做到这一点，今天就来分享一下促进大家达成共识的一些常见方法。

避免情绪化讨论

情绪化的讨论不可能得到有效的结论；就算勉强得到结论，这个结论的可靠性也非常存疑。

很多年以前我读过一本书《Crucial Conversations》，这是当年在微软内部非常受推崇的一本书，专门帮助大家应对那些艰难的沟通。书是英文的，这里简单翻译一下其中的重点，方便大家理解。

情绪化的原因一般是“不安全感”，主要表现就是沉默或激烈言辞，这种状况很容易被察觉。面对这种情况，首先要做的是让大家冷静下来，最有效的办法是暂停会议，让大家离开当前环境（step out），等情绪平复之后再讨论。

不过仅仅暂停会议还不够，必须做出改变来消除“不安全感”，有以下几件事可以做：

• 如果不安全感来自信任问题，那就得先让大家私下里建立信任，让参与讨论的人相信，无论会议过程和结论是什么，都不会对任何人带来威胁，也就是所谓的“对事不对人”。
• 大家各退一步，勇于承认刚才情绪化的事实，对一些激烈言辞做出合适的歉意。
• 解开误会。很多情绪化的讨论是误会带来的不信任和不安全，所谓“说者无心，听者有意”，或者干脆是“鸡同鸭讲”，需要冷静想想刚才的误会出在哪里，再主动澄清。
• 愿意继续寻找共识，而不是继续制造分歧。如果会议的目标根本不是寻找共识，那大可不必继续开下去。

以上做法要求会议中至少有一个人主动做出改变，这个人可以是会议组织者，也可以是有意愿促成讨论落地的人。假如谁都不愿意主动，最终结果也不可能好。

实际操作中，容易起情绪的会议真的很需要一个冷静、公正、没有利益冲突的第三方来担任组织者。例如大公司做绩效沟通时，leader 与绩效不佳的员工谈绩效，往往 HR 会在场打圆场；牵扯多方的大型项目，往往会安排一名利益无关的专职项目协调人来平衡各方的意见。

对于我们这样的小公司而言，每个会议都找一个第三方来主持公道有点不现实，也没太大必要。我们需要自己发现状态并主动做出改变，最好每个人都仔细读过这篇文章，至少要形成“避免情绪化讨论”这个共识。

从“常识”到共识

当讨论回归逻辑，大家就可以进入正常的讨论环节。

达成最终共识的前提是达成尽可能多的“基础共识”，就像盖房子一样，基础共识是地基，最终共识是整栋建筑。最基础的共识是“常识”——所有共识里不应该被挑战、天然就应该能让大家认同的那部分，既包括通常意义上的常识，也就是大家都该明白的知识、科学和方法论，也包括在我们公司里被大家广泛认同的结论。

在公司范围内持续积累一些通用的共识非常重要，这些共识会形成一个“共识库”，变成以后讨论很多事情的常识。“共识库”里最需要积累的是那些一时讲不清楚的抽象原则和方法，它们往往跟公司价值观类似，甚至就是价值观本身。这些东西临时想起来很难辩明白是非，但如果持续积累，并且在遇到事情之前就达成共识，则会事半功倍。

比如讨论一个互动内容设计是否足够好，当公司内部对“有灵魂”“不用套招”这些底层设计原则形成了广泛的共识，也就是一种公司内的常识，大家就可以把方案和常识做对比，剔除掉明显不符合常识的设计。这样，大家既不用在设计过程中去考虑所谓没有灵魂、纯粹套招的设计，碰到这样的设计也能比较简单地否决，很快对决定达成共识。如果没有这些，我们每次都得从“作品是否需要灵魂”开始讨论，那就非常南辕北辙了；而且这种抽象的概念本来就很难用逻辑说明，更多是一种文化、价值观，甚至创始人的直觉。

经典的讨论过程

一个经典的讨论过程是这样：

1. 确定目标；
2. 列举有冲突的方案和背后的核心逻辑；
3. 找到每个方案的问题并横向比较；
4. 找到解决问题的“底线”并达成共识；
5. 大家一致授权这件事情的负责人，选择一个在底线之上的方案，共同认可。

一般来说，走到第 3 步就基本能达成共识；如果还不行，就需要准备第 4、5 步。这里我重点说一下后面这两步该怎么做。

有很多方案不存在最优解。比如讨论产品体验的时候，大家口中的“用户”其实是一群差异很大的真实用户的集合，没有人能直接代表这个集合去优化体验，也就不可能做出所谓“最好”的体验。这种时候，与其争论抽象的用户体验好不好，不如思考这个体验的“底线”是什么，再共同授权一个人为最终结论拍板。

所谓“底线”，就是这个方案不能突破的基础原则，一般也应该由一些常识组成。比如产品设计中常用的一种方法叫“虚拟人物”（persona），把抽象的用户具象成一个具体的用户形象，大家先对这个用户的形象、性格和用户故事达成共识，再以实现用户故事中所有相关能力作为产品设计方案的底线——如果某个方案会让这个用户故事无法实现，或者这个用户用起来非常难受，那显然方案不够好。

关于“虚拟人物”的更多信息，可以读一读参考资料里的《用户故事（User Story）》和 What is User Story?。用户故事是一种更大的产品设计方法论，有点过于复杂，也不一定真的适用于我们遇到的场景，但“虚拟人物”这个概念很值得借鉴，用来解决共识层面上的难题非常有可操作性。

一旦确定了“底线”，并且多个方案都符合这个底线，大家就应该停止争执，让被授权的负责人自己拍板，终结讨论。大家需要意识到，如果每个方案都有不完美的地方，除非不断修改方案、重新讨论，否则坚持己见对任何人都没有好处，还不如把决定权交给一个人，然后大家继续后面的工作。

Pro tip

我们可能察觉不到自己的情绪

就像醉酒的人不会认为自己醉了一样，有时候我们感受不到自己的情绪，但旁观者能明显感觉到我们言语中不自然的地方。

如果在讨论过程中，他人善意地提醒自己带着情绪而自己毫无感觉，请不要太意外，这很正常，稍微调整一下讨论节奏就好。

自我调节最好的几个方法包括：

• 暂时停止讨论当前的问题，喝口水来个中场休息，五分钟就够了；
• 转移一下话题，聊点轻松的事情再回来继续；
• 通过什么方式发泄一下，有时候情绪宣泄之后反而能让自己快速冷静下来。

可能大家需要一个公正的第三方

达不成共识的一大原因是大家“屁股不同”，每个人站在自己的立场甚至利益上来聊方案，很可能缺少达成共识的意愿——虽然大家口头上往往不愿意承认。

这时，假如大家还是想解决问题，并且希望参与讨论的各方都能心平气和地接受最后的结论，一个推荐的做法是找一个公正的第三方来帮助大家寻找共识。

阿里有一种很有趣的文化叫“成就他人”，很多共识都可以用这一点来达成。首先，“成就他人”本身是一个非常务虚但大家都认同的“常识”，无需讨论且不容挑战。其次，这个常识背后确实有利益机制在起作用，比如晋升时的 360° 考核；再加上阿里不断“拥抱变化”、不断调整组织架构，大家不敢把事情做绝，成就他人也可能在未来帮到自己。最后，在决策层看来，这种文化也有助于实现中庸和妥协，让大家在心理上更容易接纳别人的观点和方案。

在这种文化影响下，一个足够高阶的老板，无论他是否真的知道这件事的前因后果，只要能帮助大家达成妥协，都可能成为这件事的公正第三方，事情也就更容易解决。阿里甚至还有一种说法：如果一件事情大家讨论不清，上升到老板层面后，老板可能会明确说这就是一个随机决策，无论哪个方案大家都必须认同；如果方案本身真的难以调和，又需要多个有分歧的团队长期配合，老板会直接调整组织架构，把几个团队合并，把团队之间的问题（屁股问题）变成团队内部的问题，事情往往一下就解决了。

在小公司里，公正的第三方可能就是公司的核心管理层。一般也没那么多分歧值得花时间去沟通，只要大家觉得这个第三方最后定什么方案，自己心态上都能接受就行。

讨论问题需要“锚点”

我们可能会在开会的时候“失焦”，因为一些细节讨论得偏离主线很远，导致达成共识遥遥无期。

这种情况下，需要时刻围绕问题的“锚点”进行讨论，应该做两件事：

• 把要讨论的分歧点写在白板上，与之无关的内容则记下新的分歧，暂时不展开；
• 把分歧点相关的“基本共识”写下来，不反复挑战这些共识，避免说车轱辘话。

这样可以尽可能提升讨论的效率；就算讨论最终没有结论，会议中的这些记录也会是后面继续思考和讨论的基础，也就是“锚点”。

参考资料

• Crucial Conversations: Tools for Talking When Stakes Are High（第 2 版），Kerry Patterson、Joseph Grenny、Ron McMillan、Al Switzler 著，McGraw-Hill Education，2011，ISBN 978-0-07-177132-0
• 用户故事（User Story）：https://www.jianshu.com/p/cc2e7210baeb
• What is User Story? https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/