软件开发的滑铁卢----重大失控项目的经验和教训

xblues

软件开发的滑铁卢----重大失控项目的经验和教训（之二）                                                 Posted on 2008-09-19 11:58 Jackei 阅读(1432) 评论(6)  编辑 收藏  所属分类: 21.项目经验总结                        

                               
登录/注册后可看大图

                                       
               

                               
登录/注册后可看大图

这本书是1997年10月由Prentice Hall 出版社出版，2002年2月电子工业出版业引进的。作者RobertL.Glass是40年IT行业经验的“老ITer”，从20世纪80年代开始，就专门收集和研究IT行业中那些知名的、重大“失控”项目，并努力从中抽取一些规律和经验，供同行参考。虽然书中研究和讨论的17个案例都发生在20世纪80年代中后期至1997年之间，从时间上看显得有些“过时”，但是鉴于国内跟美国之类的发达国家在工程学和软件项目管理方面都还存在着巨大的差距，并且书中的项目都算得上一些“超大型”项目，相信国内绝大多数同行都没有接触过，所以这本书在今天开来，仍然是非常非常有价值的。
不过，如果只是在一些项目中做过开发工作，而没有做过一些大型的、复杂的项目，也没有尝试去思考如何让一个IT项目成功，甚至没有切身的体会过完整的“IT行业”是一个什么概念，那么这本书就显得有些太深了。
另外，作者写这本书的目的也并不是为了系统的讲解IT项目管理，所以不能指望看过这本书后就能学会做项目；但是如果你已经有了一些项目管理的经验，那么倒是很容易通过这本书来重新系统的总结和提升已有的知识和经验，想想如果自己以后遇到类似的项目该怎么办，如何尽量避开这些问题和风险。
*********************************************************************
托尔斯泰说过，“幸福的家庭都相似,不幸的家庭各有各的不幸”，但IT项目刚好相反——成功的项目可能各有各的原因，但“失控”的项目，却总是有些相似的问题。
在本书中，作者引用了KPMG在1989年和1995年进行的两次调查的报告，而两份调查报告的核心，是对英国250家软件企业的“失控”项目进行的统计、分析和“失控根源”分类。根据KPMG的报告，这些项目最终“失控”的原因，归咎于没有指定完整的项目目标（特别是需求）、拙劣的计划和评估、采用新技术、缺乏或根本不具备项目管理方法、团队中缺少资深人士、硬件/软件供应商的低劣表现；而本书的作者在最后又附加了一条“系统无法满足性能和可靠性要求”。下面就对这7大根源先做一个整理。

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

1）需求过多，系统过于庞大：似乎注定了越庞大的项目需求就越复杂，也越容易失败；
2）需求不稳定，用户无法决定他们真正想要解决的问题；
3）需求模棱两可
4）需求不完整

作者在书中也用占整本书1/3的篇幅讲述了2个很典型的案例，来说明需求突然发生重大变更和项目目标定位过高导致的“失控”案例。可如何做好需求管理，控制好需求变更，这在今天仍然是一个难题。

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

3. 采用新技术
新的技术、框架、平台、方法论、解决方案、术语缩写的推出，相对于10年前（本书第一次出版的时候）越来越频繁，而且貌似这些新东西更新换代的速度越来越快，生命周期越来越短。曾经有做开发的朋友说自己很羡慕那些做C或者C++的人，因为可以“沉下去”，不受外界这些“新东西”的干扰，积累下真正的技术和经验；相对来说，软件测试也占有类似的优势，毕竟我们现在所使用的方法和技术，大多也都是20年前或者10年前发明并流传下来的——当然，那些沉迷于自动化框架开发或者尝试各种新工具的人会不同意我的看法。
新技术的采用，有时的确可以极大的提高生产率，并解决一些棘手的问题，帮助项目最终成功。但是技术的选型就成了最大的问题，因为新东西推出的太快，而我们的IT行业中真正的技术专家、资深人士又总是少数，大多数ITer或者说开发人员，要么只有2-3年的开发经验，对核心技术和行业应用的把握能力有限；要么迫于项目进度的压力，很少有机会去深入的研究和实践这些技术。
当然，还有另外一个关键的额问题，就是技术本身的成熟度问题——新技术是否已经被类似行业或者规模的项目检验过。

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

5. 团队中缺少资深人员
其实这个就不用多说了，就如比尔.盖茨先生的那段话所说，“坦白地说，微软所面临的挑战之一是它的很多员工还没有遭遇过多少失败。很多人从未遇到过失败的项目。结果是，人们把成功视为理所当然的事，这是很危险的。。。人们遭遇失败时，将被迫发挥出创造性，不分昼夜地深入探索并冥思苦想。每个公司都需要有过这种经历的人。”
资深人员，就是那些经历坎坷，被各种痛苦的“两难境地”项目折磨过，从一次次“死亡行军”中走过来，有着丰富的经验，知道一个完整的IT项目需要经历那些过程，能够帮助项目尽早识别和规避风险，并解决各种突发事件的人。

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

7. 系统无法满足性能和可靠性要求
这一条是本书的作者加的，并不在KPMG的报告中。也许有人会说10年前作者关心的那些性能问题，现在通过更好的硬件、网络以及新的平台和技术都已经可以解决或避免了，已经不再需要担心。可是我们也要看到，10年后的今天，计算机系统所需要处理的业务和需求也在变得日益复杂，而开发人员却并不是个个都关心系统性能的；最终，过于复杂、混乱而低效的代码，仍将导致性能、可靠性和并发性问题。
在本书中，作者也提供了一个案例，讲述了一个存在性能缺陷的系统，如何给用户带来巨大的损失，并险些使一家企业因此而倒闭。

另外，作者也提到了KPMG报告中一些有趣的结论。

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

最后，作者结合自己对失控项目的研究和分析，又给出了另外3条结论。

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

*********************************************************************