第五章 项目范围管理
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
项目范围管理的核心概念在项目环境中，“范围”这一术语有两种含义：
- 产品范围。某项产品、服务或成果所具有的特征和功能。
- 项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
采用适应型生命周期，在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建 WBS。可交付成果在每次迭代中，都会重复开展两个过程：确认范围和控制范围。
在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。确认范围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。经过批准的项目范围说明书、工作分解结构（WBS）和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。
确认范围是正式验收已完成的项目可交付成果的过程。
从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的相关方正式签字批准。
控制质量过程输出 --> 核实的可交付成果 --> 输入到确认范围，确认范围输出 --> 验收的可交付成果。
5.1 规划范围管理
规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
作用是，在整个项目期间对如何管理范围提供指南和方向。
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
制定范围管理计划和细化项目范围始于对下列信息的分析：项目章程中的信息、项目管理计划中已批准的子计划、组织过程资产中的历史信息和相关事业环境因素。
5.1.1 输入
5.1.1.1 项目章程
项目章程记录项目目的、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求。
5.1.1.2 项目管理计划
项目管理计划组件包括（但不限于）：
- 质量管理计划。在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
- 项目生命周期描述。项目生命周期定义了项目从开始到完成所经历的一系列阶段。
- 开发方法。开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。
5.1.1.3 事业环境因素
5.1.1.4 组织过程资产
5.1.2 工具与技术
5.1.2.1 专家判断
5.1.2.2 数据分析
适用于本过程的数据分析技术包括（但不限于）备选方案分析。本技术用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。
5.1.2.3 会议
项目团队可以参加项目会议来制定范围管理计划。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、范围管理各过程的负责人，以及其他必要人员。
5.1.3 输出
5.1.3.1 范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
范围管理计划要对将用于下列工作的管理过程做出规定：
- 制定项目范围说明书；
- 根据详细项目范围说明书创建 WBS；
- 确定如何审批和维护范围基准；
- 正式验收已完成的项目可交付成果。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
5.1.3.2 需求管理计划
需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。
需求管理计划的主要内容包括（但不限于）：
- 如何规划、跟踪和报告各种需求活动；
- 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
- 需求优先级排序过程；
- 测量指标及使用这些指标的理由；
- 反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
5.2 收集需求
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。
作用是，为定义产品范围和项目范围奠定基础。
5.2.1 输入
5.2.1.1 项目章程
5.2.1.2 项目管理计划
5.2.1.3 项目文件
5.2.1.4 商业文件
5.2.1.5 协议
5.2.1.6 事业环境因素
5.2.1.7 组织过程资产
5.2.2 工具与技术
5.2.2.1 专家判断
5.2.2.2 数据收集
- 头脑风暴。
- 访谈。访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。
- 焦点小组。焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。
- 问卷调查。问卷调查方法非常适用于：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
- 标杆对照。标杆对照将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
5.2.2.3 数据分析
可用于本过程的数据分析技术包括（但不限于）文件分析。
5.2.2.4 决策
适用于收集需求过程的决策技术包括（但不限于）：
- 投票。投票是一种为达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。本技术用于生成、归类和排序产品需求。投票技术示例包括：
- 一致同意。每个人都同意某个行动方案。
- 大多数同意。获得群体中超过 50% 人员的支持，就能做出决策。把参与决策的小组人数定为奇数，可防止因平局而无法达成决策。
- 相对多数同意。根据群体中相对多数人的意见做出决策，即便未能获得大多数人的支持。
通常在候选项超过两个时使用。
- 独裁型决策制定。采用这种方法，将由一个人负责为整个集体制定决策。
- 多标准决策分析。该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
5.2.2.5 数据表现
可用于本过程的数据表现技术包括（但不限于）：
- 亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。
- 思维导图。把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。
5.2.2.6 人际关系与团队技能
可用于本过程的人际关系与团队技能包括（但不限于）：
- 名义小组技术。名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式。
- 观察和交谈。
- 引导。
5.2.2.7 系统交互图
系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
5.2.2.8 原型法
原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。
5.2.3 输出
5.2.3.1 需求文件
需求文件描述各种单一需求将如何满足与项目相关的业务需求。
一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。
需求的类别包括：
- 业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
- 相关方需求。相关方或相关方群体的需要。
- 解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
- 功能需求。功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。
- 非功能需求。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
- 过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
- 项目需求。项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
- 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
5.2.3.2 需求跟踪矩阵
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
跟踪需求包括（但不限于）：
- 业务需要、机会、目的和目标；
- 项目目标；
- 项目范围和 WBS 可交付成果；
- 产品设计；
- 产品开发；
- 测试策略和测试场景；
- 高层级需求到详细需求。
需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。
5.3 定义范围
定义范围是制定项目和产品详细描述的过程。
作用是，描述产品、服务或成果的边界和验收标准。
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要。
5.3.1 输入
5.3.1.1 项目章程
5.3.1.2 项目管理计划
5.3.1.3 项目文件
5.3.1.4 事业环境因素
5.3.1.5 组织过程资产
5.3.2 工具与技术
5.3.2.1 专家判断
5.3.2.2 数据分析
5.3.2.3 决策
5.3.2.4 人际关系与团队技能
5.3.2.5 产品分析
产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。
产品分析技术包括（但不限于）：
- 产品分解；
- 需求分析；
- 系统分析；
- 系统工程；
- 价值分析；
- 价值工程。
5.3.3 输出
5.3.3.1 项目范围说明书
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。
为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。
详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：
- 产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
- 可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
- 验收标准。可交付成果通过验收前必须满足的一系列条件。
- 项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。
项目章程与项目范围说明书的内容
5.3.3.2 项目文件更新
可在本过程更新的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
- 需求文件。见 5.2.3.1 节。可以通过增加或修改需求而更新需求文件。
- 需求跟踪矩阵。见 5.2.3.2 节。应该随同需求文件的更新而更新需求跟踪矩阵。
- 相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。
5.4 创建 WBS
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
作用是，为所要交付的内容提供架构。
WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
WBS 最低层的组成部分称为工作包，其中包括计划的工作。
5.4.1 输入
5.4.1.1 项目管理计划
5.4.1.2 项目文件
5.4.1.3 事业环境因素
5.4.1.4 组织过程资产
5.4.2 工具与技术
5.4.2.1 专家判断
5.4.2.2 分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；
工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。
要把整个项目工作分解为工作包，通常需要开展以下活动：
- 识别和分析可交付成果及相关工作；
- 确定 WBS 的结构和编排方法；
- 自上而下逐层细化分解；
- 为 WBS 组成部分制定和分配标识编码；
- 核实可交付成果分解的程度是否恰当。
如果采用敏捷方法，可以将长篇故事分解成用户故事。
WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。
WBS 包含了全部的产品和项目工作，包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。这有时被称为 100% 规则。
5.4.3 输出
5.4.3.1 范围基准
范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
范围基准是项目管理计划的组成部分，包括：
- 项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述（见 5.3.3.1 节）。
- WBS。WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
- 工作包。WBS 的最低层级是带有独特标识号的工作包。
- 规划包。一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
- WBS 词典。WBS 词典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持，其中大部分信息由其他过程创建，然后在后期添加到词典中。
WBS 词典中的内容可能包括（但不限于）：- 账户编码标识；
- 工作描述；
- 假设条件和制约因素；
- 负责的组织；
- 进度里程碑；
- 相关的进度活动；
- 所需资源；
- 成本估算；
- 质量要求；
- 验收标准；
- 技术参考文献；
- 协议信息。
5.4.3.2 项目文件更新
可在本过程更新的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
- 需求文件。见 5.2.3.1 节。可以更新需求文件，以反映在本过程提出并已被批准的变更。
5.5 确认范围
确认范围是正式验收已完成的项目可交付成果的过程。
作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。
对可交付成果的确认和最终验收，需要依据：从项目范围管理知识领域的各规划过程获得的输出（如需求文件或范围基准），以及从其他知识领域的各执行过程获得的工作绩效数据。
- 控制质量过程关注可交付成果的正确性及是否满足质量要求。
- 确认范围过程关注可交付成果的验收。
控制质量过程通常先于确认范围过程，但二者也可同时进行。
5.5.1 输入
5.5.1.1 项目管理计划
项目管理计划组件包括（但不限于）：
- 范围管理计划。见 5.1.3.1 节。项目管理计划定义了如何正式验收已经完成的可交付成果。
- 需求管理计划。见 5.1.3.2 节。需求管理计划描述了如何确认项目需求。
- 范围基准。见 5.4.3.1 节。用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
5.5.1.2 项目文件
可作为本过程输入的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
- 质量报告。 见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
- 需求文件。见 5.2.3.1 节。将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。**
5.5.1.3 核实的可交付成果
核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
5.5.1.4 工作绩效数据
工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
5.5.2 工具与技术
5.5.2.1 检查
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
检查有时也被称为审查、产品审查和巡检等。
5.5.2.2 决策
可用于本过程的决策技术包括（但不限于）投票。当由项目团队和其他相关方进行验收时，使用投票来形成结论。
5.5.3 输出
5.5.3.1 验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
5.5.3.2 工作绩效信息
工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来（见 10.3.3.1 节）并传递给相关方。
5.5.3.3 变更请求
对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。
可能需要针对这些可交付成果提出变更请求，开展缺陷补救。
5.5.3.4 项目文件更新
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法。
- 需求文件。见 5.2.3.1 节。记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
- 需求跟踪矩阵。见 5.2.3.2 节。根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
5.6 控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程（见 4.6 节）进行处理。
在变更实际发生时，也要采用控制范围过程来管理这些变更。
未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。
5.6.1 输入
5.6.1.1 项目管理计划
5.6.1.2 项目文件
5.6.1.3 工作绩效数据
工作绩效数据可能包括收到的变更请求的数量、接受的变更请求的数量，或者核实、确认和完成的可交付成果的数量。
5.6.1.4 组织过程资产
5.6.2 工具与技术
5.6.2.1 数据分析
可用于控制范围过程的数据分析技术包括（但不限于）：
- 偏差分析。见 4.5.2.2 节。偏差分析用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
- 趋势分析。见 4.5.2.2 节。趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
确定偏离范围基准（见 5.4.3.1 节）的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
5.6.3 输出
5.6.3.1 工作绩效信息
本过程产生的工作绩效信息是有关项目和产品范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。
5.6.3.2 变更请求
分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程（见 4.6 节）的审查和处理。