技术观点

加强技术投入,共享技术成果

一个失败项目的总结-兼谈风险管理


编辑:杭州大显网络科技有限公司更新日期:2009-05-26
我曾经做过一个失败的项目。那时我对项目管理一知半解,对于风险管理、进度管理等更是一无所知,以致最后花费了当初几倍的人力来挽救它造成的损失。

项目概况

这个项目的策划是在11月开始的,是对现有的一个Web应用程序进行改造。客户写了一份简单的需求说明,希望能在12/25圣诞节之前投入使用。根据这份需求说明,我们整理出了一份功能列表,然后估算每个功能的代码规模,发现规模大大超出期限,于是跟客户交涉,删减了一些功能,并将发布日期定为1/26。最后结果为服务器端3KL,客户端3KL,按照1KL/人月的保守估计,需要6个人月,投入两个人,正好能在1月底完工。于是项目就开始了。

为检查项目进行状况,客户希望在12/25之前发布beta测试版。因此主要功能必须在短短的两个月之内完成。为了赶工期,我们省略了概要设计和大部分的详细设计,直接进入编码阶段。一部分用户需求还未确定,只好先进行确定部分的编码工作,将那些迟迟没有定论的需求放在beta版发布之后。

我负责客户端的开发,很不幸的是负责服务器端开发的同事在11月上旬一直在忙于另一个项目,而到了11月中旬又因病离职,导致11月份服务器端几乎没有任何进展。好在服务器端开发难度不大,项目组在12月份调入另一名强人来接班。在我俩的努力下终于在12/24如期发布了beta版。

到这里似乎一切顺利,但接下来的一个月中,未确定的需求和不断发现的bug成了灾难。项目从原定的1/25推迟到2/8,再推迟到2/16。而这时开发团队也由原来的两个人增加到五个人,增加的三个人专职测试。最后终于发布了,结果发布当天就因为一个小bug导致数十个用户数据被误删。于是暂停服务继续修改,改为封闭式开发,并且继续增加测试队伍到10个人,这样整个团队就有12个人在工作。

这样的状况一直持续到二月底,项目总算正常发布了。

计算一下结果

下面是每个月的开发者数目。

计划实际
11月21.5
12月22
1月25
2月08.5
总计617

实际的工时约为预计的3倍。

分析原因

为什么这个项目会失败?我认为原因在以下几个方面。

1.忽视项目风险。这个项目的风险有以下几条

风险影响(人月)发生的可能性实际影响(人月)
未确定的需求1100%1
原有框架的缺陷造成的实现困难0.520%0.1
开发环境不完善0.250%0.1
新的bug管理系统造成的学习困难0.250%0.1
发布后的bug150%0.5
总计1.7

总计是1.8人月,也就是说项目应当在计划的6人月上再加上1.8人月,实际的估算值应为7.8人月。但在估算时并没有考虑到这些风险(或者说,虽然考虑到了但却没有认识到它的严重性),导致1月底计划结束时风险暴露,不得不增加人力来修补问题。

2.对风险未采取相应对策。实际上,上述风险中甚至存在发生概率为100%的风险,但由于开发者过于自信(所谓的“自我膨胀”),以致并未采取相关措施。甚至在12月底,某些问题已浮出水面时依然未进行控制。

当初如果能采取一些对策,或许就不会这么糟糕。

风险对策
未确定的需求严格控制流程,在详细设计未完成之前禁止编码
原有框架的缺陷造成的实现困难及早联系框架开发者调整
开发环境不完善尽早使用较为完善的开发环境
发布后的bug发布β版

3.人月神话。《人月神话》这本经典著作中提到,增加开发者并不能加快开发进程。请注意2月份比1月份多出来的那3.5人月。从事后结果来看,这3.5人月并未发现一个有效的bug。这是因为,这3.5人月是从其他项目组临时借调过来的人员,完全不熟悉项目,加上不完善的测试用例,导致他们无法正确理解测试用例的意图。

通常编码过程中的人月效应都能引起大家的重视,但实际上测试阶段也存在人月效应,它的影响并不比编码时小多少。