咨询:谈项目管理中的沟通管理(1)
第一，积极有效的沟通
沟通管理的目的是保证项目信息的及时、正确的提取、收集、传播、存储和最终处置，保证项目组内部信息的畅通。在这个过程中，项目经理责无旁贷地成为信息传递的中心和中转站，同时避免成为信息流通的瓶颈。我认为项目的沟通主要包括与业务部门的沟通、与部门领导的沟通、项目组成员之间的沟通(包括与项目组外部资源的沟通)、与外联公司的沟通以及与其他兄弟部门(包括CS中心、NFSJ中心)的沟通等等。
1，与业务部门沟通
与业务部门的沟通一般从项目前期开始。在这项工作中，我认为有以下几点需要注意:充分分析业务部门的需求和需求的关键部位，有的放矢地进行沟通；
。让对方在一定程度上(即有利于项目组工作的程度)了解项目组的实际情况，先提出困难，增进相互了解；
。在需求的沟通中，业务的专家地位可能并不明显，项目组在条件允许的情况下可以更深入地参与业务需求的讨论，甚至引导需求，即技术引导业务；
。在项目过程中形成良性循环，就是前期积极发掘需求，中期合理安排客户体验，后期协调验证测试；
。如果沟通效果不理想，就要及时提出问题，寻求各级相关领导和职能部门的协助，合理借用外力，以达到项目团队的既定目标——项目成功。
这里我以BYXM部门某项目经理的项目为案例来说明，“XX项目”，该项目涉及的对账系统决算为380(人-天)，理论工期为7.8个月，实际工期为2.2个月。涉及:6个系统。估计的版本缺陷密度是46(ZX平均值是15.3)。最终，项目顺利建成投产。业务反馈极好，发了感谢信，在上次中心满意度调查中也给了高分。其实这个项目的实际情况是:|考试大|咨询工程师|时间很紧，任务很重，需求不明确。可以说是因为业务问题，很难和公司合作。但从项目开始到结束，在项目经理的领导下，项目组时刻与业务代表保持密切沟通，从不拖延解决存在的各种问题，每天将项目各阶段的进展发送给项目干系人，保证各方面信息的一致性。项目组成员包括业务人员在短时间内已经成为一个团结紧密的群体，业务人员也能理解项目组成员所做的努力，打下良好的客户基础。
事实上，在很多情况下，业务人员对我们项目的最终交付结果并不满意。关键是，在缺乏沟通的背景下，我们最终的交付结果偏离了他们的预期。如果我们可以在整个项目生命周期中安排业务进行讨论、分析和体验，那么我们就可以积极地调整和改善业务代表对我们的项目和我们的系统的期望，这样无论最终的项目有多困难，业务都会有所准备。同时，在沟通的过程中，他们也一定会理解我们的实际困难，尽可能看到我们的努力，以及此类项目最终的业务部门反馈。
2.与部门领导的沟通
在项目管理过程中，与部门领导的沟通是不可避免的。由于在中心现行的矩阵结构管理模式下，职能部门的权限大于项目经理的权限，项目经理在项目管理中会不断与各职能部门的经理打交道，项目经理也会定期向所在部门的领导汇报项目情况，寻求项目支持。我认为与部门领导的沟通应注意以下几点:
。寻求支持的邮件一定要明确描述问题的关键点和领导需要哪些具体的支持，根据具体问题给领导1-3个选择，并指出项目组更倾向于哪个选择以及为什么，而不是直接把问题扔给领导；
。我们必须明确各级领导的权力和作用。解决问题时，一定要找到关键路径上的关键领导，避免同时向多个领导发布信息，增加领导之间的沟通成本，影响解决问题的效率，增加领导协调解决问题的难度。
。对于一些问题，不要盲目的向领导妥协，不要盲目的去做实际上不可能完成的项目。这不仅是对工作的负责，也是对领导和项目组的负责。
3.与项目团队成员的沟通
对于项目经理来说，大型项目主要是和各种应用的职业经理人和架构师交流。这里我用自己的项目来说明一些需要注意的问题。
在XX项目的系统测试阶段，开发经理和测试经理就提交的试题数量发生了争执。开发经理认为测试部门提交重复题，数量太多。测试经理认为项目办公室把测试基准值给了测试部门，她据此执行了，并且她认为开发经理偏向开发人员，拒绝修改的问题回答太简单。针对以上情况，我先了解了一下基准值，基准值是项目办根据发布前每个应用的历史数据给出的每100个功能点问题数的参考值。比如本项目涉及的参数管理应用，13分100个功能点多题，但这只是一个参考值，测试经理没必要以此为依据控制题量。同时去找测试经理了解实际情况。有些问题确实是一样的，但是BYCS部门的要求是回复的时候可以选择同样的问题，但是不要直接回电拒绝修改并声明是同样的问题。这也是L总经理在测试部门反复强调的，所以这种情况下测试经理是绝对不会同意关闭的。同时从开发方了解到，开发人员非常反感对一个通用模块提出多个问题。在修改程序和填写问题列表时，他们必须填写多条记录。而且开发经理的反馈是，其他测试人员提交的重复问题不多，但是测试经理自己提交了很多，感觉测试经理是故意的。针对这种情况，在与开发经理和测试经理沟通后，我提出了以下要求:首先，为了保证测试的进度和质量，测试中发现的问题要提出来，但不一定要以测试基准给出的值为测试标准，要以实际情况为准；其次，开发人员和测试人员要多沟通，避免出现一个公共模块从源头提出多个问题的情况。但是，如果提交了问题，开发者会把问题当作一样的问题来对待，不拒绝修改。我还告诉开发经理，项目中有效问题的数量不会受到影响。同时出于个人面子的考虑，我单独和测试经理沟通，要求她避免提交太多同类型的题目，你可以先和开发经理打个招呼再提交。另外，我也请两位职业经理人考虑，是和谐的工作氛围还是充满火药味的工作氛围对双方更好，因为项目涉及的申请后的所有牵头合作项目都是由两位职业经理人协调的。目前项目的系统测试已完成85%，平均问题解决效率不到2天，问题数量控制在800个功能点左右。开发部门和测试部门都对这个结果感到满意。
从这个案例来看，我认为关键是项目经理在收到各种信息后不要急于下结论，因为这个结论很可能是片面的，或者根本就是错误的，要对信息进行有效的确认。同时，在沟通的过程中，项目经理要合理地切换岗位，有时从项目的岗位，有时从职业经理人的岗位。最后一点就是在项目管理过程中坚持公正公平的原则，对项目涉及的应用不偏不倚，只谈问题的解决，不谈个人问题的其余部分。