软件项目总结中的经验总结

经验总结"/>

软件项目总结中的经验总结

篇一：软件项目失败经验总结

项目失败经验总结

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

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

经验总结：

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

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

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

2、不注重用户参与。

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

经验总结：

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

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

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

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

经验总结：

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

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

低素质开发人员由于没有接触过实际业务，无法跟客户沟通，甚至害怕客户提出需求，总是担心客户

的需求会增加自己的工作量，不愿配合。导致无法理解真正的需求，也无法改进系统功能。

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

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

经验总结：

实行双项目经理制度：为开发项目设定两个项目经理岗位，一个负责技术岗位，另一个负责管理岗位。 目前，国内的软件开发企业的项目经理一般都是一名，而且是技术出身的占绝对多数，他们主要擅长的是技术研发，在管理方面先天不足，这不利于项目风险管理和控制。通过增加专门的管理经理岗位