沟通和你的专业能力一样，对在职场上打拼的你来说，扮演着举足轻重的作用。它并不像宫廷剧里皇帝赐的毒酒一样，一旦喝下就一招毙命，它更像是一剂被你经常无视，却潜藏在身体里的慢性毒药，一点点的吞噬你的职场竞争力，在不知不觉间直至摧毁你在职场的发展。
说到这，作为程序员的你是否会想起前不久和项目经理的对话？
经理：有一个任务需要完成，你看一下，给我个预计完成时间。
你：这个需求不难实现，两天就能做完，两天后准保上线。
两天以后，当项目经理又来到你身边问工作情况时，语境似乎变了。
经理：怎么样了，做完了吧，今天能上线吧？
你：我的代码写完了。
经理：测试工程师测过了吗？测试结果怎么样？
你：还没有测试呀！
经理：怎么没有测试呢？马上安排人测试能测完吗？
你：我不知道耶。
经理：什么？我可是向上汇报说今天这个需求一定能上线的。
显然，项目经理有些着急了。明明是让你自己预估的工作时间，结果还搞成这样，如果延误了产品上线，这个损失又该由谁来负责？而此时的你更委屈，心想着我的代码写好了，自认为写得完美至极，经理一句夸奖的话都没有说，还有点责怪我的意思。问题到底出在哪里呢？
乔治. 奥威尔说过：
思想可以败坏语言，语言也可以败坏思想。
直白点说就是，警惕你的话语内容，它会改变你的认知方式。
这么说，难道是因为沟通不顺畅，才导致了完成的结果差强人意？不管怎样，仅仅凭直觉的猜测并没有任何意义，让我们用3F方法详细的分析一下上面的沟通内容吧！
第一个F是Fact事实，摆明事实的信息，确认对方的客观情况。上面案例中，项目经理有一个急侍上线的产品要开发人员写代码实现，这是事实。但是，开发这个需求要用什么技术实现，完成这个任务要多长时间，这是个问题。项目经理把这个问题移交由程序员自己做决定。这个做法也说明，项目经理不关心技术实现细节，只关心产品具体的上线时间。
第二个F是Feeling感觉，指的是双方对于事实的论断是否一致。基于上面的事实，从项目经理的角度讲，他认为这个任务完成就意味着产品可以上线。而从程序员的角度讲，他认为的任务完成只意味着代码写完。这其中显然存在“认知代沟”。
第三个F是Focus意图，进一步探讨对方的意图是什么，而我的意图是什么。最好通过有意识的寻问，避免“认知代沟”。显然，案例中并没有进行这一步确认。如果换一个对话对象，一位较有工作经验的程度员会这样追问项目经理：你所说的预计完成时间，包括编写代码的时间，还包括其它时间吗，比如测试和关联产品的联调时间？有意识的寻问，减少沟通成本，总比无端的自我猜测要好得多，你说呢？
第四步是共识，对上面三步的沟通做个总结，以追求双方确认一致并达成共识。显然，这个案例中的共识，是基于对产品上线前步骤确认和时间预估而得来的。
不难看出，3F沟通方法对一次沟通中彼此在对齐信息、达成沟通共识上对我们有很大帮助。不过，想要长期稳定地提升沟通品质，一定离不开双方信任关系的建立和信任水平的逐步提高，这是个慢功夫。
再慢的功夫，也是有方法可循的。例如弥补理解偏差的方式有很多，有一个最佳实践，它就是DoD(Definition of Done)。它帮助我们定义怎样算是完成了，用任务清单的方式一项项的把每步要做的事情，哪步涉及到的检查项一一列出。有了它，双方在对齐完成的意义时，会更加的得心应手。
开篇的案例中，如果双方在工作之前，先制定DoD清单，谁该做什么事情就更加一目了然了。比如清单中可以这样写明：
开发完成，表示开发人员编写好相关功能代码；
编写好单元测试代码；
移交给测试人员测试，测试任务包括但不限于测试代码逻辑，测试功能实现，测试产品间的兼容性。测试人员要保证测试覆盖率达到90%。
产品负责人对产品验收；
整个产品代码集成完毕，产品处于可部署、侍发布状态。
而每次在任务分配和讨论时，就是在清单中增加项目，减少项目的过程。一旦双方确定了DoD清单的内容，做事的结果就有了两种状态，“做完”和“没做完“。如果这种方法在团队中推广，必定会减少团队间的合作沟通成本。
人与人的协作中，经常会出现各种问题。根本原因之一是有太多人因为理解偏差而造成了对某件事情的误解，从而浪费了大量的时间。而DoD就是将这些容易产生歧义的不确定落到实处，变成确定的方法。
记得罗振宇在跨年演讲中曾说过：
即使这个世界再不确定，你都可以用自己的超级确定，来对冲世界的不确定。
与之相对应，即使在职场中与不同角色的人沟通经常不顺畅，带给不确定感，你都可以用类似DoD的方法来对冲沟通中的不确定。长此以往，你就是他人眼里那个做事靠谱的人，用”凡事有交代，件件有着落，事事有回音”的行为方式为未来的职场发展铺平道路。
网友评论