只要有软件项目，世界就会想知道为什么他们经常失败。
我想知道是否有一个列表或等效的内容，显示今天有多少软件项目失败。如果在过去的20 - 30年间进行比较会很好。
您还可以添加软件项目失败的主要原因。我的是“要求很差甚至不存在。”其中还包括“无（真实）客户/用户参与”。
编辑：几乎不可能清楚地定义术语“失败”。假设失败意味着：该项目超出预算和时间的10％以上。 在我看来，10％+ / - 是一个很好的报价/招标范围。
编辑：到目前为止（2月11日），似乎大多数海报都认为项目失败基本上是项目管理的失败（无论失败意味着什么）。但恕我直言，大多数开发人员对这种情况不满意。也许是因为当项目不成功时，经理不会受到惩罚，而是懒惰，无能的开发团队？
当我阅读帖子时，我也可以听到开发人员和管理层之间存在巨大的“差距”。期望（也许也是要求）似乎是如此不同，一个项目最终不能成功（随着时间/预算;用户不满意;并非所有第一prio功能都实现;太多错误，因为开发人员被迫在太短的时间内实施......）
我问自己：我们怎样才能改善它？或者我们是否有可能改进它？每个人似乎对现在的方式都不满意。我们能缩小这两个世界之间的差距吗？我们（开发商）是否应该继续罢工并争取“高质量的反应”和“基于现实/迭代的时间表”？
编辑： Ralph Westphal和Stefan Lieser创建了一个名为“ Clean-Code-Developer 的新社区”。该小组的目标是为软件工程带来更多的专业性。如果开发人员具有一定程度或数年的经验，您可以独立参与此运动。
清洁代码开发人员的实时原则 像SOLID每天一样。专业 开发者是最大的评论家 他自己的工作。他有一个内部 价值体系，帮助他改善和变得更好。
编辑：我们公司目前正在开展一项名为“应用程序开发和维护基准测试”的工作。这是IBM提供的一项服务，用于获取外部人员对您的软件工程过程质量等的反馈。当我们得到结果时，我会告诉您更多相关信息。
答案 0 :(得分：30)
管理不善。
项目不是基于项目的某些基本功能的成功或失败，而是基于它们是否满足用户的需求。 （它们可能完全失败，在这种情况下，对可能的事情存在严重错误。）主要是在评估项目的可行性和成本效益比，确定目标，软件项目往往失败或成功。
处理事实和事物的人（如程序员）与处理其他人（如销售类型和经理）的人之间存在脱节。对于程序员来说，事实是事实，必须加以处理。对于销售人员来说，事实是其他人的想法，而且是可以改变的。
有形和无形事实之间也存在差异。没有人认为如果他们真的有动力，工人可以在一个月内修建一座大桥;他们可以看到所有钢筋混凝土和其他必须移动并固定到位的东西。软件不那么有形，缺乏物理限制：虽然理论上在一个月内建立桥梁甚至不可能，但可以想象一个团队可以在一个月内创建一个大型项目，因为他们必须做的“全部”第一次让一切正常。实际上每天可以输入数千行代码;只是它们可以按原样使用的几率非常接近零并不重要。与（比如）记者的工作效率相比，顶级开发者的实际生产率在字数上实际上相当不起眼。
因此，那些习惯于灵活事实的人没有强大的物理限制来提醒他们事情只能推到目前为止，不了解编程实际需要什么，也没有好好感受到现实生产力的多少可能。此外，他们知道如何在谈判中找到自己的方式，远远超过普通开发人员，所以在谈判中他们倾向于在现实世界中承担的可能性超过他们所能得到的。
与此同时，软件开发本质上是模糊的，因为生产实物产品是微不足道的。一旦开发完成，我就可以快速而廉价地制作软件副本。软件开发是设计工作，纯粹而简单。通过诸如编译器和向导以及代码生成之类的东西，无情地消除了与制造相对应的任何事物。面对想要不可能的经理的开发人员发现很难说不可能实际上是不可能的，因为没有办法说这实际上是不可能的。鉴于事实不足以让人感到灵活，具有强大谈判技巧和决心的人通常会得到他或她想要的答案。
鉴于这种脱节，人们可能会问起是谁的责任来弥合它。在我看来，答案很明确。了解不同人的想法的责任属于专门与他人打交道的人。协调不同类型人员的责任属于协调这些事情的人。因此，经理。
了解软件开发和开发人员，并能与其他经理打交道的经理人会做得很好，他们的项目通常会成功。世界上还有太多的其他类型。
答案 1 :(得分：20)
不是一个直接的答案，但我发现Virtual Case File是一个引人入胜的案例研究，研究一个由政府支持的大型资金充足的项目如何能够成功。
您还可以添加您的主要原因 软件项目失败。
另一篇IEEE Spectrum Online文章“Why Software Fails”审核了这个问题。它总结了以下主要观点：
答案 2 :(得分：11)
计划不佳。
答案 3 :(得分：11)
即使考虑到霍夫施塔特定律，它也总是比你预期的要长。
答案 4 :(得分：10)
老实说，我认为这是因为大多数程序员并不擅长他们的工作（我并不仅仅意味着只是编写代码）。 stackoverflow上的人可能是例外。我不知道你们其他人，但作为一名顾问/合同程序员，我曾在很多地方或周围工作，平庸或差的程序员与好的程序员的比例约为10比1。
我的优势之一始终是准确估算，然后按时交付，在预算内或预算不足 - 我总是希望在成本和准时下达到10％。然后我想告诉我的客户，因为我做的事情比预期的少了$$，你想加入哪些“额外”？
即使是功能完善且迟到和/或超出预算的产品，也会被许多业务经理视为失败。程序员通常只关注他们所做工作的技术方面，而不考虑成本或截止日期。你真的需要做好这三件事才能被认为是成功的项目。还有很多其他程序员可以毫无疑问地在我周围编写代码，但是对于支付项目的人来说，这很少。
答案 5 :(得分：10)
管理不善。
SW项目开始时让开发人员反对出现问题。随着项目的进展，业务需求趋于明确。在截止日期前加入新功能。投入更多开发人员。原始项目成员退出或被解雇。到目前为止，太多的时间，金钱和资源投入到项目中，因此无法取消。截止日期过后，尽管明显缺乏成品，但项目已宣告完成并取得成功。
来想一想 - 我看到一个SW项目失败了......
答案 6 :(得分：5)
这是因为似乎没有人再阅读了。 项目失败的每一个原因都经过一次又一次的分析。 您只需要阅读三本书就可以了解80％的项目失败的原因：
截止日期：关于项目管理的小说（Tom Demarco，1997年出版） 这是一个很棒的介绍，非常有趣。 Peopleware：富有成效的项目和团队（Tom Demarco，1987年出版） 神话人月：软件工程论文（Fred Brooks，1975年出版）
我们作为一个职业似乎每隔3 - 5年就会忘记一切（参见“集中计算效率低下;让客户处理它”与云计算相比）。
答案 7 :(得分：4)
首要原因：项目管理失败。
PM的存在理由是让项目成功，因为项目失败是他们的失败。当然有一些因素无法控制，但它仍然在PM的工作描述中来管理这种风险，而唯一的退出条款应该是在食物链上方进行决策控制的人（这对PM来说是一件可怕的事情）或上帝的行为。
根据我的经验，失败主要发生在PM工作快速，松散或不存在时，包括决策开始从销售人员流动以及客户开始判定变更控制时。一个好的PM是无价的。
答案 8 :(得分：4)
（从程序员的角度来看 - 我不是项目管理员，但我经常参与这个过程。）
许多人都提到坏程序员是地方病。但我认为在另一种意义上也是如此 - 我们都是糟糕的程序员，因为我们发现难以预测复杂性，这是50年的魔法估计和计划方案未能解决的不可避免的问题。
随着项目的发展，预测大型项目的副作用会越来越难以实现。当然，这是一个沉闷的老生常谈，但对我而言，这意味着在我参与估算过程的任何项目中，我遇到了一些设计决策出现意外后果的情况。导致一切都停止，或至少几天的错误修正 - 只是没有人预见的事情，而不是任何形式的弊端或愚蠢。这只是一个足够复杂系统的本质。
除了内置的不确定性之外，还有一种倾向于低估其轮廓已知的事物，因为它们具有较少的不确定性使得它们看起来更简单。
因此，不确定的东西会被放大，清晰的东西会被最小化，真正杀死你的东西就是你认为不会不确定的东西。
答案 9 :(得分：3)
失败是一种判断 - 更多的是指责，真的。
“该项目超出预算和时间的10％以上。”
哪个预算？哪个时间表？
6个月前，我写了一份计划，称需要6个月。3个月前，用户要求更多东西。我给了他们一个计划，表示还需要9个月。
上个月我被告知该项目超出预算6个月，因此是“失败”。
但是等等。它提供了用户想要的东西。这超过了“原始”估计。这是在修订后的估计数之下。用户想要更多。 IT需要更少。
答案 10 :(得分：3)
我将从与其他大多数人不同的方面来处理它。
我注意到一个项目在一段时间内缓慢失败。当然，它在那个时候也变得更好 - 但它仍然没有盈利。在这个市场中，盈利能力和黑色，意味着成功。
为什么失败？我认为这很简单：你得到的是你付出的代价。
软件就像一个银行账户，而不是原始的软泥。如果你没有把资源投入其中（时间，金钱，重点，努力），那么除了失败和成本之外你不会得到任何东西。因此，您必须在项目中投入资金，有时最早的工作将为未来几年奠定基础。你不能在你的计算机上乱扔泥土，并期望在两年内投入一只新鼠标，然后再投入一千万美元，所以同样必须花费精力。
今天最大的问题之一是第三世界国家的“预算开发者”。我并不嫉妒他们是市场的一部分，但对于资金充足的硅谷创业公司来说，寻找他们并获得预算基础（框架甚至原型）是为了在未来做出糟糕的投资。这个相同的预算框架正是导致我的朋友今天麻烦的原因。它现在有效;它写的时候很有用，但写得不好，甚至很少花时间来维护它。如果公司停止并且按照应该首先编写的方式重写软件他们就不会遇到这些麻烦。他们能承受时间吗？不。他们必须先赚钱才能实现盈利。
俗话说“我能做到：便宜，快速或好。现在，挑选其中任何两个。”每个人都想要这三个，包括我自己。但是，如果你不投入时间，计划和工作，从一开始就让你的项目取得成功......那么不要指望你以后可以为之感到骄傲。感觉就像一个伪造的蒙娜丽莎，你和其他像你一样的工程师都可以看到这里和那里的缺陷从一开始就不应该存在。
所以：
答案 11 :(得分：2)
一个常见的错误是销售人员和技术人员没有充分沟通。因此，销售人员在预算范围内销售技术上不可行的东西。 （然后他们用他们的奖金运行:)）
答案 12 :(得分：2)
我的答案在其他方面相当不寻常，但在这里很常见：杀手锏。我有一个项目需要额外两周（50％的额外时间），因为在我挖掘源代码之前我不知道有一个源代码切换（帮助或网络上没有任何记录）。
答案 13 :(得分：2)
答案 14 :(得分：1)
使用不当的做法和软件开发方法。根据我的经验，项目失败的一个重要原因是开发团队使用错误的方法来面对软件开发过程。选择一种方法而不能很好地理解它的工作原理和方法，可能会给项目带来耗时的问题，比如计划不周。
另一个常见的问题是，如果没有先前的评估技术，使用技术来理解如何应用它，以及它是否为项目带来任何价值。
答案 15 :(得分：1)
人们/公司并不自豪地大吼大叫他们的失败，所以很多情况都听不到。
答案 16 :(得分：1)
IT Project Failures是一个关于项目失败的博客，如果有人想阅读它，可能会有一些答案。
我自己，我认为其中很大一部分问题在于能够准确说明x美元在y美元的预期时间，而真正的答案是更开放的。例如，如果一家公司正在更换ERP或CRM系统，那么很可能一个人不能完全正确地获得所有要求，因此会有一些变化，错误修复和额外的事情来自于一个大项目。举一个类比，考虑进入高中或大学的学生可以在没有参加任何课程的情况下陈述他们所有4年的精确时间表，并最终坚持这一点。我的猜测是很少这样做，因为有些人改变他们想要采取的专业或课程没有提供或其他事情发生改变预期的结果但是如何在我们从这里开始的项目计划中捕捉到我们以为我们要去那里，我们最终在现场排名第三。
答案 17 :(得分：1)
对此进行了一些很好的研究。我建议来自Construx网站（Steve McConnells公司）的this link。
答案 18 :(得分：1)
上面的Construx链接真的很棒！
许多项目都是在现实的美好画面上进行管理的。管理人员倾向于让谈话开发人员乐观地估计。但是说，一个20周的项目被“谈到”到10周。需求阶段现在是1周而不是2.在1周后，需求尚未完成，但项目继续进行。现在你正处于摇摇欲坠的地面 - 而且时间紧迫！
这可能很有趣。曾经有一个老人在我对面的房间里。他的职称是系统管理员。但他应该管理的系统并不存在。虽然管理层认为它已经完成，但它从未完成。这家伙玩了大约一年的游戏，然后感到无聊并继续前进。
最有趣的部分？他离开后，管理层开了一个新职位！
答案 19 :(得分：0)
我认为这个主题成功地聚集了最大的不满意的软件开发人员，工程师，项目经理等，他们可以聚集在一个地方。
我与大多数留在这里的帖子有共同的观点，我认为通过看到同事在工作（编程）中做得不好而成功是我们工作中最重要的部分时，他们从很多痛苦中解脱出来住。
http://www.clean-code-developer.de/ 他们有一个不可思议的事业！他们的理念，如果采取进一步措施，可以设法创造一个新的英雄层，因为这些天开发商和IT专业人员的主流是如此。
我正在巴西做类似的工作，'我喜欢我们将软件带入PM和软件开发人员（.NET）的职业，我不能忍受那些面对编程的人，除了他们的方式几乎不费力地赚取大钱
。...确定我不考虑在电脑亲切之前过夜。但是少数几个重要的人已经不止一次地做过了。
答案 20 :(得分：0)
使用FBI的虚拟案例文件系统，可归结为糟糕的程序管理。该计划有9/11之前的要求和9/11之后的预期。如果政府管理层完成了他们的工作，就会有合同模式。
http://government.zdnet.com/?p=2518
“由于开放式合同几乎没有保障措施，SAIC收获了超过1亿美元，因为该项目变得越来越大，越来越复杂，尽管它的软件从未正常运行。公司继续满足该局的要求，尽管接受了付款根据参与该项目或后来为政府审查的人员，FBI对该项目的处理方式存在严重缺陷的明显迹象。“
虽然700,000行代码的105,000,000美元到每行代码150美元。还不错。
答案 21 :(得分：0)
不同的议程
管理层并不真正了解开发人员的工作，他们如何生成代码以及遇到的困难。他们所关心的只是按时交付的最终产品。但对于开发人员而言，他们关心技术方面，在我们引以为荣的解决方案中精心制作代码。
<强>截止日期
我经常听到开发人员说他们希望能够生成更好的代码，而截止日期通常会促使他们生成一些可行的东西，而不是好的代码。当这些截止日期不合时宜时，问题就会加剧。
答案 22 :(得分：0)
如前所述，参与软件开发的绝大多数人实际上并不了解如何
即使有完美的要求和相关定义，也有太多的开发人员不知道他们在做什么。
只需看看这里提出的问题类型。你会去找一个问同样问题的医生吗？可怕的是，他们要求并且不知道如何学习或推理。
答案 23 :(得分：0)
要真正衡量一个项目是否真的成功，原始估算/预算可能是一个不好的尺度。大多数工程师倾向于低估由于政治压力而需要多长时间，并且他们不知道如何估计。许多经理都是糟糕的策划者，因为他们想要不切实际的最后期限来取悦他们的老板，他们往往不了解所涉及的内容，而且他们可以看到并理解和使用的东西作为会议中的一根棍子，而不是实际帮助解决问题。实际上，它可以帮助企业对预算目的进行粗略的预算预测，至少可以为他们提供一些经验。
更好地衡量项目成功与否 - 用户是否满意？它能帮助企业赚钱吗？获得的资金有多快有助于恢复系统成本？不过，这些比简单的计划更难衡量。
最后，我发现你最好在截止日期前完成任务，即使这意味着加班加点。它很糟糕，但这就是它的现实。
答案 24 :(得分：0)
我听到的最后一个统计数据是，90％的项目要么超出预算，要么超出预算。所以如果你认为失败了，请稍微退一步。
它失败的原因主要在于过程。我们作为软件工程师并不能很好地收集需求和控制客户。因为构建软件对于IT之外的人来说是一项“神秘”的工作，所以他们很难理解为什么最后一刻的变化很难。这不像是建房子，而是清楚地告诉他们为什么不可能在砖砌房子的后面快速增加另一扇门。
答案 25 :(得分：0)
不仅软件项目超出预算，还需要超过预定的时间才能完成。打开报纸，看看像桥梁这样的公共项目。
但对于软件项目来说，取消所有内容要容易得多。如果桥梁或建筑物完成了一半，就无法回头。一半的基础设施到位。这是非常明显的，它需要钱来删除它。
对于软件项目，您可以按Shift-Delete，没有人注意到。
进行准确的成本分析只是一项非常艰巨的工作。