软件项目失败原因分析

[ 2008-09-20 16:12:30 | Author: zhenhua ]
Font Size: Large | Medium | Small
1. 没有指定完整的项目目标

在KPMG的报告中,有51%的项目失控被认为与“没有指定完整的项目目标”,而核心又是我们在IT项目中最常见的一个问题——需求。作者也列出了几个常见的需求问题,包括:

1)需求过多,系统过于庞大:似乎注定了越庞大的项目需求就越复杂,也越容易失败;

2)需求不稳定,用户无法决定他们真正想要解决的问题;

3)需求模棱两可

4)需求不完整

如何做好需求管理,控制好需求变更,这在今天仍然是一个难题。

2. 拙劣的计划和评估

关键是对项目的难度和工作量评估不准确,导致项目的进度永远达不到schedule的要求,并且被无限期的拖延下去。这的确是我们在IT项目中遇到的第二个难题,似乎所有的项目的完成时间都要比预定计划推后一些,虽然不能说一定是计划和评估做的差导致的——因为项目经理还要承担着监控和控制项目进度的职责——但在我们身边的很多项目中,的确存在对项目难度和工作量估计不足,或缺少科学的度量方法的问题;而这又最终导致我们在项目的初期就已经处于“两难境地”,并逐渐进入“死亡行军”的状态。(关于“两难境地”和“死亡行军”的论述,请参见“软件开发的滑铁卢——重大失控项目的经验与教训(之一)”)。

3. 采用新技术

新的技术、框架、平台、方法论、解决方案、术语缩写的推出,相对于10年前(本书第一次出版的时候)越来越频繁,而且貌似这些新东西更新换代的速度越来越快,生命周期越来越短。曾经有做开发的朋友说自己很羡慕那些做C或者C++的人,因为可以“沉下去”,不受外界这些“新东西”的干扰,积累下真正的技术和经验;相对来说,软件测试也占有类似的优势,毕竟我们现在所使用的方法和技术,大多也都是20年前或者10年前发明并流传下来的——当然,那些沉迷于自动化框架开发或者尝试各种新工具的人会不同意我的看法。

新技术的采用,有时的确可以极大的提高生产率,并解决一些棘手的问题,帮助项目最终成功。但是技术的选型就成了最大的问题,因为新东西推出的太快,而我们的IT行业中真正的技术专家、资深人士又总是少数,大多数ITer或者说开发人员,要么只有2-3年的开发经验,对核心技术和行业应用的把握能力有限;要么迫于项目进度的压力,很少有机会去深入的研究和实践这些技术。

当然,还有另外一个关键的额问题,就是技术本身的成熟度问题——新技术是否已经被类似行业或者规模的项目检验过。

4. 缺乏或根本不具备项目管理方法

MSF(Microsoft Solution Framework,微软解决方案框架)对于项目成功的关键,归结于人、流程和技术的完美结合。技术,高价聘请外援可以解决的干脆利索;流程,需要长期积累,但总也是个相对稳定的“风险”;唯有人,或者说PM,是没有办法的,即使有一个优秀的团队,也没法把一个不称职的PM变得称职起来。而这个,反倒是在万事俱备后剩下的最大的风险。

5. 团队中缺少资深人员

其实这个就不用多说了,就如比尔.盖茨先生的那段话所说,“坦白地说,微软所面临的挑战之一是它的很多员工还没有遭遇过多少失败。很多人从未遇到过失败的项目。结果是,人们把成功视为理所当然的事,这是很危险的。。。人们遭遇失败时,将被迫发挥出创造性,不分昼夜地深入探索并冥思苦想。每个公司都需要有过这种经历的人。”

资深人员,就是那些经历坎坷,被各种痛苦的“两难境地”项目折磨过,从一次次“死亡行军”中走过来,有着丰富的经验,知道一个完整的IT项目需要经历那些过程,能够帮助项目尽早识别和规避风险,并解决各种突发事件的人。

6. 硬件/软件供应商的低劣表现

这条分类也是来源于KPMG的调查报告,作者说他手上并没有这方面的案例。不过实际上,可以在本书的17个案例中看到一些端倪。特别是最近我所接触的一些项目,也越来越多的涉及到与外包商的合作——而这也是目前IT行业的趋势。所以我会在今后的项目中留意这一类问题,也许在不久的将来就能有一些身边的案例可以拿出来讨论。

7. 系统无法满足性能和可靠性要求

也许有人会说10年前作者关心的那些性能问题,现在通过更好的硬件、网络以及新的平台和技术都已经可以解决或避免了,已经不再需要担心。可是我们也要看到,10年后的今天,计算机系统所需要处理的业务和需求也在变得日益复杂,而开发人员却并不是个个都关心系统性能的;最终,过于复杂、混乱而低效的代码,仍将导致性能、可靠性和并发性问题。

一些有趣的结论。

·许多失控项目都是(或曾经是)“野心过大”的项目;
·失控项目可能有一个主要原因,但总是由多个原因导致的;
·50%的项目在开发过程中显示可能会失控,而25%的项目在初始的计划阶段就已经显示出将来可能会失控;
·72%的失控项目,最初是由项目团队成员发现的;而只有19%的项目失控是最先有管理层意识到的;
·1989年只有7%的企业认为技术问题是导致项目失控的主要原因,但1995年这个数字上升到了45%;
·有55%的被调查项目根本没有实行过任何风险管理,而38%的实行了风险管理的项目中,又有50%的项目在启动后没有识别到任何风险;

·那些一开始就被牵涉到“政绩”和某些其他的商业利益,并被大肆宣扬的项目,大多最终会失控——根据国内的经验来看,这类项目常见的问题是项目目标定位模糊而经常发生变化,或者根本就没有人关心项目真正的成败与否;
·越来越多的系统要求用来处理实时交互操作,这导致性能问题越来越成为影响项目的最终成功的问题;
·大型的涉及到复杂集成的行业应用,越来越容易成为失控的项目。

---------------------------------------
备注
1997年10月Prentice Hall出版社出版
2002年2月电子工业出版业引进的
作者Robert L.Glass
书名Software Runaways
Comments Feed Comments Feed: http://www.zhenhua.org/feed.asp?q=comment&id=619
UTF-8 Encoding Trackback URL: http://www.zhenhua.org/trackback.asp?id=619

There is no comment on this article.

If you feel this site you find this information helpful, please click on the donation, which is voluntary,Thank you.
Post Comment
Smilies
[arrow] [biggrin] [confused] [cool]
[cry] [eek] [evil] [exclaim]
[frown] [idea] [lol] [mad]
[mrgreen] [neutral] [question] [razz]
[redface] [rolleyes] [sad] [smile]
[surprised] [twisted] [wink]
Enable UBB Codes
Auto Convert URL
Show Smilies
Hidden Comment
Username:   Password:   Register Now?
Security Code * Please Enter the Security Code