项目为什么会失败?

从毕业到现在,已经两年半了,大大小小的项目也做了八九个了,最大的一个项目规模是大约170人月,耗时半年,最小的项目也就是三四个人,做了一个月。幸运的是,从来还没有做过失败的项目,于是,我就想当然地认为:怎么可能会有失败的项目呢?
究竟怎么样的项目才叫失败呢?项目组成员的辛苦加班,算不算项目失败的一种呢?
我这里暂且认为无法交付成果物,或者是交付的成果物无法满足客户需求。
我曾经旁观(没有参与其中)过一个项目,这个项目可以说是完全失败了。先说一下最终的结果:
代码量:客户端、服务器端、数据库PL/SQL等,总计大约是120W行。
周期:开发大概是4个月,测试三个月。
结果:单体测试、结合测试合计发现Bug数近7000个。
这个项目由于到结合测试后期,发现Bug在不断的增多,而且每修改一个Bug,会引入至少一个的另外的Bug,于是项目宣告失败,项目组成员解散。
我当初不在这个项目组里面,不了解为什么会有这样的结果。
很优秀的程序员,天天加班,那么辛苦,换来的却是失败的结局,搞得从上到下没有人愿意再谈论那个项目。
那已经是很久之前的项目了,前不久跟一个朋友聊天的时候说起,然后那个朋友(曾经参与过)就对我发牢骚,总结起来,也不过是以下几点:
1)项目周期紧,每个过程的时间太短。上面说过,开发过程四个月,需求分析、基本设计、详细设计、编码,每个过程大概是不到一个月,而最终的代码量是12W行,产出/时间,这个比值太大,这样就有很大的风险。时间紧,很多的工作都不够充分,比如WT、CodeReview、项目审查等,这些工作没有做,造成这个项目的质量得不到保证。

2)需求分析阶段,没有充分理解业务,造成了业务逻辑的人为复杂化。那个朋友负责一个画面的一部分,为什么是一部分呢?整个画面100多个控件,关联到40多个表,完成画面的雏形代码量是15K,这个只是画面部分,这个画面整个技能的代码量在30K左右,这样的代码量足够完成一个小系统了。如果在需求分析的时候,把业务逻辑理清,就可以把大画面分割为多个小画面,这样不管从设计还是编码测试的角度来说,都会在很大程度上降低风险。

3)项目管理不善。整个项目在每个阶段开始的时候,没有给出相应的CheckList,于是每个成员写出来的成果物风格不一,中途有项目组成员的离职,给别人理解这部分成果物带来了很大的困难。详细设计的文档风格不统一,跟别的模块接口没有商榷,代码风格极差,测试力度不够,一个很简单的例子,那个项目组中竟然有类似的声明:ArrayList list01。前面说过,由于周期短,CodeReview没有进行,造成了代码质量差,直接影响了测试Bug的修改。而这些事情项目负责人没有很好的控制,本来就暗藏危机的项目更加雪上加霜。

在测试的时候,以上的危机全部爆发了,Bug越测越多,数量与日俱增,最后到了无法维护的地步,代码没有人敢去修改,更没有人敢提出在设计上修改。于是,项目无法交付,宣告失败。

在做类似项目的时候,有什么办法可以避免上述情况吗???

posted on 2007-12-01 19:17  Game_over  阅读(3981)  评论(39编辑  收藏  举报