市场崩溃：2004年10月新的自动供应链管理系统出现故障后，商品滞留在公司仓库，英国食品零售商Sainsbury’s 不得不另外雇用3000名店员来摆货架。
您有没有听说过仓库消失的新闻？有一天，它凭空消失了，不是真的消失，而是从一家知名零售商的自动化配送系统的眼皮下消失了。软件故障以某种方式使仓库不复存在，因此发往仓库的货物被改道送到别处，而仓库里的货物搁置起来。由于公司陷入财务困境，一直在关闭其他仓库以节省资金，那个“消失”仓库的员工闷声不响。整整三年，没有进货，也没有出货。然而，员工照样领薪水，因为处理工资单的是一套不同的系统。软件故障最终真相大白后，仓库里的商品被削价出售，公司高管要求员工不得吐露半点风声。
这个故事在IT行业已流传了大约20年。它可能是杜撰的，但对于我们这个行业的人来说，这完全很合理。为什么？因为这样的事情一直在上演。比如2004年10月，英国大型食品零售商J Sainsbury PLC不得不注销其在自动化供应链管理系统上高达5.26亿美元的投入。商品似乎滞留在该公司的仓库，没有进入到许多店铺。Sainsbury只好另外雇用了约3000名店员来摆货架。
软件耻辱榜：
*按截至发稿时的当前汇率换算成美元。
+根据美国商务部国际贸易管理局的数据，按引用当年的汇率换算成美元。
**根据美国统计摘要（1996年）的数据，按引用当年的汇率换算成美元。
历来众多IT项目出岔子，这只是最近的一个案例。大多数IT专家一致认为，这类失败太频繁了，远超过应有的水平。此外，失败具有普遍性：它们发生在各个国家、大小公司，发生在商业组织、非营利组织和政府组织，根本不顾及地位或声誉。这些失败给商界和 会造成的损失现在每年高达数十亿美元，损失包括浪费的纳税人和股东钱财和因而无法进行的投入。
随着IT日益普及，问题只会变得愈加严重。2005年全球组织和政府在IT硬件、软件和服务上花费了估计约1万亿美元。在启动的IT项目中，5%到15%的项目因差强人意而在交付前或交付后不久被抛弃。其他许多项目延迟超支，或需要大量返工。换句话说，很少有IT项目真正成功。
最大的悲剧在于，软件失败大多数是可以预见和避免的。遗憾的是，大多数组织不认为预防失败是紧迫的事情，尽管这种观点可能损害甚至毁灭组织。了解为什么这种态度会持续存在不仅仅是学术研究，对商业和 会也大有影响 。
软件无所不在。软件让我们可以从ATM取钱、打电话和开汽车。现在，一部普通的手机含有200万行软件代码。到2010年，这个数字增加到10倍。通用汽车公司估计，它的每辆汽车拥有上亿行代码。
普通公司在IT上的支出约占收入的4%至5%；至于高度依赖IT的那些公司（比如金融和电信公司），支出占收入的比例更是超过10%。换句话说，IT现在是员工成本之外最大的公司支出之一。这些钱主要用于软硬件升级和软件许可费等，但很大一部分用于旨在为组织和客户创造更美好未来的新软件项目。
政府也是软件的一大消费者。2003年，英国开展的100多个大型政府IT项目总计203亿美元。2004年，美国政府统计1200个民用IT项目成本超过600亿美元，另有用于军事软件的160亿美元。
这些项目中任何一个花费都超过10亿美元。举两个例子，美国退伍军人事务部的计算机现代化项目耗资35亿美元，而英国国民保健署的医疗记录自动化需要超过143亿美元用于开发，另需要508亿美元用于部署。
这类大型软件项目曾经很少见，现在越来越普遍，因为小型IT运营加入到了“系统中的系统”。空中交通管制就是个典例，因为它依赖提供通信、天气、导航及其他数据的几十个 络之间的连接。但集成工作让许多IT开发人员陷入困境，以至于学术研究人员日益认为，鉴于这些庞大而复杂的系统，可能需要重新考虑计算机科学本身。
项目失败时，会危及组织的发展前景。如果失败够惨重，公司将毫无未来可言。在一起重大的失败中，一套执行不力的资源规划系统导致FoxMeyer Drug Co.这家市值50亿美元的得克萨斯州卡罗尔顿批发药品分销公司在1996年陷入破产。
美国联邦调查局（FBI）的虚拟案件文档（VCF）失败案例表明，政府的IT失败还可能危害国家安全。这个耗资1.7亿美元的VCF系统是一个易于搜索的数据库，旨在让特工可以“连点成线”，根据不同的情 采取进一步行动，但还没有部署就终止了。
IT失败还会阻碍经济发展和生活质量。早在1981年，美国联邦航空局就开始研究升级其过时的空中交通管制系统，但开发替代系统的工作很快问题重重。到1994年该机构最终放弃项目时，预计成本增加了三倍，前后花费了逾26亿美元，交付日期延后了数年。每位因航路拥堵而延误的航班乘客仍受这一项目取消的影响。所有这些延误单单给美国航空公司（更不用说对乘客）造成的累积经济影响接近500亿美元。
放眼全球，很难说有多少软件项目失败或因而浪费了多少钱。如果您将失败定义为项目在交付前或交付后不久被完全抛弃，如果您接受保守的失败率：5%，那么每年有数十亿美元浪费在糟糕的软件上。
比如在2004年，美国政府在软件（不包括武器系统中的嵌入式软件）上花费了600亿美元，5%的失败率意味着可能浪费了30亿美元。然而在担任IT顾问数十年之后，我深信对预算不低于1000万美元的项目而言，失败率更是达15%至20%。回顾过去五年政府和企业在新软件项目上的总投入，我估计项目失败可能使美国经济损失至少250亿美元，甚至可能高达750亿美元。
当然，这750亿美元并不体现超预算的项目——大多数项目超预算，也不体现晚交付的项目——大多数项目晚交付。它也没有算上一旦项目被放弃，必须从头来过的机会成本，或必须一再返工的漏洞百出的系统的成本。
还有愤怒的客户因实施不力的系统而起诉供应商所产生的诉讼费用。如果把所有这些额外费用加起来，单单在美国，失败和有问题的软件每年造成的费用保守估计高达600亿美元到700亿美元。这笔费用足够发射航天飞机100次、构建和部署24颗卫星的整套全球定位系统，以及从头开发波音777飞机。
为什么项目如此频繁地失败？
最常见的因素包括如下：
当然，IT项目很少仅仅因一两个原因而失败。FBI的VCF项目存在上面列出的许多问题。实际上，大多数失败可以追溯到技术决策、项目管理决策和业务决策的多个因素叠加。每个方面与其他方面发生错综复杂的联系，因而加大了项目风险和问题，并增加了失败的可能性。
以简单的软件任务为例：一套采购系统可自动处理零部件的的订购、开票和运送，以便销售员可以输入客户订单，对照价格和合同要求自动核查订单，并且安排将零部件和发票从仓库发给客户。
假设编写第一个流程即销售流程时，程序员将每笔订单视作好像是在公司的主经营场地下的订单，即使公司在多个州和国家有分支机构。反过来，这个错误又影响了计算税务的方式、签发哪种合同等等。
越早发现并纠正疏忽就越好。这有点像编织毛衣。如果你刚织好就发现漏针，只需拆开一点纱线，补上那针就行。但如果您到最后才发现错误，可能需要拆掉整件毛衣，才能补上漏掉的那针。
如果软件编程人员在最终系统测试时才发现遗漏，或更糟糕的是，系统部署后才发现，纠正错误所花费的成本可能比他们仍致力于初始销售流程时发现错误要高出好多倍。
而且不像毛衣中漏针，确定这个问题的根源要难得多。程序员将只看到出现的错误，而这些错误可能有多个原因。即使纠正了原始错误，他们也需要更改其他计算和文档，然后重新测试每一步。
实际上研究表明，软件专业人员将大约40%到50%的时间花在可以避免的返工上，而不是花在所谓的增值工作上，增值工作基本上是首次做正确的。一旦某个软件投入实际使用，修复错误的成本可能是开发阶段成本的100倍。
如果错误很多，那么返工可能会开始淹没项目，就像暴风雨中的小舢板一样。更糟糕的是，试图修复错误常常带来新的错误。就好比你正在把那只小舢板里的水舀出去，但同时也会渗水。如果生成的错误太多，完成系统所需的成本和时间会变得很大/很长，因而继续修复不明智。
简单来说，返工超过编制预算的增值工作时，IT项目通常会失败。澳大利亚最大的供水商悉尼水务公司在2002年试图引入一套自动化客户信息和计费系统时就出现了这种情况。据澳大利亚审计长的调查显示，导致项目失败的几个因素有：规划和规范不到位，进而导致无数次变更请求，大大增加了成本和延误。悉尼水务公司在花费6100万澳元（约合3320万美元）后中途终止了项目。
这一切让我们想到了一个显而易见的问题：为什么会发生那么多错误？
软件项目失败与飞机失事有诸多共同之处。就像飞行员从不想失事一样，软件开发人员也从不想失败。民用飞机失事时，调查人员分析许多因素，比如天气、维修记录、飞行员的配置和培训以及航空公司内部的文化因素。同样，我们需要分析业务环境、技术管理、项目管理和组织文化，才能了解软件故障的根源。
最主要的商业因素是竞争和需要削减成本。公司高管越来越要求IT部门少花钱多办事，而且比以前更快地完成。他们认为软件项目不是投资，而是必须加以控制的纯成本。
紧迫的政治形势也会严重破坏IT项目的进度、成本和质量。当丹佛国际机场试图推出其自动行李处理系统时，州和地方政治领导人迫使项目一次又一次推行不切实际的时间表。机场（当时是美国最大的机场）原定于1995年开张营业，但系统无法按时交付导致延后，财务更是大受影响。
即使该系统完工后，也根本无法可靠地运行：行李受损，用来载送行李的推车经常脱轨。最终，机场的主要承租方联合航空公司起诉了系统承包商，这一事件表明了政治因素带来的危险。
缺乏公司高管的支持也可能会破坏IT项目，有的无法分配足够的资金和人力，有的未清晰地建立IT项目与组织业务的关系，不一而足。2000年，密歇根州特洛伊市的零售商凯玛特（Kmart Corp.）启动了一个耗资14亿美元的IT现代化项目，旨在将其销售、营销、供应和物流等系统联系起来，与阿肯色州本顿维尔的竞争对手沃尔玛展开更有力的竞争。不过事实证明沃尔玛太强大了，18个月后，现金拮据的凯马特缩减现代化项目，注销了已经在IT上投入的1.3亿美元。四个月后，凯玛特宣布破产。
渴望获得资金的IT项目经理常常打一种说谎者的扑克牌，过分承诺项目的功能、所需费用和完成的时间。许多（即使不是大多数）软件项目开始时的预算太少。出现这种情况时，开发人员不得不设法弥补不足，采取的办法通常是竭力提高生产力、缩小项目范围或在审查和测试阶段冒险抄捷径。这些都加大了错误、最终失败的可能性。
由Budget Rent-A-Car、希尔顿酒店、万豪酒店和美国航空公司的母公司AMR共同牵头开发的最先进的旅行预订系统就是个典例。1992年，这个项目已耗时三年半，耗资1.65亿美元，但最后还是放弃了项目，主要有两个原因：过于乐观的开发进度，低估了涉及的技术难度。同样这支团队之前构建了大获成功的Saber预订系统，这证明过去的表现并不能保证未来的结果。
事故调查人员将天气因素视为飞机失事的一个因素后，考虑飞机本身。飞机设计中的哪方面导致失事？是否载重量过大？
在IT项目失败中，难免出现项目技术部分的类似问题：用于开发系统的软硬件和开发实践本身。组织经常被技术必要性的诱惑所吸引，总忍不住想使用最新技术，希望获得竞争优势。由于技术迅速变化、有望带来出色的新功能，很容易使用新技术。但是使用不成熟或未经测试的技术必然会遇到失败。
1997年，华盛顿州花费4000万美元后关闭了一个IT项目，该项目原本处理驾驶执照和车辆登记。机动车官员承认，他们陷入了一味追求技术的困境，而不是专注于实施满足其要求的系统。之前导致FoxMeyer Drug倒闭的IT失误同样源于采用了最新的资源规划系统，随后要求实现不切实际的功能。
项目的庞大规模是失败的一个根源。研究表明，大型项目失败的频率是小项目的三到五倍。项目越庞大，静态部分（独立的软件和硬件等）与动态部分（硬件、软件和用户之间的耦合和交互以及与其他系统的联系等）的复杂性就越大。复杂性加大，增加了错误的可能性，因为没有人真正了解整体的所有相互联系的部分或有能力进行测试。
一个无情的事实是，不可能全面测试任何规模的IT系统。Roger S. Pressman在其著作《软件工程》（该领域的经典著作之一）中指出：“详尽的测试带来了一些操作问题……如果一个100行的小型程序有几条嵌套路径和执行不到20次的简单回路，可能需要执行1014条潜在的路径。”他特别指出，假设评估每条路径需要1毫秒，测试完所有这100万亿条路径也需要3170年的时间。
所有IT系统本质上都是脆弱的。在大型砖砌建筑中，您要拆掉成百上千块位置很关键的砖头，才能让一堵墙倒塌。而在一个10万行的软件程序中，只需要一两行坏代码就可以带来严重问题。1991年，AT&T的电话 络一部分瘫痪，导致1200万用户无法使用电话，这一切都归咎于一行代码中输错了单单一个字符。
拙劣的开发实践是导致失败的根源，会在IT?6?7?6?7项目的任何阶段导致错误。为了帮助组织评估其软件开发实践，位于匹兹堡的美国软件工程研究所开发了能力成熟度模型（CMM）。它对照成熟度的五个级别对公司的开发实践进行评估。级别1表示组织在使用临时的、可能混乱的开发实践。级别3表示公司描述了其开发实践的特点，现已了解。级别5则表示组织定量了解其运用的流程和实践方面的变化。
截至1月，近2000个政府和商业组织自愿 告了CMM级别。一半以上承认处于1级或2级，30%处于3级，只有17%达到了4级或5级。如果您意识到这是自我选择的群体，百分比甚至更低得可怜。很显然，IT实践最糟糕的公司不会接受CMM评估。（CMM已被CMM-Integration取代，后者旨在对组织创建软件密集型系统的能力进行更广泛的评估。）
不成熟的IT实践注定了美国国税局（IRS）在1997年耗资40亿美元的现代化项目泡汤，而且继续困扰着IRS目前耗资80亿美元的现代化项目。将税收法规转换成软件代码天生就不可能，因为税法很复杂，基于常常含糊不明的法规，会一直变化。从IT开发人员的角度来看，这无异于需求噩梦。但是对IRS来说雪上加霜的是，内外程序员的公开敌视、严重低估涉及的工作量以及另外许多糟糕的做法。
调查人员总是很关注飞行员在飞机失事前采取的动作。那是由于飞行员是最终决策者，负责飞机的安全飞行。同样，项目经理在软件项目中扮演着至关重要的角色，可能是导致失败的错误的主要源头。
早在1986年，伦敦证券交易所决定对其股票交易结算系统进行自动化。七年后，花费了6亿美元后，它放弃了开发Taurus系统的工作，不仅是由于设计过于复杂繁琐，还由于用一位高级经理的话来说项目的管理“如同妄想”。调查发现，即使出现了越来越多的问题，错过了最后期限，成本飙升，也似乎没有人想知道项目的真实状况。
IT项目经理最重要的功能是将资源分配给各项活动。除此之外，项目经理还负责项目规划及评估、控制、组织、合同管理、质量管理、风险管理、沟通以及人力资源管理。
项目经理的错误决策可能是如今软件失败的头 原因。相比之下，糟糕的技术管理会导致技术错误，但这些错误一般可以隔离开来加以修复。然而，糟糕的项目管理决策（比如说聘用太少的程序员或选择错误类型的合同）可能会造成严重后果。比如说，那套注定失败的旅行预订系统的开发人员声称，他们一方面被使用固定价格的合同所阻碍。这样的合同假设工作是常规性的，而预订系统根本就不是这样。
项目管理决策常常很棘手，就是由于它们需要基于模糊或不完整的知识来权衡。估算某IT项目花多少钱、花多少时间与其说是一门科学，不如说是一门艺术。项目越庞大或越新颖，估计的准确性就越低。业界流行的一个笑话是，IT项目的估计费用和时间在75%的时候最多只有其实际值的25%。
糟糕的项目管理会以其他方式加快软件项目完蛋。宾夕法尼亚州纽敦广场的项目管理学院的一项研究表明，风险管理是各行各业中所有项目管理学科中做得最少的一个做法，这个现象在IT行业再普遍不过。若没有有效的风险管理，软件开发人员几乎无法洞悉可能出问题的地方、为什么出问题以及如何消除或减轻风险。也没有办法确定哪些风险是可以接受的，因而几乎不可能做出考虑权衡的项目决策。
糟糕的项目管理还有其他许多形式，包括沟通不畅（这导致了一种不友好的氛围，增加了人员流失）、不致力于员工培训以及不定期检查项目进度。这任何一种情况都会导致软件项目脱轨。
飞机失事后调查人员调查的最后一个方面是组织环境。航空公司有强大的安全文化，还是格外注重遵循航班时间表？在IT项目中，重视开放、诚实、沟通和协作的组织更容易尽早发现并解决错误，因而返工不至于让人措手不及。
要说哪个主题贯穿糟糕软件的可怕历史，那就是未正视现实。美国司法部监察长、外部专家小组及其他人士多次向FBI局长表示，VCF系统按照定义是不可能的，但该项目还是继续进行。负责旅行预订系统、伦敦证券交易所的Taurus系统和FAA空中交通管制项目的那些人当中存在同样的态度，这一切表明了被恐惧和傲慢左右的组织文化。
英国国家审计署的近期 告发现，好多回建议政府IT项目不要继续，但还是继续进行。英国甚至有一个政府部门专门负责防止IT失败，但正如 告指出，该部门监督的政府机构中一半以上常常忽视其忠告。我将这种行为称为非理性的项目升级——即使成功的可能性很显然迅速接近零，也无力停止项目。遗憾的是，这种行为绝非很独特。
归根结底，大型软件失败往往类似最严重的飞机失事：飞行员经验不足，但异常鲁莽，驾驶未经测试的飞机迎向冰暴，供职于一家口口声称要加强安全，但缩减培训和维护工作的航空公司。如果你看过调查人员的 告，就会摇摇头问：“这种失事真的不可避免吗？”
因此，软件项目失败的原因也众所周知，已在无数的文章、 导和书籍中得到了充分的记载。不过，失败、险些失败和老式的糟糕软件仍困扰着我们，已知可以避免错误的实践或做法却避而远之。在大多数组织，在预算之内按时交付高质量的软件似乎不是紧迫的任务。
康涅狄格州特伦布尔的牛津健康计划公司（Oxford Health Plans Inc.）在1997年似乎不是很注重按时交付高质量的软件。该公司的自动计费系统对其收入至关重要，但相比确保计费系统满足当前需求，其高级管理人员更感兴趣的是扩大业务。即使出现了问题，比如晚几个月开票，管理人员仍未引起注意。计费系统实际上崩溃时，该公司损失了数千万美元，股价在一天之内从每股68美元狂泄至26美元，公司价值蒸发34亿美元。股东提起诉讼，几个政府机构调查该公司，最终因违反监管规定被罚300万美元。
连因糟糕的软件体验而焦头烂额的组织似乎也无力或不愿意从错误中汲取教训。美国国防部的咨询机构美国国防科学委员会在2000年的一份 告中特别指出，国防部委托开展的多项研究列出了改善软件开发的134条建议，但其中只有21条得到了贯彻。该委员会特别指出，另外113条仍然有效，但还是被无视，尽管国防部抱怨国防软件开发状况差强人意！
一些组织确实关心软件质量，位于英格兰巴斯的软件开发公司Praxis High Integrity Systems的经历证明了这点。Praxis要求客户对项目做出承诺，不仅在财力上，还要积极参与IT系统的创建。该公司还花费大量时间来了解和定义客户的需求，并要求客户解释他们想要什么以及为什么想要。编写代码之前，客户和Praxis双方就预期目标、什么是可行的、涉及哪些风险达成了一致。
之后，Praxis采用严格的开发方法来限制错误数量。这种做法的一大优势是，这过滤掉了许多不愿承担这一责任的潜在客户：明确表达IT需求，并投入时间和金钱正确落实这些需求。
某种程度的软件失败会永远伴随我们。的确，我们需要真正的失败（而不是可以避免的失误）来保持技术和经济进步。但是今天发生的太多失败是原本可以避免的。随着我们 会越来越依赖规模更庞大、集成度更高、成本更高昂的IT系统，失败的代价可能会异常高。
即使是现在，也可以猜测下一次重大软件失败会出现在哪里。我认为最可能失败的系统之一是来自美国政府的美国健康信息 区的IT系统，这个公私合作项目力求定义电子病历的一套数据标准。其想法是，一旦定义了标准，便可以构建起IT系统，使全国各地的医疗专业人员可通过数字手段输入患者记录，从而使医生、医院、保险公司及其他医疗保健专业人士可以立即访问患者的完整病历。医疗保健专家认为，这种系统中的系统可改善患者护理，估计每年可减少780亿美元的成本，并减少医疗失误，挽救成千上万条性命。
但是如果软件实践和失败率仍与今天一样，这种方法完全是白日梦。即使是最乐观的估计，开发一套电子病历系统也需要10年的努力、3200亿美元的开发成本和每年200亿美元的运营支出，假设不存在任何失败、超支、进度延误、安全问题或拙劣软件。这种情况几乎是不现实的，尤其是由于大多数IT专家认为医疗界是所有专业企业中最不懂计算机的。
患者和纳税人将最终为这种浪费开支的项目的开发或失败埋单。鉴于如今的IT实践，失败确有可能，那会造成空前的损失。不过，全球许多国家在考虑或已经开展许多规模和影响相似的项目，包括在航空、国家安全、军事及其他领域。
就像电力、水、运输和我们基础设施的其他关键部分一样，IT正迅速成为我们日常生活的必要组成。几十年内，大规模的IT失败不仅仅带来严重不便，它将使我们的生活方式面临风险。如果没有那种整个行业的变化以减少软件失败，我们愿意拿未来的哪些方面作赌注，依赖这些庞大、高昂又复杂的系统？
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！