软件项目失败经验总结.doc

项目失败经验总结
1、在项目初期没有进行风险的管理探讨,项目远景定义和功能集合的详细定义。
当项目走了很远,出现很多问题的时候,领导总算想起要做一个边界定义,但这个时候已经迟了,项目已经变得不可控制。
经验总结:
由于客户一般对计算机不是很了解,和他们交流是用软件行业的专业俗术语,他们根本就不懂,如果用文档也很难把需求写得那么明白,而且文档很多的话,客户都看烦了,很不直观。
如果让客户一看就可以看出这个就是他们想要的,我认为最好的方式就是做系统原形(界面的功能模拟)。
系统原形应该在需求分析师的指导下完成,当然开发只是界面的功能模拟,没有底层代码的实现。这样做的目的有三个好处,一是客户很直观的看到他们的系统是什么样子的以及怎么操作,二是这些开发的成果是可以二次利用的,三是可以更好的激发客户的需求。
2、不注重用户参与。
没有一开始就让用户参与详细需求的制定的做法,大部分都是靠需求采集人员的猜想,猜想往往和实际有差距,造成系统功能不切合实际,与项目实际需求差距大,运行效果差。
经验总结:
项目的开始和结束用户是需要一直参与进来的,我们每做个可以运行的功能等就需要和用户交流,这样可以避免很多风险也可以尽早发现需求的误解的等等。
需求调研前期的《信息化规划》、《目标与范围》和需求调研末期的《软件开发需求规格说明书》都要跟客户签字确认,这样既能保证我们所理解的需求就是客户所要的,也使得项目末期跟客户验收时有据可依。
3、集团化以后,项目经理没有意识到信息化核心问题是管理变革问题,还跟着原来的思路开发软件。
在组织架构、权限、供应商等方面与力和集团理解不一致,没有分别按组织进行区分。
经验总结:
要根据企业业务需求制订策略,调整软件组织结构, 详细设计软件各组织架构之间的逻辑关系,做好这些最基础的功课,避免信息化项目成为无本之木。
4、软件开发人员、设计人员能力的低下、项目经理的管理能力不足。
低素质开发人员由于没有接触过实际业务,无法跟客户沟通,甚至害怕客户提出需求,总是担心客户的需求会增加自己的工作量,不愿配合。导致无法理解真正的需求,也无法改进系统功能。
设计人员能力的低下,设计系统结构时过于定制,系统的可扩展性较弱,给后期维护带来巨大的负担和维护成本的激增。
当出现严重问题时,项目经理没有根据现阶段状况重新评价需求分析结果、开发人工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚的措施,致使问题更严重。
经验总结:
实行双项目经理制度:为开发项目设定两个项目经理岗位,一个负责技术岗位,另一个负责管理岗位。
目前,国内的软件开发企业的项目经理一般都是一名,而且是技术出身的占绝对多数,他们主要擅长的是技术研发,在管理方面先天不足,这不利于项目风险管理和控制。通过增加专门的管理经理岗位,可以弥补技术出身的项目经理的不足,提升软件开发项目的管理水平。而且这样的经验也已得到了国外业界大多企业的认可。
技术岗位:负责技术框架的稳定性和可扩充性、质量的保证、风险的预测以及数据库的设计,模块测试、接口测试、白盒测试等;
对于该项目具体需要多少人员、时间;到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划;
对程序组每周具体的开发目标的进行检测验收,保证开发进度。以及其它需要考虑的问题等,如网络速度,服务器访问量