项目管理之力挽狂澜

有些项目总是很“难搞”，例如，对一些新领域的项目，因为与客户有关系，所以就接下来了，在项目启动后，由于对项目的范围没有确定，导致项目的需求总是在变化，项目周期一再延期，用户也不满意，公司项目小组也很累，成本也很难控制！这样的所谓“烂”项目到了中后期如何进行项目管理？

 

其实，这样的项目是我们经常会遇到的一些项目，项目启动的时候项目范围不清，过程中业主和开发者关系紧张难以协调。或许做过IT政府大型项目的人对这些情况都不陌生。我不想谈这样的项目有如何的不好、如何的难以管理，

以及如何的没有在开始的时候确定范围等，我只想谈谈项目在此时此刻的生存环境下，如何管理和沟通，尽最大的努力来完成作为项目组层次上的项目管理应该做的事情。（此为亲生经历的一个项目，反思如下）：

1、鼓舞项目团队的士气。项目进行到这个层次，项目组成员的感受是最不稳定的。这个时候很多项目组成员对项目出现绝望的情绪，甚至影响到项目进一步工作开展中来。这个时候项目组管理者一定要注意缓解这种情绪的蔓延，要鼓舞士气。

2、项目长期的范围和目的不明确的情况下，要多和业主沟通，同时注意沟通的效率和频次。如果可以和最高决策层沟通就直接沟通，当然沟通的时候需要准备的是完整的系统方案。对应的需求方案可以不拘泥于规定的格式，但是一定要利于理解。根据受众的不同而调整需求方案。另外对项目需求管理要做一个动态控制的计划。不能指望一次就可以做好整个系统，而是根据需求确定的程度来步步推进，动态控制需求及变更，过程中一定要将业主方的技术和业务负责人及项目关键干系人引入到你需求变更控制流程中来。

3、项目进行过程中或许已经出现了这样那样的问题，但是对于科学的管理依然要坚持。项目管理中有很多很好的工具和方法，不能因为项目出现问题而摈弃。我看到很多项目经理都会有这样的想法：只要我交出的东西ok，其中的过程你不用理会。这样的想法是错误的。行业里一句话讲：上乘的项目管理是效果和过程都实现好，中乘的项目管理是效果好但过程马虎，下乘的项目管理是效果不好过程ok，失败的项目管理是过程效果都没有。我想这个项目进行到这个程度，作为项目组层次的管理者来说一定要认清形势，在这个时候项目的结果很好已经不是我们最终可能或者追求的结果了。但是注重管理过程也许就要提到一个更加重视的程度。管理过程既可以反促进项目结果，又可以提高客户对此项目的满意度，减少不满程度。

4、采取迭代型开发，合理分配资源来达到项目的最终结果。

 

总之，如果我们能尽最大的努力保证项目的完工，交一份中下乘项目管理答卷，无论从客户还是企业的角度来说这样的项目就算成功了。

感悟：项目生存于一个更大的环境中，例如项目的商务环境、项目规模、客户成熟度、客户关系、客户满意关键点等等；而它自己内部由人员、技术、风险、成本等个体组成。比如范围，通常在政府IT项目中，范围有两个难点，一是范围不确定，而是范围变化频繁。你要求自己都不清楚想要什么内容的客户提供清晰的功能描述，以此来规避在进度和成本上的风险，不现实。

 

 

 

 

——时光荏苒，一转眼从2010年来到了2012年，这一年接手了一个非常难弄的项目（产品）。

背景为该产品有一定的技术难度，且产品经理比较喜欢钻牛角尖，我是中途接手该项目（原PM由于种种原因离开了）。

我进入的时候，根据观察和调查，发现存在以下严重的问题：

§bug居高不下；

§团队士气非常低落；

§与客户沟通成本奇高：每天都举行bug review（按规定是每周一次），每次至少2小时

§在结案前新需求频繁

 

我知道，考验我的时候又到了。我只有一个念头，把这个项目正常的release。这个时候，需要冷静、要拿出毅力和韧性，并且给出对应的solution。

 

我的具体对策如下：

一、找原因

1、分析bug并分类，这样找到产生的根本原因

§由于需求和设计不当引起的bug；

§大部分bug是由极少数几个模块产生

§修改旧bug引起的新bug

2、团队士气低落的原因

§工作毫无成就感

3、与客户沟通成本高的原因

§我们未做好导致客户不放心，他们就催着问。

4、需求变动的原因

§客户想做一个什么，以前我们的第一反馈就是不能做，关系矛盾激化；我们没有去引导和理顺。所以客户索性就不管三七二十一，一股脑的提过来。

二、给出措施执行改进

1、设计合理化，举例来讲，我们以前的很多场景是无极限，其实这是设计遗漏，所以加了加了很多这方面的边界条件。

2、重点模块重点对待，code review时花绝大部分的精力在它们上面。

3、对反复出现的bug在修改前检查上一个版本是否存在。这是我陪他们加班时见到修改某一个bug引起了别的bug后，制定的针对措施。其实这种状况，我只要想看到，每天都可以看到。

4、进行团队建设，开展适当的关怀活动。这绝对不是一句空话，必须落到实处，喊喊口号现在骗不了任何人。

5、集中办公，我的办公室本来同开发、MD、QT他们不在一起，我特意每天花大半天同他们一起，这样的好处是很多的。可以快速讨论和解答问题；可以让他们知道我在干什么，我关注什么；有事加班时，我不走他们也会一起干；…。

6、每日里程碑，事情一日一清。下班前让大家花10分钟show一下他们的成果，可以透明化、可视化，另外也可以起到鼓舞人心的作用。

7、我亲自参与测试，并且经常在晚上11点或凌晨6点发出bug list给团队，这样一是自己对产品了然于胸；二是检测出一些问题；三是感染大家。我一直强调，团队的战斗力肯定不是喊口号能够喊出来的，带头人的身体力行比别的什么办法都有用。

8、每日把当天的成果向客户反馈，包括不好的结果。电话沟通或电子邮件，这样ta就不会对我们不放心了，减少了很多沟通成本。

 

以上活动坚持两周后，情况就慢慢好转了。向着积极的方向发展了，为后面的工作开展创造了好的条件。虽然累点，但至少心没有以前累了，怕就怕心累。

老实讲，在这样的项目环境下，指望能够达到优异是一种奢望，能够全身而退即是胜利。

后话：正是通过这个项目（尽管这个项目的综合得分不高），让公司看到了我作为资深人员所具有的能力，所以后面就将优质也很重要的项目交给我去处理。

正所谓，轻舟已过万重山！