现在想起来，当时亏得对项目的进展每两天就检查一次，发现问题比较早，否则要是这个问题再晚发现一个星期，恐怕好多项目组成员已经离开了，项目肯定会失败。其实这个问题的本质原因有两个：第一，项目组的每一个人都担心项目失败，这样肯定会很大程度上影响个人利益，而并不是对项目组的其他人有看法。项目发生变动以后，项目主管并没有及时的把承包商和用户的真实用意与所有项目组成员及时沟通，导致大家纷纷猜测，并且很可能被一些别有用心的人利用了这种情绪。第二：这里面也的确有个别别有用心的人为因素，这个问题一定的及早处理，否则它会搅得整个项目组不得安宁。
解决方案
问题根源找到以后，首先得解决沟通的问题。这包括用户、承包商总体负责人、项目组成员之间的沟通，项目主管尽快找到最终用户，把用户的更改要求和我们的理解与用户进行了更加细致的沟通确认，让用户认识到我们非常在意他们的意愿，但是按照原来的方案更改的话，项目至少要延期半个月，其实这个风险对用户方的影响也很大，最终项目组与用户达成了折中的方案：项目组在第一次移交的时候，只是更改那些工作量不是非常大的但是不解决无法让用户方领到满意的问题，而对于其它的问题，都放在第一次移交一直到维护期结束这段时间来完成。其实，当时用户并没有想得非常多，只是想尽量尽早的把所有的工作提前做完，也并没有认真考虑到很多工作需要耗费大量的时间和精力而导致整个项目拖延而影响到他们自己，而这些工作大部分并不是那么要紧。经过第一次沟通以后，项目组成员对于项目的问题和期限有了更加清晰的认识，已经能够感觉到其实用户并非是故意难为项目组，项目即使延期，对项目整体的影响并不大。紧接着，项目主管找到了承包商的直接负责人，把项目需求变更可能导致延期的问题和原因进行了汇报，随即在项目例会中，承包商的直接负责人对项目组的整体成绩给予了肯定，对项目组的优秀人员给予了口头表彰，对个别的非常懈怠的员工也提出了一定的批评。终于，项目组内部的种种猜疑都基本上结束了，用户方和承包方对于项目的问题都有了比较清楚的认识，项目组的成员也都明白：项目虽然有困难，但是还是会成功结束的，每一个人的利益其实并不受什么影响。
沟通的问题解决以后，还是有个别涣散军心的人继续做一些对项目不利的事情。但是这个人在项目组中又比较重要，如果轻易的在项目组中去除，很多比较关键的工作就没有人负责了。为了避免这个人笼络更多的人，最后掌握更多的要害来要挟项目组而造成更坏的结果，当时在项目组中专门制定了“代码同行评审”的制度，每天抽出一点时间对于项目中比较共性的设计、代码进行相互评审，这也是一个相互学习的过程，对于表现比较好的个人记入绩效，予以表彰。这不但让每个人都有更多机会了解学习他人，也给每个人提供了更加好的展示自己的舞台，大大激发了大家学习进取的积极性。这样不但更好的保证设计与编码的一致性以及好的设计、代码的复用性，而且大大降低了个别人的变动对整个项目组的影响。然后项目组决定把涣散军心的人的地位抬高到系统设计师的地位，而把具体的工作不断的拆分给那些比较好学的其它人员手中。果然，当项目后期这个人离开的时候，项目组中的其它两个人已经可以接手他的工作了。 看来在项目管理中重视文档以及公共知识的管理，并且能有很好的沟通环境，可以大大降低项目进程中的人为风险，并且，有了更加客观的绩效标准以后，能够塑造出更合理的环境，更好的保证成员的积极性。
此文章共有5页 上一页 1 2 3 4 5 下一页
|
Leadge.com首页 > 知识库 
