23

只要有软件项目，世界就会想知道为什么它们经常失败。

我想知道是否有一个列表或类似的东西可以显示今天有多少软件项目失败了。如果能对过去 20 到 30 年进行比较就好了。

您还可以添加软件项目失败的主要原因。我的是“需求很差，甚至不存在”。其中还包括“不涉及（真实）客户/用户”。

编辑：几乎不可能清楚地定义“失败”一词。假设失败意味着：项目超出预算和时间超过 10%。在我看来，10% + / - 是一个很好的报价/投标范围。

编辑：直到现在（2 月 11 日），似乎大多数张贴者都同意项目的失败基本上是项目管理的失败（无论失败意味着什么）。但恕我直言，大多数开发人员对这种情况并不满意。也许是因为当项目不成功时受到惩罚的不是经理，而是懒惰、无能的开发团队？

当我阅读帖子时，我还可以听到开发人员和管理人员之间存在很大的“差距”。期望（也许也是要求）似乎如此不同，以至于项目最终无法成功（随着时间/预算；用户不满意；并非所有优先功能都已实现；由于开发人员被迫在太短的时间内实施...）

我在问自己：我们如何改进它？还是我们有可能改进它？每个人似乎都对现在的方式不满意。我们能缩小这两个世界之间的差距吗？我们（开发人员）是否应该罢工并为“高质量要求”和“基于现实/迭代的时间安排”而战？

编辑： Ralph Westphal 和 Stefan Lieser 建立了一个名为Clean-Code-Developer的新“社区” 。该小组的目标是为软件工程带来更多的专业性。独立地，如果开发人员拥有学位或多年的经验，您就可以成为这一运动的一部分。

清洁代码开发人员每天都遵循 SOLID 等原则。一个专业的开发者是他自己工作的最大审稿人。他有一个内部价值体系，可以帮助他提高和变得更好。

看看： 清洁代码开发人员

编辑：我们公司目前正在做一个叫做“应用程序开发和维护基准测试”的事情。这是 IBM 提供的一项服务，用于从外部人员那里获得关于您的软件工程过程质量等的反馈。当我们得到结果时，我会告诉您更多有关它的信息。

4

26 回答 26

30

管理不善。

项目的成功或失败不是基于项目的某些基本特征，而是取决于它们是否满足用户的需求。（它们可能完全失败，在这种情况下，可能会出现严重错误。）在评估项目的可行性和成本效益比以及建立目标的过程中，软件项目往往会失败或成功。

与事实和事物打交道的人（如程序员）和与其他人打交道的人（如销售人员和经理）之间存在脱节。对于程序员来说，事实就是事实，必须处理。对销售人员来说，事实就是别人的想法，而且是可变的。

有形和无形的事实之间也存在差异。没有人认为工人真的有动力可以在一个月内建造一座大桥。他们可以看到所有需要移动和固定到位的钢材、混凝土和其他材料。软件的有形性要少得多，并且缺乏物理限制：虽然理论上甚至不可能在一个月内建立桥​​梁，但可以想象一个团队可以在一个月内创建一个大型项目，因为他们必须做的“全部”是第一次把一切都做好。一天输入数千行代码在物理上是可能的；只是它们按原样可用的机会如此接近于零，这并不重要。顶级开发人员的实际生产力在字数方面实际上并不令人印象深刻，

因此，那些习惯于灵活事实的人没有强加的物理限制来提醒他们事情只能推到这么远，没有了解编程实际需要什么，也没有对实际可能的生产力有多少感觉。此外，他们比普通开发人员更了解如何在谈判中取得成功，因此在关于可能发生的谈判中，他们倾向于假设比他们在现实世界中所能得到的更多。

同时，软件开发本质上是模糊的，因为生产物理产品是微不足道的。一旦软件开发完成，我可以快速、廉价地制作软件副本。软件开发是设计工作，纯粹而简单。任何与制造相关的东西都被编译器和向导以及代码生成等东西无情地消除了。开发人员，面对想要不可能的经理，发现很难说不可能实际上是不可能的，因为没有办法说它实际上是不可能的。鉴于未知的事实足以让人感到灵活，具有强大谈判技巧和决心的人通常会得到他或她想要的答案。

鉴于这种脱节，人们可能会问是谁负责弥合这种脱节。在我看来，答案是明确的。了解不同人的想法的责任属于专门与他人打交道的人。协调不同类型的人的责任属于协调这些事情的人。因此，管理者。

真正了解软件开发和开发人员并能与其他经理打交道的经理会做得很好，他们的项目通常会成功。世界上其他类型的人仍然太多。

于 2009-02-09T14:55:45.473 回答
20

不是一个直接的答案，但我发现虚拟案例文件是一个有趣的案例研究，它说明了一个大型政府支持的资金充足的项目如何仍然失败。

您还可以添加软件项目失败的主要原因。

另一篇IEEE Spectrum Online文章“为什么软件失败”研究了这个问题。主要总结如下：

  • 不切实际或不明确的项目目标
  • 对所需资源的估计不准确
  • 定义不明确的系统要求
  • 项目状态报告不佳
  • 未管理的风险
  • 客户、开发人员和用户之间的沟通不畅
  • 使用不成熟的技术
  • 无法处理项目的复杂性
  • 马虎的开发实践
  • 项目管理不善
  • 利益相关者政治
  • 商业压力
于 2009-02-09T14:05:26.343 回答
11

计划不周。

于 2009-02-09T14:20:18.680 回答
11

霍夫斯塔德定律

即使考虑到霍夫施塔特定律，它也总是比您预期的要长。

于 2009-02-09T14:26:01.817 回答
10

老实说，我认为这是因为大多数程序员并不擅长他们所做的事情（而且我并不是说只是编写代码）。stackoverflow 上的人可能是个例外。我不知道你们其他人的情况，但作为一名顾问/合同程序员，我曾在很多地方或附近工作过，平庸或差劲的程序员与优秀程序员的比例约为 10 比 1。

我的优势之一一直是准确地估算，然后按时按预算或按预算交付——我的目标是在成本和按时减少 10%。然后我想告诉我的客户，因为我完成的事情比预期的要少，你想添加哪些“额外”？

即使是延迟和/或超出预算的完美功能产品也会被许多业务经理视为失败。程序员通常只关注他们所做工作的技术方面，而很少考虑成本或截止日期。你真的需要把这三件事都做好才能被认为是成功的项目。毫无疑问，还有许多其他程序员可以在我周围编写代码，但对于为项目付费的人来说，这还不够。

于 2009-02-09T14:12:37.187 回答
10

管理不善。

SW 项目通过让开发人员解决一个感知到的问题开始。业务需求随着项目的进展而具体化。在截止日期不变的情况下添加了新功能。更多的开发人员被投入其中。原始项目成员退出或被解雇。到目前为止，该项目投入了太多时间、金钱和资源，因此无法取消。随着最后期限的过去，尽管明显缺乏成品，但该项目被宣布完成并成功。

想一想 - 我已经看到一个 SW 项目失败了......

于 2009-02-09T14:34:28.397 回答
5

这是因为似乎没有人再读书了。项目失败的每一个原因都经过了一次又一次的分析。你只需要读三本书就知道为什么 80% 的项目会失败：

截止日期：关于项目管理的小说（Tom Demarco，1997 年出版）这是一个很棒的介绍，而且非常有趣。Peopleware : Productive Projects and Teams (Tom Demarco, 1987 年出版) The Mythical Man-Month: Essays on Software Engineering (Fred Brooks, 1975 年出版)

作为一个行业，我们似乎每 3 到 5 年就会忘记所有事情（参见“集中计算效率低下；让客户处理它”与云计算）。

于 2009-02-10T12:29:45.530 回答
4

第一个原因：项目管理失败。

PM 存在的理由是让项目成功，因此项目失败就是他们的失败。当然有一些他们无法控制的因素，但管理该风险仍然在 PM 的工作描述范围内，唯一的退出条款应该是食物链更高层的人进行决策控制（这对 PM 来说是一件可怕的事情）或上帝的作为。

以我的经验，失败主要发生在 PM 工作快速松散或不存在的情况下，包括当决策开始从销售人员手中流出以及当客户开始下令更改控制时。一个好的 PM 是无价的。

于 2009-02-09T16:31:46.273 回答
4

（从程序员的角度来看——我不是项目经理，但我经常参与这个过程）。

许多人提到糟糕的程序员很普遍。但我认为这在另一种意义上也是正确的——我们都是糟糕的程序员，因为我们发现很难预测复杂性，这是一个不可避免的问题，50 年的灵丹妙药估计和规划方案未能解决。

随着项目的增长，预测大型项目的副作用变得更加困难。当然，这是一个乏味的老生常谈，但对我来说，这意味着在我参与过的任何项目中，我参与了估算过程，我遇到了一些设计决策产生意想不到的后果的情况导致一切停止，或至少几天的错误修复 - 只是没有人预见到的事情，而不是任何形式的渎职或愚蠢。这只是一个足够复杂的系统的本质。

除了内在的不确定性之外，还有一种趋势是低估轮廓已知的事物，因为它们具有较少的不确定性这一事实使它们看起来更易于实现。

所以不确定的东西被放大了，清晰的东西被最小化了，真正要你命的是那些你认为不会是不确定的东西。

于 2009-02-09T14:33:43.763 回答
3

失败是一种判断——更多的是一种指责，真的。

“该项目超出预算和时间超过 10%。”

哪个预算？哪个时间表？

6个月前，我写了一个计划，说需要6个月。

3 个月前，用户要求更多的东西。我给了他们一个计划，说还需要 9 个月。

上个月我被告知该项目超出预算 6 个月，因此“失败”。

可是等等。它提供了用户想要的东西。它超过了“原始”估计。这是在修订后的估计之下。用户想要更多。IT 想要的更少。

于 2009-02-11T03:15:30.050 回答
3

我将从与这里的大多数其他方面不同的方面来处理它。

我注意到一个项目在一段时间内慢慢失败。当然，它在那个时候也变得更好了——但它仍然没有盈利。在这个市场中，盈利和盈利意味着成功。

为什么会失败？我认为这很简单：你得到你所支付的。

软件就像一个银行账户，而不是原始的软泥。如果你不投入资源（时间、金钱、专注、努力），那么除了失败和成本之外，你将一无所获。所以你必须在你的项目中投入一些东西，有时最早的工作为未来几年奠定了基础。你不能在你的电脑上扔泥巴，并期望在两年内获得新鼠标并在 1000 万美元之后获得新鼠标，因此同样必须付出努力。

今天最大的问题之一是第三世界国家的“预算开发商”。我并不嫉妒他们在市场上的份额，但对于一家资金雄厚的硅谷初创公司来说，寻找他们并获得预算基础（框架甚至原型）是对未来的糟糕投资。这个相同的预算框架是今天给我的朋友们带来如此多麻烦的原因。现在可以了；它在写的时候就可以工作，但是写得不好，甚至很少有人花时间去维护它。如果公司停止并按照最初应该编写的方式重写软件，他们就不会遇到所有这些麻烦。他们能负担得起时间吗？没有。他们必须先让它盈利，然后才能考虑到它。

俗话说，“我能做到：便宜、快或好。现在，选择其中任何两个。” 每个人都想要这三个，包括我自己。但是，如果您没有投入时间、计划和工作以使您的项目从一开始就取得成功……那么就不要指望以后有什么可以引以为豪的事情。感觉就像是伪造的蒙娜丽莎，您和其他所有像您一样的工程师都可以在这里和那里看到从一开始就不应该存在的缺陷。

所以：

  • 不要承担你负担不起的事情：时间、金钱、努力、专注等。
  • 不要跳过计划！
  • 不要害怕在最重要的时候尽早重写。（相信我，以后会比去看牙医更糟糕。）
  • 不要低估官僚主义阻止你做正确的事情的力量。
  • 并且不要在你应该花大部分时间的地方便宜。 以后会花你的钱，保证。 如果不是你，那么别人会替你挡子弹。
于 2009-02-11T13:33:56.897 回答
2

一个常见的错误是销售人员和技术人员没有充分沟通。所以销售人员销售的东西在技术上在预算范围内是不可行的。（然后他们带着奖金跑了:)）

于 2009-02-09T14:28:31.797 回答
2

超出预算和时间并不能很好地定义失败（实际上超出预算和时间并不总是意味着成功）。以 PMP 的 Hugh Woodward 在专家项目管理 - 项目成功：超越传统项目度量标准中提供的以下示例为例：

  • 悉尼歌剧院：悉尼歌剧院以其优雅的风帆统治着悉尼港，可以说是世界上最知名的建筑之一。然而，从项目管理的角度来看，这是一个巨大的失败。1959 年开工建设时，估计耗资 700 万美元，建造时间为 4 年。它最终于 1973 年以超过 1 亿美元的价格完成。

    [...]

  • 猎户座计划：从项目管理的角度来看，为开发柯达新的 Advantix 摄影系统所做的巨大努力据说得到了很好的管理。PMI 将其评为 1997 年年度国际项目，《商业周刊》将该系统选为 1996 年最佳新产品之一（Adams，1998）。但自推出 Advantix 系统以来，柯达的股价已下跌 67%，部分原因是它未能预见到加速转向数码摄影。

  • 企业内联网: Finch 描述了一个项目，该项目涉及实施企业内部网以实现全球化和改进通信。从传统项目的角度来看，它未能达到其成功标准，但并不显着。它迟到了一个月，据信是在小额预算超支的情况下完成的。但项目经理和高级管理层都认为该项目是成功的。硬件和软件已成功安装，中断最少，因此所有员工都可以访问公司内部网。然而，在实施之后，员工仅有限地使用了内部网设施。因此，该项目的主要目标没有实现。在这种情况下，项目经理和高级管理人员都专注于一个过于狭窄的目标。

    [...]

  • 制造工厂优化：一家在北美拥有五家工厂的造纸公司决定通过实施消除瓶颈计划来提高其制造能力。成立了一个项目团队来安装必要的设备，并负责在 18 个月内完成这项工作，耗资 2600 万美元。但几乎立即，项目团队被要求推迟主要支出，直到一个不相关的现金流问题得到解决。该团队并没有完全停止工作，而是采取了一种策略，对去瓶颈计划所基于的技术进行原型设计，并实际上开发了一些更便宜、更有效的解决方案。即使该项目被授权继续进行，该团队仍继续采用相同的方法。该项目最终跨越了五年，但由此产生的产能增加是最初承诺的三倍。

    [...]

那么在这些例子中，哪些是真正成功的？2002 年冬奥会和 Batu Hijau 铜矿选矿厂等例子表明，这些都是真正的成功，因为它们不仅符合传统项目经理对成功的定义，而且符合项目发起人对成功的看法。

当我们开始研究猎户座项目、企业内部网和笔记本电脑升级等示例时，我们注意到传统指标开始失效。这些项目在项目经理对成功的定义中被认为是成功的，但未能满足发起人的成功标准。Orion 项目的例子非常令人震惊，因为该项目在 1997 年被 PMI（国际项目管理）认定为年度国际项目。然而这并没有增加柯达的收入，因为他们没有预见到数码相机的采用。

最有趣的是制造工厂优化和悉尼歌剧院的例子。他们都未能达到传统项目经理的成功指标，但实际上都被认为是成功的。当您看到悉尼歌剧院“成本超支 1300%”和“进度超支 250%”时，这尤其令人震惊。

一旦我们意识到项目可能无法满足传统的成功指标，但对利益相关者来说仍然是成功的，这会给项目经理带来困境。如何真正定义成功？是否有可能取消满足发起人需求的“挑战”项目？是否还可以确定一个当前按时、在预算范围内并满足既定需求的应该取消的项目？

你怎么看这个结论？你如何真正定义成功？

于 2009-10-21T18:23:13.050 回答
2

我的回答与其余部分相比相当不寻常，但在这里很常见：杀手虫。我有一个项目额外进行了两周（50％的额外时间），因为在我挖掘源代码之前我不知道源代码的一次切换（帮助或网络上没有任何文档记录）。

于 2009-10-21T18:44:38.983 回答
1

上面的 Construx 链接非常好！

许多项目都是在现实的美好画面上进行管理的。经理们倾向于说服开发人员做出乐观的估计。但是假设一个 20 周的项目被“讨论”到 10 周。需求阶段现在将是 1 周而不是 2 周。1 周后，需求尚未完成，但项目继续进行。现在你在摇摇欲坠的土地上工作——而且时间很长！

这可能很有趣。曾经有一个老家伙在我对面的房间里。他的职位是系统管理员。但是他应该管理的系统并不存在。它从未完成，尽管管理层认为已经完成。这家伙玩了大约一年的游戏，然后才感到无聊并继续前进。

最有趣的部分？管理层在他离开后提出了一个新的职位空缺！

于 2009-02-11T20:54:12.857 回答
1

对此进行了一些很好的研究。我推荐来自 Construx 网站（Steve McConnells 公司）的这个链接。

于 2009-02-11T18:06:21.563 回答
1

实践和软件开发方法使用不当。以我的经验，项目失败的一大原因是开发团队使用错误的方法来面对软件开发过程。在没有很好地理解它的工作原理和需要什么的情况下选择一种方法，可能会给项目带来耗时的问题，比如计划不周。

还有一个常见问题是使用技术而没有事先对其进行评估，以了解如何应用它，以及它是否为项目带来任何价值。

于 2009-02-09T16:20:41.793 回答
1

人们/公司不会自豪地大喊他们的失败，所以很多案例都不会被听到。

于 2009-02-09T14:15:17.773 回答
1

IT Project Failures是一个关于项目失败的博客，如果你想阅读它，这里可能会有一些答案。

我自己，我认为这个问题的很大一部分在于能够准确地说明 x 个月内 $y 的预期，而实际上答案更加开放。例如，如果一家公司正在更换 ERP 或 CRM 系统，那么很有可能无法完全正确地满足所有要求，因此会出现一些变化、错误修复和额外的内容。一个大项目。打个比方，考虑一下有多少进入高中或大学的学生可以在不参加任何课程的情况下说出他们所有 4 年的准确时间表，并最终坚持下去。我的猜测是很少有人会这样做，因为有些人会改变他们想要学习的专业或课程'

于 2009-10-06T21:01:48.617 回答
0

不同的议程

管理层并不真正了解开发人员做什么、他们如何生成代码以及遇到的困难。他们只关心按时交付的最终产品。但是对于开发人员来说，他们关心技术方面，在他们引以为豪的解决方案中生成良好的代码。

截止日期

我经常听到开发人员说他们希望他们能写出更好的代码，而最后期限往往会促使他们写出能正常工作的东西，而不是好的代码。当这些最后期限不切实际时，问题就会加剧。

于 2009-02-11T21:33:02.077 回答
0

如前所述，绝大多数参与软件开发的人实际上并不了解如何

  • 提出正确的问题以了解问题
  • 欣赏用户的目标并判断期望
  • 了解可用的技术和相关的生态结构
  • 大多数直接/间接参与的团队技能都很差。
  • 不欣赏或不知道他们什么时候错了，他们可以采取行动。

即使有完美的需求和相关定义，也有太多的开发人员不知道他们在做什么。

只需查看此处提出的问题类型即可。你会去看问同样问题的医生吗？可怕的是他们会问，却不知道如何学习或推理。

于 2009-02-11T09:33:25.240 回答
0

不仅软件项目超出预算，或者花费超过预定时间来完成。只需打开报纸，看看像桥梁这样的公共项目。

但是对于一个软件项目来说，取消一切要容易得多。如果一座桥梁或建筑物完成了一半，就没有回头路了。一半的基础设施已经到位。它非常明显，需要花钱才能将其移除。

对于软件项目，您可以按 Shift-Delete 并且没有人注意到。

进行准确的成本分析是一项非常艰巨的工作。

于 2009-02-09T14:16:24.023 回答
0

使用 FBI 的虚拟案件文件系统归结为糟糕的项目管理。该计划有 9/11 之前的要求和 9/11 之后的期望。如果政府管理层完成了他们的工作，就会有合同模式。

http://government.zdnet.com/?p=2518

“由于一项没有保障措施的开放式合同，随着项目变得更大、更复杂，上汽收获了超过 1 亿美元，尽管其软件从未正常运行。该公司继续满足该局的要求，尽管有明显迹象表明，该公司仍接受付款据参与该项目或后来为政府审查该项目的人士称，联邦调查局对该项目的处理方式存在严重缺陷。”

尽管 700,000 行代码的 105,000,000 美元相当于每行代码 150 美元。还不错。

于 2009-02-09T14:32:24.593 回答
0

我听到的最后一个统计数据是，90% 的项目要么超时，要么超出预算。因此，如果您认为失败，请退出。

它失败的原因主要在于过程。我们作为软件工程师没有做好收集需求和控制客户的工作。因为对于 IT 以外的人来说，构建软件是一项“神秘”的工作，他们很难理解为什么最后一刻的改变是困难的。这不像盖房子并清楚地向他们展示为什么不能快速在砖房子的背面添加另一扇门。

于 2009-02-09T14:00:42.613 回答
0

要真正衡量一个项目是否真的成功，最初的估计/预算可能是一个糟糕的衡量标准。由于政治压力，大多数工程师往往会低估需要多少时间，而且他们也不知道如何估计。许多经理是糟糕的计划者，因为他们想要不切实际的最后期限来取悦他们的老板，他们通常不了解所涉及的内容，而且他们可以在会议中查看、理解和使用这些东西，而不是实际帮助解决问题。实际上，它可以帮助企业出于预算目的对费用进行粗略的预测，至少它可以为他们提供一些参考。

衡量项目成功的更好方法是——用户满意吗？对企业赚钱有帮助吗？获得的资金能以多快的速度帮助收回系统成本？不过，这些比简单的计划更难衡量。

最后，我发现你最好在截止日期前交付，即使这意味着加班。这很糟糕，但这就是它的现实。

于 2009-02-11T03:53:51.237 回答
0

我认为这个线程成功地聚集了最大的一群不快乐的软件开发人员、工程师、项目经理等，有可能聚集在一个地方。

我与卡在这里的大多数帖子分享观点，我认为当工作（编程）和成功是我们生活中最重要的部分时，看到同事没有做好工作，他们经历了很多痛苦。

http://www.clean-code-developer.de/ 他们有一个不可思议的事业！他们的理念，如果被采用，可以设法创造一个新的英雄层，因为现在开发人员和 IT 专业人士的主流已经很烂了。

我正在巴西做类似的事情，因为我喜欢我们作为 PM 和软件开发人员 (.NET) 让软件活起来的职业，我不能忍受那些面对编程的人，他们只是想出路几乎不费吹灰之力就能赚大钱。

...当然，我不考虑在电脑前通宵达旦。但是少数重要的人不止一次这样做了。

于 2010-04-27T11:01:07.640 回答