——比尔.盖茨 “犯错的重要性”，《美国航kong杂志》，1995年7月

　　上面这段话是摘自《软件开发的滑铁卢——重大失控项目的经验与教训》一书的，两个月前第一次看到这段话，那时刚好经历了一个让我印象无比深刻的项目，对这段话也特别有感触，两个月过去了，又重新找出这本书来看，对作者提到的一些现象有了更深的共鸣。鉴于这本书目前尚没有中文电子版，所以决定把其中一些值得反复体会的文字，以及自己在读书过程中的一些思考记录下来，与大家一起分享。

　　所谓的“软件失控项目”，是指在创建系统所需的软件时遇到困难，从而导致大大超出可控制范围的项目。“项目失控”暗示着项目变得无法管理，从而无法达到最初的目标，甚至无法接近目标——这里所指的目标，包括进度目标、成本目标以及满足功能性和非功能性需求的目标。

　　但软件项目未能达到成本和进度的目标，常常是因为这些目标本身就是错误的，而软件从业人员辛辛苦苦的工作，其实是不断的耗费时间去迎合不可实现的目标;而这些目标通常是由营销人员或客户指定的，其次是由管理人员来制定，很少有实际完成项目的技术人员涉足其中。

　　书中作者引用了三个词来说明软件项目所处的不同情形：两难境地(crunch mode)，死亡行军(death march)，和 失控。我特别喜欢作者对“两难境地”和“死亡行军”项目的描述，很生动很形象的这样两种项目对软件从业人员的影响。

　　处于“两难境地”的项目面临着无法达到最初目标的威胁，而项目团队在努力想要跨越该困境。软件专家会在办公室给家人打电话说：“我们正处于两难境地，在半夜之前我是不会回家的”。家人也不会吃惊。两难境地的状况可能会持续几天、几周，甚至几个月，这取决于项目本身持续的时间以及它偏离目标的程度。

　　“两难境地”这个词源自John.Boddie在1987年出版的《Crunch Mode》一书，而这个词并不是Boddie发明的，而是由发现自己被迫完成项目的软件从业者们发明的，通常用来描述进度表极其紧迫的项目，说明项目参与者感受到的压力。

　　而“死亡行军”项目简单的说，就是当你发现不得不参与到一个项目中，又不得不通过超常的努力和超长时间的工作才能完成那些不合理目标时，你所参与的这个项目就是一个“死亡行军”的项目。

　　“死亡行军”这个词源自Ed.Yourdon在1997年出版的《Death March》一书，而这个词也同样是由那些被迫在“死亡行军”项目中行走的人们发明的，通常用来描述进度表几乎不可能完成的项目，说明项目参与者的周围弥漫着的是难以忍受的潜在的失败气味。

　　在我们现实的世界中，通常是因为有人对项目结果期望太高，时间要求太紧，所以从项目开始就呈现出“两难境地”;随着项目的进行，项目参与者很快发现自己在进行“死亡行军”，正在设法实现越来越不可能实现的目标;当项目明显成功无望、多个方面都已失败时，改项目就成为“失控”项目了。

　　大多数人，如果让他们选择的话，都不愿意加入到死亡行军，不想让自己处于两难境地，而且永远不想处于失控的项目中。可因为系统项目通常受到进度表的支配，管理者根据项目预先确定的进度表来检查项目进度，而进度表总是由那些没有能力精确估算的人来确定——比如营销人员或者客户——所以总是时间紧迫，不合情理。

　　有意思的是，“两难境地”的提出是在1987年，“死亡行军”的提出是在1997年，两者相隔10年;而我们再反观又过了10年后的今天，2008年，20年过去了，可似乎我们身处的软件行业、软件项目管理并没有出现太明显的改善。虽然真正“失控”的项目只是极少数，而且也并不是所有的死亡行军项目都会失败，但我们可以发现自己要么处于“两难境地”，要么正在“死亡行军”，总是难以逃脱。

　　托尔斯泰说过，“幸福的家庭都相似,不幸的家庭各有各的不幸”，但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(Microsoft Solution Framework，微软解决方案框架)对于项目成功的关键，归结于人、流程和技术的完美结合。技术，高价聘请外援可以解决的干脆利索;流程，需要长期积累，但总也是个相对稳定的“风险”;唯有人，或者说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条结论。

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

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

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