软件项目失败经验总结

项目失败经验总结

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

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

经验总结：

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

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

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

2、不注重用户参与.

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

经验总结：

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

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

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

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

经验总结：

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

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

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

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

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

经验总结：

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

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

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

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

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

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

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

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

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

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

经验总结:

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

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

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

经验总结：

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

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

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

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

经验总结：

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

８、没有项目总结会议，不重视项目质量.

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

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

经验总结：

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

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

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

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

经验总结:

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

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

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

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

经验总结:

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

11、缺少数据风险意识。

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

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

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

经验总结:

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

１2、不注重细节。

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

经验总结: