如何在职场建立「共识」？

大力哥呀 2023-07-28 19:04:03

工作越久越体会到，团队的协作效率会比个人的努力，在某种程度上更能决定你可以在职场中到达什么样的高度。但在我职业生涯的前几年，我更关注的是如何提升个人的技能，而很少去思考协作这件事。

一月份入职新公司后，带着新的身份和新的任务，我又跟一群新的伙伴开始了一种合作关系。在这一次，相比于个人的单打独斗，我开始更关注“如何提高协作效率”这样的问题。

而在协作效率这个话题下，有个概念可能不得不谈，那就是共识。基于共识的协作，是我向往的工作方式。

一、什么是共识？

从字面意思看，共识就是共同的认识。但是在职场中，我更关注具有两个属性的共识：

一种是操作性，即这个共识是能够引出下一步动作的。比如“我们应该完成什么任务”，“我们下一步应该从哪些方面着手”，这些共识可以直接带来下一步的动作，而这比只能停留在认识层面要重要得多。

另一种是约束力，即对于确认共识的所有人来说，在之后否认这个共识的成本都是较大的。比如大家说好了要做一件事，需要所有参与共识形成的人的共同努力，那到你该出力的时候，你说太累了不想做，那这时候这个共识就在瞬间失去了价值。因为它没有了约束力。

所以，当我去其他部门沟通，无论是邮件还是会议，或者是当面沟通，我都特别关注一点，这样的沟通结论是什么，最后我们达成的具有约束力和操作性的共识，到底是什么。

二、如何达成共识？

虽然我们都知道共识很重要，但达成共识的路程并没有那么轻松，甚至有时候以达成共识目的的沟通，最后变成了一次吵架，不欢而散。

在此分享一些我自己的看法。

首先，你需要给予共识以仪式感

最好的仪式感来源于，每个人都亲自确认。而谁来完成这个确认动作呢？共识对谁最重要，谁来。获益最大的人，需要承担最大的责任。

所以在我发起的每个会议中，我会阶段性捕捉大家达成了一致的意见，然后逐个确认。

在这个阶段，对我来说，让大家都确认不是唯一的目的，而是共识的每个直接干系人是否都到场，如果没有，是否当下正在接入。

比如我要做一个需求，我邀请到了前端开发，后端开发跟我说有事儿来不了，我想着反正讨论的结果可以同步他，那这个会就先开吧。结果最后发现，会议中达成的共识，在后端那边的成本非常大，而在会议中，我错误的预估了这个成本，导致这个共识可能就作废了。

其次比较难的是，确认的人是否是关键人物？

关键人物对于共识的确认才具有决定性意义，如果他来不了，来的是非关键人物，比如下面的一线人员，那这个共识就应该要从结论变成“待某某确认后再重新形成共识”。

这就说到了第三点，共识不一定是当前非要形成统一的结论。当然，如果能形成结论并推进到动作当中，这对于整件事的推进是效率最高的。但很多时候，我们并不能通过一次沟通就形成某个确认的结论，这时候共识就变成了待讨论。

可尽管是待讨论，我们也要清楚，在这次沟通中，到底是因为什么导致了某个待讨论，是因为意见相左，还是关键人物不在。

最后，也是最难的，如何面对跟你不一样的想法？

站在不同的岗位上，每个人都有从自己出发的想法，所谓屁股决定脑袋。因此一个人提出的建议，其他人有不同的想法，这是很正常的。如果一种想法提出来，所有人都同意，可能这也是一件很危险的事情，这就意味着，也许大家都没有思考过。

对于不同的想法，我自己在努力践行两个原则：控制情绪、拆解归类再处理。

情绪是很重要的，我曾经有过一个阶段，只要有人跟我提出不一样的想法，就会在心底里排斥，进而排斥这个人的所有观点。

后来我发现，这种情绪状态对于我更客观地去接受不同的想法，从而开拓自己的思路，是没有任何好处的。

所以，情绪控制是第一步，不能因为有了情绪，而导致不再能做到兼听。

而第二步是更重要的，将不同的想法拆解再处理。有时候对方不同意的只是我们表达观点中的一部分，但我们会觉得，对方在否定我的整个观点。

在面对不同的想法时，最重要的是搞清楚，矛盾点在哪里。是在假设，还是在推理逻辑，还是最后的结论。

作为产品经理，我经常会遇到别人对于我们需求的质疑，那我就需要弄清楚，矛盾点是在为什么要做这件事，还是做这件事的优先级，还是做事情的方式。

精准捕捉矛盾点，就跟看病时精准诊断病情一样，对于处理达成共识过程中的冲突，非常关键。

而达成共识后，千万不要忘了，将共识记录下来。

三、共识为什么需要被记录

第一，共识本身的约束力，依赖共识被记录下来，并被呈现给了所有相关方。

因此，被记录是形成共识的第一要义。

如果你和某个同事是合作伙伴，你们私下达成了口头共识，但这个共识没有被记录，那么任何一个人想要反悔，其成本都只是另一个人变得更讨厌和不信任他。

但如果这个共识被记录下来，并且在公共渠道呈现出来，例如工作群里，或者邮件里，那么任何一个人想要反悔，他都要掂量掂量这样做值不值。因为这个东西被记录下来了，并且被广播出去了，其触达到的人群，就比单纯的口头共识要广泛的多。

很可能如果这个共识被全公司的人都预先知道了，那么反悔它的代价就是公司范围内的社会性死亡。

其次，共识的可溯源，也要依赖共识被记录下来。

作为产品经理，每天需要进行大量的沟通，在所有沟通中，最浪费成本的沟通就是双方的沟通前置条件不一致。

即，我们经常会遇到的，我记得这件事当初是这么说的，当你面前的这个人不同意，他记得当初说的是那一套。

然后你们就会为各自的论点去找论据，后来发现由于当初的共识没有被记录（甚至当初的沟通结论没有被记录），你们又需要去讨论之前已经讨论过的话题。

在执行层面，我们有代码重写的返工成本，有原型图重画的返工成本，而在沟通层面，总是讨论过去已经讨论过的问题，也是一大返工成本。这个成本是隐形的，很难看见的，但是能够算出来的。

你和讨论对象的日薪总和，除以8，乘以你们在这件事上浪费的额外讨论时间，就是缺乏共识记录带来的返工成本。

最关键的是，这样的讨论，会消耗团队间彼此协作的情感账户，每个人在别人眼里都貌似变成了一个不靠谱的人。

四、围绕共识的工作中，还会出现一个问题：共识需要变更时，该怎么办？

这是常见且合理的，战略的变更，支撑条件的变化，都会导致先前达成的共识可能会面临变更。以我为例，产品经理处理的最常见共识，就是产品需求。

围绕一个需求，有业务部门，有支持部门，对接上下游时，一个需求为什么要做，怎么做，什么时间上线，这一切都是共识。

但共识是会变的，而且也应该允许被调整，否则做事情的方式就太死了，至少不适合互联网公司。而我们真正要解决的是，如何确保变化与效率的冲突。我自己有四个体会。

（1）不要害怕确认

对我来说，很多时候需求出现变更是因为在设计阶段没有考虑的很清楚，导致会出现一个模糊的点，但代码是不允许有模糊性的，所以之前觉得可能可以做的事情，在仔细考虑后发现要用另一种解决方案了。

面对这样的变更，早几年我可能会犯的错误是自以为是。我觉得应该能做，我觉得应该可以确认，但事实上，我并不是100%了解，我需要找到最了解的人去确认。

所以，不要害怕确认。再次确认，会比不负责任的确认，要好得多。

（2）找到所有关键人评估变更

共识变更后影响了谁，就需要找到那个人一起来评估变更。变或者不变，怎么变，都需要所有关键人知晓。一旦关键人之间出现信息不一致，那对于最终的结果交付来说，将是一个巨大的隐患。

（3）及时记录

变更也是一种共识，为了将来能对此刻达成的变更共识同样可以溯源，及时记录是很有必要的。

（4）及时响应

以上四点做到都不难，难就难在及时响应。变更发生的阶段，往往是执行阶段。一个需求在设计阶段，总是可以达到一个大家普遍认可的方案，但真正到了落地时，才知道有各种各样的限制，并由此带来各种各样的变更。到了这个阶段，解决变更不再是制约协作效率的瓶颈，瓶颈在于及时响应。否则那些待确认待沟通的问题，就会像滚雪球一样，越来越大，最终导致效率的崩塌。

最后分享一点题外故事吧：在上周，公司内部开了一个创新创业课，公司的某个创始人分享了公司是如何从0到1发展起来的。故事很动听，但在老板讲故事过程中，他特别提到了一点：开会要明确共识，那些没有达成一致的结论，也属于共识。

而这一点，在我心里成为了那节课最大的收获，于是沉淀一周，整理了关于共识的种种思考，并努力在工作中将思考变为行动。

我喜欢这种细听、多想、落地、复盘的感觉，这是我成长的闭环方式。