软件项目最常见的失败原因分析

最佳实践建议在启动一个新的软件项目时，寻求一名在软件开发领域具有丰富经验并且可以在项目计划的早期阶段提供协助的主题专家的帮助。这一策略已经被证实可以极大提升项目的成果，然而在项目结束时你还是只能眼睁睁的看着失败发生。为什么会这样呢？

项目失败可分为成本超支、交付延期、质量不合格和 / 或产品未被应用等一种或几种情况。无论是否曾经参与到项目计划阶段，通常情况下，软件开发人员都会首当其冲承担失败的责任；无论怎样，他们是真正构建这个应用的人。然而，对项目更进一步的审查表明并非所有失败的项目都应归咎于开发人员能力不足。当对这些失败的项目进行评估时，其中一些项目与行业趋势相比完成的“还算不错”，然而却被其所在组织认定为失败项目。其原因在于绝大多数的问题都与项目之初有缺陷的评估或错误的商务决策联系紧密。为了避免这种情况发生，整个组织首先必须要使用标准的评估术语集合。我们经常会发现个人和组织大量地互换使用关键术语，而实际上他们各自都有独特的含义。

目标 - 我们想要完成或达成的目标 约束 - 在我们所能完成的工作上的一些内部或外部的限制 估算 - 在范围、成本、日程、人员和可能性确定的情况下，对我们所能完成的工作的技术性计算。 承诺 – 通过选择一个评估场景并分配合适的资源，在一系列的限制条件下达成目标的商务决策。 计划 – 一系列项目任务和活动的集合，让我们可以在确定的范围、预算、日程以及人员的情况下，有一定的概率可以履行某一承诺。

这些概念的清晰定义可以确保项目拥有一个良好的开端——实际的目标和对项目所受限制的理解。若非如此，下面这些因素很有可能导致项目在一开始就踏上死亡的征程。

1. 在没有实质的数据和分析的情况下，就接受一个强制的日程安排或完成日期 / 里程碑日期。 组织中的某个人公开推测项目将在某一特定日期完成，这样在无意中整个团队都会致力于这一期限。也许你的预算周期显示分配给这一项目的资金必须花费到今年年底或者下一个版本不会得到资金支持。也许项目的利益相干人希望项目能在圣诞节前完成，知道项目已经结束他 / 她就可以安静地享受假期。或者干脆就是因为利益相干人特别喜欢整数，希望项目能够在该月一号发布。为什么一个开发团队会被设定一个主观的项目完成日期的原因五花八门。过于狂热的计划经常导致项目人员配备过度的不幸现实是为什么软件项目失败的另一原因。

2. 添加过多的人员以实现不切实际的日程压缩。 项目经理如何处理过度乐观的项目计划？一个常见的反应就是增加项目组成员，增加的成员经常会比完成项目所需的成员更多。这样不仅会大幅增加项目的成本，还会降低项目质量。让更多的人参与到项目中会增加错误传达的可能性，也会让不同部分的代码整合更具挑战。此外，Frederick Brooks (1975) 的主张“在延期项目中增加人手只会让项目更加滞后”是有一些道理的。这些人员通常是从其他项目中调派而来。这会让其他项目的项目计划更加滞后并且还要求新的成员能够赶上资深成员，这样整体来说生产力是下降的。

3. 未能考虑和调整需求的增长或变化并据此对计划和预算预期进行必要的调整。 “如果……不是更好么？”这种话有时候是最可怕的，特别是在项目组建的过程中道听途说而来时。当然，确实需要时间和场所进行头脑风暴，这些活动应该在第一阶段和第二阶段开展。实际上，这两个阶段的目的就是要决定一个项目是否可行，以及应用应该具备哪些功能特性。你可以如此考虑这个问题，第二阶段帮助你确定所要构建的内容，第三阶段则开始构建在第二阶段所确定的内容。在这两个高级阶段之间存在一定的重叠，当处于阶段三时，对于一个产品发布版本来说，应该已经有了一个清晰的必要功能列表。如果在没有增加开发时间和预算的前提下就增加功能，需求的增长就会成为问题。实际上，这是在要求在更短的时间内完成更多的工作，这种手段早已被证明无效。取决于其特性和时点，已有需求的变更也有可能成为问题。只要变更发生在某一特定迭代的构建之前，使用敏捷开发方法的项目就可以处理这些明细需求的变更。不过，对于任何会导致代码返工的软件架构方面的需求变更几乎必然会对项目的计划和预算产生影响。

4. 忽略事实和统计数据的情绪化或”全凭直觉的“利益干系人谈判。 或早或晚，我们都会与某个我们参与的具体项目紧密联系并在该项目的产出之上投入情感。对于许多人来说，该项目可能关乎自己的声望；项目太大经不起失败，而这经常会让我们被我们的情感所控制。当软件项目的成功或失败悬而未决导致个人的事业处于危险之中时，任何相关的业务决策很有可能都会受到影响。压力可以让人思维混乱，特别是在赌注巨大之时。为了给客户留下深刻的印象，某个利益相干人可能会要求一个 12 个月的项目计划安排，而完全不顾之前类似规模的项目报告均显示了 15 个月的生命周期。利益相干人很可能会忽略项目成员的建议，并声称他“感觉”项目团队可以渡过难关。在这种情况下，凭直觉可能是相当不利的并且有可能直接导致项目的失败。

5. 错误，但普遍认为众所周知的银弹可以独自解决项目吞吐量或过程问题。 当其他尝试都已失败时，一个常见的方法就是改变策略。这时比较常见的想法就是“我们现在的所作所为一定是错误的”以及“我们的竞争对手在做些什么？”也就在这时，“IT 银弹”的思虑可能就会开始在办公室中蔓延。例如，某人可能会建议组织，需要采用最新的流行开发方法。虽然这可能会将组织引领至一个伟大的方向，但像这样的决策决不应该草草定论。无论你的组织决定采用哪种开发方法，这也只是实现层面的变化。仅仅是开发方法的转变并不足以完成开发操作的转换。无论做出什么决策，为了能够成功实施，就需要各方均能接受并支持这一决策，并且需要为项目成员提供培训，而且所有人都需要为同样的标准负责。否则，每次启动新的项目时，你的开发策略就基本相当于等待天空的星辰排列整齐，期盼奇迹发生一样。如果没有经过深思熟虑，实现这种策略不仅存在令人难以置信的风险，同时也会减少团队成员在项目中期提供反馈的机会。简而言之，造成软件项目失败的原因林林总总。花点时间认真反思一下上述原因是否曾经也是导致你的组织中项目失败的元凶。那么现在是否有了应对它的措施？作为一个执行领导人，可以做的工作有很多，不过对开发操作提供支持仍需很大的勇气。他们需要在合理的预期内运行。显然，他们仍需要对自己的行为负责，因此就需要历史绩效数据作为证明他们能力的证据。你需要从多个不同的维度搜集数据，包括项目的计划持续时间、所花费的精力、工作的范围、项目的整体质量以及所达到的生产力水平。这种情况下，生产率指数（PI）以指数点数作为计量单位，这是一个有专利的 QSM 计算单位，范围从 0.1 到 40。它让项目之间的比较更有实际意义并且对软件开发因子作出了解释，其中包括如下变量：管理影响、开发方法、工具、经验水平和应用程序类型的复杂度。一旦某个组织建立了已完成项目的仓库，就可以计算定制化趋势线，用于基线创建。这些趋势线作为参考点可用于组织内的项目比较。项目相对于趋势线所处的位置表明了项目与平均水平的相比孰优孰劣。这会让你对组织的当前能力有清晰的洞察。

图 1. 公司项目组合与基线生产力趋势对比图通过查看我们的项目与基线的相对关系，可以了解到许多关于我们在哪些方面做的很好，哪些方面仍需提高的信息。检测项目与各种趋势的偏离度有助于杜绝最好或最差的绩效。项目的极端值也可以为此提供有力的洞察。图 1 展示了公司项目组合与他们的基线平均生产率的对比。有两个项目由于落在两个标准偏差之外而显得尤为突出，其中一个在平均线之上而另一个则在平均线之下。对影响这些项目的因子的进一步检查（如，新技术、工具和方法、人员或项目复杂度）可以帮助了解为什么这些项目的执行如此成功或失败。效仿一流项目中最好的经验，避免失败项目中的教训可以帮助提升未来项目的绩效。通过展示过去已经完成的成果，了解当前开发操作的基线，可以帮助你合理地设立将来的项目的预期。如果所需的项目参数将评估置于一个未知的领域，就可以使用历史基线协商出一个更加合理的方案。这个基线还可以用于合约谈判、报价及供应商绩效评估以及引导客户约束，从而达到缩减成本和改进过程的目标。这一工作会让你在与客户和业务干系人的谈判中占据更加有利的位置。理想的结果是达到共赢。很有可能这会需要一些妥协和折衷，但这个过程中你会播下成功的种子。

关于作者

C. Taylor Putnam-Majarian__ 是 QSM 的一名顾问分析师，有超过 7 年的专业的数据分析、测试和研究经验。除了为来自商业和政府部门的客户提供软件评估和基准测试方面的咨询支持之外，Taylor 还撰写了大量敏捷开发、软件评估和过程改进方面的出版物，她还是 QSM 博客的定期撰稿人。最近 Taylor 在华盛顿特区举办的 Agile in Government 会议上展示了题为 _Does Agile Scale? A Quantitative Look at Agile Projects_ 的研究。泰勒拥有迪金森学院的学士学位。

Doug Putnam是数量化软件管理股份有限公司（QSM）的联合首席执行官。他在软件度量领域有 35 年的经验并且被看作是这一行业发展的先驱者。Putnam 先生曾帮助指导业界领先的软件评估和度量工具 SLIM 套件的开发，并且是一个相当出名的国际化作家、演说家和顾问。其主要职责包括管理和交付 QSM 软件度量服务，定义 SLIM 产品套件的需求以及监督从 QSM 基准数据库衍生而来的研究活动。

查看英文原文： The Most Common Reasons Why Software Projects Fail