为什么今天许多软件项目都失败了？
只要还有软件项目，全世界都会想知道为什么它们经常失败。
我想知道是否有一个列表或类似的东西可以显示今天有多少软件项目失败了。 如果能对过去 20-30 年进行比较就好了。
您还可以添加软件项目失败的首要原因。 我的答案是“需求很差，甚至不存在”。 其中还包括“不涉及（真正的）客户/用户”。
编辑：明确定义“失败”一词几乎是不可能的。 假设失败意味着：该项目超出预算和时间 10% 以上。 我认为 10% +/- 对于报价/投标来说是一个不错的范围。
编辑：到目前为止（2 月 11 日），似乎大多数发帖者都认为项目的失败基本上是项目管理的失败（无论失败意味着什么）。 但恕我直言，大多数开发人员对这种情况并不满意。 也许是因为项目不成功时受到惩罚的不是经理，而是懒惰、无能的开发团队？
当我阅读这些帖子时，我还可以听到开发人员和管理人员之间存在很大的“差距”。 期望（也许也是需求）似乎如此不同，以至于项目最终无法成功（随着时间/预算的推移；用户不满意；并非所有优先功能都已实现；太多错误，因为开发人员被迫在太短的时间内实施......）
我问自己：我们如何改进它？ 或者我们有可能改进它吗？ 每个人似乎都对现在的情况不满意。 我们能否缩小这两个世界之间的差距？ 我们（开发人员）是否应该罢工并争取“高质量要求”和“基于现实/迭代的时间安排”？
编辑： Ralph Westphal 和 Stefan Lieser 建立了一个新的“社区”，名为：Clean-Code-Developer。 该小组的目标是为软件工程带来更多的专业精神。 独立地，如果开发人员拥有学位或多年经验，您就可以成为这一运动的一部分。
清洁代码开发人员的生活原则 每天都像固体一样。 专业人士 开发者是最大的评论者 他自己的作品。 而且他有一个内在的 价值体系帮助他提高并变得更好。
查看：清洁代码开发人员
编辑： 我们公司是目前正在做一项名为“应用程序开发和维护基准测试”的事情。 这是 IBM 提供的一项服务，旨在从外部人员那里获取有关您的软件工程流程质量等的反馈。当我们得到结果时，我会告诉您更多相关信息。
As long as there are software projects, the world is wondering why they fail so often.
I would like to know if there is a list or something equivalent which shows how many software projects fail today. Would be nice if there would be a comparison over the last 20 - 30 years.
You can also add your top reason why a software project fails. Mine is "Requirements are poor or not even existing." which includes also "No (real) customer / user involved".
EDIT: It is nearly impossible to clearly define the term "fail". Let's say that fail means: The project was more than 10% over budget and time.
In my opinion the 10% + / - is a good range for an offer / tender.
EDIT: Until now (Feb 11) it seems that most posters agree that a fail of the project is basically a failure of the project management (whatever fail means). But IMHO it comes out, that most developers are not happy with this situation. Perhaps because not the manager get penalized when a project was not successful, but the lazy, incompetent developer teams?
When I read the posts I can also hear-out that there is a big "gap" between the developer side and the managment side. The expectations (perhaps also the requirements) seem to be so different, that a project cannot be successful in the end (over time / budget; users are not happy; not all first-prio features implemented; too many bugs because developers were forced to implement in too short timeframes ...)
I',m asking myself: How can we improve it? Or do we have the possibility to improve it? Everybody seems to be unsatisfied with the way it goes now. Can we close the gap between these two worlds? Should we (the developers) go on strike and fight for "high quality reqiurements" and "realistic / iteration based time shedules"?
EDIT: Ralph Westphal and Stefan Lieser have founded a new "community" called: Clean-Code-Developer. The aim of the group is to bring more professionalism into software engineering. Independently if a developer has a degree or tons of years of experience you can be part of this movement.
Clean Code Developers live principles
like SOLID every day. A professional
developer is the biggest reviewer of
his own work. And he has an internal
value system which helps him to improve and become better.
Check it out on: Clean Code Developer
EDIT: Our company is doing at the moment a thing called "Application Development and Maintenance Benchmarking". This is a service offered by IBM to get a feedback from someone external on your software engineering process quality etc. When we get the results, I will tell you more about it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（26）
管理不善。
项目的成功或失败并不取决于项目的某些基本特征，而是取决于它们是否满足用户的需求。 （它们可能会完全失败，在这种情况下，对可能发生的事情存在严重错误陈述。）软件项目往往是在评估项目的可行性和成本效益比以及建立目标的过程中倾向于失败或失败。成功。
处理事实和事物的人（例如程序员）和处理其他人的人（例如销售人员和经理）之间存在脱节。 对于程序员来说，事实就是事实，必须面对。 对于销售人员来说，事实就是其他人的想法，并且是可变的。
有形事实和无形事实之间也存在差异。 没有人认为工人们如果真的有动力的话，可以在一个月内建造一座大桥； 他们可以看到所有必须移动和固定到位的钢材、混凝土和其他东西。 软件不太有形，并且缺乏物理限制：虽然理论上不可能在一个月内建造桥梁，但可以想象，一个团队可以在一个月内创建一个大型项目，因为“所有”他们都必须做就是第一次就把一切做好。 从物理上来说，每天输入数千行代码是可能的； 只是它们按原样可用的机会非常接近于零，所以并不重要。 与（比如说）记者的生产力相比，顶级开发人员的实际生产力在字数方面实际上并不令人印象深刻。
因此，那些习惯于灵活事实的人不会受到强加的物理限制来提醒他们事情只能推进到此为止，无法理解编程实际需要什么，也无法很好地了解实际可能实现的生产力有多大。 此外，他们比一般开发商更知道如何在谈判中取得进展，因此在谈判中，他们往往会假设比在现实世界中所能得到的更多的东西。
与此同时，软件开发本质上是模糊的，因为生产物理产品是微不足道的。 一旦软件开发完成，我就可以快速且廉价地制作软件的副本。 软件开发是纯粹而简单的设计工作。 任何与制造相关的东西都被诸如编译器、向导和代码生成之类的东西无情地消除了。 面对想要实现不可能的经理，开发人员发现很难说不可能实际上是不可能的，因为没有办法说它实际上是不可能的。 鉴于未知的事实足以让人感觉灵活，具有强大谈判技巧和决心的人通常会得到他或她想要的答案。
鉴于这种脱节，人们可能会问谁有责任弥合这种脱节。 在我看来，答案是明确的。 了解不同人的想法的责任属于专门与他人打交道的人。 协调不同类型的人的责任属于负责协调这些事情的人。 因此，管理者。
真正了解软件开发和开发人员并且能够与其他经理打交道的经理会做得很好，他们的项目通常会成功。 世界上还有太多其他类型的人。
Bad management.
Projects are not successes or failures based on some underlying feature of the project, but on whether they fulfill the needs of the users. (They can fail altogether, in which case there was a gross misstatement of what was possible.) It is mostly in the process of evaluating the feasibility and cost-benefit ratio of the project, and establishing goals, that software projects tend to fail or succeed.
There's a disconnect between people who deal with facts and things (like programmers) and people who deal with other people (like sales types and managers). To a programmer, the facts are the facts, and have to be dealt with. To a sales person, the facts are what other people think, and are changeable.
There's also differences between tangible and intangible facts. Nobody thinks that workers could build a large bridge in a month if they were really motivated; they can see all the steel and concrete and other stuff that has to be moved and fixed into position. Software is much less tangible, and lacks the physical restrictions: while it is not even theoretically possible to build the bridge within a month, it is conceivable that a team could create a large project within a month, as "all" they have to do is get everything right the first time. It is physically possible to type thousands of lines of code a day; it's just that the chance that they're usable as is is so close to zero it doesn't matter. The actual productivity of a top developer is actually pretty unimpressive in word count, compared to (say) the productivity of a journalist.
Therefore, those who are used to flexible facts don't have the imposing physical limits to remind them that things can be pushed only so far, no appreciation for what programming actually requires, and no good feel for how much productivity is realistically possible. Moreover, they know how to get their way in negotiations, much more than the average developer, so in negotiations about what's possible they tend to assume more than they can, in the real world, get.
In the meantime, software development is inherently fuzzy, because producing the physical product is trivial. I can produce a copy of software quickly and cheaply, once it's been developed. Software development is design work, pure and simple. Anything corresponding to manufacturing is ruthlessly eliminated with such things as compilers and wizards and code generation. The developer, faced with the manager who wants the impossible, finds it hard to say the impossible is actually impossible, because there's no way to say it's actually impossible. Given facts that are unknown enough to feel flexible, the person with strong negotiating skills and determination will typically get the answer he or she wants.
Given this disconnect, one might ask whose responsibility it is to bridge it. The answer is, in my opinion, clear. The responsibility for understanding how different people think belongs to the people who specialize in dealing with other people. The responsibility for coordinating different types of people belongs to the people whose job it is to coordinate these things. Therefore, managers.
Managers who do understand software development and developers, and can deal well with other managers, will do well, and their projects will generally succeed. There are still far too many of the other type in the world.
这不是直接答案，但我发现虚拟案例文件是一个令人着迷的案例研究一个政府支持、资金充足的大型项目如何仍然会陷入困境。
另一篇 IEEE Spectrum Online 文章“为什么软件失败" 研究了这个问题。 它总结了以下要点：
Not a direct answer, but I found the Virtual Case File to be a fascinating case study on how a big government-backed well-funded project can still tank.
Another IEEE Spectrum Online article "Why Software Fails" examines this very question. It summarizes the major points as follows:
规划不善。
Poor planning.
霍夫施塔特定律
Hofstadter's Law
管理不善。
软件项目的启动是让开发人员解决一个已知的问题。 业务需求随着项目的进展而具体化。 在截止日期不变的情况下添加新功能。 更多的开发人员被投入。原始项目成员退出或被解雇。 至此，该项目投入了太多的时间、金钱和资源，因此无法取消。 随着截止日期的到来，尽管明显缺乏成品，但该项目仍被宣布完成并成功。
想想看 - 我曾乘坐飞机看到一个软件项目失败......
Mismanagement.
SW project get started by throwing developers against a perceived problem. Business requirements crystallize as the project progresses. New functionality gets added while deadlines stay put. More developers are thrown in. Original project members quit or get fired. By this point too much time, money and resources is invested in the project so it cannot be canceled. As the deadline passes the project is declared finished and successful despite the obvious lack of finished product.
Come to think of it - I've jet to see a SW project fail...
老实说，我认为这是因为大多数程序员不太擅长他们所做的事情（我并不是说只是编写代码）。 stackoverflow 上的人可能是例外。 我不了解你们其他人的情况，但作为一名顾问/合同程序员，我在很多地方或周围工作过，平庸或差劲的程序员与优秀程序员的比例约为 10 比 1。
我的优势之一一直是准确估算，然后按时、按预算或按预算交付 - 我的目标始终是按时、低于成本 10%。 然后我想告诉我的客户，因为我完成的事情比预期的要少，所以你想添加哪些“额外”？
即使功能完美的产品迟到和/或超出预算也会被许多业务经理视为失败。 程序员通常只关注他们所做工作的技术方面，很少考虑成本或截止日期。 你真的需要把这三件事都做好才能被认为是成功的项目。 毫无疑问，还有许多其他程序员可以在我周围编写代码，但对于为该项目付费的人来说，这远远不够。
Honestly, I think its because most programmers are not very good at what they do(and I don't mean just cranking out code). People on stackoverflow are probably the exception. I don't know about the rest of you but as a consultant/contract programmer I have worked in or around many places, and the ratio of mediocre or poor programmers to good ones is about 10 to 1.
One of my strengths has always been estimating accurately and then delivering on time and on or under budget - I always aim for coming in 10% under cost and on time. Then I like to tell my client that because I got things done for less $$ than expected, which of the "extras" would you like to add in?
Even a perfectly functioning product that is late and/or over budget will be considered a failure by many business managers. Programmers often focus on just the technical aspects of what they do, with little regard for the cost or deadline. You really need to do all three well for it to be deemed successful project. There are many other programmers that could code circles around me without a doubt, but for the person paying for the project, that is rarely enough.
这是因为似乎没有人再读书了。
项目失败的每一个原因都被一次又一次地分析。
您只需阅读三本书就可以知道为什么 80% 的项目失败：《
最后期限：一本关于项目管理的小说》（Tom Demarco，1997 年出版）
这是一个很棒的介绍，而且非常有趣。
Peopleware：富有成效的项目和团队（Tom Demarco，1987 年出版）
《人月神话：软件工程论文》（Fred Brooks，1975 年出版）
作为一个职业，我们似乎每隔 3-5 年就会忘记一切（参见“集中计算效率低下；让客户处理它”与云计算）。
It is because no-one seems to read anymore.
Every single reason why projects fails has been analyzed time and time again.
You only have to read three books to know why 80% of projects fail:
The Deadline: A Novel About Project Management (Tom Demarco, published 1997)
It's a great introduction and it's pretty entertaining.
Peopleware : Productive Projects and Teams (Tom Demarco, published 1987)
The Mythical Man-Month: Essays on Software Engineering (Fred Brooks, published 1975)
We as a profession simply seem to forget everything every 3-5 years (see "centralised computing is inefficient; let the clients handle it" vs cloud computing).
（从程序员的角度来看 - 我不是项目经理，但我经常参与这个过程）。
许多人提到糟糕的程序员是一种普遍现象。 但我认为这在另一种意义上也是正确的——我们都是糟糕的程序员，因为我们发现很难预测复杂性，这是一个不可避免的问题，50 年的灵丹妙药估计和规划方案都未能解决。
随着项目的增长，预测大型项目的副作用会变得更加困难。 当然，这是一个乏味的老生常谈，但对我来说，这意味着在我参与过的任何项目中，我参与了估算过程，我遇到过一些设计决策会产生意想不到的后果的情况，导致一切都陷入停滞，或者至少需要几天的错误修复——只是没有人预见到的事情，而不是任何形式的弊端或愚蠢。 这只是一个足够复杂的系统的本质。
除了内在的不确定性之外，人们还倾向于低估那些已知轮廓的事物，因为它们的不确定性较小，这使得它们看起来更容易实现。
因此，不确定的事情被放大，明确的事情被最小化，而真正杀死你的是那些你认为不确定的事情。
(From a programmers point of view - I'm not a project managemer, but I've often been involved in the process).
A number of people have mentioned that bad programmers are endemic. But I think this is true in another sense as well - we're all bad programmers in that we find it difficult to anticipate complexity, an unavoidable issue that 50 years of magic bullet estimation and planning schemes have failed to solve.
Anticipating the side effects of large projects gets exponentially more difficult as projects grow. This is a dull truism, for sure, but for me it means that on any project I've worked on where I've been involved in the estimating process I've run into some case where there's an unanticipated consequence of a design decision that causes everything to come to a grinding halt, or at least a few days of bugfixing - just something that nobody foresaw, not any sort of malpractice or stupidity. It's just the nature of a complex enough system.
Aside from the built-in uncertainty, there's also a tendency to underestimate things whose outline is known, because the fact that they have less uncertainty makes them seem simpler to implement.
So the uncertain stuff gets magnified, the clear stuff gets minimized, and what really kills you is the thing that you didn't think would be uncertain.
第一个原因：项目管理失败。
PM 存在的理由是让项目成功，因此项目失败就是他们的失败。 当然，有些因素是他们无法控制的，但管理这种风险仍然在PM的职责范围内，唯一的退出条款应该是食物链上层的人采取决策控制（这对PM来说是一件可怕的事情）或天灾。
根据我的经验，失败大多发生在 PM 工作快速、松散或不存在时，包括当销售人员开始做出决策时以及当客户开始颁布变更控制令时。 一位好的产品经理是无价的。
The number one reason: a failure of project management.
A PM's raison d'etre is to make a project succeed, ergo a project failure is their failure. Certainly there are factors beyond their control, but it's still within the PM's job description to manage that risk, and the only get out clauses should be someone higher up the food chain taking decision control (which is a terrible thing to do to a PM) or acts of god.
In my experience failures mostly occur when PM work has been fast and loose or non-existant, including when decisions start to flow from sales people and when the client starts decreeing change control. A good PM is priceless.
失败是一种判断——实际上更多的是一种指责。
“该项目超出了预算和时间 10% 以上。”
哪个预算？ 哪个时间表？
6个月前，我写了一个计划，说需要6个月。
3个月前，用户要求更多的东西。 我给了他们一个计划，说还需要 9 个月。
上个月我被告知该项目超出预算 6 个月，因此“失败”。
可是等等。 它提供了用户想要的东西。 这超出了“最初”的估计。 这是根据修订后的估计。 用户想要更多。 IT 想要更少。
Failure is a judgement -- more of an accusation, really.
"The project was more than 10% over budget and time."
Which budget? Which schedule?
6 months ago, I wrote a plan saying it would take 6 months.
3 months ago, the users asked for more stuff. I gave them a plan that said it would take 9 more months.
Last month I was told that the project was 6 months over budget and therefore a "failure".
But wait. It delivered what the users wanted. It was over the "original" estimate. It was under the revised estimate. The users want more. IT wants less.
我将从与这里其他大多数人不同的方面来处理它。
我注意到一个项目在一段时间内慢慢失败。 当然，当时它也变得更好了——但它仍然没有盈利。 在这个市场中，盈利和盈利就意味着成功。
为什么会失败？ 我认为这很简单：一分钱一分货。
软件就像银行账户，而不是原始的软泥。 如果你不投入资源（时间、金钱、专注、努力），那么除了失败和成本之外，你不会得到任何东西。 因此，你必须在你的项目中投入一些东西，有时最早的工作为未来几年奠定了基础。 你不可能在你的电脑上泼脏水，然后指望在两年内得到一个新鼠标，并在之后花费 1000 万美元，所以同样必须付出努力。
当今最大的问题之一是第三世界国家的“预算开发商”。 我并不嫉妒他们占据市场份额，但对于一家资金雄厚的硅谷初创公司来说，寻找他们并获得预算基础（框架甚至原型）对于未来来说是一项糟糕的投资。 今天，同样的预算框架给我的朋友们带来了很多麻烦。 现在可以了； 它在编写时有效，但写得不好，甚至很少有人花时间维护它。 如果公司停止并按照最初应该编写的方式重写软件，他们就不会遇到所有这些麻烦。 他们有时间吗？ 没有。 他们必须先使其有利可图，然后才能真正实现这一目标。
俗话说：“我能做到：便宜、快或好。现在，选择其中任意两个。” 每个人都想要这三个，包括我自己。 但是，如果您没有投入时间、计划和工作来使您的项目从一开始就取得成功……那么就不要指望以后会有什么让您感到自豪的事情。 感觉就像是伪造的蒙娜丽莎，您和所有其他像您一样的工程师都可以在这里或那里看到从一开始就不应该存在的缺陷。
所以：
I'll approach it from a different aspect than most the rest here.
I've noticed a project slowly fail over a period of time. Sure, it's gotten better in that time too--but it still isn't profitable. In this market profitability, and being in the black, means success.
Why is it failing? I think it's simple: you get what you pay for.
Software is like a bank account, not primordial ooze. If you don't put resources into it (time, money, focus, effort) then you won't get anything out of it except failure and cost. So you must invest things into your project, and sometimes the earliest work sets the stage for years to come. You can't throw mud at your computer and expect a new mouse in two years and $10 million dollars later, so likewise there must be effort expended.
One of the biggest problems today are "budget developers" in a third-world country. I don't begrudge them their part of the market, but for a well-funded Silicon Valley startup to seek them out and get a budget foundation (framework or even prototype) is to make a poor investment in the future. This very same budget framework is what is causing my friends so much of a hassle today. It works now; it worked when it was written, but it wasn't written well and few even take the time to maintain it. Were the company to stop and rewrite the software the way it should have been written in the first place they wouldn't have all this trouble. Can they afford the time? Nope. They have to make it profitable before they can even thing of it.
As the saying goes, "I can make it: cheap, fast or good. Now, pick any two of those." Everyone wants all three, myself included. But if you don't invest the time, planning, and work required to make your project a success from the start ... then don't expect anything you can be proud of later. It'll feel like a forged Mona Lisa where you, and every other engineer like you, can see a defect here and there that shouldn't have been there from the start.
So:
一个常见的错误是销售人员和技术人员沟通不充分。 因此，销售人员出售的产品在技术上在预算范围内是不可行的。 （然后他们带着奖金跑了:)）
One common mistake is that sales people and technical people do not communicate sufficiently. So the salespeople sell things that are technically not feasable within budget. (And then they run with their bonus :) )
超出预算和时间并不是失败的一个很好的定义（实际上，在预算和时间之内并不总是意味着成功）。 采用 PMP 休·伍德沃德 (Hugh Woodward) 在 专家项目管理 - 项目成功：寻找中提供的以下示例超越传统项目指标：
你觉得这个结论怎么样？ 你如何真正定义成功？
Being over budget and time is not a good definition of failure (and actually being in budget and time doesn't always mean success). Take the following examples provided by Hugh Woodward, PMP, in Expert Project Management - Project Success: Looking Beyond Traditional Project Metrics:
What do you think of that conclusion? How do you really define success?
我的回答与其余部分相比相当不寻常，但在这里很常见：致命错误。 我有一个项目额外进行了两周（50% 的额外时间），因为源代码中的一个切换我直到我深入研究源代码才知道（帮助或网络上没有任何记录）。
My answer is rather unusual from the rest of this, but quite common around here: killer bugs. I had a project go an extra two weeks (50% extra time) because of one switch in source that I didn't know about until I dug through the source code (there was nothing documented in help or on the web).
人们/公司不会自豪地大喊自己的失败，因此很多案例永远不会被听到。
People/companies do not proudly shout about their failures, so many cases wont be ever heard.
实践和软件开发方法使用不当。 根据我的经验，项目失败的一大原因是开发团队使用了错误的方法来面对软件开发过程。 在没有充分了解方法的工作原理和需要什么的情况下选择一种方法，可能会给项目带来耗时的问题，例如规划不善。
另外一个常见的问题是使用技术时没有事先对其进行评估，以了解如何应用它，以及它是否给项目带来任何价值。
Poor use of practices and software development methods. In my experience, one of the big reasons a project failed its that the development team use a wrong method to face the software development process. Choosing a methodology without having a good understanding of how it works and what it takes, can bring a time consuming issues to a project, like poor planning.
Also a common problem is also the use of technologies without a previous evaluation of it to understand how it can be applied, and if it brings any value to the project.
在这方面已经做了一些很好的研究。 我推荐 Construx 网站（Steve McConnells 公司）的此链接。
There have been some good studies done on this. I recommend this link from the Construx website (Steve McConnells company).
上面的 Construx 链接非常好！
许多项目都是在乐观的现实情况下进行管理的。 管理者倾向于说服开发商做出乐观的估计。 但假设 20 周的项目被“讨论”到 10 周。 需求阶段现在将是 1 周，而不是 2 周。1 周后，需求尚未完成，但项目会继续进行。 现在您的工作基础并不稳固，而且日程安排也很紧张！
这可能很有趣。 有一次，我对面的房间里有一个老家伙。 他的职位是系统管理员。 但他应该管理的系统不在那里。 尽管管理层认为已经完成，但它从未完成。 这家伙玩了大约一年的游戏，然后感到无聊并继续前进。
最有趣的部分？ 他离开后，管理层提出了一个新的职位空缺！
The Construx link above is real good!
Many projects are managed on a rosy picture of reality. Managers tend to power talk developers into optimistic estimates. But say a 20 week projects gets "talked down" to 10 weeks. The requirements phase will now be 1 week instead of 2. After 1 week, the requirements aren't finished, but the project moves on. Now you're working on shaky ground-- and on a stretched schedule!
This can be funny. Once there was this old guy in a room opposite mine. His job title was system adminstrator. But the system he was supposed to adminsiter wasn't there. It had never been finished, although management thought it had been. The guy played games for about a year before he got bored and moved on.
The funniest part? Management put up a new job opening after he left!
IT 项目失败 是一个关于项目失败的博客，如果有人想阅读，这里可能有一些答案关于它。
我自己认为，这很大程度上取决于一个问题，即能够准确地说明 x 个月内 y 美元的预期，而实际上答案是更加开放的。 例如，如果一家公司正在更换 ERP 或 CRM 系统，那么很可能无法完全满足所有要求，因此会出现一些更改、错误修复和额外内容。一个大项目。 打个比方，考虑一下有多少进入高中或大学的学生可以在不参加任何课程的情况下说出他们四年的准确时间表，并最终坚持下去。 我猜很少有人会这样做，因为有些人改变了专业，或者没有提供他们想要学习的课程，或者发生了其他事情，改变了预期的结果，但这是如何在我们在这里开始的项目计划中体现的，而我们我们以为我们要去那里，结果我们却到了第三个地方。
IT Project Failures is a blog about project failures that may have a few answers here if one wants to read about it.
Myself, I think a large part of this lands on the question of being able to state exactly what is expected in x months at $y when really the answer is much more open-ended. For example, if a company is replacing an ERP or CRM system, there is a good chance that one isn't going to get all the requirements exactly right and thus there will be some changes, bug fixes and extras that come from taking on such a large project. For an analogy consider how many students entering high school or university could state their precise schedule for all 4 years without taking any classes and actually stick to that in the end. My guess would be very few do that as some people change majors or courses they wanted to take aren't offered or other things happen that change what the expected result is but how is this captured in a project plan that we started here and while we thought we were going there, we ended up way over in spot number three.
我听到的最后一个统计数据是，90% 的项目要么超出时间，要么超出预算。 所以，如果你认为这失败了，那就退出吧。
失败的原因主要在于流程。 作为软件工程师，我们在收集需求和控制客户方面做得不好。 因为构建软件对于 IT 以外的人来说是一项“神秘”的工作，所以他们很难理解为什么最后一刻的改变很困难。 这不像建造一栋房子并清楚地向他们展示为什么不可能在砖砌房子的背面快速添加另一扇门。
The last statistic that I heard was that 90% of projects are either over time or over budget. So if you consider that failing, quit a bit.
The reason why it fails mainly lies on process. We as software engineers don't do a good job of gather requirements, and controlling the customer. Because building software is a "mysterious" job to people outside of IT, it is difficult for them to understand why last minute changes are difficult. It's not like building a house and clearly showing them why it isn't possible to quickly add another door to the backside of the house made of brick.
不仅软件项目超出了预算，或者完成时间也超过了预定时间。 只要打开报纸，看看桥梁等公共项目。
但对于软件项目来说，取消一切要容易得多。 如果桥梁或建筑物只完成了一半，就没有回头路了。 一半的基础设施已经到位。 它非常明显，需要花钱才能将其去除。
对于软件项目，您可以按 Shift-Delete 键，但没有人会注意到。
进行准确的成本分析是一项非常困难的工作。
Not only software projects go over budget, or take more than scheduled time to complete. Just open the newspaper and look at public projects like bridges.
But for a software project it is far more easy to cancel everything. If a bridge or building is half finished, there is no way back. Half the infrastructure is in place. It is very visible and it takes money to remove it.
For a software project you can press Shift-Delete and nobody notices.
Its just a very hard job to do an accurate cost analysis.
使用联邦调查局的虚拟案件文件系统可以归结为程序管理不善。 该计划有 9/11 之前的要求和 9/11 之后的期望。 如果政府管理层完成了他们的工作，就会有合同模组。
http://government.zdnet.com/?p=2518
“由于开放随着项目变得越来越大、越来越复杂，SAIC 在几乎没有保障的情况下结束了合同，尽管其软件从未正常运行，但仍继续满足该局的要求，接受付款，尽管有明显迹象表明 FBI 的态度。据参与该项目或后来为政府审查该项目的人士透露，该项目存在严重缺陷。”
虽然 700,000 行代码需要 105,000,000 美元，但每行代码需要 150 美元。 还不错。
Using the FBI's Virtual Case File system it comes down to poor program management. The program had pre-9/11 requirements and post-9/11 expectations. Had government management done their job there would have been contract mods.
http://government.zdnet.com/?p=2518
"Because of an open-ended contract with few safeguards, SAIC reaped more than $100 million as the project became bigger and more complicated, even though its software never worked properly. The company continued to meet the bureau’s requests, accepting payments despite clear signs that the FBI’s approach to the project was badly flawed, according to people who were involved in the project or later reviewed it for the government."
Although $105,000,000 for 700,000 lines of code comes to $150 per line of code. Not too bad.
要真正衡量一个项目是否真正成功，最初的估算/预算可能是一个糟糕的标准。 由于政治压力，大多数工程师往往会低估需要多少时间，而且他们也不知道如何估计。 许多经理都是糟糕的计划者，因为他们想要不切实际的最后期限来取悦他们的老板，他们常常不明白其中涉及的内容，而且他们可以在会议中查看和理解并使用这些东西作为会议的棍子，而不是真正帮助解决问题。 实际上，它可以帮助企业出于预算目的对费用进行粗略预测，至少为他们提供了一些依据。
衡量项目成功的一个更好的标准是——用户满意吗？ 对企业赚钱有帮助吗？ 所获得的资金能够以多快的速度收回系统成本？ 不过，这些比简单的计划更难衡量。
最后，我发现你最好按时交付，即使这意味着加班。 这很糟糕，但这就是现实。
To truly gage whether a project is really successful, the original estimate / budget is probably a poor yardstick. Most engineers tend to underestimate how much time it will take because of political pressure, and they don't know how to estimate anyway. Many managers are poor planners because they want unrealistic deadlines to please their boss, they often don't understand what's involved, and plus it's something they can look at and understand and use as a stick in meetings, as opposed to actually helping solve problems. Practically, it helps businesses make rough projections of expense for budgeting purposes, at least it gives them something the go by.
A better measurement of project success would be - are the users happy? Does it help the business make money? How fast will the money gained help recover the cost of the system? These are harder to gauge than a simple plan, though.
In the end, I've find you're better off delivering on deadline, even if it means working some overtime. It sucks, but that is the reality of it.
如前所述，参与软件开发的绝大多数人实际上并不了解如何
即使有完美的需求和相关定义，太多开发人员也不知道他们在做什么。
只需看看这里提出的问题类型即可。 您会去找一位问同样问题的医生吗？ 可怕的是他们提出问题却不知道如何学习或推理。
As stated previously the vast majority of people involved in software development to not actually understand how
Even with perfect requirements and related definitions too many developers don't know what they are doing.
Just look at the types of questions asked here. Would you go to a doctor that asked the same equivalent question. The scarey thing is that they ask and don't know how to learn or reason.
不同的议程
管理层并不真正了解开发人员的工作、他们如何生成代码以及遇到的困难。 他们所关心的只是按时交付的最终产品。 但对于开发人员来说，他们关心的是技术方面，以及他们引以为傲的解决方案中制作精良的代码。
截止日期
我经常听到开发人员说他们希望能够编写出更好的代码，而截止日期常常迫使他们编写一些可以正常工作的东西，而不是编写好的代码。 当这些最后期限不切实际时，问题就会加剧。
Different agendas
Management do not really understand what a developer does, how they produce code and the difficulties encountered. All they care about is the final product delivered on time. But for a developer they care about the technical aspects, well produced code in a solution they our proud of.
Deadlines
I've often heard developers say they wish they could produce better code, and that deadlines often push them into producing something that just works, rather than good code. When these deadlines are unreallistic the problems are exacerbated.
我认为这个帖子成功地将最大的一群才华横溢、不高兴的软件开发人员、工程师、项目经理等聚集在一个地方。
我与这里的大多数帖子有着相同的观点，我认为当工作（编程）和成功是我们生活中最重要的部分时，看到同事做得不好，他们就从很多痛苦中走出来。
http://www.clean-code-developer.de/
他们有着不可思议的事业！ 他们的理念如果被采纳，可能会创造出新的英雄阶层，因为如今开发人员和 IT 专业人员的主流已经如此腐烂了。
我在巴西正在做类似的事情，因为我喜欢我们作为 PM 和软件开发人员 (.NET) 的职业，让软件焕发活力，而且我无法忍受那些将编程视为别的东西，但他们却想出路的人几乎不费吹灰之力就能赚大钱。
...当然我不考虑在电脑前过夜。 但少数重要人物却不止一次地这样做过。
I think this thread managed to gather the biggest group of tallented unhappy software developers, engineers, project managers, etc. that it is possible to gather in one place.
I share point of view with most of the posts stuck here and I think they come out of a lot of suffering through seeing co-workers not doing a good job when job (programming) and success is the most important part of our lives.
http://www.clean-code-developer.de/
They have an incredible cause! and their philosophy, if taken ahead, could manage to create a new layer of heroes, as the main stream of developers and IT professionals is so ROT these days.
I'm working on something similar here in Brazil, 'cos I love our profession of bringing software alive both as PM and software developer (.NET) and I can't stand people who face programming as nothing else but they way out to make big money with almost no effort.
... sure I don't consider going overnight in front of the computer geniality. but the few who matter, have done it more than once.