浅谈项目管理中的沟通管理（一）

　项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内完成项目的各项工作。项目管理的内容涉及到诸多方面，比如项目的计划、控制、度量等等，而在这些过程当中，沟通是贯穿始终，必不可少的一个工作，我记得上次在清华光环管理培训中心的调研面试中，面对老师的提问“你认为沟通应该占项目经理日常工作的百分之多少？”，我说“项目经理日常工作的80%”，“那剩下的20%做什么？”我说“剩下的20%就是准备沟通的内容，以期达到沟通的目的”。虽然答复有些许夸张，但是沟通确实已经成为项目经理日常工作的一个重要组成部分，而且是贯穿项目整个生命周期的一项持久工作，这项工作的好与坏直接影响项目的过程控制和最终的项目质量。　　　
　　一、积极有效的沟通　
　　沟通管理的目的就是要保证项目信息及时、正确的提取、收集、传播、存储以及最终进行处置，保证项目组内部的信息畅通。在这过程当中，项目经理责无旁贷的成为信息传输的中心和中转站，同时又要避免成为信息流通的瓶颈。我认为项目的沟通主要包括与业务部门的沟通、与部门领导的沟通、项目组内成员之间的沟通（包括与项目组中外部资源的沟通）、与外联公司的沟通和与其他兄弟部门（包括CS中心、NFSJ中心）之间的沟通等等。　　　
　　1、与业务部门的沟通　　　
　　与业务部门的沟通一般从项目前期阶段就开始了，在这工作当中，我想有以下几点需要注意：。充分分析业务部门的需求，以及需求的重点部分，沟通做到有的放矢；
　　。让对方在一定程度上（即有利于项目组工作开展的程度上）了解项目组的现实情况，有困难一定先提出来，增进双方的相互理解；
　　。在需求沟通中，业务的专家地位可能不很明显，项目组在有条件的前提下可以更加深入的参与业务需求讨论，甚至引导需求，即技术引导业务；
　　。在项目过程当中形成前期积极进行需求挖掘、中期合理安排客户体验、后期协调验证测试的良性循环；
　　。如果沟通效果不理想，要及时上升问题的高度，寻求各级相关领导和职能部门的协助，合理的借用外部力量达到项目组的既定目标-项目成功。
　　这里我举BYXM部一位项目经理的项目作为案例加以说明，《XX项目》，这个项目涉及的对账系统决算规模380（人天），理论工期7.8月，实际工期2.2月。涉及：6个系统。预估版本缺陷密度为46（ZX平均15.3）。最后该项目得以成功完成，并顺利投产。业务反馈极佳，并发来感谢信，在上次中心满意度调查中也给予了很高的分数。其实该项目实际情况是：时间非常紧，任务也很重，而且需求不明确，配合公司由于商务问题不能及时支持，可以说困难重重。但从项目开始到结束，项目组在项目经理的领导下与业务代表时刻保持着紧密的沟通，对于存在的各种问题从不拖延解决，每天将项目各阶段的进度情况发与项目干系人了解，保证各方面信息的一致性。项目组成员包括业务人员短期内成为了一个团结而紧密的团体，业务人员也能够了解项目组成员为此付出的努力，并打下了良好的客户基础。
　　其实很多情况下，业务人员对我们的项目最后的交付成果不满意，关键是在缺乏沟通的背景下，我们最后的交付成果和他们的预期产生了偏差。而如果在项目整个生命周期中能不断的安排业务来进行讨论、分析和体验，那么就可以主动的调整和完善业务代表对我们项目、对我们系统的预期值，这样最后的项目不论多么困难，业务也都是有心里准备的，同时在这个沟通的过程当中，他们一定也会体谅到我们的实际困难，看到了我们为此做出的尽可能多的努力，这样的项目最后的业务部门反馈的结果一定不会差。
　　2、与部门领导的沟通　
　　与部门领导的沟通在项目管理过程当中是不可避免的，由于目前中心的矩阵结构管理模式中，职能部门的权限要大于项目经理的权限，所以项目经理在项目管理中一定会不断的和各职能部门经理打交道，同时项目经理还要定期的向本部门领导汇报项目情况，寻求项目支持。我认为与部门领导的沟通有以下几点需要注意：
　　。寻求支持的邮件一定要简练的描述清楚问题的关键所在，需要领导哪方面的具体支持，最好根据具体问题给领导1-3个选择，并指出项目组倾向于哪个选择，原因是什么，而不是把问题直接扔给领导；
　　。一定要清楚各级领导的权限和角色，解决问题时一定是要找到关键路径上的关键领导，避免信息同时发布多个领导，造成领导之间的沟通成本加大，影响问题的解决效率，增加领导协调解决问题的难度；
　　。对于有些问题，不要一味的向领导妥协，不要一味的承诺实际不可能完成的项目工作，这既是对工作的负责，也是对领导、对项目组的负责。　　　
　　3、与项目组成员之间的沟通
　　对于项目经理来说，规模较大的项目主要是与各应用的专业经理以及架构师之间的沟通。这里我用自己带的一个项目来说明一些需要关注的问题。
　　《XX项目》在系统测试阶段，开发经理和测试经理关于提交的测试问题数量存在争论，开发经理认为测试部门提交问题重复，且数量过多；而测试经理认为项目办对于测试部门给出了测试标杆值，她是按照这个来执行的，而且她认为开发经理一味偏袒开发人员，且拒绝修改的问题答复过于简单。针对以上这些情况，我首先了解了一下标杆值的问题，这个值是项目办根据每个应用以往的历史数据给出的每百功能点发版前的问题数参考值，比如该项目涉及的参数管理应用是百功能点13点多个问题，但这只是一个参考值，所以测试经理以此作为依据进行问题数目的控制是不必要的。同时我去测试经理那里了解了一下实际情况，部分问题确实是相同问题，但是BYCS部的要求是回复的时候可以选择相同问题回复，但是不要直接打回拒绝修改且写明是相同问题，这也是L总在测试部门内部一再强调的，所以碰到这种情况测试经理坚决不会同意关闭。同时我在开发这边了解到，开发人员对于一个公用模块提多个问题非常反感，修改一处程序而填写问题清单的时候要填写多条记录，而且开发经理反馈实际上其它测试人员提交的重复问题并不多，而测试经理本人提交的很多，感觉测试经理有意而为之。针对这种情况，我和开发经理、测试经理沟通之后做了如下要求：首先为了保证测试进度和质量，测试方面发现问题该提就提，但是没有必要以测试标杆给出的值作为测试标准，要以实际情况为准；其次，开发人员和测试人员多沟通，从源头上避免一个公共模块提多个问题的情况，但如果一旦问题提交了，开发人员就按照相同问题处理，不要拒绝修改，这个我也告知了开发经理对于项目的有效问题数不会有影响。同时由于考虑到个人面子问题，我和测试经理单独做了沟通，请她避免提交过多相同类型的问题，提交之前可以先和开发经理打个招呼。另外我也请两位专业经理考虑，由于项目所涉及应用之后的所有牵头配合项目都是两位专业经理配合工作，到底是一个和谐的工作氛围还是一个充满火药味的工作氛围对双方更好？目前项目系统测试已经完成85％，问题解决效率平均不超过2天，问题数也控制在百功能点8个左右，开发部门和测试部门均较为满意这样的结果。
　　从这个案例当中，我认为关键在于项目经理接收到各方面信息之后，不要急于做出结论，因为这个结论很可能是以偏概全或者根本就是错误的，要对信息进行有效的确认。同时在沟通过程当中项目经理要做到立场的合理切换，有时候要站在项目的立场上、有时候站在专业经理的立场上。最后一点就是要坚持项目管理过程当中的公正、公平原则，对项目所涉及应用不偏不倚，只谈问题的解决不谈其余的个人问题。