借助各种手段，创造良好的沟通环境

　　在一般人的眼里，技术人员都普遍比较孤傲，不好管理。主管不仅仅要掌握良好的沟通技巧，还要擅于感情交流，帮助解决项目组成员工作上和生活上的实际困难，使他们集中精力干好本职工作。良好的上下级和同级关系创造了融洽的工作气氛，尤其是有了这个良好的气氛以后，每个人不但清楚的知道自己工作的进展，还能够了解其他人和整个项目的进展，没有人甘心落后，项目成功的可能性大大增加。

　　创造这种沟通环境有很多办法。首先在技术层面上可以建立一个项目组内部的信息收集发布平台，使得项目干系人都能随时掌握自己关注的项目情况，这个平台利用好以后，还能够使大家共享很多技术信息，大大降低重复劳动造成的浪费。简单的沟通环境可以采用E_Mail系统，复杂一点的可以采用比较专业的工具，例如PVCS、微软PROJECT2000、IBM/Lotus QuickPlace等，这些的工具结合起来，不但提供简单的信息收集发布功能，还能帮助项目组成员更好的协作。

　　其它的交流方式可以采用会议、头脑风暴等手段。这些会议可以是不定期的，也可以是定期的项目例会，通常项目例会是非常必要的，频率根据项目的不同而不同，一般一个星期左右为宜，这些沟通活动气氛要相对轻松，但是效率非常重要。

　　总而言之，建设好项目团队，保证项目成员的活力和士气而能够充分发挥每一个人的主管能动性是贯穿整个项目的复杂的管理活动，尤其是比较大一点的项目涉及人员比较多，人员之间的关系通常也比较复杂，这项工作更显得重要了。

三、案例分析

问题

　　在以前的项目中，笔者曾经遇到过这样的事情：项目已经完成过半，项目的期限马上要到了，但是我在日常绩效审核（绩效审核是反应项目组效率的非常客观直接的一种方式）中发现整个项目组制订的计划的执行越来越拖拉，原来一个星期内做好的事情，现在两个星期了还没有完成，这样下去，随时有项目失败的危险。

原因

　　发现这件事情的时候，我感觉到这是一件非常严重的事情必须很快处理，否则后果不堪设想，在请教了一些有经验的项目主管甚至人力资源主管以后，发现这种情况表面上是由以下两个原因造成的。

1．项目很可能要延期。当时项目组为了避免移交的时候产生太多风险，在项目正式移交前一个月给用户提交了一个beta版本，结果出乎意料：用户觉得我们其中两个比较大的模块与用户想象的大相径庭，不满意。这意味着项目组要多花至少半个月时间来重新做，项目延期几乎是必然的。

2．个别人怠工。因为项目要延期，个别人在项目组里面担心自己的利益受损，在项目的比较关键的时刻怠工，以此作为筹码想让项目组满足他自己的一些私人利益，为了达到目的，曾经还与其它的相关成员进行了协商，这样很多项目组的成员也与他一道来对抗。

　　现在想起来，当时亏得对项目的进展每两天检查一次，发现问题比较早，否则要是这个问题再晚发现一个星期，恐怕好多项目组成员已经离开了，项目肯定会失败。其实这个问题的本质原因有两个：第一，项目组的每一个人都担心项目失败，这样肯定会很大程度上影响个人利益，而并不是对项目组的其他人有看法。项目发生变动以后，项目主管并没有及时的把承包商和用户的真实用意与所有项目组成员及时沟通，导致大家纷纷猜测，并且很可能被一些别有用心的人利用了这种情绪。第二：这里面也的确有个别别有用心的人为因素，这个问题一定的及早处理，否则它会搅得整个项目组不得安宁。

解决方案

　　问题根源找到以后，首先得解决沟通的问题。这包括用户、承包商总体负责人、项目组成员之间的沟通，项目主管尽快找到终用户，把用户的更改要求和我们的理解与用户进行了更加细致的沟通确认，让用户认识到我们非常在意他们的意愿，但是按照原来的方案更改的话，项目至少要延期半个月，其实这个风险对用户方的影响也很大，终项目组与用户达成了折中的方案：项目组在第一次移交的时候，只是更改那些工作量不是非常大的但是不解决无法让用户方领到满意的问题，而对于其它的问题，都放在第一次移交一直到维护期结束这段时间来完成。其实，当时用户并没有想得非常多，只是想尽量尽早的把所有的工作提前做完，也并没有认真考虑到很多工作需要耗费大量的时间和精力而导致整个项目拖延而影响到他们自己，而这些工作大部分并不是那么要紧。经过第一次沟通以后，项目组成员对于项目的问题和期限有了更加清晰的认识，已经能够感觉到其实用户并非是故意难为项目组，项目即使延期，对项目整体的影响并不大。紧接着，项目主管找到了承包商的直接负责人，把项目需求变更可能导致延期的问题和原因进行了汇报，随即在项目例会中，承包商的直接负责人对项目组的整体成绩给予了肯定，对项目组的人员给予了口头表彰，对个别的非常懈怠的员工也提出了一定的批评。终于，项目组内部的种种猜疑都基本上结束了，用户方和承包方对于项目的问题都有了比较清楚的认识，项目组的成员也都明白：项目虽然有困难，但是还是会成功结束的，每一个人的利益其实并不受什么影响。

　　沟通的问题解决以后，还是有个别涣散军心的人继续做一些对项目不利的事情。但是这个人在项目组中又比较重要，如果轻易的在项目组中去除，很多比较关键的工作没有人负责了。为了避免这个人笼络更多的人，后掌握更多的要害来要挟项目组而造成更坏的结果，当时在项目组中专门制定了“代码同行评审”的制度，每天抽出一点时间对于项目中比较共性的设计、代码进行相互评审，这也是一个相互学习的过程，对于表现比较好的个人记入绩效，予以表彰。这不但让每个人都有更多机会了解学习他人，也给每个人提供了更加好的展示自己的舞台，大大激发了大家学习进取的积极性。这样不但更好的保证设计与编码的一致性以及好的设计、代码的复用性，而且大大降低了个别人的变动对整个项目组的影响。然后项目组决定把涣散军心的人的地位抬高到系统设计师的地位，而把具体的工作不断的拆分给那些比较好学的其它人员手中。果然，当项目后期这个人离开的时候，项目组中的其它两个人已经可以接手他的工作了。

　　看来在项目管理中重视文档以及公共知识的管理，并且能有很好的沟通环境，可以大大降低项目进程中的人为风险，并且，有了更加客观的绩效标准以后，能够塑造出更合理的环境，更好的保证成员的积极性。