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

0 评论 2839 浏览 5 收藏 14 分钟

编辑导语:对于职场人来说,日常工作仅仅是个人的思考,更重要的是团队合作。而团队合作中,对某个问题或答案达成一致的意见是需要重点关注的问题。本篇文章中,作者对如何在职场建立共识给出了自己的建议,与大家分享。

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

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

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

一、什么是共识?

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

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

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

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

二、如何达成共识?

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

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

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

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

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

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

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

其次比较难的是,确认的人是否是关键人物?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1)不要害怕确认

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

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

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

(2)找到所有关键人评估变更

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

(3)及时记录

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

(4)及时响应

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

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

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

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

#专栏作家#

大力哥呀;微信公众号:大力哥求职,人人都是产品经理专栏作家。正年轻的产品经理,关注新零售、用户体系,擅长问题抽象及拆解。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!