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