这本书是1997年10月由Prentice Hall 出版社出版2002年2月电子工业出版业引进作者Robert L.Glass是40年IT行业经验“老ITer”从20世纪80年代开始就专门收集和研究IT行业中那些知名、重大“失控”项目并努力从中抽取些规律和经验供同行参考虽然书中研究和讨论17个案例都发生在20世纪80年代中后期至1997年的间从时间上看显得有些“过时”但是鉴于国内跟美国的类发达国家在工程学和软件Software项目管理(project management)方面都还存在着巨大差距并且书中项目都算得上些“超大型”项目相信国内绝大多数同行都没有接触过所以这本书在今天开来仍然是非常非常有价值

　　不过如果只是在些项目中做过开发工作而没有做过些大型、复杂项目也没有尝试去研究如何让个IT项目成功甚至没有切身体会过完整“IT行业”是个什么概念那么这本书就显得有些太深了

　　另外作者写这本书目也并不是为了系统讲解IT项目管理(project management)所以不能指望看过这本书后就能学会做项目；但是如果你已经有了些项目管理(project management)经验那么倒是很容易通过这本书来重新系统整理总结和提升已有知识和经验想想如果自己以后遇到类似项目该如何办如何尽量避开这些问题和风险

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

　　托尔斯泰说过“幸福家庭都相似,不幸家庭各有各不幸”但IT项目刚好相反——成功项目可能各有各原因但“失控”项目却总是有些相似问题

　　在本书中作者引用了KPMG在1989年和1995年进行两次调查报告而两份调查报告核心是对英国250家软件Software企业“失控”项目进行统计、分析和“失控根源”分类根据KPMG报告这些项目最终“失控”原因归咎于没有指定完整项目目标(特别是需求)、拙劣计划和评估、采用新技术、缺乏或根本不具备项目管理(project management)思路方法、团队(Team)中缺少资深人士、硬件/软件Software供应商低劣表现；而本书作者在最后又附加了条“系统无法满足性能和可靠性要求”下面就对这7大根源先做个整理

　　1. 没有指定完整项目目标

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

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

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

　　3)需求模棱两可

　　4)需求不完整

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

　　2. 拙劣计划和评估

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

　　3. 采用新技术

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

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

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

　　4. 缺乏或根本不具备项目管理(project management)思路方法

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

　　5. 团队(Team)中缺少资深人员

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

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

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

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

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

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

　　在本书中作者也提供了个案例讲述了个存在性能缺陷系统如何给用户带来巨大损失并险些使家企业因此而倒闭



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

　　许多失控项目都是(或曾经是)“野心过大”项目；

　　失控项目可能有个主要原因但总是由多个原因导致；

　　50%项目在开发过程中显示可能会失控而25%项目在计划阶段就已经显示出将来可能会失控；

　　72%失控项目最初是由项目团队(Team)成员发现；而只有19%项目失控是最先有管理层意识到；

　　1989年只有7%企业认为技术问题是导致项目失控主要原因但1995年这个数字上升到了45%；

　　有55%被调查项目根本没有实行过任何风险管理而38%实行了风险管理项目中又有50%项目在启动后没有识别到任何风险；

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

　　那些开始就被牵涉到“政绩”和某些其他商业利益并被大肆宣扬项目大多最终会失控——根据国内经验来看这类项目常见问题是项目目标定位模糊而经常发生变化或者根本就没有人关心项目真正成败和否；

　　越来越多系统要求用来处理实时交互操作这导致性能问题越来越成为影响项目最终成功问题；

　　大型涉及到复杂集成行业应用越来越容易成为失控项目

　　版权声明:本文可以被转载但是在未经本人许可前不得用于任何商业用途或其他以盈利为目用途本人保留对本文切权利如需转载请在转载时保留此版权声明并保证本文完整性也请转贴者理解创作辛劳尊重作者劳动成果