软件项目之范围管理.doc
软件项目之范围管理 1、引言 产品软件的研发 ,特别是针对具体客户定制软件的开发 ,由于其业务的复杂性 ,需求的可变性 ,功能的多样性和事先的不可见性 ,决定了相关项目的成功率和满意度都比较低。那么 ,我们该如何提高软件项目的成功率 ,如何改善项目干系人的满意度呢 ?根据自己多年从事软件项目管理、带领开发团队的经验 ,结合查阅一些 IT 项目管理方面的资料 ,在这里想对这一很多项目经理经常关注而又难以处理的问题进行探讨、分析。希望提供给同行参考 ,哪怕是带来点滴的启示或激发些许的灵感。 首先 ,必须明确什么是项目范围管理。项目范围管理是指对项目包括什么与不包括什么的定义与控制过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。它包括用以保证项目能按要求的范围完成所涉及的所有过程 :确定项目的需求、定义和规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。 其次 ,必须认识到范围管理的重要性。项目的成败受到四个方面的影响 ,即项目组内环境、项目所处的组织环境、客户环境、自然社会环境。从可控角度 ,通常需着重考虑前三个方面。 把前三个方面放在整个项目生命周期进行考察 ,可以得到影响项目成败的因素。美国凯勒管理研究院的项目经理威廉· V·黎巴认为 ,缺少正确的项目定义和范围核实是导致项目失败的主要因素。 软件项目范围管理如此重要 ,怎样才能做好呢 ?难以有效管理的影响因素是什么呢 ? 2、阻碍范围管理的常见因素及分析 阻碍软件项目范围管理的因素很多 ,个人觉得常有以下几种情况 : (1)客户本身无法确定清晰的范围定义。现实项目中经常存在着这种现象 ,就是客户对自己要开发的内容说不清楚。这种情况可以通过以下几种途径解决 :一是向对方介绍 或带领参观已经实现的相关工程 ,消除对方的疑虑 ,清晰对方的思维 ;二是根据双方沟通的情况 ,以快速原型法迅速提供一个版本 ,在此基础上界定范围 ;三是请业务专家、相关领域专家参与 ,按照 RUP 统一规范的软件开发过程 ,了解用户的业务模型 ,分析用例模型 ,设计原型界面 ,形成需求清单、需求分析报告、功能规格说明书等文档。供双方沟通确认。 (2)客户有意拖延明确的范围定义。现在的 IT 市场基本上属于甲方的市场 ,IT 产商在签订合同之前往往非常被动。激烈的市场竞争导致 IT 产商在做前期的商务谈判时无法对客户进行有效的约束。在签订合同 后 ,有的客户就不作清晰的范围定义 ,留下了充足的时间再作观察、思考和收集 ,有时也是出于敷衍了事 ,前面说了需求到了后期自己都会推倒重来。这种情况如果处理不好 ,不但无法做好范围管理 ,还会影响和客户的关系 ,影响到可能存在的第二、第三单的业务。此时需要项目经理组织人员做好攻关 ,软硬兼施 ,让客户负责人真心投入 ,提高对方领导的重视程度 ,加深项目干系人对各阶段性工作的印象 ,扩大范围定义在对方单位的认知度和影响面。 (3)项目经理对做好范围定义的重要性认识不足。在中小型企业里 ,经常技术骨干就是项目经理。而这些技术骨干对技 术实现比较感兴趣 ,对开发的范围和时间进度意识不够强烈。 IT 领域的特殊性造成有些工程师过于追求技术的先进性。另外 IT 人才跳槽是比较普遍的 ,部分 IT 企业对技术骨干存在着某种程度的纵容和缺乏责任教育。对这些技术骨干要经常培养项目范围管理意识、成本意识和风险意识。 (4)项目组对引导客户明确开发需求的经验、能力不足。理由同上 ,技术骨干有时是技术天才 ,同时在人际沟通等方面存在着不足。这种项目组人员构成有些问题 ,但现实中有很多这样的项目组存在。具备技术背景的管理人才在 IT 项目的开发实施方面占据明显优势 ,这大概就是这 种现象存在的有效解释。技术专家培养成管理人才需要一个过程。 在下认为 ,利用客户方熟悉业务的人员和技术力量共同组成项目组 ,让客户专职参与结合有效的协调沟通 ,大家同舟共济 ,对项目的范围管理和总体开展会有很大的益处。我曾经组织过这样的项目 ,出于保证项目的成功和后期的维护考虑 ,客户不但不要任何参与开发的补贴费用 ,还很积极的配合 ,对项目的成功起了很大的推动作用。 3、范围说明书的编制及评审确认 经过尽量仔细地了解客户的需求后 ,就必须整理有关的需求材料 ,出项目范围说明书 ,一般来说 ,项目范围说明书要由项目班子 来编写 ,它是项目班子和任务委托者之间签订协议的基础 ,也是未来项目实施的基础 ,是对项目范围管理的关键一个步骤 ,这个阶段的核心目的是要让客户明确并且接受这些所要开发的内容、表现形式以及运行效果等。虽然随着项目的不断往前推进 ,还可能对范围说明进行修改和细化 ,以反映项目本身和外部环境的变化。但在做确认之前能够细化的还是要尽量细化 ,不要把能够细化的工作移到后面去做。 我建议软件项目的范围说明书起码应该包括以下三个方面的内容 : A、项目的合理性说明。即解释为什么要实施这个项目 ,也就是实施这个项目的目的和意义。它 可以为将来评估各种利弊关系提供评判基础。 B、项目目标。确定了项目目标 ,也就确定了成功实现项目所必须满足的某些数量标准。当项目成功地完成时 ,必须向他人表明 ,项目事先设定的目标均已达到。值得注意的一点是 ,项目目标要尽量量化 ,否则将承担很大风险。 C、项目可交付成果清单。如果列入项目可交付成果清单的事项一旦被完满实现 ,并交付给使用者 --项目的中间用户或最终用户 ,就标志着项目阶段或项目的完成。软件开发项目的可交付成果一般包括能够运行的电脑程序、用户手册、维护手册、安装手册和帮助用户掌握该电脑软件的交互式教 学程序等。显然 ,对于这些可交付成果都必须有明确的要求和说明。 范围说明书因项目类型的不同而不同。规模大、内容复杂的项目 ,其范围说明书也可能会很长。有的范围说明书可以长达几百页 ,特别是要对产品进行详细说明的时候。总之 ,范围说明书应根据实际情况做适当的调整以满足不同的、具体项目的需要。不同项目的范围说明书所描述的重点也不一样。重点是要把弹性的、模糊的内容具体化、清晰化。 项目班子编写出来的范围说明书要经过项目干系人的评审确认 ,特别是要获取用户的同意和支持。但是如何才能得到他人的承认呢 ?我觉得需要向他们表 明项目事先设立的目标均已明确体现并可衡量 ,至少要让他们看到既定的费用、进度、可交付成果和质量均将满足要求。这个过程有时需要几次的反复 ,但无论多么艰难也必须取得通过才可以进行下一步骤。 4、范围管理的实施与控制 在范围说明书通过确认以后 ,接下去的工作就是做好范围管理的实施。范围管理的实施 ,是指控制项目中实际执行的工作 ,而通过活动定义确定的活动应该按照项目计划实施和控制。 可能有人会认为 ,范围说明书一旦通过确认 ,就万事大吉了 ,掌握了约束客户的 "条款 ",可以完全按照范围说明书进行开发 ,不允许有其他的变 更 ,直至项目的成功。根据我的经验判断及行业专家的分析 ,这种想法是很不切实际的。在实际的项目实施中 ,要建立和维护变更控制系统以作为进行范围管理的基础。 变更 ,是指项目干系人常常由于项目环境或者是其它的各种原因、要求而对项目的范围计划进行修改 ,甚至是重新规划 ,而这一类修改或变化就叫做变更。范围的变更管理是对项目中存在的或潜在的变化 ,采用正确的策略和方法成功地处理它。项目范围的变更多数由于客户对原有需求的修改或者追加造成的 ,而且其中可能有部分需求是合理的、迫切需要追加的 ,这时需要我们给予足够的理解并想办法接纳 ,但必须有足够的风险意识。在我负责项目的时候 ,合同 /范围说明书随时都是带在身边 ,经常看看 ,特别是有需求变更的时候 ,好好分析确定是否符合合同的要求 ,是否符合既定的范围以及它可能存在的风险。在客户有较多超出原定范围的开发内容时 ,应该尽量说服客户分期开发 ,把新开发内容作为第二期项目 ,还可以把第二期的项目作大 ,那样可以使第二期的项目有条不紊受控运作 ,又为公司创造了新的商业机会 ,还能较好的推动客户的信息化应用 ,何乐而不为 ? 这里补充说明一点 ,范围变更控制应当全过程地与其他控制过程结合起来 ,如进度控制、成本控制、质 量控制等。 5、范围核实 最后 ,我们来谈谈范围核实。范围核实 ,是项目干系人正式接受项目范围的过程 ,需要审查可交付成果和工作结果 ,以确保它们都已经正确圆满的完成。一般在每个项目生命周期的收尾阶段进行 ,以工作结果、产品文档、工作分解结构、范围说明和项目计划为依据 ,通过检查 ,来正式接受项目范围。一般来说 ,项目完成了既定范围目标 ,满足了项目三要素 :时间进度、成本控制、质量要求 ,就可以认为项目是成功的。但我认为有时候项目的成果被客户接受 ,通过了范围核实 ,也可认为成功 ,因为在 IT 行业里 ,产品研发突破原定时间、成 本要求的情况非常普遍 ,这是篇首提到的软件的复杂性、可变性、多样性和不可见性造成的。 6、结束语 范围管理在软件项目管理中具有及其重要的意义。我个人认为 ,成功的项目运作来自于较好的范围管理。范围管理的好坏直接影响到对项目时间、质量、成本的有效掌控 ,清晰的范围定义可以极大的降低项目实施的风险。