浅谈项目管理在软件开发项目的应用.pdf

浅谈项目管理在软件开发项目的应用 项目管理是第二次世界大战后期发展起来的重大新管理技术之一。虽然在此之前项目管 理已广泛应用于许多事业领域，如工程建设项目和新产品开发，但直到第二次世界大战期间 以及战后，它作为管理技术复杂的活动，或需要多学科协作的活动的一种特殊工具的价值， 才完全被认识，其结果使项目管理成为一种相对来说较新的管理方法，得到迅速发展和不断 完善，现在，项目管理已经被公认为是一种有生命力并能实现复杂的企业目标的良好方法。 　　随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发 方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中， 对开发实行有效的管理。从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、 进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际 上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力 转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟， 企业越能够稳定发展（即减小开发风险）。 　　本文将根据自己在软件开发项目中的实际经验来浅述在软件项目开发过程中项目经理 如何使用项目管理的理论来进行软件项目的管理。 一、 需求的确定 　　需求的确定也就是项目范围的确定，这是项目管理中首先要注意的，是软件开发项目管 理的重中之重，只有分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工 率越低，风险也越小，成本越容易得到控制。而需求分析没有做好就急忙上马进行开发的项 目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段，一些潜伏期比较长但破 坏作用比较大的问题就会显现出来，造成返工，延长测试时间。 　　本人原来负责过一个企业的 B2B 电子商务系统的项目，客户方对项目进度要求特别快， 我们公司领导因为和客户方的领导关系比较好，所以就要求我们必须满足他们的时间要求。 所以在做需求分析是，客户方就要求我们做需求的时间不要太长，还说具体细节可以在以后 填充。就这样，经过简单的需求分析后，该项目就正式开始启动了，我们项目团队也就抓紧 时间开始进行项目的开发了。 但结果证明我们是错误的，等我们按照项目开发计划的时间把 DEMO 版交给客户方的时候， 客户方却对结果不满意，他们认为他们想实现的一些功能我们没有替他们实现，而实际上他 们说的功能我们在做需求分析的时候他们并没有提供给我们；另外，客户方对系统的界面、 操作方法还有一些其他功能也不满意，认为界面不符合他们企业的风格、操作过程也和他们 现有的一些操作流程不太吻合等。所有的这些客户不满意产生的原因就是我们需求没有做够。 　　后来，我们只能又根据客户提出的新的需求对系统进行调整，就这样反复过多次，最终 系统才能满足用户的需求。但就这个项目本身而言已经是失败了，因为项目的进度拖后、项 目的成本也超支了。 　　所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。 经验告诉我，需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分 析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求 模型。所有的文档将会提交给项目经理进行复审并签字，不合格的打回重做。反馈表随之将 提交给客户，第二遍第三遍等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格， 目的只有一个，明确需求。当项目经理最终合并了所有文档并确立需求之后，最终生成的需 求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项 目变更或者碰到重大问题时和客户扯皮的重要依据。 二、 需求变更的管理 　　需求变更的管理属于项目管理中的过程控制内容，对任何项目，变更无可避免，无从逃 避，只能去积极应对，这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项 目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。而需求没做 好，基准文件里的范围含糊不清，被客户抓住空子搞你一下是非常头疼的事情，往往要付出 无谓的牺牲。 　　一般的，需求做好了，文档清晰又有客户签字，那么后期客户提出的变更就超出了合同 的范围，需要另外收费。这个时候千万不能手软，并非要刻意赚取客户的钱财，而是不能养 成客户经常变更的习惯，否则后患无穷，维护的成本会让项目经理吃不消。在客户提出变更 请求时，要建立变更申请登记表和变更申请表，并让客户签字。当然，有时候一些不是非常 关键的模块项目经理也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领