范围管理概述

简单地理解，项目范围管理〈Scope Management）就是要做范围内的事，而且只做范围内的事，既不少做也不多做。具体来说，项目范围管理需要做以下三个方面的工作:
(1)明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作是不包括在项目范围之内的。
(2)对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说“不”，杜绝做额外工作。
(3)防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。

产品范围与项目范围

在项目中，实际上存在两个相互关联的范围，分别是产品范围与项目范围。
产品范围是指产品或者服务所应该包含的功能，项目范围是指为了能够交付产品,项目所必须做的工作。显然，产品范围是项目范围的基础，产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础，两种范围在应用上有区别。
项目的范围基准(Scope Baseline）是经过批准的项目范围说明书、WBS 和 WBS词典。判断项目范围是否完成，要以范围基准来衡量。而产品范围是否完成，则根据产品是否满足了产品描述来判断，例如，软件产品是否完成，需要根据软件需求规格说明书的要求来判断。

项目范围管理主要是通过规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围六个过程来实现的。

项目范围管理的各过程如表5-1所示。

规划范围管理

规划范围管理（Plan Scope Management）是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。
规划范围管理过程的输入有项目管理计划、项目章程、事业环境因素和组织过程资产，使用的工具与技术有专家判断和会议，输出有范围管理计划和需求管理计划。

范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，要对将用于下列工作的管理过程做出规定。
如何制订项目范围说明书。
如何根据范围说明书创建WBS。如何维护和批准WBS.
如何确认和正式验收已完成的项目可交付成果。
如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。

项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。

需求管理计划

需求是软件项目成功的核心之所在，它为其他许多技术和管理活动奠定了基础。在信息系统集成项目中，需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围,始终保持产品与需求的一致性。
需求管理计划(Requirements Management Plan）描述在整个项目生命周期内如何分析、记录和管理需求。生命周期各阶段间的关系对如何管理需求有很大影响。

需求管理计划主要包括以下内容。

(1)如何规划、跟踪和汇报各种需求活动。
(2)需求管理需要使用的资源。
(3)培训计划
(4)项目干系人参与需求管理的策略。
(5)判断项目范围与需求不一致的准则和纠正规程。
(6)需求跟踪结构
(7)配置管理活动

收集需求

收集需求(Collect Requirement）是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围（包括产品范围）奠定基础。

需求分类

(1)业务需求:整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
(2)干系人需求:是指干系人或干系人群体的需要。
(3)解决方案需求:是为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求。功能需求是关于产品能开展的行为，例如，流程、数据，以及与产品的互动等。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量，例如，可靠性、安全性、性能、服务水平等。
(4)过渡需求:从当前状态过渡到将来状态所需的临时能力，例如，数据转换和培训需求。
(5)项目需求:项目需要满足的行动、过程或其他条件。
(6)质量需求:用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。

收集需求的工具与技术

收集需求的工具与技术主要有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。

焦点小组

焦点小组将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服各或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈.
焦点小组是一种群体访谈而非一对一访谈，可以有6~10个被访谈者参加。

引导式研讨会

通过邀请主要的跨职能干系人一起参加会议，引导式研讨会(Facilitated Workshop)对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一个好处是，能够比单项会议更快地发现和解决问题

群体创新技术

群体创新技术(Group Creativity Technique〉是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。

头脑风暴法

头脑风暴（BrainStorming，BS）法又称为智力激励法、自由思考法或集思广益法，是用来产生和收集对项目需求与产品需求的多种创意的一种技术。

名义小组技术

名义小组技术(Nominal Group Technique）通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法

德尔菲技术

德尔菲技术(Delphi Technique）是一种组织专家就某一主题达成一致意见的一种信息收集技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。

概念/思维导图

思维导图(Mind Mapping）又称为心智图，是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
思维导图运用图文并重的技巧，将各级主题的关系用相互隶属与相关的层级图表现出来，将主题关键词与图像、颜色等建立记忆链接，思维导图充分运用左右脑的机能，利用记忆、阅读、思维的规律，协助人们在科学与艺术、逻辑与想象之间平衡发展。

亲和图

亲和图（Affinity Diagram）又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。

多标准决策分析

多标准决策分析(Multi-Criteria Decision Analysis）是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。

群体决策技术

群体决策(Group Decision-Making）就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。达成群体决策的方法很多，例如:
一致同意(Unanimity ) 。所有人都同意某个行动方案。
大多数原则（Majority）。获得群体中50%以上的人的支持，就能做出决策。参与决策的人数定为奇数,防止因平局而无法达成决策。
相对多数原则(Plurality)。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。通常在候选项超过两个时使用该原则，例如，某个软件构件的功能有3种实现方案（标记为A、B、C)，在群体决策时，同意A方案的人有40%，同意B方案的人有35%，同意C方案的人有25%，则最终确定采用A方案。
独裁(Dictatorship)。由某一个人（例如，项目经理〉为群体做出决策。

问卷调查

问卷调查(Questionnaire and Survey)是指通过设计书面问题，向为数众多的受访者快速收集信息。如果受众众多、需要快速完成调查，受访者地理位置分散，并想要使用统计分析法,就适宜采用问卷和/或调查方法。

标杆对照

标杆对照（Benchmarking）将实际或计划的做法与其他类似组织的做法（例如，流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。

系统交互图

系统交互图（Context Diagram）是范围模型的一个例子，它是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。例如，软件需求分析中的 DFD、用例图都可以看作是系统交互图。

文件分析

文件分析（Document Analysis）就是通过分析现有文档，识别与需求相关的信息来挖掘需求。

需求跟踪的内容

每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，
正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果)中找到对应点;
反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型,如图5-1所示。

需求跟踪矩阵

表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪(能力)矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。

定义范围

定义范围(Define Scope）是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。由于在收集需求的过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件中选取最终的项目需要，然后制定出关于项目及其产品、服务或成果的详细描述。

范围说明书的内容

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。项目范围说明书包括如下内容。
(1)产品范围描述。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征。
(2)验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
(3)可交付成果。可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，例如，项目管理报告和文件。对可交付成果的描述可详可简。
(4)项目的除外责任。通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望。
(5)制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素，例如，客户或执行组织事先确定的预算、强制性日期或强制性进度里程碑。如果项目是根据协议实施的，那么协议条款通常也是制约因素。
(6)假设条件。假设条件是指在制订计划时，不需验证即可视为正确、真实或确定的因素。在项目范围说明书中，需要列出并说明与项目范围有关的具体项目假设条件，以及万一不成立而可能造成的后果。在项目规划过程中，项目团队应该经常识别、记录并验证假设条件。

范围说明书的作用

项目范围说明书的主要作用如下。
(1)确定范围。项目范围说明书描述了可交付成果和所要完成的工作。
(2)沟通基础。项目范围说明书表明项目干系人之间就项目范围所达成的共识。为了便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
(3)规划和控制依据。项目范围说明书使项目团队能开展更详细的规划，并可在执行过程中指导项目团队的工作。
(4)变更基础。项目范围说明书为评价变更请求或额外工作是否超出项目边界提供基准。
(5)规划基础。在项目范围说明书的基础上，其他计划也将被编制出来，它同时还是滚动式规划的基础。

创建工作分解结构(WBS)

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。

工作包

工作包(Work Package)是位于WBS每条分支最底层的可交付成果或项目工作组成部分。由于工作包应便于完整地分派给不同的人或组织单元，所以要求明确各工作单元直接的界面。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。
作为一种经验法则，8/80规则(80小时原则）建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时。

控制账户

控制账户(Control Account）是一种管理控制点。在该控制点上，将范围、预算(资源计划)、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。
控制账户是 WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。

规划包

规划包（Planning Package）是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。也就是说，规划包是在控制账户之下、工作包之上的WBS要素。项目管理团队虽然已经知道它是一个什么样的成果，但是尚不清楚究竞要做哪些具体的活动才能将该成果开发出来。由于当前无法分解到编制项目管理计划所需要的详细程度,规划包是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

WBS词典

在制作WBS的过程中，要给WBS的每个部分赋予一个账户编码(Code of Account)标志符，它们是成本、进度和资源使用信息汇总的层次结构。需要生成一些配套的文件,这些文件需要和WBS配套使用，称为WBS词典。WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。对于WBS的每一组成部分，WBS词典可能包括账户编妈标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
在控制范围变更的过程中，如果要评价变更的影响，由于WBS词典比WBS包含的信息更多，因此作用更大。

分解工作包

1.识别和分析可交付成果及相关工作。
2.确定WBS的结构和编排方法。
3.自上而下逐层细化分解。
4.为WBS组件制定和分配标识编码。
5.核实可交付成果分解的程度是恰当的。

WBS分解注意事项

(1)WBS必须是面向可交付成果的。
(2)WBS必须符合项目的范围。100%原则(包含原则)认为，在 WBS中,所有下一级的元素之和必须100%的代表上一级元素。
(3)WBS的底层应该支持计划和控制。
(4)WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
(5)WBS的指导。作为指导而不是原则，WBS应控制在4~6层。一个工作单元只能从属于某个上层单元，避免交叉从属。
(6)WBS应包括项目管理工作（因为管理是项目具体工作的一部分)，也要包括分包出去的工作。
(7)WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与
(8)WBS并非是一成不变的。滚动分解原则。

确认范围的一般步骤如下。

(1)确定需要进行范围确认的时间。
(2)识别范围确认需要哪些投入。
(3)确定范围正式被接受的标准和要素。
(4)确定范围确认会议的组织步郢。
(5)组织范围确认会议。
通常情况下，在确认范围前，项目团队需要先进行质量控制工作,

确认范围与核实产品

核实产品是针对产品是否完成，在项目（或阶段〉结束时由发起人或客户来验证，强调产品是否完整;
确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。

确认范围与质量控制

确认范围主要强调可交付成果获得客户或发起人的接受:
质量控制强调可交付成果的正确性,并符合为其制定的具体质量要求(质量标准).

质量控制一般在确认范围前进行，也可同时进行;
确认范围一般在阶段末尾进行,而质量控制并不一定在阶段未进行。

质量控制属内部检查，由执行组织的相应质量部门实施;
确认范围则是由外部干系人(客户或发起人）对项目可交付成果进行检查验收。

确认范围与项目收尾

虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段〉所要做的流程性工作。
确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。

控制范围

控制范围(Control Scope）是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。

范围变更控制的工作

(1)影响导致范围变更的因素,并尽量使这些因素向有利的方面发展。
(2)判断范围变更是否已经发生。
(3)范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。