2.项目范围管理

确保项目做且只做所需的全部工作，以成功完成项目。

在项目环境中，“范围”的两种含义：

• 产品范围：某项产品、服务或成果所具有的特征和功能。
• 项目范围：为交付成果而必须完成的工作。项目范围有时也包括产品范围。

2.1 规划范围管理

定义：创建范围管理计划（记录如何定义、确认和控制项目范围及产品范围）的过程。（仅开展一次）

作用：在整个项目期间对如何管理范围提供指南和方向。

2.1.1 输入

1、项目章程：记录项目目的、项目概述、假设条件、制约因素，以及想实现的高层级需求。

2、项目管理计划

• 质量管理计划：组织的质量政策、方法、标准的实施方式会影响项目 / 产品范围的管理方式
• 项目生命周期描述：定义了项目从开始到完成的一系列阶段
• 开发方法：定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法

3、事业环境因素、组织过程资产

2.1.2 工具

1、专家判断

2、数据分析：备选方案分析

3、会议

2.1.3 输出

1、范围管理计划：描述如何定义、制定、监督控制、确认项目范围。
计划规定了下列工作的管理过程：

• 制定项目范围说明书
• 根据详细项目范围说明书创建WBS
• 确定如何审批和维护范围基准
• 正式验收已完成的可交付成果

2、需求管理计划：描述如何分析、记录、管理项目和产品需求。内容包括：

• 如何规划、跟踪报告各种需求活动
• 配置管理活动
• 需求优先级排序
• 测量指标和选用指标的原因
• 记录哪些属性将被纳入跟踪矩阵

2.2 收集需求

定义：确定并记录相关方需要和需求的过程。（仅开展一次）

作用：为定义产品/项目范围奠定基础。

2.2.1 输入

1、项目章程：包含项目描述、项目高层级需求（用来制定详细需求）

2、项目管理计划

• 范围管理计划：包含如何定义和制定项目范围
• 需求管理计划：包含如何收集、分析和记录项目需求
• 相关方参与计划：用于了解相关方的沟通需求和参与程度，便于评估相关方对需求活动的参与程度。

3、项目文件
假设日志：了解可能影响需求的假设条件和制约因素
经验教训登记册：提供有效的需求收集技术，
相关方登记册：了解哪些相关方能够提供需求方面的信息，记录相关方需求

2.2.2 工具

1、专家判断：商业分析、需求获取、需求分析、需求文件、以往类似项目的项目需求、uu 图解技术、引导、冲突管理

2、数据收集

• 头脑风暴
• 访谈
• 焦点小组
• 问卷调查：适用于受众多样化，需要快速完成调查，受访者地理位置分散的情况，适合开展统计分析。
• 标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以识别最佳实践，形成改进意见，并为绩效考核提供依据。

3、数据分析：文件分析，即审核和评估任何相关的文件信息。可能包括：

• 协议；
• 商业计划
• 业务流程或接口文档；
• 业务规则库；
• 现行流程；
• 市场文献；
• 问题日志；
• 政策和程序；
• 法规文件，如法律、准则、法令等；
• 建议邀请书；
• 用例

4、决策

• 投票
• 独裁型决策制定
• 多标准决策分析

5、数据表现

• 亲和图：对大量创意进行分组，进一步分析
• 思维导图：从头脑风暴中获得的创意整合成一张图，反应共性和差异

6、人际关系与团队技能

• 名义小组技术：是一种结构化的头脑风暴形式。通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。分为4步骤：提出问题，众人思考后写下答案；主持人在活动挂图上记录各人的想法；集体讨论达成共识；投票排序，选出胜者。
• 观察和交谈：也称为“工作跟随”，便于挖掘隐藏的需求
• 引导：与主题研讨会结合使用，召集主要相关方一起定义产品需求。适合采用情境包括：
  联合应用设计或开发 (JAD) → 软件行业
  质量功能展开 (QFD) → 制造业
  用户故事（对所需功能的简短文字描述）

7、系统交互图：是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式

8、原型法：指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。支持渐进明细。

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。

2.2.3 输出

1、需求文件：描述各种单一需求将如何满足与项目相关的业务需求。开始可能只有高层级的需求，后期随=有关需求信息的增加逐步细化。
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。
需求分类包括：

• 业务需求
• 相关方需求
• 解决方案需求：分为功能需求和非功能需求（功能需求：描述产品应具备的功能；非功能需求：是对功能需求的补充，产品正常运行所需的环境条件或质量要求）
• 过度和就绪需求：求描述了从“当前状态”过渡到“将来状态”所需的临时能力
• 项目需求：项目需要满足的行动、过程或其他条件
• 质量需求：确认可交付成果条件或标准

2、需求跟踪矩阵：连接产品需求从和满足需求的可交付成果的一种表格。
阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。也为管理产品范围变更提供了框架。

跟踪需求包括：

• 业务需要、机会、目的和目标；
• 项目目标；
• 项目范围和 WBS 可交付成果；
• 产品设计；
• 产品开发；
• 测试策略和测试场景；
• 高层级需求到详细需求

应在需求跟踪矩阵中记录每个需求的相关属性，有助于明确每个需求的关键信息。

2.3 定义范围

定义：是制定项目和产品详细描述的过程

作用：描述产品、服务或成果的边界和验收标准。

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。

2.3.1 输入

1、项目章程：包含对项目的高层级描述、产品特征和审批要求。

2、项目管理计划：范围管理计划。记录了如何定义、确认和控制项目范围。

3、项目文件

• 假设日志：包含可能会影响项目和产品范围的假设条件和制约因素。
• 需求文件
• 经验教训登记册：包含可能影响项目范围的应对策略

4、事业环境因素、组织过程资产

2.3.2 工具

1、专家判断
2、数据分析：备选方案分析
3、决策：多标准决策分析
4、人际关系与团队技能：引导
5、产品分析：用于定义产品和服务。
产品分析技术包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程。

2.3.3 输出

1、项目范围说明书：对项目范围、主要可交付成果、假设条件和制约因素的描述。
包括内容：

• 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征
• 可交付成果
• 验收标准：可交付成果的验收条件
• 项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，便于理相关方的期望、减少范围蔓延。

2、项目文件更新：

• 假设日志
• 需求文件
• 需求跟踪矩阵
• 相关方登记册

2.4 创建WBS（工作分解结构）

定义：把项目可交付成果和项目工作分解成较小、更易于管理的组件的过
程。（仅一次）

作用：为所要交付的内容提供架构

WBS 包含了全部的产品和项目工作，包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。这有时被称为 100% 规则。

工作包：WBS 最低层的组成部分。其中包括计划的工作。
工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。

“工作分解结构”这个词中，“工作”是指作为活动结果的工作产品或可交付成果，而非活动本身。

2.4.1 输入

1、项目管理计划：范围管理计划
2、项目文件：项目范围说明书、需求文件
3、事业环境因素、组织过程资产

2.4.2 工具

1、专家判断
2、分解：把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
把项目工作划分为工作包，然后对其成本和持续时间进行估算和管理。
划分时需要开展的活动：

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

2.4.3 输出

1、范围基准：项目管理计划的组成部分，包括经过批准的范围说明书、WBS 和相应的 WBS 词典。
只有通过正式的变更控制程序才能进行变更，被用作比较的基础。
内容包括：

• 项目范围说明书（经批准）：包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
• WBS
• 工作包：WBS 的最低层级是带有独特标识号的工作包。
• 规划包：一个控制账户可以包含一个或多个规划包，是一种低于控制账户而高于工作包的工作分解结构组件。工作内容已知，但详细的进度活动未知。
• WBS词典：针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。对WBS提供支持。

2、项目文件更新：假设日志、需求文件

2.5 确认范围

定义：正式验收已完成的项目可交付成果的过程。

作用：使验收过程具有客观性；通过确认每个可交付成果，来提高最终成果获得验收的可能性。

由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。

确认范围过程 and 控制质量过程的区别：
前者关注可交付成果的验收， 后者关注可交付成果的正确性及是否满足质量要求。

2.5.1 输入

1、项目管理计划：范围管理计划、需求管理计划、范围基准（用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。）

2、项目文件

• 经验教训登记册
• 质量报告：包括全部质量保证事项、改进建议，和在控制质量过程中发现的情况的概述。
• 需求文件
• 需求跟踪矩阵：含有与需求相关的信息，包括如何确认需求

3、核实的可交付成果：已完成、并被控制质量过程检查为正确的可交付成果

4、 工作绩效数据

2.5.2 工具

1、检查：指开展测量、审查与确认等活动，判断工作和可交付成果是否符合需求和
产品验收标准。

2、决策：投票

2.5.3 输出

1、验收的可交付成果：符合验收标准的可交付成果由客户或发起人正式签字批准，获
得正式文件 → 文件将提交给结束项目或阶段过程

2、工作绩效信息：记录项目进展信息（哪些成果通过验收哪些没有、未通过的原因）

3、变更请求：未通过正式验收的可交付成果，需要记录成果和未通过验收的原因，提出对应的变更请求，开展缺陷补救。

2.6 控制范围

定义：监督项目和产品的范围状态，管理范围基准变更的过程。（整个项目期间开展）

作用：在整个项目期间保持对范围基准的维护

该过程与其他控制过程协调开展。
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。
变更实际发生时，也要采用控制范围过程来管理这些变更。

未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。

2.6.1 输入

1、项目管理计划：

• 范围 / 需求管理计划
• 变更管理计划
• 配置管理计划：定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
• 范围基准：用范围基准与实际结果比较，以决定是否有必要进行变更
• 绩效测量基准：使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否
  有必要进行变更

2、项目文件

• 经验教训登记册：参考早期经验教训，改进范围控制
• 需求文件：用于发现对商定的范围的偏离。
• 需求跟踪矩阵：有助于探查变更 / 偏离范围基准对项目目标的影响，还可以提供受控需求的状态。

3、 工作绩效数据：包括收到的变更请求的数量、接受的变更请求的数量，和已核实、确认和完成的可交付成果的数量。

4、组织过程资产

2.6.2 工具

1、数据分析：

• 偏差分析：将基准与实际结果进行比较，判断偏差是否在临界值内，是否需要变更
• 趋势分析：审查项目绩效随时间的变化情况，判断绩效变好还是变差

2.6.3 输出

1、工作绩效信息
2、变更请求
3、项目管理计划更新

• 范围管理计划
• 范围基准：在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后，需
  对应变更范围基准。
• 进度基准：针对范围、资源或进度估算的变更获得批准后，需对应变更~
• 成本基准：针对范围、资源或成本估算的变更获得批准后，需对应变更~
• 绩效测量基准：针对范围、进度绩效或成本估算的变更获得批准后，需对应变更~

4、项目文件更新

• 经验教训登记册
• 需求文件
• 需求跟踪矩阵