软件研发项目管理最早源自于70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因,发现70%的项目是因为管理不善引起的,而并不是因为技术实力不够,进而得出一个结论,即管理是影响软件研发项目全局的因素,而技术只影响局部。这个结论非常重要。到了90年代中期,软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。针对软件项目管理不善的局面,我简要谈谈在软件项目管理中存在的一些问题。
1 客户需不需要全程参与
不少软件企业认为客户的参与主要在三件事情上:协议签订和需求调研、客户需求变更和项目验收签字,其它事情是企业内部项目开发管理的事情,属公司内部行为,无需客户参与。结果,企业经常发现客户严重拖延验收,而且在验收期间客户大量的需求变更,致使项目的进展严重推迟。经常一个预期盈利的项目,最后拖的不堪重负。
我认为这里边的一个重要原因就是客户没有参与项目的全过程。比方,项目初期的启动会议、项目过程中所有干系人的知情制度,每周的工作例会、项目阶段性工作总结等等都需要客户的参与和反馈。否则当企业一年之后提交一个无比庞大和复杂的最终方案时,客户方根本不了解你的方案的进程,由谁敢签字验收呢?客户只能花上几个月来完全“肢解”消化整个方案,最终当然是发现一大堆问题需要改进,企业只能再花上几个月重新修改,如此往而复始,恶性循环。
2 如果需求分析很困难,可不可以先做软件
对需求把握得越准确,软件的修修补补就越少。有些需求在一开始时很难确定,在开发过程中要不断地加以改正。软件修改越早代价越少,修改越晚代价越大,就跟治病一样道理。
一是在项目的需求分析阶段,开发方与客户方在各种的问题的基本轮廓上达成一致即可,具体细节可以在以后填充。软件过程改善是一个持续改善的过程,需要不断地学习,需要知识的积累,特别是当主客观环境发生变化时,需要对过程进行修改,以适应变化了的情况。无论多么细致的需求分析,几乎都难以避免修改。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致,导致后来预算超出或者时间 进度达不到要求。这就要求在项目需求分析阶段,开发方与客户方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。并且,在需求分析结束以后,双方还要建立可以直接联系的渠道,以尽早地对需求变动问题进行沟通。
3 软件项目需求的改变容易实现吗
在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进,往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过,这并不表明“软件项目的需求可以持续不断的改变 ,而且这些改变可很容易地被实现”。实践表明,随着开发进度的推进,实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改需要花费1倍的代价;那么,在系统设计和编码阶段,需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软件版本发布以后,甚至可能要花费60-100倍的代价。由此可见,在项目开展过程中,软件需求的改变应当尽量早地提出。这样才可能花费少,容易被实现。
4 项目的质量提高是否要依赖完善的质量测试制度
不少企业把软件的测试工作定位于提高软件开发项目的质量。我认为质量测试制度只是一个补救措施,是来挑出各种因素造成的缺陷,但不能避免新的缺陷的出现。真正有效的质量管理是建立在