软件项目失败经验总结 (1)

项目失败经验总结

1、在项目初期没有进行风险的管理探讨，项目远景定义和功能集合的详细定义。

当项目走了很远，出现很多问题的时候，领导总算想起要做一个边界定义，但这个时候已经迟了，项目已经变得不可控制。

经验总结：

由于客户一般对计算机不是很了解，和他们交流是用软件行业的专业俗术语，他们根本就不懂，如果用文档也很难把需求写得那么明白，而且文档很多的话，客户都看烦了，很不直观。

如果让客户一看就可以看出这个就是他们想要的，我认为最好的方式就是做系统原形（界面的功能模拟）。

系统原形应该在需求分析师的指导下完成，当然开发只是界面的功能模拟，没有底层代码的实现。这样做的目的有三个好处，一是客户很直观的看到他们的系统是什么样子的以及怎么操作，二是这些开发的成果是可以二次利用的，三是可以更好的激发客户的需求。

2、不注重用户参与。

没有一开始就让用户参与详细需求的制定的做法，大部分都是靠需求采集人员的猜想，猜想往往和实际有差距，造成系统功能不切合实际，与项目实际需求差距大，运行效果差。

经验总结：

项目的开始和结束用户是需要一直参与进来的，我们每做个可以运行的功能等就需要和用户交流，这样可以避免很多风险也可以尽早发现需求的误解的等等。

需求调研前期的《信息化规划》、《目标与范围》和需求调研末期的《软件开发需求规格说明书》都要跟客户签字确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。

3、集团化以后，项目经理没有意识到信息化核心问题是管理变革问题，还跟着原来的思路开发软件。

在组织架构、权限、供应商等方面与力和集团理解不一致，没有分别按组织进行区分。

经验总结：

要根据企业业务需求制订策略,调整软件组织结构, 详细设计软件各组织架构之间的逻辑关系，做好这些最基础的功课，避免信息化项目成为无本之木。

4、软件开发人员、设计人员能力的低下、项目经理的管理能力不足。

低素质开发人员由于没有接触过实际业务，无法跟客户沟通，甚至害怕客户提出需求，总是担心客户的需求会增加自己的工作量，不愿配合。导致无法理解真正的需求，也无法改进系统功能。

设计人员能力的低下，设计系统结构时过于定制，系统的可扩展性较弱，给后期维护带来巨大的负担和维护成本的激增。

当出现严重问题时，项目经理没有根据现阶段状况重新评价需求分析结果、开发人工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚的措施，致使问题更严重。

经验总结：

实行双项目经理制度：为开发项目设定两个项目经理岗位，一个负责技术岗位，另一个负责管理岗位。

目前，国内的软件开发企业的项目经理一般都是一名，而且是技术出身的占绝对多数，他们主要擅长的是技术研发，在管理方面先天不足，这不利于项目风险管理和控制。通过增加专门的管理经理岗位，可以弥补技术出身的项目经理的不足，提升软件开发项目的管理水平。而且这样的经验也已得到了国外业界大多企业的认可。

技术岗位：负责技术框架的稳定性和可扩充性、质量的保证、风险的预测以及数据库的设计，模块测试、接口测试、白盒测试等；

对于该项目具体需要多少人员、时间；到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划；

对程序组每周具体的开发目标的进行检测验收，保证开发进度。以及其它需要考虑的问题等，如网络速度，服务器访问量，数据库查询优化，都需要整体考虑。

管理岗位：掌握行业知识、项目的前期调研、需求分析、功能模块架构设计、人员的管理、实施计划的安排执行和跟踪。提交《目标与范围》和需求调研末期的《软件开发需求规格说明书》。

一个项目在前期的工作非常重要，就算是一个错误的话，后面有再强大的开发团队也是白搭。我们还是一个年轻的团队，很需要公司来培养这样的人才，如果是遇到项目，再招外来人员来担当这样的工作，风险是可想而知的。

而且这样的人员肯定是从项目实战中成长起来的，不是有其他软件项目管理经验的人员或者技术开发人员转过来就可以做好的，更不是从书本或者参加某些培训就可以学到的。

5、一味的追求快速开发，时间进度。

每天都加班加点地工作，造成人员流动的扩大以及工作效率的降低。最后无论客户，还是开发人员，都想早点结束项目。

经验总结：

项目中有个不变的金三角法则，即时间、功能和资源。我个人的意见是用我们的实际能力按照一个正常的进度去做，一个项目在功能、时间和资源一定的情况下，没有捷径可以走的，必须一步一个脚印。

6、胡子眉毛一把抓，不分主次。

整个项目没有指定里程碑或规定设计评审期，没有计划什么时间节点完成某一个组织或部门的信息化评审后，再进行下一个阶段的开发计划与实施。摊子铺得太大，软件人员和准备严重不足。

经验总结：

根据企业不同的发展阶段，按照规划逐步深入，这样一方面可以避免投资的盲目性，另外一方面在前期的投入收到效果后，再进行下一阶段投入的同时，员工和企业领导也容易接受，软件人员的压力也会相对减少。

7、开发结果不验收测试，开发技术水平低下。

开发结果没经过测试就给客户上线使用，造成报表的数据很多对不上账目，已经打印出来的报表，过几天再打印数据就不一样了。

由于项目经理没有明确要求技术水平，寄希望于员工自己努力，造成打印的单据上，‘毛重’减去‘皮重’不等于‘净重’的情况。

经验总结：

必须做好充分准备的开发计划，对于该项目具体需要多少人员、时间；到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划。

8、没有项目总结会议，不重视项目质量。

软件从实施开始就产生了很多问题，但遗憾的是从开始到结束没有组织过一个项目总结会议，问题日积月累，最后导致项目失败。

不重视项目质量。在代码和数据库设计中时间投入很少，这些工作本来就是比较抽象的，需要不断的研究和推敲才能设计好的，但是我们为了时间进度，很快就赶出来了。

经验总结：

每日必须召开项目总结会议，随时捕获风险，当日事当日毕。

软件开发初期的时候，就开始猛抓质量，而不是走“先上线、后优化”的项目常规实施方法。若发现质量不合格的地方，就让开发人员重新返工。

9、软件版本发布周期频繁。

几乎每天都需要进行一次版本更新，有时候1天更新几次。更新完成后，客户无法登陆，软件功能无法使用，以前录入的数据看不见等情况。让客户怨声载道，骂声一片。

经验总结：

发布周期为1周1次或2周1次，在版本更新前，必须做好充分的测试，方可交给客户使用。

10、不重视客户体验，缺少抵御风险的奖励机制。

系统不以客户为中心,不能提高业务部门的工作效率,忽视了客户体验；通常10分钟能完成的工作，工作人员操作软件1小时才能完成。

很多时候加班是没有加班费的，并且在实施过程中又没有任何奖励。所以，员工认为是这套系统拖累了他。虽然项目对公司有益，对他个人就没有多少好处了。

经验总结：

公司应该拿出一部分预算，有计划有规模地组织用户进行测试，对操作员给出的体验意见做好详细的记录，并给予充分的重视，对其中有用的软件改进意见给出相应的奖励。做好足够的风险应对计划，抵御这种影响所带来的对系统本身的顺利实施以及实施人员的信心和工作激情的冲击。

11、缺少数据风险意识。

在系统的并行阶段，没有统一的基础数据，如材料编码、单据标准等。数据录入的缺少合理安排，缺少数据风险意识。

用户总是反映报表数据与小票单据帐目对不上，录入的小票数据丢失了。

软件系统是一个高度集成的系统，一个环节的出错将可能导致一系列的错误，所以，对数据的准确性提出了很高的要求。

经验总结：

必须制定《公司基础信息编码》，搭建了整个信息化制度。在项目实施过程中，针对类似的问题也不能光靠人工对账减少错误，而应该采取一定的控制措施，利用系统设置，做好问题的预防措施。比如我们可以建立每日审账制度，在系统中进行设置，每天录入完成的票据都进行核对，核对完成后进行锁账。出台《操作规程》，《操作员奖惩办法》等等，规避风险。

12、不注重细节。

天下大事，必做于细。1%的错误往往会导致100%的失败。力和项目在开发的时候，仅仅是满足于“软件可以使用”或“功能能够实现”的情况，并没有关注到每个设计、每次改动、每天的操作。

经验总结：

在此对之前开发过程中一些可以改进的细节列出，进行总结，在今后的开发中将进行改进。

（1）软件每一个打开的窗体都应该写上标题，而不能是默认的标题。

（2）操作按钮位置、操作顺序必须一目了然。

（3）软件的功能都加上快捷键，使它适应不同操作习惯的用户。

（4）每一个窗体都加上“关闭”快捷键，当用户需要关闭窗体时，只需要点“ESC”键就可以退出，方便用户的操作。

（5）所有输入文本框都必须按照用户的业务要求进行排列，使用户可以更快更好地输入数据。

（6）进入系统以及退出系统时，如果程序执行比较耗时的代码，应该给出个提醒，而不能让用户傻等，最好放到线程中处理，不能让主线程出现假死状态。

（7）用户登陆的窗口，应该自动帮用户记住用户名，用户可以自己确定是否要记住密码。

（8）复杂的查询条件，错误提示之后，原来的输入是否都还保存？如果都没有了，用户要再输入一遍会很烦。

（9）查询错误或无结果，必须有提示。

（10）下拉框中的数据必须有排序。

（11）系统中的各种提示必须要合理，不能有误导用户的情况。

当然，还有许多需要注意的技术和非技术的细节问题，往往我们技术人员觉得不重要的东西偏偏是用户觉得最重要的。我相信，在软件开发的过程中，你只有琢磨你的用户是怎么想的，你才能使我们的软件更加完美，付出得越多，得到的越多。

13、没有结果的结束。

我们几乎听不到有人出来说项目失败了，我们听到的是延期、暂停、取消等等形容词，但是其实，我们其实应该承认，我们有做了一个失败的项目。

经验总结：

我们花了钱，项目失败了，但至少应该买到教训。

项目的成败是变数多多，既有技术的，也有管理的，也有关系的，既有自身的，也有客户的，但是只要我们把我们可以控制的做好了，至少这个项目成功了一半。