从毕业到现在，已经两年半了，大大小小的项目也做了八九个了，最大的一个项目规模是大约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越测越多，数量与日俱增，最后到了无法维护的地步，代码没有人敢去修改，更没有人敢提出在设计上修改。于是，项目无法交付，宣告失败。

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

评论:

分类： 项目管理 管理工具 软件工程