我从事软件开发工作已经有十年了，这十年中，亲眼所见、亲耳所闻，报纸、杂志、网络上有各种各样软件项目开发的经验和教训，总的感觉是，成功的少，而失败的多，有的是部分失败，有的是完全失败，我在软件的开发中，也有许多失败的教训，那么软件为什么会失败呢？对于这个问题的回答，有各种各样的答案，我所经历的软件开发中的失败，总结起来，大概是这么几种:
遇到了技术难关项目管理错误，软件失去了控制。
用户需求变化太快，无法把握。
由于某些人员变化而引起项目失败。
我认为，上面的问题只是项目失败的现象，本质并不在于上面提到的几种原因，而在于在软件开发的过程中，项目管理者在项目管理中所犯的几个致命错误：
一、没有或者没有好的项目计划
在开发活动中，项目计划是项目启动后的头一件重大事件，但是经常被忽略或者得不到应有的重视。
项目计划好比是一份项目的交通图，指导项目准确的达到目标，即使它不是被形成提交客户的正式文件，也应该是项目组内的规范文档。可是项目计划往往只是由项目管理者制定或是在项目管理者的脑子里，只有项目管理者知道。这样的项目计划比较粗糙和模糊，同时由于项目计划是由项目管理者制定的，项目组的其他成员只能被动的执行。而项目管理者既不可能是项目中的全才，也不可能代替其他成员工作，因此这种得不到成员认可的项目计划就等于没有制定项目计划。
为什么每个项目都需要一份项目计划，并且要形成规范的文档呢？这是因为：
第一、通过制定计划，使得小组成员，对项目有关事项，如资源配备、风险化解、人员安排、时间进度、内外接口等形成共识，形成事先约定，避免事后争吵不清；
第二、通过计划，可以使得一些支持性工作以及并行工作及时得到安排，避免因计划不周造成各子流程之间的相互牵掣。比如测试工具的选择，人员的培训都是需要及早计划和安排的。
第三、可以使项目组人员明确自己的职责，便于自我管理和自我激励；
第四、计划可以有效的支持管理，作为项目管理者、业务经理、QA经理、测试经理们对开发工作跟踪和检查的依据；
第五、做好事先计划，就可以使注意力专心于解决问题，而不用再去想下一步做什么。
第六、计划是项目总结的输入之一，项目总结其实就是把实际运行情况与项目计划不断比较以提炼经验教训的过程。通过计划和总结，将项目过程中的经验和教训变成公司及项目组成员的知识积累。
制定项目计划的过程被称为项目策划。在项目策划时，要尽量让所有项目参与人员估计自己的工期，使团队成员积极参与到项目中来，而且由于技术发展如此迅速，往往只有具体模块开发人员对那部分工作最了解；项目管理者应该积极推动项目有序进行，积累项目管理数据，推动开发过程能力成熟度的提高，以便可以协同开发人员进行越来越准确的项目估计。
实际工作执行项目计划常常遇到各种困难。有的组织文化中有种观念认为计划是一种约束，反正大家努力往前赶就对了，没必要自己捆住手脚；另外一种情况是大家没有按照计划工作的习惯，计划虽然做好了，做的时候还是我行我素，项目管理者也没有维护计划的习惯，项目开始没多久，项目管理者就埋头去解决具体的技术问题，将计划完全撂到了一边。
事实上，不仅是在项目计划这一问题上，在其它引入制度化的场合都遇到了类似的困惑。据说，美国家庭常会对做家庭清扫这样的事情列出一张“责任矩阵表”，按表的内容顺序进行扫除活动，完成一项作一个记号，这其实就是一种简单的项目管理，他们在如此自然的运用，对于中国人是不可想象的。但是制度化是商业社会的基石，迟早要渗透到社会生活的每一个缝隙。具体到项目管理中的计划活动，除了尽量把计划做的更具可行性以外，努力在组织内传播和培育制度化的组织文化也将是项目管理者们的一项长期责任。
二、正确对待需求变更
作为软件开发人员或者软件系统客户，相信我们都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，说，当时我是那样要求的，不过现在我们的业务调整了…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要……。
需求包括业务需求、用户需求和功能需求。业务需求（Business
Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（UserRequirement ）描述了用户使用产品必须完成的任务，功能需求
（Functional Requirement ）定义了开发人员必须实现的软件功能。在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因:
第一、对需求的理解分歧，当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的做出来的时候客户当然会跳起来了！这是理解分歧的问题，有客户表述责任、同时也体现了双方的交流不够，项目管理者工作中很重要的一项就是“沟通”。项目管理者应该不断组织协调甚至参与和用户的沟通。
第二、系统实施时间过长，一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候（事实上还会有个Deadline ），开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求；
第三、客户具体情况不同，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变；开发本身要求有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了！
所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以我们不应该梦想客户需求不变，当我们开始一个项目的时候就应该意识到，客户需求变更一定会有的。
那么对于这样的现状，我们该怎么办呢？客户是上帝，难道我们就象以前一样，跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护？
如果需求一定会变化，如果我们不得不面对的话，或许可以通过以下的几个方面做到：
加强人员沟通
我们要提高与客户的沟通能力，增强服务意识和责任感，因为将要开发的系统直接建立在和客户沟通后形成的《需求分析》的基础上的；同时规范需求分析人员和客户沟通的方式，以及规范需求说明的格式，如果可能的话，尽量采取象XP的UserStory ，或者用户可以理解的用例图来对需求进行标准、规范的描述，保证双方在工具的协助下对需求达到共同的认识。
确定文档的有效性（Validity ）
需求文档是相当重要的，可是目前存在一种奇怪的现象，本来说必须要有文档，而且是按照某种特定的格式，当然这没有错，但接下来，却没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用（而且很多情况下是在几天时间里赶出来或补上去的），例如我遇到一个例子，
需要在原来的需求基础上进行后续开发，文档找到了，完全符合格式的要求，但是我在里面找到的线索是有限的，结果是自己花几天的时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系，这种情况在设计文档里也存在，所以同时提一提，希望我们的开发人员、PM 以及各级领导可以注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。
建立代价估算（Cost Estimate ）概念
这一点对开发方和客户同样重要，因为如果出现需求变更，不可避免将带来成本的增加、开发时间延长等不良后果，这样的影响是双方的。
这时候需要区分需求变更的原因，是客户方必要/不必要的要求，还是由于开发方的工作失误，还是双方都有原因，然后对现实情况进行分析，得出双方实现变更需求的需要的成本，包括时间，人力，资源等等方面，再与客户商讨是否必要进行变更和如何在最小代价下实现变更。
当客户看到实际的代价估算，他们也会再一次慎重地考虑需求变更问题，也会更容易理解系统建设中的进行状况，自然开发方也不用负担所有的需求变更成本，所以进行成本分摊还是有其积极意义的。
当然还有建立需求变更版本控制等等专业的需求管理。
从软件分析和设计着手
前面说了面对需求变更的几种策略，那么从软件系统分析和设计的角度来看，通过采用合理的分析设计方法，进行可扩展性设计也是有效地降低需求变更引起的风险和维护代价的一个重要手段。
三、项目管理者和开发人员之间的关系
项目管理者和开发人员之间的关系，本来应该是相互团结，相互帮助，共同面对问题的关系，可是许多项目管理者把这种关系扭曲成了管理与被管理的强制性关系，用种种规章制度，种种管理方法来强迫开发人员接受，把自己放到了开发人员的对立面，和开发人员离心离德，甚至还美其名曰"量化管理，科学管理"。在这种糟糕的管理下，开发人员没有任何办法，要么被动接受糟糕的管理，要么辞职以抗议。一旦一个项目发生了这种情况，它想成功就非常难了。
这种问题原来并不明显，现在随着各种MBA，印度经验，软件工厂等似是而非的理论的泛滥，许多人，尤其是许多根本不懂软件开发的管理者，更加变本加历，用近乎苛刻的手段来加强对开发人员的管理，提出种种令人发笑的量化指标来对开发人员进行度量，还加上理论的依据，对于敢于反抗他们这种做法的开发人员，一律以开除来解决问题，造成的一个非常荒诞的现实就是，许多公司里宁愿使用刚刚毕业没有任何经验的学生，不要有工作经验的工程师，美其名曰:易于管理，哈，容易上当受骗而已。请问，在这种管理者和开发人员之间的关系作用下，软件项目有可能获得成功吗?
我个人并不反对尝试性的使用各种开发方法来进行管理，也不反对MBA来管理开发人员，我反对的是软件开发中的强权行为，完全剥夺了开发人员应当具有的对于项目的发言权和建议权，完全不考虑软件开发作为高强度脑力劳动的特殊性，用外行来管理内行并不可怕，可怕的是这个外行偏偏认为自己是内行，这才是事情的可怕之处。外行就是外行，不能因为处在管理者的位置上，就认为自己一下子变成了内行，谁敢反对我谁就走人，用这样的人来管理软件开发，项目组内没法形成一种民主讨论的机制，人人只考虑进度而不考虑质量，软件开发怎么可能成功呢？
项目管理者和开发人员并没有本质的区别，他们只是所处的岗位不同，担任的责任不同而已，在软件开发的问题上，尤其在具体的技术细节上，往往管理者不甚精通，如果他不能吸纳开发人员的智慧，而是自己一个人拍脑袋来做决策，那么失败就在眼前了。
在软件开发中，无论采用那种模型，那种工具，都离不开人的参与，离不开人与人之间的关系，如果不能正确对待人与人之间的关系，把本来正常的，平等的，合作的人与人之间的关系变成了不正常的，不平等的，对抗的人与人之间的关系，那么还希望项目能够成功，无异于缘木求鱼，南辕北辙了。
以上谈到了项目失败的几方面原因，实际上还有很多原因，但是以上的几点是完全可以通过科学的管理解决的。作为一名项目管理者我们没有办法保证所做的每个项目都成功，但是可以通过学习和运用科学的管理办法提高项目的成功率。这是我们的工作也是我们的责任。