谈谈IT项目中的沟通管理

谈谈IT项目中的沟通管理

--------------------------------------
作者：王辉
发布日期：2002-12-30
--------------------------------------

1 前言

在IT项目中，要做到一个项目迅速成功的完成，并能达到或者超过预先设计好的效果，是很不容易的，在完成所下达的任务当中，设计好的蓝图跟具体的实诸于实践，既要有规定统一的制定计划，还要有一套适时的监控执行方法，但同时又不能扼杀了整个项目开发中的创造性和自主性，这样，就必须有一个灵活而且容易使用的沟通方法的过程，从而使一些的重要的项目信息时时最新，做到实时同步。
在IT项目中，许多专家都认为：对于成功，威胁最大的就是沟通的失败。与IT项目成功的三个主要因素分别为：用户的积极参与，明确的需求表达，管理层的大力支持。而这三要素全部依赖于良好的沟通技巧，特别是非信息技术人员。
沟通管理的目标是及时并适当地创建、收集、发送、储存和处理项目的信息，标准的项目沟通包含沟通计划、信息传递、实施情况报告、管理收尾共四个过程。
本文将谈谈一些本人在沟通管理实践中的一些经验。

2 制定沟通计划

在项目立项后，第一步就要制定《沟通计划》，《沟通计划》应包括以下内容：

Ø 文件保存方式：在沟通计划中首先明确信息保存方式、信息读写的权限，明确用户信件、会议记录、工作报告、项目文档（需求、设计、编码、发布程序等）、辅助文档等的存放位置，及相应的读写权力。这样用于收集和保存不同类型的信息，有必要制定和遵循一个规定好了的统一规章制度，将与项目有关的重要工作建档。

Ø 联系方式：应该有一个专用于项目管理中所有的相关的人员的联系方式的小册子，其中如项目组成员、项目组上级领导、行政部人员、技术支持人员、出差定房订票等系统中相关的人员，座机、手机、职能等等，应相应的一一列上，做到简洁又要明了 ，最好能有特殊人员的一些细小的标注，能够做到在一打开小册子的同时就能将所有的相关人员的资料了然于胸，正所谓知已知彼，这样一来，很多在平时大费周章的事，就能在养成的良好的习惯中，轻松做到。 

Ø 工作汇报方式：明确表达项目组成员对项目经理或项目经理对上级和相干人员的工作汇报方式，明确什么时间，什么形式。比如项目组成员对项目经理通过EMAIL发送周报；项目经理对直接客户和上级按月通过EMAIL发月报的方式；紧急汇报通过电话及时沟通；每两周项目组进行一次当前工作沟通会议；每周同客户和上级进行一次口头汇报等等。
Ø 统一项目文件格式：对于一个项目本身统一的文件模板，是正规管理的一部分，所以必须统一各种文件模板，并提供编写指南。

Ø 《沟通计划》维护人：明确本计划在发行变化时，由谁进行修订，并对相关人员发送。

由于《沟通计划》是同很多人员有相关的，必须保证计划是有相关干系人参于制订，并且保证《沟通计划》是相当人员已经正解接收及理解。计划是用来执行的，而不是为计划而计划束之高阁。

3 信息发送

对于项目管理的信息正确传达到相应的人员，是相当重要并有一定的困难的，经常发生的事情是信息发送人感到自己把信息正确传达了，但实际的结果却是信息没有传达到或是被错误的理解了。太多的人还是不太习惯成堆的文件或者通篇的E-MAIL传送的邮件，如果能利用非正式的方式或者是双方会谈的方式来听取重要的信息，就来得又快又准确更能让人接受，就象传统里的一纸书信在某些场合还是比任一现代化的联系方式来得好一样，价值取向不同，沟通的方式也就在使用效果上全然不一样了。 　　　　　　　　　　　　
我们在沟通中应遵循彼得.德鲁克提出的四个基本法则：
Ø 沟通是一种感知
Ø 沟通是一种期望
Ø 沟通产生要求
Ø 信息不是沟通
本人在通过学习及结合实践的过程中得到以下的感受。

3.1 沟通是一种感知

沟通一定是双向，必须保证信息被接收者接到了。所有的沟通方式，必须有回馈机制，保证接收者接收到。比如：电子邮件进行沟通，无论是接收者简单回复“已收到、OK”等，还是电话回答收到，但必须保证接收者收到信息，并回应信息已经接收到。
信息收到必须保证理解是正确的，很多事情信息收到了，但被错误的理解了，很多信息是传达到了，但却被错误理解了。
比如：A项目经理对B项目经理说“今天我要去投标，不过我这边的现在人手少，你那边可否抽些人过来帮我壮壮声势”。
B项目经理手中有一些程序员和系统分析员，而当前程序员有些空闲人手，系统分析员今天正好有些紧急工作，但B项目经理错误理解为A项目经理需要的人是系统分析员，到时协助答辩，所以回答“不行，今天正好有紧急工作，没有办法帮忙”。
A项目经理只好另想办法。
以上就是典型的理解错误，发送方的正确表达、接收者的正确理解是非常重要的。比较简单的方式是发送者进行信息发送，接收者进行理解后进行细化并进行二次表达，但这种表达却是在确认自己理解了的同时去转叙或者执行的结果，而不是复述。

3.2 沟通是一种期望

在项目管理中，项目不同干系人是有不同的沟通需要的。
项目组成员在具体的工作安排中他想明白那个职位是否符合他的意愿等等，上级要了解接收者的期望，向下属传达工作安排的同时还要了解他的意愿取向的问题，再采取相应的方法，调起其在工作上的热情，从而促使其在工作的高效付出，在项目管理中如让下属有反抗情绪的产生或者低效的工作，则是一个项目经理在沟通上不得法的一个失败实例。因此制定一个协调的沟通计划就更为重要了。
而项目经理的上级和客户更加关心是进度的问题：时间是否会延期、是否要添加成本、质量是否有保障等等。这对于项目经理来说，就应即时的反馈这些时间，特别是将会有延期、将添加项目成本、质量将会有问题的苗头等等，更加必须提早汇报，使项目经理的上级和客户能及时并适时调整工作计划。

3.3 沟通产生要求

沟通是双向的，沟通必须能够符合接收者的利益，那样才有说服力。这就要求双方都要有良好的沟通方式，特别是良好的沟通又能达到双赢的目的，一致的沟通有助于组织促进项目更新。
口头的沟通能力同时似乎又是职位提升的关键因素。于是，沟通又必然的产生要求，比如：职位上成功，项目的早日完成，对问题作出恰当的回应，小到假期薪金等等都要沟通来达到目的。

3.4 信息不是沟通

当前是信息时代，必须分清哪些是沟通哪些是信息，对于用于沟通的信息必须明确简练、醒目，避免沉没于信息之海中。
信息也可用于沟通，但信息过于的生搬硬套，一个文字性的文件是并不能起到沟通的作用的，在项目中，项目经理并不是想集中于信息中而是想了解项目里工作的人员，并与之建立起相互信任的关系。而有效的发送信息，只能是依赖于项目经理和项目组成员的良好的沟通技能。
我们现在就能通过上面的四个法则来进行有效的沟通，达到保证管理中信息有效传达的目的了。

4 实施情况报告

实施情况报告一般有三种形式：定期报告，阶段审查，紧急报告。

Ø 定期报告：就是在某一特定的时间内将所完成的工作量向上级汇报。在实际的项目管理中项目人员对项目经理按周报告，对于客户和项目经理的直接上级是按阶段或月进行统一的进展报告，从项目管理上讲，项目定期报告的主要内容就包括：当前是什么状态？在什么阶段？进度完成情况？当前有什么问题请上级（用户）协助解决？下周（下阶段或下月）的计划是什么等等。

Ø 阶段评审：在项目进行到重要的阶段或里程碑似的项目发展阶段，就要进行阶段评审。阶段评审的意义就在于评审当前的项目情况，迫使人们对其工作负责；阶段评审可以提前发现问题，提前将问题解决在初期阶段。不过阶段评审也是最容易产生争执的地方，这主要是针对于问题严重性的定级，项目经理或项目管理委员会必须在全面了解项目发展进展的情况下及时找到问题的重点，从而就事论事的解决问题的真正症结所在，并进行后面的项目。

Ø 紧急报告：在出现意外情况下，进行紧急报告。紧急报告包括以下内容：当前发现的问题，相关影响，需如何解决（动用什么资源），问题紧迫性（必须什么时间内进行反馈）。

在实际的项目管理过程中，质量管理的质量保证部门也将进行质量审计，按阶段提交质量审计报告。
项目干系人接到实施情况报告后也应即时的进行反馈，明确报告已经成功接收到。并让项目干系人一道解决执行中的问题。

5 管理收尾

5.1 项目客户验收

项目收尾期间客户将根据合同对项目进行验收，一般是对最终成果《软件系统》，项目文档《操作手册》、《安装手册》、《软件光盘》、《维护计划》或《维护手册》进行验收，双方将产生双方《项目开发总结报告》及《项目总结会议备忘录》
不同的人都有不同的见解，这些报告都是极好的资源，对未来项目的平稳运行有很大的帮助。

5.2 过程文件归档

项目组内部将对项目过程中的计划、需求、设计、源代码、变更、会议纪要、客户信件等文档整理归档，为以后的查询及参考作为一定的依据。项目档案常常在结束多年以后还有用，良好的项目档案能为当前的项目节省时间和金钱，有时还能对组织进行审计等快速提供有价值的信息。

5.3 项目总结

很多项目没有能进行很好的总结，推脱的理由有项目总结时项目人员已经不足/不全、现在有新的项目要接没有时间、写了没人看等等。这些理由全不是正确的，无论如何也要进行总结，只能总结当前，才能提高以后。
项目的成员应当在项目完成后，为取得的经验和教训写一《项目总结报告》，总结在本项目中哪些方法和事情使项目进行的更好、哪些为项目制造了麻烦、以后应在项目中避免什么情况、那些事情应在后面的项目中坚持等等。为以后的项目人员更好的工作提供一个极好的资源和依据。

6 关于作者

王辉　从1994年开始工作，曾是一名ORACEL和DB2数据库管理员、JAVA、VB及C程序员，现在深圳一家公司担任项目经理。可以通过ddxxkk@21cn.com联系。
　　　　　　　　　　　　　　　　　　　　　　　　　                 

2002/10/08

原文转自：http://www.ltesting.net