logo标签列表

为什么今天许多软件项目都会失败？

project-managementprojects
23
只要有软件项目存在，世界都会想知道为什么它们经常失败。我想知道是否有一个列表或类似的东西，显示今天有多少软件项目失败。如果过去20-30年有比较就更好了。你也可以加上你认为软件项目失败的最重要原因。我的原因是“需求不清楚或根本不存在”，其中也包括“没有（真正的）客户/用户参与”。
编辑：几乎不可能清晰地定义“失败”这个术语。让我们假设失败意味着：该项目超预算和时间10%以上。在我看来，10%的范围是一个报价/投标的好范围。
编辑：到目前为止（2月11日），大多数帖子都认为项目失败基本上是项目管理失败（无论失败意味着什么）。但在我看来，大多数开发人员对这种情况并不满意。也许是因为当项目不成功时，不是经理受到惩罚，而是懒惰、无能的开发团队？
当我读这些帖子时，我还听到了开发者方面和管理方面之间存在很大的“差距”的声音。期望（也许还有需求）似乎如此不同，以至于项目最终无法成功（超时/超预算；用户不满意；未实现所有第一要素；太多的程序错误，因为开发者被迫在太短的时间内实现...）
我在想：我们如何改进它？或者我们有可能改进它吗？每个人似乎都对目前的情况不满意。我们能否缩小这两个世界之间的差距？我们（开发人员）应该罢工并为“高质量需求”和“实际/基于迭代的时间表”而斗争吗？
编辑：Ralph Westphal和Stefan Lieser创立了一个名为“Clean-Code-Developer”的新“社区”。该团体的目的是将更多的专业精神引入软件工程中。无论开发人员是否拥有学位或数年的经验，都可以成为这个运动的一部分。

清晰的代码开发者每天都遵循SOLID等原则。一位专业的开发者是其自己工作最大的评审人。他有一个内在的价值体系，帮助他不断改进和变得更好。

请访问：Clean Code Developer

编辑：我们公司目前正在进行所谓的“应用程序开发和维护基准测试”。这是IBM提供的一项服务，旨在获得外部人员对您的软件工程流程质量等方面的反馈。当我们获得结果时，我会告诉你更多信息。

你对于一个失败的软件项目有什么定义？ - mouviciel
3
可能是与为什么你的软件开发项目失败了？重复。 - gnovice
26个回答
30

管理不善。

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

在处理事实和物品（如程序员）和处理其他人（如销售人员和经理）之间存在差异。对于程序员来说，事实就是事实，必须处理。对于销售人员来说，事实是其他人的想法，并且可以改变。

还有具体的和抽象的事实之间的区别。没有人认为工人如果真的有动力可以在一个月内建造一座大桥；他们可以看到所有需要移动和安装的钢筋混凝土和其他东西。软件要少得多，并且缺乏物理限制：虽然在一个月内建造大型项目甚至在理论上都不可能，但团队在一个月内创建大型项目是可以想象的，因为“所有”他们要做的就是第一次就将所有事情搞定。每天打印数千行代码在物质上是可能的，但它们可用的概率非常接近于零。与记者的生产率相比，一流开发人员实际上在字数方面的生产力令人印象不深。

因此，那些习惯于灵活事实的人没有压倒性的物理限制提醒他们事情只能推动到一定程度，也没有欣赏编程所需的实际情况，并且对于实际可能的生产力没有好的感觉。此外，他们知道如何在谈判中发挥自己的作用，比普通开发人员更多，因此在关于可能性的谈判中，他们往往承担了更多的任务，而在现实世界中无法完成任务。

与此同时，软件开发本质上是模糊的，因为生产物理产品很微不足道。一旦开发完成，我可以快速、廉价地复制软件。软件开发是纯粹的设计工作，任何对应于制造业的东西都会被无情地消除，例如编译器、向导和代码生成器。面对想要不可能的经理，开发人员很难说这是不可能的，因为没有办法说它实际上是不可能的。考虑到事实并不足够了解，让那些具有强烈谈判技巧和决心的人通常会得到他或她想要的答案。

鉴于这种脱节，人们可能会问，谁承担架起沟通桥梁的责任。在我看来，答案很清楚。理解不同人思考方式的责任归属于专门处理与其他人打交道的人。协调不同类型人员的责任则归属于协调这些事情的人员。因此，就落在经理身上。

了解软件开发和开发人员，并能与其他经理良好相处的经理将做得很好，他们的项目通常会成功。但世界上还有太多另一类的经理。

这个回答非常棒。 - canadiancreed
4
对于程序员来说，事实就是事实，必须处理。对于销售人员来说，事实是别人的想法，是可以改变的。这句话是形容销售人员最贴切不过的了！ - Mahdi
20

虽然没有直接回答，但我发现Virtual Case File是一个关于大型政府支持的、资金充足的项目如何失败的有趣案例研究。

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

另一篇IEEE Spectrum Online文章 "Why Software Fails" 探讨了这个问题。它总结了以下几点：

  • 不切实际或未明确的项目目标
  • 对所需资源的估计不准确
  • 系统需求定义不清
  • 项目状态报告不佳
  • 未管理的风险
  • 客户、开发人员和用户之间的沟通不良
  • 使用不成熟的技术
  • 无法处理项目的复杂性
  • 粗心的开发实践
  • 项目管理不善
  • 利益相关者政治
  • 商业压力
谢谢你的回答。但是我问的是你的最重要原因！不是一个列表，你个人认为怎么样（你的内心感受）？ - TomTom
1
@TomTom 如果这项工作已经被一家有声望的期刊完成，为什么你需要人们提供他们自己的（可能存在偏见的）意见呢？我认为这是你所问的一般问题的完美答案。 - gnovice
@govice：我只是好奇。这是一个维基问题，所以人们的意见很重要。 - TomTom
@TomTom：我知道我的回答不是直接的，因此有免责声明。此外，我认为这个答案比个人轶事更有价值，但这当然是我的观点 =) - Zach Scrivena
@Zach：好的，我可以接受这个。可惜你没有告诉我们你令人兴奋的个人趣事；-) - TomTom
我记得曾经在一本浴室读物中读到过VCF - 一个被怀疑是共产主义者同情者的人有一个非常酷的代号[Graysuit]（http://en.wikipedia.org/wiki/Robert_Hanssen）。 - new123456
11

计划不足。

1
正如温斯顿·丘吉尔所说：“计划本身毫无意义，但制定计划却至关重要！” - TomTom
11

霍夫斯塔特定律

即使你考虑到了霍夫斯塔特定律，事情总是比你预计的要花更长时间。

10

说实话，我认为这是因为大多数程序员并不擅长他们所做的事情（我不仅指编写代码）。在StackOverflow上的人可能是例外。我不知道你们其他人怎么样，但作为顾问/合同程序员，我曾在许多地方工作过或周围工作过，而中等或差劣的程序员与优秀的程序员的比率约为10比1。

我的优点之一一直是准确估算并按时按预算交付 - 我总是力求成本比预期低10％并且准时完成。然后我喜欢告诉我的客户，因为我用比预期更少的钱完成了任务，所以您想要添加哪些"额外"功能？

即使是完全运行良好的产品，如果推迟或超出预算，许多业务经理也会认为其失败了。程序员经常只关注他们所做的技术方面，很少考虑成本或最后期限。要使项目成功，您确实需要将这三个方面都做好。还有许多其他程序员可以毫无疑问地编写比我更好的代码，但对于支付项目费用的人来说，那通常是不够的。

我认为这在项目层面上是彻底错误的。一个好的项目经理知道可用的资源，并根据此进行计划。如果项目失败是因为程序员比计划中更差，那么这仍然部分归咎于项目经理的责任。 - David Thornley
我同意David的观点。找到具备所需技能的程序员是“领导者”中的核心竞争力之一。 - TomTom
1
哪个更有可能成功：一个拥有优秀程序员但项目经理较差的团队，还是一个拥有优秀项目经理但程序员较差的团队？我认为第一个团队更有可能成功。 - E.J. Brennan
你还需要考虑到大多数项目经理对那些开发者缺乏经验，并且他们只是被安排在该项目中。所以找出哪些开发者是“摇滚明星”（如果有的话）可能很困难，但我认为真正的问题是程序员薪酬不足。 - Chris Marisic
3
公司不愿意承认一个优秀的程序员比一般的程序员更好，应该为此付出更多报酬。这就是为什么他们会接受、甚至期望和强制将平庸的人加入到项目中去。 - Chris Marisic
10

管理不善。

软件项目开始时是通过让开发人员解决一个被认为的问题来启动的。随着项目的进展，业务需求逐渐明确。在保持截止日期的同时添加了新功能，增加了更多的开发人员。原始项目成员退出或被解雇。到这个时间点，项目已经投入了过多的时间、金钱和资源，所以不能取消。当截止日期过去后，尽管显然缺乏完成品，但该项目被宣布为完成和成功。

说起来，我还没有见过一个软件项目失败的情况......

2
当然，因为一切都成功了，所以没有吸取教训，下一个项目也会以完全相同的方式运行... - pipTheGeek
5
由于似乎没有人再阅读，这就是为什么项目失败的每一个原因都被反复分析过了。您只需阅读三本书，就可以知道80%的项目失败原因：
1.《Deadline：关于项目管理的小说》（Tom Demarco，1997年出版）- 这是一个很好的介绍，也很有趣。 2.《Peopleware：高效项目与团队》（Tom Demarco，1987年出版） 3.《神话般的人月：软件工程的散文集》（Fred Brooks，1975年出版）
我们作为一个专业人士，似乎每3-5年就会忘记一切（比如“集中式计算是低效的；让客户端处理”与云计算）。
4

从程序员的角度来看（我不是项目经理，但我经常参与这个过程），许多人提到了糟糕的程序员普遍存在。但我认为在另一个意义上，这也是正确的 - 我们都是糟糕的程序员，因为我们很难预见复杂性，这是50年的魔法子弹估算和计划方案未能解决的问题。

随着项目的增长，预测大型项目的副作用变得越来越困难。这是一个乏味的真理，但对我来说，这意味着在我参与估算过程的任何项目中，我都遇到了一些情况，即设计决策的一个未预料到的后果导致一切停滞，或者至少需要几天的漏洞修复 - 只是没有人预见到的事情，而不是任何恶意或愚蠢。这只是足够复杂的系统的本质。

除了内置的不确定性外，还有一种倾向于低估已知轮廓的事物，因为它们的不确定性较小，使它们看起来更简单易行。

因此，不确定的东西被放大了，清晰的东西被最小化了，真正让你崩溃的是你没有想到会不确定的事情。

4

首要原因：项目管理失败。

项目经理的存在目的是使项目成功，因此项目失败就意味着他们的失败。当然，有些因素超出了他们的控制范围，但在项目经理的工作描述中，管理风险仍然是必须要做的事情，而唯一的免责条款应该是更高层级的人员负责决策（这对项目经理来说是一件可怕的事情）或者不可抗力。

根据我的经验，大多数失败都是由于项目经理工作松散或不存在导致的，包括当决策开始从销售人员那里流动，以及客户开始颁布变更控制时。一个好的项目经理是无价的。

3

失败是一种评判——实际上更像是一种指责。

“项目的预算和时间超支了10%以上。”

哪个预算？哪个进度安排？

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

3个月前，用户要求增加更多内容。我给他们提供了一个计划，说需要再花费9个月的时间。

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

但是等等，它实现了用户想要的东西。它超出了“最初”的估计，低于修订后的估计。用户想要更多，而IT则想要更少。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接