美国的研究者分析了大量软件开发项目的数据之后，告诉我们，任何时候这个世界上都有超过50%的软件开发项目正在步向失败。实际上我记忆中最近看到的确切数据是73%的项目最后都是失败的，失败意味着最终提交的系统要么在满足市场需求上已经失效，要么在时间和金钱投入上都大大超过了最初的预计，这还没有包括由于某些原因而被迫中止的项目。

　　连软件开发领域处于世界最前沿的美国都如此，其它地方的情况可想而知;也许这正是为什么软件开发项目管理会成为一门专门的学问之原因。

　　原因

　　言归正传，也许我们可以从他人的教训中吸取一些经验教训，以下几点原因是在一些软件工程著作中经常被提起的项目失败原因，它们大多都在我的工作经验中得到验证，在此分享给各位，以此作为警戒：

　　不切实际的时间安排

　　《最后期限》这本书，也许是项目干系人都应该看看的书，书里面对这条导致项目失败的原因进行了淋漓尽致的刻画和描写，遗憾的是这类项目依然随处可见。几乎在每本介绍软件开发的书中，作者都能举出失败的例子来证明由外界压力强加在开发团队头上的Deadline会对项目造成什么样的伤害，也许在商界，指定一个最后期限是打不破的定律。

　　制定Deadline本身没有错，也是必要的，关键在于Deadline是否切合实际，切合实际的Deadline不是他人凭空捏造出来的，应该是开发团队经过仔细评估之后做出的承诺。

　　不恰当的人员配置

　　这一条也几乎是每本讲软件开发项目管理的书必提到的内容，包括了很多种情况：比如人手配备不够，人员配置混乱，指定了不合适的项目经理，在关键时刻加入人手却指望他们能够立刻发挥作用，etc.

　　软件开发最经典的2本著作《人件》和《人月神话》早就告诉我们，“人-People”才是软件开发里面最关键的因素，而很多决策者却喜欢一定程度上忽略这个事实，这个也没什么好说的，我最近的一条体会是：你用什么样的人去做这个事情，往往已经决定了你会取得什么样的结果，能否取得事先设想的结果，取决于完成工作的“人”以及他们之间的互动关系。

　　破坏性的需求改变

　　需求管理已经成了项目管理的必修课之一，这个没什么好质疑的，一个项目存在的理由就是为了满足某种需求;

　　这里要强调的是，需求的随意更改，对项目必然会造成不好的影响，来自客户的需求如果随意发生变化，软件的设计和实现就要不断地被改动，这是需要时间和金钱代价的;来自开发团队自身的需求更改，可以造成更大的问题，即提交出来的东西是客户不需要的。

　　需求不是不能更改，是不要随意更改，要在控制下更改，或者是有一个良好的变更程序来需求的变化不会对项目造成破坏性的影响。

　　低质的工作

　　如果迫于某种压力生产了一个低质量的软件产品，后期的处理客户投诉、改错、测试等工作会蚕食掉你获得的利润，会让你付出更大的代价;已经有很多很多软件公司在这点上倒下了，以后还会有很多很多的后来人继续栽跟头;

　　让我想起了一句话“恶有恶报，善有善报，不是不报，时间未到”。在开发阶段，若缩减了必要的质量保证工作，就好像欠下了一笔债，迟早是要还的，买单者可能会是不同的人，但必然还是这同一个公司;在一开始就把质量保证好是成本最低的做法，修复同一个缺陷，越到后面就越需要付出更多的代价。

　　相信奇迹

　　自然界可能是真的有奇迹，我们应该相信;然而聚集一群人一起做软件开发这件事情上，有的只是人们的付出产生的结果，连“银弹”都不会有，怎么会有奇迹呢?然而依然有不少人“相信”有奇迹：譬如期望在混乱无序的团队中产出高质量的成果;期望在不可能实现的交付日成功交付产品;比如希望在没有质量控制措施的情况下得到很高质量的产品;

　　在软件产品开发这件事情上，真的是一分耕耘，一分收获，不存在所谓的奇迹，需求分析的时候没有对需求进行良好的管理，最终提交的时候客户一定会提出问题;设计的时候没有考虑性能问题，测试时你必将遇到性能上的限制;实现一个功能的时候没有做好质量控制，最终整合的时候一定会暴漏很多缺陷;所以只有报着踏踏实实的态度才是成功完成项目的王道。