-------------------------------------------------------------------------------- 　 1998年7月6日，香港新机场赤角正式开通运营。这个耗资200亿美元的建筑项目终于可以让人喘一口气了。然而，当新机场开通运营之时，令人窘迫的问题出现了：电子信号显示了错误的信息，电话系统被迫关闭，行李不见了，客货运搁浅不前。 200亿美元复杂的建筑结构的确是有史以来全球最大的建筑项目之一。在项目中，半个世界的挖掘机队伍都在忙忙碌碌地参与这浩大工程的建设。数十个承包合约和建筑项目时刻等待着协调，以完成在同一时间进行的数千项不同的又常常相互关联的复杂活动。尽管项目不时地面临着绝境，但项目最终还是从绝境中走出来了。 然而，本文开头所描述的困境还是产生了，而且这难题使机场损失了6亿美元。但这个难题与机场的建筑项目没有一点关系。他们全都来自计算机硬件与软件。 事实上，香港新机场遇到的软件开发的问题是软件业司空见惯的失败案例之一。软件业的成功只是个例外。 开始即意味着失败 Standish集团针对美国大约8000个软件项目进行了调查研究，结果表明：所有软件项目中令人惊讶地有84%未能按时完成、按预算完成或者安装所有预先要求的特性；所有项目中有超过30%在完成之前被取消了，其他则明显超过了期限，并且（平均来说）超过了预算的189%。 另一项研究发现，高度复杂的项目中有超过50%被取消了。也就是说，这样一个项目从一开始，失败的机会就要比成功的机会更高。 软件总是让人觉得战战兢兢。在上个世纪的80年代初，美利坚银行就经历了MasterNet系统失败的噩梦。为了能够抓住信息技术带来的机遇，使美利坚银行成为信托业的巨子，1982年秋天，美利坚银行决定建立一套业务和客户管理的软件系统。在经过18个月的详尽研究分析之后，一份预算为2000万美元的计划批准了，项目计划的截止时间是1984年12月31日。然而，一个除夕来了又走了，系统并没有出现。直到1986年年中，在最初期限的一年半之后，银行才得以向客户演示一个还有着太多漏洞的系统。 1987年3月，系统在晚了27个月投入正式工作。而此时，美利坚银行的IT噩梦开始了。银行在晚了3个月才能发布会计报表，于是，客户的信任开始丧失，企业客户抽走了价值40亿美元的基金。最后，美利坚银行的管理层放弃了这个项目。 这种灾难也许是在静悄悄地发生，但丹佛机场的灾难、“亚利安娜”火箭的爆炸，一直到波音“德尔塔”3号火箭的爆炸，都是软件给人留下的轰天巨响。 谁是罪魁祸首？ 软件业为什么这么容易失败？到底谁是罪魁祸首？ 在盖大楼的时候，也许几块砖的错误摆放或者有瑕疵并不影响整座大楼的平地拔起。但这对于软件来说就不一样了。大多数软件产品都是由上百万行源代码构成。例如，Windows95操作系统有大约1100万行代码，每一行代码至少执行一个命令，而它则会影响程序的其他部分，并且也和其他行相互影响。拿一本有300多页共计达11000多行文字的书本来做参照，Windows95打印出来的源代码则会填满大约1000本这样的书。在这些书中，每一本书只要有一个小小的排印错误，则就会导致整个系统的崩溃。 软件之所以会轻易失败的原因，除了它的源代码的复杂之外，软件系统中不同模块之间的大量相互影响也是重要原因。在软件程序中，著名的“80∶20”法则失去威信，因为一个软件程序要差不多100%地适合工作，而不仅仅是接近如此。 软件业失败的因素贯穿了软件开发的全过程。 当安达信公司为一家大的运输公司设计一个信息系统时，他们难以预测新系统会被如何使用。原因是货运市场的迅速变化，以及缺乏任何已有系统进行比较和验证。注意到这种不确定性，安达信最后不得不采用一种特别有弹性的方法设计系统结构，允许在不同的交易模式之间进行转换，而不需要任何的开发工作。客户需求很难确定，结构就必须保持相对开放，以便适应接下来的变化；否则，昂贵的返工甚至是从头开始的局面就会接踵而来。 雅虎在推出它的个人化网站MyYahoo!之前，就估计自己将不得不做三次实质性的返工，因为它必须把竞争对手在此期间推出的新特性考虑在内。这是不断变化的需求使然。 一家面向对象的软件技术公司，原来在一个软件项目的设计中包含了一个复杂的特性，它预定通过为多任务组织缓存来节省系统资源。但在做该项目的过程中，该公司发现这个特性实际上是有害而不是有助于系统的表现，而这在编码之前是不容易被预计出来的。对象设计公司不得不放弃了这一特性。这是设计在人的大脑中不容易被完全预测所造成的。 此外，软件系统，特别是软件产品，高度依赖于软件开发和运行的技术环境。当你在开发时所选择的开发工具在不断地产生新版本或者改变了设计和工作的思路，那么依赖于这种技术环境的软件开发就不得不惶惶然以应变。 “软件”遇到什么情况会夭折？ “失败在软件业是件常事，而时间估计不足引起的问题比所有其他的问题加起来还要多。”软件开发专家布鲁克斯说。而位于美国西雅图的软件著作作家麦康奈尔则补充道：“在较早阶段精确估计一个项目不只是很难的，而且在理论上是不可能的。”麦康奈尔的话反映了这样的一个事实: 最终产品的设计和特色只有在过程中才能变得清晰，而不是在开始之时。所以，项目开始时高度的不确定性使固定的时间表和最终期限成为不可能。 但很多公司并不想把这一点考虑进来，经理们从一开始就要求一张精确的时间表和开支计划。“事实上，太多的软件项目经理同意提出建立在没有任何分析或者只有很少的预测分析之上的估算。”麦康奈尔对此评论道。“而这，在一个建筑项目中，永远不会发生。” 而正是在这样一个需要高度分析的行业里，这种令人惊讶的非分析的方法使很多软件项目夭折或者失败。 过分乐观的开发人员。许多开发人员，特别是那些没有太多经验的，总是假设一切都将进展顺利。他们常常拍着胸脯打保票，认为自己可以按照时间表来交货，而事实常令他们懊恼不已。 企图通过增加人手来缩短项目日程。一些开发人员的错误是认为增加项目人手就可以缩短项目日程。这通常是错误的，原因有两个：首先，开发工作往往无法在许多工作者之间进行分割，相互依赖性使某些任务要求必须按顺序进行。正如布鲁克斯所说：“生小孩总是需要9个月，无论安排了多少女人。”其次，人手增加的同时，花在交流上的时间将同步增长。 低估项目需要的“制造”软件的时间。专业服务公司常常会走上一条错误的路线：为几个顾客开发了一些相似的系统之后，他们开始尝试着开发一个标准产品，具有为数十个用户提供的相同功能。原因很简单：大众软件市场和企业解决方案软件产品必须比服务业中的定制代码设计得更为广泛，因为它们必须致力于应对更多可能的应用和挑战。此外，软件产品必须比服务软件更多地遵循技术环境，因为顾客使用不同的操作系统和硬件系统。再次，产品说明必须更加清晰以利别人使用，或者扩展它们。 来自营销、客户和管理者的压力。一些软件开发管理专家认为，在所有软件错误里，40%是由压力产生的。软件专家伯姆在TRW公司就经历了一个由压力而产生的错误，这使他们在一个为期两年的项目上超支20%。这个项目的目标是建立一个命令和控制系统，设计运行于一个由几台计算机组成的网络上。需求分析包含了一个条款，要求系统在万一网络中有一台计算机出现故障的时候依然是健全的，但在设计中，该条款被忽视了。由于极其巨大的时限压力，设计审查根本就没有做。后来，当系统在编码中的缺陷被发现之后，整个结构不得不重新设计。他们不得不更换几个主要组件，并重写大量代码。此外，说明文件和测试案例也不得不重新编写。最后TRW将这类错误的原因添加到了它的高风险清单上，这使他们提高了在未来的项目中避免这类事故的机会。 在这类问题中，之所以会有巨大的压力，这产生于几个环节。首先，营销部门或者专业服务公司的独立客户，总是希望能够缩短日程，以便减少开发时间，以利于最快地投放市场或赶上外部期限。其次，管理层前沿不现实的期望也很常见。管理层总是倾向于用过分乐观的时间表对开发小组增加压力。而开发经理们常常既没有经验、也没有权威来和高层领导者进行成功的谈判。 “在盖好屋顶之后重建地基。”——软件业的特色蠕变。“没有人会强迫一个建筑者在上好了屋顶之后重建其地基，但在软件业，这是件常事。”PLATINUM公司的CTO波佩克说。这是指软件公司在产品开发时，所忍受的一些称为“特色蠕变”的现象。波佩克对此是有感而发，因为他经历过这样的折磨。当他还在Locus公司时，该公司正为大型计算机网络开发一个操作系统。IBM看到了这个产品，非常喜欢它，并要求做一个基本的改变——使之与IBM的网关兼容。这是个小小的要求，但却花了大量工作和一年的时间完成。“我们不得不重新设计整个系统，并重写50%的代码。”波佩克说。 在专业服务公司，重要客户充当了“需求添加者或改变者”的角色。来自客户组织各部分的“小”变动或者增添不知不觉进入了特色蠕变的清单。更糟的是这些愿望并没有反映在清单上，而是给了单个的开发人员或者顾问。这常常使专业服务公司不可能去跟踪特色蠕变。 在不可能中寻找成功 尽管软件开发如此地容易失败，但例外的公司还是诞生了。的确，他们同失败的软件公司一样面临着这样的软件开发环境：