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

1. 在没有实质的数据和分析的情况下，就接受一个强制的日程安排或完成日期/里程碑日期。 
组织中的某个人公开推测项目将在某一特定日期完成，这样在无意中整个团队都会致力于这一期限。也许你的预算周期显示分配给这一项目的资金需要花费到今年年底或者下一个版本不会得到资金支持。也许项目的利益相干人希望项目能在圣诞节前完成，知道项目已经结束他/她就可以安静地享受假期。或者干脆就是因为利益相干人特别喜欢整数，希望项目能够在该月一号发布。为什么一个开发团队会被设定一个主观的项目完成日期的原因五花八门。过于狂热的计划经常导致项目人员配备过度的不幸现实是为什么软件项目失败的另一原因。 　　
2. 添加过多的人员以实现不切实际的日程压缩。 　　
项目经理如何处理过度乐观的项目计划?一个常见的反应就是增加项目组成员，增加的成员经常会比完成项目所需的成员更多。这样不仅会大幅增加项目的成本，还会降低项目质量。让更多的人参与到项目中会增加错误传达的可能性，也会让不同部分的代码整合更具挑战。此外，Frederick Brooks (1975) 的主张“在延期项目中增加人手只会让项目更加滞后”是有一些道理的。这些人员通常是从其他项目中调派而来。这会让其他项目的项目计划更加滞后并且还要求新的成员能够赶上资深成员，这样整体来说生产力是下降的。 　　
3. 未能考虑和调整需求的增长或变化并据此对计划和预算预期进行必要的调整。 　　
“如果……不是更好么?”这种话有时候是更可怕的，特别是在项目组建的过程中道听途说而来时。当然，确实需要时间和场所进行头脑风暴，这些活动应该在第一阶段和第二阶段开展。实际上，这两个阶段的目的就是要决定一个项目是否可行，以及应用应该具备哪些功能特性。你可以如此考虑这个问题，第二阶段帮助你确定所要构建的内容，第三阶段则开始构建在第二阶段所确定的内容。在这两个高级阶段之间存在一定的重叠，当处于阶段三时，对于一个产品发布版本来说，应该已经有了一个清晰的必要功能列表。如果在没有增加开发时间和预算的前提下就增加功能，需求的增长就会成为问题。实际上，这是在要求在更短的时间内完成更多的工作，这种手段早已被证明无效。取决于其特性和时点，已有需求的变更也有可能成为问题。只要变更发生在某一特定迭代的构建之前，使用敏捷开发方法的项目就可以处理这些明细需求的变更。不过，对于任何会导致代码返工的软件架构方面的需求变更几乎必然会对项目的计划和预算产生影响。 　　
4. 忽略事实和统计数据的情绪化或”全凭直觉的“利益干系人谈判。 　　
或早或晚，我们都会与某个我们参与的具体项目紧密联系并在该项目的产出之上投入情感。对于许多人来说，该项目可能关乎自己的声望;项目太大经不起失败，而这经常会让我们被我们的情感所控制。当软件项目的成功或失败悬而未决导致个人的事业处于危险之中时，任何相关的业务决策很有可能都会受到影响。压力可以让人思维混乱，特别是在赌注巨大之时。为了给客户留下深刻的印象，某个利益相干人可能会要求一个12个月的项目计划安排，而完全不顾之前类似规模的项目报告均显示了15个月的生命周期。利益相干人很可能会忽略项目成员的建议，并声称他“感觉”项目团队可以渡过难关。在这种情况下，凭直觉可能是相当不利的并且有可能直接导致项目的失败。 　　
5. 错误，但普遍认为众所周知的银弹可以独自解决项目吞吐量或过程问题。 　　
当其他尝试都已失败时，一个常见的方法就是改变策略。这时比较常见的想法就是“我们现在的所作所为一定是错误的”以及“我们的竞争对手在做些什么?”也就在这时，“IT银弹”的思虑可能就会开始在办公室中蔓延。例如，某人可能会建议组织，需要采用时新的流行开发方法。虽然这可能会将组织引领至一个伟大的方向，但像这样的决策决不应该草草定论。无论你的组织决定采用哪种开发方法，这也只是实现层面的变化。仅仅是开发方法的转变并不足以完成开发操作的转换。 无论做出什么决策，为了能够成功实施，就需要各方均能接受并支持这一决策，并且需要为项目成员提供培训，而且所有人都需要为同样的标准负责。否则，每次启动新的项目时，你的开发策略就基本相当于等待天空的星辰排列整齐，期盼奇迹发生一样。如果没有经过深思熟虑，实现这种策略不仅存在令人难以置信的风险，同时也会减少团队成员在项目中期提供反馈的机会。