导致软件项目成败的因素分析

《软件需求分析报告的对比报告---导致软件项目成败的因素分析》

目录

目录 (1)

结论一：软件项目的成功率竟然如此的低 (1)

结论四：项目成败的因素 (5)

总结 (10)

我想很多人跟我一样，在没有对软件项目的成败有个比较全面的认识之前，脑海里的软件项目根本没有失败这个概念，更加不可能知道导致软件项目失败的因素。而自己接触的项目与那些具有一定规模的软件项目来比根本不算什么，即便是有过那么几次项目成功的经验，也不知道自己为何完成了项目任务。可以说，了解导致软件项目成败的因素至关重要。

美国专门从事跟踪IT 项目成功或失败的权威机构Standish Group 在它每年的CHAOS Report 报告中给出了IT 项目相关调查数据结果。而今天我们将对它的1994年版、1999年版和2003版本的CHAOS Report 进行对比分析。

结论一：软件项目的成功率竟然如此的低 0

10

20

30

40

50

60

199419992003

成功项目质疑项目损伤项目

1994、1999、2003年软件项目成功失败率图表

1994 1999 2003

成功项目

16.2 26 34 质疑项目

52.7 46 51 损伤项目

31.1 28 15

从Standish Group的1994、1999、2003关于软件项目的成功失败率的统计数据，真的可以让我们大吓一跳，直至2003年，软件项目的成功率竟然连百分之五十都达不到，即便是已经完成的了项目也不一定算得上是成功，受质疑项目竟然占如此之多的比率。可见，关于软件项目的开发还是有一定学问的。其1994年的报告还举了个例子，作为传统工程-建筑工程，其项目成功率远比软件工程的高。同属于工程科学，除了前者发展时间长，积累方法经验多之外，这里面到底还存在着什么神秘的地方让软件工程项目的成功率上不去的呢？请看后面分析。

结论二：软件项目的成功率有上升趋势，损伤率有下降趋势 0

10

20

30

40

50

60

199419992003成功项目质疑项目损伤项目

1994、1999、2003年软件项目成功失败率图表

1994 1999 2003

成功项目

16.2 26 34 质疑项目

52.7 46 51 损伤项目

31.1 28 15

从这个趋势图我们对软件项目的开发找回了一些信心，在1994至2003年之间，软件项目的成功率有上升趋势，而失败率有下降趋势。不过，其上升的程度及下降的程序并不尽如人意，反映其中必定存在某些关键制约因素限制了软件项目的发展。再者，受质疑项目比率仍然处于50％左右，这更让人百思不得其解。

结论三：项目重新开始竟如此多，成本超支、进度落后、不能交付所有功能成三孪生兄弟

在3个版本的报告中，以1994年的报告数据为例，如下： 0

20

40

6080

100

120

百分比重新开始其他

软件项目中重新开始的数据

成本超支

进度落后

内容不足

有100个软件项目中，在项目开始后竟然有94个项目需要重新开始，重新开始意味着什么？相信不用什么知识背景都会知道：开发成本上升、进度拖延、开发士气可能低落等等。而在看项目成本超支、进度落后，内容不足这三项简直让人沮丧，如果照这个比率来开发软件项目，其即便是“成功”开发出产品，也可能要饱受质疑。这里的质疑可能来自多方面的，可能是软件产品过时了已经不适合市场，或者客户因对本项目投资过大从而不满而让公司名义有损，或者说实现的内容跟当初与客户协商的不尽一致导致验收困难重重，等等。这些都是软件项目开发中可怕的后果，其出现率竟如此的高，真的不得不让人反省研究过中学问。

好了，竟然看到软件项目开发中如此多让人不满的地方，也该是时候看看过中缘由，看看到底是什么导致了失败的项目了，又看看什么是导致软件项目成功的因素。

结论四：项目成败的因素

1994版项目成功的因素

1999版项目成功的因素

1994版项目受质疑的因素

1994项目损伤因素

可以发现，虽然上面没有将1999和2003的图标全部列出，但是可以说的是，软件工程经过了尽10年的发展，影响其成功的因素主要都是：用户参与、管理层支持、清晰明确的软件需求、合理的计划、现实的期望。

而导致软件项目失败的因素主要是：缺少用户参与、不完整的需求及规格、需求规格的变更、缺乏管理层的支持和不现实的期望。

其实这里很值得去思考。为何这些项目失败的原因跟成功的原因都位于项目开发的中期甚至乎是前期？软件需求与对项目的期望、计划都是软件项目开发前期主要的工作，其实，需求在变这似乎是一个真理，而这种变动与前期跟客户协商的定位好了的期望能不能掌控在一个限度之内？也就是说，假如前期跟客户协商好了项目要开发什么，并且协商好了不开发什么，这样对于客户期望的变动能否实现一定的限制呢？而就像建房子挖一个地基似的，前期说好了建多少层是客户说了算，而作为开发人员则有确定挖多深的地基的权利，开发人员必定会量力而为，即便是与客户达成协议也会给自己一个余地。而这个余地，对于应付日后客户的需求变动能否有一定的作用。或者说，对于应对市场的变动能否留有余力？

就像任何工程一样，软件项目工程也是一个人与人之间的工程，而实现工程就是实现人脑海中的想法，假如作为客户都不能清晰地表达自己想要什么，或者说开发人员不能正确引导客户说出他心中的想要的东西而产生误解，到了最后交付的时候客户发现“货不对版”，这岂不是会让这个项目受到质疑？所以说，管理层与客户的沟通，开发人员与用户的沟通是很需要的，这会让一个项目能够得到及时的纠正以避免最后的失败。

而合适的更小的历程碑我认为是在开发过程中的一个很好的工具。