为什么软件项目倾向于失败

引言

这是一个令人悲伤的统计事实，软件项目在科学上是脆弱的，并且比其他工程领域更容易失败。

“Standish Group的一项研究报告显示，惊人的31.1%的项目将在完成之前被取消。进一步的结果表明，52.7%的项目将花费其最初估算的189%。”(1)

统计数据也显示了不同规模和类型的软件公司的结果。

“……这种失败发生的频率远高于应有的水平。更重要的是，失败是普遍不加区分的：它们发生在每个国家；大公司和小公司；商业、非营利和政府组织；并且不考虑地位或声誉……”(4)

范围

本文描述了软件项目失败的几个原因。

谁应该阅读本文？

对文章问题感兴趣的读者，特别是软件项目经理。

何时可以定义一个软件项目为失败？

耻辱的失败标记相当武断和主观。问一个失败项目的项目经理，他会告诉你事实并非如此。失败的严重程度也因项目而异。在一家商业软件公司中，失败将与软件消费者相关。例如：

• 软件未能满足消费者的需求。
• 软件发布晚于预定日期（截止日期违约）。
• 软件的错误太多。

悲伤的统计事实

根据Standish Group在2005年进行的研究

• “……2000年只有28%的软件项目成功……” (2)
• “……约有23%的项目被取消，其余的则严重延误……”(2)
• 以下统计数据是2000年的结果
  
• 以下是Standish Group（1）的失败原因列表

为什么软件项目容易失败？

注意： 以下软件项目失败原因列表并非按优先级排序。其中一些原因是研究人员测量的说法。我试图不添加自己的判断；留给读者。

1. 软件工程领域的成熟度

   • 软件工程领域比其他工程领域年轻得多，假以时日，它会变得更加稳定。
   • 该领域还很年轻，因此该领域的大多数工程师和经理也很年轻。年轻人经验较少，因此更容易失败。
   • 年轻人更乐观，倾向于进行错误的估算。

2. 知识库短缺

   作为一个相对年轻的工程领域，软件工程缺乏积累的知识库。例如，著名的“四人帮”书籍《设计模式：可复用的面向对象软件元素》于1994年末首次出版。该书提出了解决常见软件设计问题的设计模式，它是软件工程领域著名的知识库材料之一。“软件工程自20世纪40年代成立以来稳步发展”（5），但与许多其他工程领域相比，它仍然缺乏积累的知识库。另一个例子是OOP（面向对象范式）。OOP比之前的过程范式更成功。OOP直到1990年代才被软件行业广泛接受。“尽管它起源于20世纪60年代，但直到1990年代，OOP才在主流软件应用程序开发中被普遍使用。”（维基百科）

3. 软件是无形的

   与土木工程等其他工程领域不同，软件工程的构建块的无形性要大得多，因此难以衡量和估算。“软件是抽象的”（2）

4. 竞争：严苛的截止日期

   软件行业的竞争非常激烈。上市时间（TTM）至关重要，满足严苛截止日期的压力巨大。这种特性，以及其他方法论上的异常，如“先编码，后思考”和“计划扔掉一个；你反正会扔掉”，使得竞争更加激烈。软件行业的激烈竞争不仅导致了尽快交付的需求，还要求抓住尽可能多的潜在客户的眼球。全方位出击导致了混乱、快速编码和规划不周的项目。

5. 技术变化迅速

   “软件开发技术比其他建筑技术变化更快。”（2）直到最近，微软频繁地向行业发布新技术。快速的技术变革给软件制造商带来了风险。例如，新的操作系统迫使像Ahead这样的公司发布新版本以兼容的Nero。几年前，微软决定改变其推出新技术的方式。它引入了波浪式方法。在这种方法中，微软同意每隔几年发布一系列技术（工具、框架、编程语言等），从而让软件行业适应和消化即将到来的新技术。许多曾经在Windows XP上运行的流行软件，如Ulead Video Studio和Nero，在Windows Vista上无法运行。

6. 变化是诱人的

   建筑师在建筑施工期间不会决定增加额外的楼层。结果将是灾难性的，因为建筑地基不是为此建造的。然而，软件架构师的手在触发时会更加松懈。像增加新功能和重新定义现有功能这样的不负责任的更改可能会导致截止日期违约和/或不良的规划和编码（补丁）。考虑到激烈的竞争（见第6项），变化似乎是不可避免的。

7. 糟糕的时间管理

   开发时间的估算应与现有员工（“资源”）相关。在某些情况下，经理们会进行估算，然后强制执行时间表，就好像他们是开发人员一样。这种强制执行会给开发带来压力，并可能对其造成损害。此外，在这种情况下违反截止日期是很常见的。

8. 糟糕的管理技能或根本没有管理技能

   软件经理通常过去都是优秀、成功且专业的软件工程师。不幸的是，在成功的管理方面，这些技能并不相同。出色的工程技能并不能保证出色的管理。新晋的软件经理得不到正确的指导，或者根本没有指导。

9. 错误或根本没有软件开发生命周期（SDLC）方法

   开发生命周期方法论必须是软件项目管理的一部分。然而，它不应该被强加于研发环境。软件工程领域相对年轻（见第4项），但已经存在一些知名的开发生命周期方法论（敏捷、水晶、螺旋、瀑布等），并且有成功的案例研究。软件项目经理可以采纳现有的方法论之一，但通常还需要根据具体公司进行调整。调整包括：公司文化、员工、市场、经理等。这是瀑布模型。

   

10. 糟糕的文档或根本没有文档

    文档应被视为“必需品”，而不是“锦上添花”。文档是开发生命周期过程的一个组成部分。它不应该被视为烦人的枯燥任务，只是为了满足某个严格的QA经理的要求而完成。软件项目文档有各种类型，每种类型都与项目开发生命周期的特定阶段相关。例如：

    • 工作说明书：初步需求和项目框架，通常由客户编写
    • 市场需求文档（MRD）
    • 软件需求规格（SRS）
    • 高层设计（HLD），由研发部门编写
    • 低层设计，由研发部门编写
    • 项目计划
    • 软件质量保证计划（SQA）

    上述文档有很多模板和不同的名称。尽管如此，重要的是它们的存在要求持有该职位的人在开始项目工作之前进行思考。文档需要在项目生命周期中存储和更新，就像源代码一样（过时的文档就是一个bug）。糟糕的MRD或SRS文档可能会导致项目失败（见第11项，糟糕的SRS文档）。

11. 糟糕的软件需求或根本没有软件需求

    尽管听起来很奇怪，但在某些软件项目中，SRS（软件需求规格）根本不存在，或者写得很糟糕。SRS格式有很多种，即使只有一个通用的模板，内容也会因公司而异。这是一个关于需求定义有多清晰的问题。我从未听说过定义清晰的SRS会导致项目失败，但我熟悉与之相反的情况。简洁的需求文档会影响分解软件复杂性、生成任务和估算时间的能力。此外，不充分的定义会导致误解和错误的实现。项目在开发过程中发生变化变得不可避免，并且随着时间的推移，项目截止日期将会错过。

12. 缺乏测试

    • 开发软件的人不应该测试它。开发人员应该进行单元测试，但这不能替代客观的QA测试。
    • 在漫长的里程碑结束时才进行测试，会因为测试量大和应该在早期阶段就发现的固有问题而引发问题。
      此外，经理们倾向于在里程碑结束时匆忙进行测试，以按时发布。
    • 不具有约束力且没有实际权力的QA对研发部门没有应有的影响，项目本身也因此受到影响。
    • QA应该从软件项目开始就介入。因此，即使在规划阶段。QA参与早期阶段对于其为软件做好准备很重要。例如，QA也应该检查SRS文档，并确保软件是根据它实现的。
    • 以下布鲁克斯教授的经验法则可能显得激进，但没有给予规划和测试相等的时间确实是个问题：“1/3的时间用于设计，1/6用于编码，1/4用于组件测试，1/4用于系统测试。”（3）
    • 测试人员与开发人员比例：没有经验法则规定了每个软件工程师的QA工程师数量。原因是这取决于许多变量，特别是软件的特性。例如，如果“多语言”是软件需求，那么测试的数量就会增加。另一个例子是支持的操作系统数量。测试软件所需的测试人员数量需要估算。错误的估算可能导致项目失败。有几种模型可以帮助确定测试人员与开发人员的比例（参见参考7）。根据2000年9月QAI第20届年度软件测试会议的一次非正式调查（8）
      
      

13. “圣三角”：客户、研发和市场之间沟通不畅

    “圣三角”，根据我的定义，描述了客户、市场和研发之间重要的关系。如下图所示，市场一方结合了客户和研发。市场不断采访客户并了解他们的需求。然后将重要的知识带到研发部门。奇怪的是，在一些商业软件公司中，客户的需求和期望并没有被收集。这种异常情况可能发生在公司遭受“英雄式项目”的情况下。在这种情况下，某个特定人物，通常是公司的CTO，会强制推行项目需求，而不考虑市场和客户的真实需求。这种行为的结果可能是创造出缺乏市场需求、最终导致项目失败的软件。“……从客户到开发人员的需求沟通是常见的问题根源，从开发人员到客户沟通这些需求的影响也是如此……”（2）
    

14. 人力资源管理

    事实是，许多软件项目经理在开始工作时，都没有如何激励人们取得成功的基本指导。软件经理倾向于仅在专业工程方面管理他们的软件工程师。然而，软件工程师也是人。学习什么能激励他们需要经理方面的时间和意愿。没有人是完全相同的，无论是管理还是激励方面。

15. 没有版本/源代码控制

    令人惊讶的是，一些软件项目没有源代码控制备份。源代码丢失；版本无法恢复；客户端的 the products 无法重建。

16. 没有或糟糕的风险管理

    “……项目风险是对项目有影响的不确定事件或情况……风险管理的目的是识别、分析和响应项目风险……”（2）。鉴于以上几点以及软件项目容易失败的事实，不进行风险管理是荒谬的。风险管理文档是强制软件公司思考可能出现问题的首要设计。思考过程本身就可以在问题发生之前解决它们。风险示例：

    • 需求不完整或写得糟糕
    • 选择当前开发人员不熟悉的技术
    • 依赖复杂的第三方软件

    风险管理文档需要在项目生命周期中进行更新。它不应该过于笼统或模糊，而应该针对可能发生的问题的真实细节。

摘要

“……软件开发不仅仅是创建软件的过程；它也是一个学习如何创建最适合其目的的软件的过程。”（2）本文描述了对“为什么软件项目容易失败？”这个问题的部分解答。我鼓励读者继续阅读这个主题，原因有两个：

• 知识：了解软件项目为何失败是防止您自己的软件项目失败的一个良好开端。
• 不完整：本文中的信息不完整；我将其视为一个鼓励您继续阅读的宣传。

参考文献

1. CHAOS 报告
   Standishgroup 网站，1994年
2. 软件项目秘诀：为何软件项目会失败
   George Stepanek，Apress，2005年9月
3. 《人月神话》软件工程随笔
   20周年纪念版，Frederick P. Brooks, JR，Addison Wesley，2002年8月；软件失败原因，Spectrum IEEE Online，Robert N. Charette
4. 软件工程史，维基百科
5. 软件工程理论与问题
   David A. Gustafson，McGraw-Hill。
6. 估算测试人员与开发人员的比例
   Kathy Iberle, Sue Bartlett
7. 难以捉摸的测试人员与开发人员比例
   Randall W. Rice
8. 模板和指南
9. 项目参考
10. 推荐的需求收集实践
    Dr. Ralph R. Young，Northrop Grumman Information Technology