摘 要：在项目中往往都会遇见这样的情况，不同的人对同一个问题有不同的理解，从而增加沟通成本降低执行效率，就像缺乏润滑的机器。本文主要讨论的内容就是让参与项目的干系人能够按照合理的方式进行沟通，快速达成统一认识。就如同把高效的干系人管理手段当成润滑剂注入项目这台机器，让项目能够高效运转。
一、引言
作为项目的参与者都希望正在参与的项目能够像一台保养良好的机器，各个部件紧密配合，能够高效平稳地运转。那么有效的沟通管理让项目干系人都能够有效的为项目出力，就成为了项目成功与否的一个关键因素。通常不同的项目干系人因为职位、文化、技术等不同的立场，导致对同一个问题的理解也不尽相同。如果不能及时达成一致，则需要花费更多的时间和精力。就如同缺乏润滑的机器，运作缓慢，甚至陷入停滞的状态。本文想探讨的就是找到项目沟通中常见的问题，并采用行之有效的办法使沟通变的高效顺畅，就像把润滑剂注入机器，让机器重新恢复快速运转。
二、导致项目运转不良的常见问题
现在的项目团队组成往往呈现复杂化的趋势，在IT项目中这种现象尤为显著。从职责上区分，有需求人员、开发人员、测试人员、质量保证人员、项目管理者等；从所处的立场区分，有客户、项目组、投资人、高层管理人员等；从各自擅长的领域上区分，有业务、技术、管理等。不同的项目干系人的在项目的不同阶段对项目要求的也不尽相同。而在如此复杂的沟通环境中，总会出现这样那样的问题。其实人与人的沟通过程就如下图所示的IT项目中的必不可少的编码解码过程。信息发出者会根据自己的理解组织语言文字然后传达给接收方，这就如同编码过程；信息接收方则会按照对自己的方式理解信息的具体内容，这就如同解码过程。一条信息能不能被正确地理解，是不是能够按照统一协调的方式进行编码和解码就显得尤为重要了。下面我们就来看看3个典型容易导致编码和解码方式不能顺畅进行的问题。
图1：沟通模型
（一） 先入为主
先入为主又是沟通中经常遇见的另一个问题。美国社会心理学家洛钦斯曾经做过一个经典的实验。他杜撰了描述一个名叫詹姆的人的两段文字，一段是描写他在路上与各种人交谈打招呼，另一段是描写他安静地喝饮料看书。把打招呼作为第一段进行阅读的时候，78%的人认为詹姆是一个外向的人。而反之把安静看书的这段放在前面进行阅读的时候，只有18%的人认为詹姆是外向的人。这就是心理学中常说的认知过程中最初形成的印象起着非常重要的作用，这被称之为首因效应，也就是常说的先入为主。
现代心理证明当不同的信息结合在一块的时候，人们总是倾向于重视前面的信息。即使信息不一致，往往也会把后面的信息当做偶然而非必然，不经意间根据前面的信息解释后面的信息，以便形成整体印象。在项目的沟通中这种情况也是时常发生的。例如，技术或者业务方案讨论时，大部分人都会按照自己最初的想法进行设计和规划；再比如，人力规划的时候，依旧按照以前了解的情况进行任务分配等。当预设立场也就是先入为主的观念在脑海中慢慢形成的时候，沟通中就难免出现各种误会了。
（二） 讲不清、没听懂
在沟通中的另一类典型的问题就是表达的人没有说清楚，接受信息的人没有理解真正的问题。这里我们再看一个网上流传很久的经典小段子，程序员买瓜的故事。一个程序员的老婆给他打电话说：“下班顺路买个西瓜，要是看到西红柿就买两个。”结果呢，这个程序员买了两个西瓜回家。按照他老婆或者说大多数人的思维，对这句话的理解应该是，顺路买一个西瓜，要是有西红柿就买两个西红柿。但是程序员呢，就把这句话当成了编码里常见的条件语句。他是按照下面的编码方式理解的。
函数名 顺路买西瓜（）{
If（没有西红柿） {
买一个西瓜；
}
else If（看见西红柿）{
买两个西瓜。
}
}
如上面的函数所示，这段代码如果真的能编译执行，那么在看见西红柿的情况下，就是买了两个西瓜。
我们可以看到在这个问题上程序员的老婆讲清楚了吗？没有，她没有明确地说出她还需要买西红柿的需求，埋下了误会的隐患。程序员听懂了吗？显然也是没有，程序员没有理解他老婆的真正需求。这类听不懂或讲不清的问题往往成对出现，很难说清到底是谁没讲清楚，或是谁没有真正听明白。而最容易发生这个问题的阶段就是在需求分析阶段，当业务人员与技术人员进行需求讨论的时候，就是不懂技术的人与不熟悉业务的人要把技术业务问题一起讨论清楚，因为相互的不了解出现误解的概率就很高了。大家也都会有这样的经验，当客户进行实际体验或是验收的时候，客户满腹牢骚：“这就不是我想要的东西”，而技术人员委屈地说：“都是按您的要求做的啊！”。
（三） 没有及时正确的反馈。
不知道大家有没有碰到过这种情况。A在评审B的代码的时候，根据自己的经验跟B说了对一个问题的看法，觉得某个业务函数调用的太频繁，可能会造成性能下降。B在梳理业务需求之后发现这就是客户的要求，没有必要改。但是B只是回复“知道了”并没有修改，觉得这个既然是客户的要求，就是理所当然的。结果在交付代码时A发现这个代码没有修改不同意交付。从而引发了出不少争执。
上面的情况就是接受信息方，并没有对信息发送者进行清晰及时的反馈。这样作为发送方，也没有办法对于后续应该的动作进行正确的规划。拿上面的问题来说，如果B回复“这是客户的要求，性能下降，也是在客户允许的范围内，所以不用修改。”这样A就可以根据技术业务数据进一步判断不需要修改代码的合理性。所以即使是拒绝或者否定对方的信息，也需要清晰及时地进行反馈。才能保证信息的传递形成一个有效的闭环。
除了上面3个比较典型的问题之外文化的差异、成长环境的不同、看问题角度的不同等因素都会造成沟通的误会。在项目推进中应该尽可能避免这些误会的出现。
三、通过对沟通的规划形成有效的体系
大家看到了上面的几个问题，一定会问我们怎么才能既能进行高效的沟通，又能避免沟通中出现的各种误会呢。在这里要说的是，沟通离不开见招拆招去随机应变，但是更需要的是对沟通进行合理有效的规划，从而形成完整的沟通体系。依靠体系去识别沟通中的人和事，也要依靠体系引导沟通向预想的方向发展，更需要依靠体系保证项目目标最终能够实现。
（一） 沟通离不开“以人为本”的基础
沟通始终离不开的核心因素就是人，所以“以人为本”就成为的沟通的基础。因为我们是讨论项目中的沟通管理，我们就先来了解一个概念“项目干系人”。项目干系人是参与项目或利益可能受项目实施而受消极或积极影响的人或组织。对项目来说，关键的联系人有，客户、投资人、组织高层、PMO、项目经理、职能经理、业务伙伴等。每个干系人对项目都有着不同的利益诉求，也有着不同的权利和义务。下图就是在项目的干系人管理中常用的权利利益矩阵，通过这个图告诉我们对应不同的利益和权力，应该采用什么样的沟通策略。
图2：权利利益矩阵
清楚需要进行沟通的项目干系人所处的位置后，就可以进行“看人下菜碟”式的有针对性的沟通方式了。从这张图上最需要重点关注的肯定是位于D区的干系人，他们对项目既有很高的权利，对项目的结果也非常在意。比如客户、最终用户、项目核心技术业务人员或是项目经理以及团队的直接领导就属于这类人。所以要重点管理，及时汇报，尽可能采取有力的行动保证这个区域的人对项目进展情况随时了解，力争满意，以便对项目继续推进形成积极的影响。
B区的人虽然权利小，但是自身利益受项目影响大，所以非常关注项目结果。因此要随时告知项目的进展用以维系满意程度。因为大部分项目成员是属于这个区域的，所以如果低估了他们的利益，可能产生严重的后果。
C区的人权利虽然大，但是自身利益受项目影响较小。如公司股东、高管之类的人。因此争取他们的支持对项目来说也是至关重要的。对于他们的管理策略就是保证合理的汇报内容以适度的沟通频率，让其对项目保持满意状态。
对于A区的人来说，给予足够的尊重，争取他们的支持，降低可能的敌意，就足够了。在整体精力有限的情况下，用最少的努力维持合理的关系即可。
（二） 沟通少不了“洞悉一切”的慧眼
前面说过沟通中因为这样或是那样的原因，会产生很多的误会。既然是误会，就说明没有搞明白对方的真正意图。所以想方设法看清楚对方的真正目的就显得尤为重要了。
做过项目尤其是IT项目的人大多都有过项目进行过程了，客户又要追加功能的情况。遇到这种问题的时候，项目组大多数人的反应就是反感，容易与客户发生争执。但是客户毕竟是客户，事情又不能不做，做了又影响项目的进度和质量，于是乎陷入两难的境地。
想破解这个难题，除了尊重对方的态度、柔和的沟通技巧之外，想根本解决这个问题，那就需要首先搞清楚客户的真正隐含需求是什么。而这种需要才是客户衡量项目的真正标准。表面上客户变更的原因可能是不一样的：有的因为重要的功能发生遗漏，有的因为外部承诺的变化，有的因为可以提升上线后的工作效率等等。但是对于客户以及项目组来说，项目都只有三个核心因素，范围、进度、资源。那么就可以缩小范围从这三个因素中找到客户真正最在意的那个。如果进度是必须保证的，那么对于项目的范围上是不是可以进行优化或者删减。如果范围是不能变的，进度上能不能合理地延长。另外资源上可不可以得到补充。总之在搞清楚客户的真实意图之后才能明白对项目的实际影响，进而找到合理的平衡点，提出有效的解决方案。即便可能超出项目组的决策能力之外，也能利用这些实际的真实信息，帮助项目外的高层领导作出合理的决策。
解决需求以及技术分歧的时候也是同样的道理，一定要搞清楚对方真正想要的东西，才能提出双方都能接受的共赢方案。
（三） 沟通省不掉“按部就班”的计划
说到沟通，很少有人觉得自己有问题。因为每个人每天都需要不断跟不同的人进行沟通。所以每个都都有自己的沟通习惯。再加上我们上面所说到的各种问题产生的影响。
使得很多时候会发现沟通的各方不在一个频道上，整个沟通变的生涩。都说无规矩不成方圆，想要让项目的沟通变成“按部就班”的稳定状态。就需要我们把沟通的计划定下来。
项目沟通计划是确定利害关系者的信息交流和沟通要求。项目干系人都必须准备该项目“语言”进行沟通。并且要明白：每个项目干系人所参与的沟通将会如何影响到项目的整体。谁需要何种信息、何时需要以及相应如何将其交到他们手中就好通过沟通方式和手段。因而沟通计划对于项目的成功很重要。沟通计划的依据包括：沟通要求、沟通技术、制约因素三个方面。确认项目沟通要求的信息一般包括：项目组织和各利益相关者之间的关系；该项目设计技术知识；项目本身的特点决定的信息特点；与项目组织外部的联系等等。
好的沟通计划具有可行性。考虑问题的影响因素是否全面和解决问题的方法是否可行决定了计划的可行性和可操作性。计划需经过各方的认可，方可公布。是执行和控制的有力保证。
四、能帮助我们的几个沟通技巧
说了不少沟通的规则，那么我们再来看看沟通的技巧。沟通的技巧能够让我们把沟通做的更平顺更圆滑更容易让人接受。
（一） 同项目组内部沟通
项目组内部首先要做到及时准确，因为是项目组内部，为了保证沟通的及时性，沟通的方式可以不用非常正式。但是沟通中必须保证双方都能准确理解对方的真实意图。当然事后需要通过正式的方式确认。其次对于项目中重要的工作内容，需要多次确认强调，保证计划顺利实施。当然处理具体问题的时候，切记要对事不对人。保障进行内部沟通时内部人员敢于发言，这样才能收集到项目内部的真实信息，并据此制定真正可执行的项目计划。
（二） 和外部客户沟通
和外部客户沟通要保证能够建立起一条顺畅而且标准的内外部沟通渠道。内外部信息交换都需要经过这条通道。凡是不通过该通道的信息可以视为无效信息。这样能够减少信息收集的难度，也能尽可能保证信息的准确。在对外沟通的时候，一定要记住，对于决策性的沟通内容，一定要通过双方都接受的正式方式进行确认。确保沟通结果能够按照双方真正理解的方式，在项目中得到执行。
（三） 与公司高层沟通
公司高层通常比较忙，所以没有时间听大段的汇报。沟通前一定要明确想通过高层获得什么样的资源、或是解决什么样的问题、亦或是想了解什么样的内容，只有明确的目的性才能保证沟通能够围绕目标简洁明了。虽然表达观点简洁明了，但是在高层产生疑问时就要用充分的分析和论据进行说明。这就需要充足的准备工作，可以提起进行沙盘推演，以免因为紧张而没有把问题阐述清楚。
（四） 其他的技巧
首先要做到的就是真诚，而且真诚要胜过一切技巧。在沟通的时候，用心去体会对方的立场以及想法。其次要耐心聆听，努力去做一只“空杯”。不要预设立场，接纳对方的观点，海纳百川有容乃大。还有kiss原则，这里是Keep It Short & Simple的缩写。意思很直接，就是告诉我们沟通的信息需要简洁明了。毕竟不是写作文，项目沟通追求的就是高效准确。
五、案例浅析
最后我们来看一个案例，如何处理一个棘手的项目变更。
正当一个项目正在紧张赶进度的时候，客户方负责人H突然提出更改项目方案，修改部分接口设计，将系统的一部分提前上线。此方案对项目组非常棘手，需要改变很多，增加额外工作量，而且新老系统同时运行风险极大。可不论项目经理M如何解释，H依然坚持。冷静下来之后M向自己的高层领导S汇报了这一情况。S利用自己与客户高层良好的关系，对项目情况进行了了解。原来对方的高层负责领导刚刚发生变化，新上任的高层领导觉得这个项目极为重要，不允许有闪失，但周期长任务重，担心一次性上线有风险，而决定分批上线降低项目整体的风险。在获悉真实情况后，M通过自己的高层领导将项目变更的风险向对方的高层领导进行说明，争取了一次宝贵的双方高层领导都参与的项目说明会。会前安排项目骨干将项目的实际情况以及如果按此方案实行所带来的巨大风险通过数据加以细致分析并形成汇报材料。在会上把握住对方最在意的是项目能否平稳顺利上线运行，而缩短时间相对次要的心理，站在客户的角度尽可能充分论证。在对方态度软化以后，随即提出解决方案，重新规划项目工作计划，需要多投入一部分资源，从而达到项目整体可以提前进行试运行降低项目整体风险的目的，不过需要客户追加一部分预算。客户方在权衡利弊之后同意了该方案。
在这个案例里，我们可以看到，项目经理在解释无效的情况下，冷静地利用自己的高层领导搞清对方的真实意图。进而充分准备，论证了客户的方案其实风险更大，并没有达到降低风险的目的。最后，在获得客户理解的基础上，提出了双方都能接受的合理方案。从而化解了一个棘手问题。
六、总结
项目沟通是个复杂的管理任务。通过本文，我们可以知道，要对项目干系人进行有效的识别，深挖需求。进而针对性的建立合理的沟通规则和体系。避免出现不必要的误会。希望能让良好的沟通成为润滑剂，向项目这台机器平稳高效地运转，最终建成直冲云霄的通天塔。
