大家都知道项目经理的大部分工作就是进行沟通：与项目成员沟通、与上司沟通、与相关业务部门沟通、与客户沟通等等，其中一个主要的内容就是沟通项目的进度和状态/问题，本文分享了笔者在日常项目管理过程中总结的一些小的心得体会供大家参考。
首先，理解什么是有效的沟通，然后结合具体项目讲述如何实现沟通的有效性。
如何理解沟通的有效性。在谈沟通的一些文章中有一个著名的漏斗理论，就是一个人通常只能说出心中所想的80%，但对方听到的最多只能是60%，听懂的却只有40%，结果执行时就只有20%了，而三个月后只有5%存留在对方脑中了。
因此，在沟通过程中需要重点关注被听懂了的40%，实际项目中经常出现需求方（市场、商务、产品等）和实现方（技术开发、视觉交互、测试等）沟通不畅和理解偏差的问题，由于这两类角色关注的领域不一样（需求方关注的是商业价值、做什么的问题，而实现方关注的是如何做和什么时候可做完的问题），那么如何提高这两方的沟通效率呢？除了使用下图中的DoD方式外，还有一种方法就是让实现方进行需求反讲，如果能够复述出来那么就应该是听懂了。这个模型类似于TCP通信中的三次握手协议：
首先由需求方描述需求；然后实现方进行复述；最后需求方进行确认。
那么，有效沟通至少是项目经理/需求方同时要能自信清楚地表达的想法，实现方/接收方清楚理解并能够达到可复述的地步。
接下来笔者将分别讲述与业务部门、团队成员、PMO部门及其他干系人，如何进行有效的沟通。
一、与业务部门沟通项目的进度、问题
在弱矩阵组织架构中业务部门是我们项目经理的客户和服务对象，项目经理通过成功的交付项目使之满意，并通过提高各业务部门的价值来体现项目经理的作用。
如何与业务部门进行有效的沟通。那“有效的40%”包含哪些内容呢？笔者在与业务部门进行沟通时主要有以下几个方面：
项目的现状是什么，客观而独立的给出判断，可以通过项目天气图标或者项目红绿灯的方式来表示一个项目的总体状态。需要一定的勇气和相关的度量指标来协助我们项目经理进行客观独立的判断。一些比较常用的度量指标有：
1.计划偏差率/计划达成率；
2.质量指标（bug 收敛情况、线上bug/投诉等）；
3.风险发生概率和影响程度；
4.人力资源/费用使用率以及是否满足未来需求；
5.一些运营指标：活跃用户数、销售额、PV/UV/VV 等。
项目中遇到的问题原因分析，并进行归纳总结。项目中出现任何问题项目经理都应当第一时间组织相关人力、物力进行解决；对于业务部门本身由于人力资源紧张而导致的项目资源冲突，项目经理需要组织资源负责人一起沟通，从部门整体角度来看如何进行项目取舍；并在事后与业务方一起对重点问题进行原因分析和经验总结。
建议下一步如何做，最好能够辅以SWOT分析。如业务部门中经常遇到的各自为政的情况是否可以通过建立功能团队来解决；项目经常延迟，原因也许是不断有维护任务打断开发人员的工作，是否可以成立专门的维护任务小组和开发项目小组来解决？项目经理可以通过望、闻、问、切等手段来发现业务部门存在的问题，并提出相应的解决方案供大家讨论。
在与业务部门沟通过程中需要注意/避免的一些事情是：
不要假设自己是产品经理而对需求进行决定；也许有时你很希望有/没有哪一个功能，但不能在项目需求列表中强行加入，而需要在需求讨论会上提出自己看法以供讨论。
在做计划时需要包含团队成员来进行项目计划而不是一个人武断的进行承诺，如果团队规模较大而又在项目初期的话可以先由对应的架构师、团队负责人来进行大致的估算和计划，待项目更详细的需求被定义、更清楚的视觉稿被通过，则可以召集相关的团队成员对这些大致的项目计划进行进一步的细化和承诺；当遇到问题时需要做解决问题驱动者、协助者而不是解决者。
二、与项目组其他干系人沟通项目的进度和状态
项目团队是实现项目目标的主体，而发现问题、组织讨论和处理问题是项目经理的主要职责之一，因此我们需要使团队成员真正的参与项目而不是为项目打工、为策划团队打工，笔者认为透明性和可视化是使团队成员参与到项目的很好的途径。
项目透明性主要包含项目计划、需求、进度、问题、风险等方面的透明，透明意味着只要项目团队想看这些内容就能迅速的找到这些内容，或者通过‘消息推送’机制将项目中的主要变化、项目简报通过IM，Email等方式推送给项目团队。
项目可视化，主要可以使用电子文档库（如团队wiki、共享文件夹、FTP等方式），或者使用物理白板的方式来呈现项目的状态。对于同一办公室的项目团队而言使用物理白板、项目墙壁的形式都能很好的公布和传递项目状态和变化，如Scrum 敏捷项目管理中使用白板的todo, in-proress, done 等状态和燃尽图来表示任务的进展情况。如果能够达到项目成员的目光所及之处就能够获取到项目相关信息那是最好不过啦。
让团队来讨论如何解决问题，在敏捷项目管理相关的培训和书籍中经常被提到的一句话就是“take it to the team”，不论我们是否采用敏捷方式的项目管理方法，还是采用瀑布模型式的项目管理方法，让团队来讨论如何解决问题是最好的方式。既可以提高大家的参与度也可以众人拾柴火焰高找到更优的解决方案。例如包含项目团队来做WBS、项目计划就是很好的例子，并且由项目团队参与制定的项目计划是最具有执行力的。
促使团队通过反思来提高，项目经理除了组织和协调项目团队交付项目外，还需要通过采取一些措施促使项目团队的成长，而每个里程碑或项目结束后的总结反思会则是促使团队提高的最佳时刻。如可以通过简单的K.P.T [1]三个方面来展开讨论，即团队认为哪些是上一阶段做的好的需要继续keep；哪些方面是有问题的；哪些措施和方法希望在后续工作中进行尝试的。
三、与项目组其他干系人沟通项目的进度和状态
在弱矩阵环境下的项目经理除了上面所列举的一些关键方面人员沟通外，可能还需要与各子项目的负责人沟通(如果是多项目管理模式下的情况)、商务市场人员等。
一般而言商务市场人员是非常关心上线时间节点，因为这都是大部分市场推广运营活动的起点、触发点，在项目的上线时间点有变化时候一定要第一时间并且最好是F2F的进行沟通和说明变化、以及变化背后的原因是什么。
以下是笔者在一个业务部门与项目集中的各子项目经理的沟通的一些方面：
每周三安排一次1-1 进度和状态沟通过程，周五进行书面项目周报，对于一些各子项目经理遇到的问题给出建议和跟踪一些主要问题的进展。这其中需要避免轮询式的进度状态汇报会议，否则就浪费很大部分其他与会人员的时间；
组织每两周一次的项目经理间分享会议，除了各子项目经理的项目交付/里程碑交付后的心得、经验、教训分享外，我也会在会议上把过去两周观察到的一些情况进行反馈，和分享一些业界的社区活动和项目管理领域的一些新的点子等。这样的会议能够比较好的形成讨论和相互提高的氛围。
四、与PMO部门沟通项目的进度、问题
PMO部门是我们每一位项目经理的‘娘家’，犹如《阿凡达》电影中的‘母体’，是一个大家可以畅所欲言和进行自我提升的地方，通过参与讨论、分享来相互帮助和共同提高。在与PMO部门成员沟通中主要涉及以下方面：
主要项目的进度和状态，也许每个项目经理承担了一个或多个项目的项目管理工作，在与PMO部门的沟通上可以聚焦在有风险的项目上或者说有问题的项目上，略过一些相对安全的项目，这样大家就聚焦在一些讨论、分享上而不是项目状态的轮询上。
讨论项目中所遇到问题背后的根本原因，沟通中大家会就某个现象背后的原因进行分析，例如每个项目的延迟原因会有多种多样（如依赖关系变化、需求调整、资源变更等），但也有一些共性可以供大家参考，也许今天A项目经理遇到的问题会成为我明天项目的问题。RCA(Root Cause Analysis)分析法、鱼骨图分析法都是常见的问题原因分析法。例如，某些项目中通过执行的上线评审会、线上问题处理流程来减低线上事故发生，可以为其他项目所借鉴和参考。
讨论用什么方法、措施来处理项目中的问题，有时候一个项目的问题可能以前在其他项目中被处理过。例如日前我们有位项目经理遇到如何制定、推行线上事故处理流程的问题，恰好另外一位项目经理以前有在大型电信通讯产品公司参与过类似的流程制定、执行步骤，在此基础上比较事半功倍的制定出适合这个项目的线上事故流程。
经验、教训分享，从分享项目周报格式内容到项目站会的内容形式等。例如Q2中的每个礼拜找出一个半小时由每一位项目经理来分享他/她是如何执行项目的，这不是对项目的审计，而是以开放的心态通过每位项目经理从项目背景、计划、执行、风险、结项等环节的描述来形成讨论的氛围、提供相互学习的渠道。在这一环节的讨论中也不仅仅局限于讨论项目相关的内容，有时也会讨论一些部门本身发展、定位的‘大’问题。
这样通过对项目现状的描述、遇到问题的讨论、背后原因的分析、经验的借鉴、分享以及延伸，实现与PMO部门内的有效沟通。
有效性沟通的一些tips。在弱矩阵组织架构下关于项目经理日常沟通，笔者建议需要保持良好的心态、服务的角色来与相关部门、人员进行沟通，具体而言就是：
摆正态度，心中要时刻保持一种“PM is an overhead cost”的心态（因为项目经理的价值是通过团队提高效率、节省成本等方式体现的，项目经理无法直接贡献编码、测试等工作）。有了这样的态度后那么其他沟通中的一些方法、技巧运用就会水到渠成了，如通过认真倾听，建设性的提出观点。
始终有计划在心中，有建议的方法和措施在心中，项目经理很多时候是项目节奏的控制者，无论是临近上线时的变化还是遇到不可预知的问题时都需要保持冷静，始终有一份计划在团队和自己的心中来指引大家前进，如果项目经理不保持冷静的话那么团队成员就会变成了一团马蜂窝。
对事不对人，成功帮助业务部门交付项目是我们的职责，以业务部门的利益为出发点，客观、公正的进行相关工作。
本文作者
