项目沟通的四个原则

计划、流程、进度、规则等等，这些是项目经理常见的工作输出。在这各种项目问题的解决、进度的顺利推进背后，都凝结了大量的沟通协调。今天，我们就来聊聊项目沟通中的四个原则。

1、主动尽早

情形1：

项目4月20日就要发布了，项目总监早就把这个信息通告给几个重要客户了；但这边，项目经理小A和团队在4月上旬就发现越来越多计划外的任务不断地塞进了任务列表，比如测试服务器搭建啥的。大家从第一个任务加入的时候，就在暗自忍耐并企图自行通过加班方式进行消化。虽然大家都看到了任务列表越来越长，但没有人愿意去触碰4月20日能否发布这个问题，小A也是如此，更是祈祷团队能在计划内吃掉新增任务，而不必惊动总监。终于，到了4月19日，大家不得不面对明天无法发布的现实了，项目经理硬着头皮告诉了项目总监这个不幸的消息……

情形2：

项目5月20日的发布目标，预留了一周测试时间。项目经理小B对测试预留时间反复思考后，判断测试时间不足，有延期风险，第一时间向项目总监报告了这一风险。在第二天的站会上，小B向团队提出了这一风险，项目总监和团队一同讨论后，对整体计划进行了调整，测试提前一周开始。最终，项目5月20日按期发布。

小A希望把问题扛下来解决，而给总监报告好消息，结果却发出了最坏的消息；小B尽早向总监和团队沟通了可能的问题，结果收获了成功交付。

怕什么来什么，躲什么来什么。就像爸妈从小教育我们的一样，“要敢于面对问题”。直面是种勇气，也是种意识和态度。项目沟通中，第一条原则就是“ 敢于尽早暴露问题 ”。只有把问题摆出来了，才可能调动大家的力量来尽早解决问题。

对重要干系人的沟通也是如此，虽然他们非常希望听到产品顺利交付的结果，但尽早了解可能存在的问题，一方面可以避免他们对客户传递潜在有误的信息，另一方面可以为团队争取到最及时有力的帮助来解决问题。而这，也一定好过发布前一天才得知一切落空吧！

有人总结，“项目经理，就是要悲观面对项目，乐观面对团队”。话虽不尽然，但项目经理的确就是项目背后的那一双眼，纵观全局，发现潜在问题；项目经理也是项目身后那一张嘴，不时提醒大家需要注意的问题或者需要做出的调整。 一路报喜，只是假象；只有对问题的主动和及早沟通协调，才能真正收获最后的喜报 ！

2、抓住本质

情形3：

测试主管在泡泡群里呼唤项目经理小C，“小C，有个小意见！”

“yes?”

“现在开发任务都记录到白板中，完成这个版本以后收走了那些任务便签，我们报bug的时候都不知道谁做哪个任务了。如果后面来了新人，每次发现bug都过来问应该报给哪个开发。这个代价有点大。”

接着小C拉着测试主管到会议室私聊。原来，新来的测试发现了回归bug，每一个都得询问测试主管应该报给哪个开发，测试主管正愁着呢！原来测试团队一直都非常了解模块开发归属，哪怕遇到模糊地带，也会查询JIRA关键词来找到对应的任务和开发者。那为啥不直接报给开发负责人，让他来分配呢？开发负责人可以帮忙解决小部分问题，但如果是全部，那占用的工作量就太大了。

小C似乎看到了测试主管的痛苦所在，“是啊， 的确需要有个地方让测试很明确地了解模块的开发归属 。” （将问题引向本质而不是具体解决方式）

“就是啊！否则我真不用干活了，整天都在帮新人指定bug归属！”测试主管很头疼。

看到了一致的问题，最终，小C和测试主管商量决定建一个wiki页面，列明主要模块和对应的前后端开发，这样还解决了JIRA中原开发者离职变更这样的问题，可以根据团队情况保持wiki页面更新。

测试主管以质疑白板作为沟通的开始，这是他所遇到的直接问题。如果小C作为白板方式发起人，天然以自卫的心态做沟通的话，很容易将视点聚焦于白板本身的矛盾，从而将沟通变成攻守关系，可能很难有双赢结局。在上面的例子中，一方面小C及时避免了在泡泡群中公开讨论矛盾问题，另一方面，把视点聚焦在测试主管的“需求”而不是“需要”上，这就把双方都放在了更高的、容易达成一致的目标上，而不是具体的解决方式上。这样，在相同的出发点前提下，沟通就容易顺利进行了，解决方案也就更水到渠成了。

生活工作中，有无数类似的场景，讨论由具体的某个“需要”开始。 如果纠结于“需要”，沟通就容易陷于泥沼；而如果聚焦“需求”，那求同存异就容易达成 。

产品经理和开发争执某一个临近发布时的需求变更，如果着眼于为什么那么晚才提变更或者进度是如此之紧张，那么结果无论如何总会有人内心郁闷不堪。但如果先一起来看看为什么要做这个变更，对产品对用户的作用如何，也许结果就变成我们如何来做的讨论了，而不是做和不做或者责任的问题。透过现象看本质，才能在沟通中真正求同存异 。

3、 共情引导

说到共情，最深刻的案例来源于育儿界，咱们一起看一个案例，是一位妈妈和女儿之间的对话，相信几乎所有的家长都会有这样的对话开始：

情形4：

“ 妈妈，我明天不想上学了！ ”

“哦？” （敞开对话大门）

“ 上周的考试，我才得了30分。 ”

“ 是你说过的那个数学考试吗？没想到只得了30分哦。 ”

女儿立马放声大哭：“我已经非常努力了！可才考了30分！ ”

“ 很努力了才得30分，的确令人沮丧。 ” （共情，并且中立）

女儿梨花带雨： “ 我要原来的中文老师！ ”

“ 要是她在，你就不会考这么惨了。 ” （说出女儿的心声）

女儿使劲儿点头，认可老妈的诠释——说到她心窝窝里啦。

“ 你是因为看不懂题而没考好吗？ ” （女儿中文阅读不太好，应用题不一定能理解。）

这下子女儿 的防卫 又自动脱落了好大一层： “ 老师说话太快了！我根本听不懂！谁都听不懂他说什么！ ”

而后女儿又抱怨了一堆老师的不是，老妈表示理解。然后……

女儿： “ 我不上学了行不行？等到下周一再去，行吗？ ”

老妈： “ 恩，这件事于你来说是非常严肃沉重的，一直压在你心口，你一直在纠结，你想停止思考它，却发现自己做不到。 ” （终极洞察 ）

小女yes了一声后沉默。老妈知道这一箭射中了靶心，曙光在望了。

女儿： “ 我是不是非上学不可呢？ ”

老妈： “ 当你特别不想做一件事，可又必须去做的时候，是挺困难的。 ” （没有直接给判断）

女儿： “ 我也不是特别不想去，明天有体育课和艺术课。 ”

老妈： “ 你最喜欢的两门课，如果不去就可惜了。 ” （说出感受）

女儿： “ 我不想错过体育和艺术课。 ”

老妈： “ 你感觉很矛盾。 ” （说出感受）

女儿再次陷入沉默。

沉默良久之后，女儿声音颤抖着，带着哭腔，说： “ 那好吧，我明天还是上学吧，因为我想上体育课和艺术课。如果中文老师还不好，我星期四和星期五就不去学校了。 ”

随后，她小哭了两声，表示她提出的这个解决方案是多么地令她忍辱负重、委曲求全，她是多么地可怜啊！ [1]

妈妈自始至终没有直接给女儿任何判断或者指令，取而代之的，是共情和引导。很多时候我们的立场是随着情绪而微妙变化的，所以沟通时的情绪基调很可能会导致沟通结果的迥异。 理解和接纳对方的情绪，充分引导对方把问题和情绪表达出来，也就开启了沟通的大门。 相反，如果开门见山就给出自己的判断和见解，不仅会把对方的倾诉欲望堵回去，更可能让双方站在了情绪对立面上。

当然，仅仅共情，还是不够的。沟通，尤其是项目沟通，大都是希望达成一定的目标，如果仅做了倾诉，是无法解决问题的。因此， 以共情为基本基调，需要在陪伴的情绪中洞察问题根源和解决突破口，并适时加以引导 。如上例中妈妈所说的“ 这件事于你来说是非常严肃沉重的，一直压在你心口，你一直在纠结，你想停止思考它，却发现自己做不到 ”，把女儿的情绪从负面发泄，引导到问题解决的思路上。最后，女儿自己能够找到解决问题的方法，妈妈所做的，只是陪伴和顺势引流而已。

4、完整解决

和普通的个人沟通不同，项目沟通往往是为了解决项目问题。所以，往往不是一次性的沟通或者和单人沟通就能解决问题的。项目沟通需要在时间维度和沟通对象维度有计划地做拓展，来为问题解决服务。

情形5：

随着产品的发布和发展，项目经理小D和测试主管小E都看到回归测试工作压力越来越大，产品的质量风险也一天天升高，持续集成和单元测试的强化要求迫切。如何来引导团队开始在这方面起步呢？

小D和开发团队负责人沟通，获得了长期而言加强持续集成的认可，但开发负责人觉得可能还不到时机开始推行，不过赞同下个版本从最基本的持续编译开始尝试；小E和质量保障部门沟通获得了基础工具和专业指导方面的支持。

在迈出了持续编译的第一步（大约1个月）之后，小D和产品总监沟通了持续集成和单元测试对于产品目前和未来的重要性，得到了总监的基本认可，同时，也获知需要充分平衡产品交付节奏和额外的持续集成精力付出；小E给开发团队做了持续集成方面的基础分享式培训，让大家对为什么要做持续集成以及可以如何做形成了初步概念；小D和小E又多次和开发团队及其负责人进行了沟通，确认了逐步引入和保障单元测试的方式；随后，基本的持续集成框架和集成状态看板开始了，持续集成状态也被包括进了项目日常状态公告中……

完整解决，并不是具体的沟通技巧，而是如何完整地安排沟通以及使用不同的沟通方式来解决问题。项目中，很少是仅凭一人之力可以解决的问题，尤其是策略性方向性的问题。需要我们有目标、有计划、有耐心、有积极心态地去面对整个沟通和推进过程。

要做到完整解决，首先要有 强大的愿力和强大的内心 。愿力，是根本驱动，是原始目标的期待强度，完整解决的过程往往漫长，坚定的决心可以陪伴我们坚持到底；强大的内心，是耐心，是韧性，过程中一定有挫折，一定有起伏，强大的内心可以给我们积极的心态和越挫越勇的精神。

其次，要有 敏锐的洞察力和审时度势的能力。问题的解决方式有很多种，需要看清问题的根源和不同角色对问题的影响力及作用，也要看到不同时期不同人对于问题的态度和需求。为什么开发负责人一开始表示认同但无力推进尝试？产品阶段、团队规模、团队状态都是他考虑的因素。为什么会同意从持续编译开始？毕竟不需要团队本身的额外付出，但又可以为未来搭建基本框架。为什么要先给团队做分享？因为团队年轻经验不足，甚至会有人完全不了解持续集成是什么。

完整解决，已经不仅仅是沟通的问题了，而是项目过程中持续改进的典型实例。 有愿景、有策略、有坚持、有反馈，成为真正的闭环 ，才能实现项目和团队的改进成长。

写在最后

沟通的过程，技巧其次，关键在沟通的心态和心境。无论是主动尽早、抓住本质、共情引导、完整解决，真正起到作用的都是沟通者的内在修炼和积极心态。

沟通，可以修炼吗？不，因为她不仅仅是技巧。沟通，可以修炼吗？可以，因为她正是我们人生修炼的过程！

本文来自微信公众号“网易杭研项目管理”（ID：NeteasePM），作者 曹智清。

管理圈经授权发布，如需转载请联系原作者。