# 项目范围管理 Scope Management

• 做且只做所需的全部工作。

# 产品范围和项目范围

产品范围

某项产品、服务或成果所具有的特性和功能。

项目范围

为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。

# 范围蔓延

• 未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。
  • 来自团队内部原因造成的范围蔓延称为 “镀金”。
  • 来自团队外部原因造成的范围蔓延称为 “范围潜变”。

镀金

项目人员为了 “讨好” 客户而做的不解决实际问题、没有应用价值的项目活动。

范围潜变

是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败

如果已经出现了范围蔓延，一样需要走变更流程。

# 规划 规划范围管理

• 创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。

本过程的作用

在整个项目中对如何管理范围提供指南和方向。

# 输入

# 1️⃣ 项目管理计划

• 规划范围管理需要参照项目管理计划中已批准的子计划。

# 2️⃣ 项目章程

• 依据项目章程中的项目背景信息来规划各个范围管理过程。

# 输出

# 1️⃣ 范围管理计划

• 描述将如何定义、制定、监督、控制和确认项目范围。

主要作用

在整个项目中对如何管理范围提供指南和方向。

注意点：

• 范围管理计划无范围
  都是描述如何去管理范围，没有描述有哪些范围
• 范围管理计划，有助于降低项目范围蔓延的风险
  PMIS 里的子系统之一 —— 工作授权系统，有助于预防 “镀金”

包含的内容：

• 如何制订项目范围说明书；
• 如何根据范围说明书创建 WBS；
• 如何维护和批准 WBS；
• 如何确认和正式验收已完成的项目可交付成果；
• 如何处理项目范围书的变更，该工作与实施整体变更控制过程直接相联；

所有 XX 管理计划中都有的通用内容，如：

• XX 管理会用到哪些工具和方法论；
• XX 管理用什么格式、多少频率进行汇报
• XX 管理中定了哪些岗位职责
• XX 管理预算花多少钱做，花多少时间做

# 2️⃣ 需求管理计划

需求管理

• 贯穿于整个过程，最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。
• 还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理计划

描述在整个项目生命周期内，如何分析、记录和管理需求

> 需求管理计划无需求 

包含的内容

• 如何规划、跟踪、报告各种需求活动；
• 用什么标准对需求进行优先级排序；
• 需求管理需要使用的资源；
• 培训计划；
• 项目干系人参与需求管理的策略。
• 判断项目范围与需求不一致的准则和纠正过程；
• 需求跟踪结构；
• 配置管理活动。

# 规划 收集需求

收集需求 Collect Requirement

为实现项目目标而确定、记录并管理干系人的需要和需求的过程。

本过程的作用

为定义和管理项目范围（包括产品范围）奠定基础。

# 输入

# 1️⃣ 需求管理计划

• 其中有描述 “整个收集需求过程的工作流程” 的规定

# 2️⃣ 项目章程

• 其中有 “产品、服务或成果的高层级描述”

# 3️⃣ 干系人登记册

• 其中有 “干系人对项目的主要需求和期望” 及 “哪些干系人能提供需求方面的信息” 等内容

# 工具与技术

# 1️⃣ 访谈

• 通过与干系人直接交谈来获取信息。
• 典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。

访谈分类

• 结构化：事先准备好一系列问题，有针对地进行；
• 非结构化：只列出一个粗略的想法，根据访谈具体情况发挥。

关键词

• 直接交谈
• 预设和即兴问题
• 深入了解
• 一对一、一对多
• 获取机密和敏感的信息

# 2️⃣ 焦点小组

• 由一位受过训练的主持人引导预先选定的干系人和主题专家 SME 进行互动式讨论。
  • 焦点小组的参加者往往是同职能，同一领域、或有相似背景条件的人
  • 是 “一对多” 的群体访谈，最终是为了获取整个焦点小组更有价值的集体意见。

关键词

• 同职能
• 同一领域
• 有相似背景
• 主题专家 SME
• 主持人
• 互动式讨论

# 3️⃣ 引导式研讨会

• 把主要干系人召集在一起，通过集中讨论来定义产品需求（也需主持人）
• 引导式研讨会能快速定义跨职能需求和协调干系人差异，着重于形成既定目标的一致意见。

关键词

• 跨职能
• 不同部门
• 协调干系人差异
• 联合应用开发 JAD
• 质量功能展开
• 用户故事（敏捷）

常用的引导式研讨会：

联合应用开发 JAD

常用于软件开发行业，强调由用户与项目开发团队一起共同定义需求。

质量功能展开 QFD

常用于制造行业。
三步骤：1、收集客户需要；2、分类和排序；3、设定目标；

用户故事会

常用于敏捷。
三部分构成：干系人角色，干系人想要什么，为什么想要它。

# 4️⃣ 群体创新技术

群体创新技术 Group Creativity Technique

通过一些群体活动来识别需求。

重点在识别

# 头脑风暴

头脑风暴（BrainStorming、BS、智力激励法、自由思考法、集思广益法）

单纯地收集创意，不进行分析及投票或排序。

直接头脑风暴法（头脑风暴法）

尽可能激发创造性，产生尽可能多的设想；

质疑头脑风暴法（反头脑风暴法）

对提出的设想、方案逐一质疑，分析其现实可行性；

• 参与人：不同专业或岗位的 5~10 人；

• 时间：1 小时左右；设主持人 (仅主持)、记录员 (完整记录)

• 头脑风暴的原则：

  • 庭外判决原则（不质疑、不分析、不批判、不反对）
  • 追求数量
  • 各抒己见、自由鸣放
  • 探索取长补短和改进办法；

关键词

• 畅所欲言
• 单纯收集
• 尽可能多
• 尽可能激发

# 名义小组

• 促进头脑风暴，通过投票排列最有用的创意，以便进一步头脑风暴或优先排序。
• 名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法；
• 名义小组技术可以使那些不善言辞的参与者也能充分发表自己的意见。

关键词

• 投票
• 排序

# 德尔菲技术 Delphi Technique

• 一种组织专家就某一主题达成一致意见的一种信息收集技术。

  • 专家回答问卷，并对每一轮给出反馈意见
  • 专家的答复只能交给主持人，以保持匿名状态。

• 德尔菲技术的主要缺点是：过程比较复杂，花费时间较长。

关键词

• 专家
• 匿名
• 多轮
• 趋同
• 消除偏见

# 概念 / 思维导图 Mind Mapping

概念 / 思维导图（心智图、脑图）

从头脑风暴中获得的创意整合成一张图，反映创意之间的共性与差异，激发新创意。

关键词

• 整合
• 反映共性与差异
• 激发新创意
• 图文并重

# 亲和图 Affinity Diagram

亲和图（KJ 法）

从头脑风暴中获得的创意，根据相似性进行分组，以便进一步审查和分析。

关键词

• 分组，归类
• 有助于 WBS 制订

# 多标准决策分析

• 如优先矩阵
• 借助决策矩阵，用系统分析方法建立多种标准，可用于识别关键事项和合适的备选方案，并通过一系列决策对众多备选方案进行评估和排序。

关键词

• 多种标准
• 权重
• 评估
• 排序

# 5️⃣ 群体决策技术

群体决策技术 Group Decision-Making

为达成某种期望结果，对多个未来行动方案进行评估

重点在决策

• 分类：
  1. 一致同意 Unanimity
     所有人都同意。
  2. 大多数原则 Majority
     群体中超过 50% 的人同意。
     把参与决策的小组人数定为奇数，防止平局。
  3. 相对多数原则 Plurality
     群体中相对多数者同意，即便未能超过 50%。
     通常在候选项超过两个时使用。
  4. 独裁 Dictatorship
     由某一个人做出决策。

# 6️⃣ 问卷调查

问卷调查 Questionnaire and Survey

设计一系列书面问题，向众多受访者快速收集信息。

• 缺点：
  • 缺乏灵活性
  • 无法了解细节及更隐性的信息
  • 干系人不重视
  • 真实性差

关键词

• 受众多样化
• 快速完成
• 成本低
• 地理位置分散
• 适合开展统计分析

# 7️⃣ 观察

观察 Observation 、工作跟踪

直接察看个人在各自的环境中如何执行工作和实施流程。

关键词

• 直接察看
• 难以或不愿清晰说明
• 挖掘隐藏的需求

# 8️⃣ 原型法

原型法 Prototype

在实际制造产品之前，先造出实用模型，据此征求对需求的早期反馈。

• 步骤：
  1. 模型创建；
  2. 用户体验；
  3. 反馈收集；
  4. 原型修改

关键词

• 减轻风险
• 渐进明细
• 敏捷
• 故事板

# 9️⃣ 标杆对照

标杆对照 Benchmarking

将实际或计划做法与行业内或行业外的可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。

关键词

• 可比组织、内部、外部、识别最佳实践、形成改进意见、为绩效考核提供依据

# 1️⃣0️⃣ 系统交互图

系统交互图 Context Diagram

• 范围模型的例子。
• 是对产品范围的可视化描绘，显示业务系统以及与人和其他系统之间的交互方式
• 如：DFD、用例图等

关键词

• 拓扑图
• 可视化

# 1️⃣1️⃣ 文件分析

文件分析 Document Analysis

通过分析现有文档，识别与需求相 关的信息，来挖掘需求

关键词：分析现有文档

# 输出

# 1️⃣ 需求文件

• 描述各种单一需求将如何满足与项目相关的业务需求。 清单
  • SRS 就是一种典型的需求文件
• 只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人认可的需求，才能作为基准。

# 2️⃣ 需求跟踪矩阵

• 把产品（项目）需求从其来源连接到能满足需求的可交付成果的一种表格。
  • 提供了在整个项目生命周期中跟踪需求的一种方法；
  • 把每个需求与业务目标或项目目标联系起来。
  • 收集需求时产生的需求文件和需求跟踪矩阵并不代表项目的真实

• 箭头表示需求跟踪能力联系链，能跟踪需求使用的整个周期。
  • 正向跟踪：原始需求 ➡️ 需求文件 ➡️ 产品
  • 反向跟踪（逆向跟踪）：产品 ➡️ 需求文件 ➡️ 原始需求；

# 规划 定义范围

定义范围 Define Scope

制定项目和产品详细描述的过程。

本过程的作用

• 明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外。
• 明确项目、服务或成果的边界。

# 输入

# 1️⃣ 项目章程

• 项目章程中包含对项目和产品特征的高层级描述，它还包括项目审批要求。

# 2️⃣ 需求文件

• 使用需求文件来选择哪些需求将包含在项目中。

# 工具与技术

# 1️⃣ 产品分析

产品分析 Product Analysis

把高层级的产品描述转变为有形的可交付成果。

• 产品分析技术包括
  • 产品分解
  • 系统分析
  • 需求分析
  • 系统工程
  • 价值工程
  • 价值分析等。

# 2️⃣ 备选方案生成

备选方案生成 Alternatives Generation

制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。

• 可生成备选方案的技术有
  • 头脑风暴
  • 横向思维
  • 备选方案分析等

备选方案分析 Alternatives Analysis

对已识别的可选方案进行评估，来决定选择哪种方案或方法来执行项目工作。

横向思维 Lateral Thinking

戴勃诺理论、发散 思维、水平思维，指思维的广阔度，要求人们能全面地观察问题，从事物多样的联系和关系中去认识事物，不一定有顺序，也不能预测。

# 输出

# 1️⃣ 项目范围说明书

项目范围说明书 Project Scope Statement

是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。

• 项目范围说明书也代表项目干系人之间就项目范围所达成的共识。
• 为了便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

# 规划 创建工作分解结构 WBS

创建 WBS

把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

本过程的作用

对所要交付的内容提供一个结构化的视图。

• WBS 组织并定义了项目的总范围
  • 项目范围说明书只定义范围，没有组织范围
• WBS 中的 “工作” 并不是指工作本身，而是指工作所导致的产品或可交付成果。

# 输入

# 1️⃣ 范围管理计划

• 定义了应该如何根据详细项目范围说明书创建 WBS，以及应该如何维护和批准 WBS。

# 2️⃣ 项目范围说明书

• 描述了需要实施的工作及不包含在项目中的工作，同时也列举和描述了会影响项目执行的各种内外部制约或限制条件。

# 3️⃣ 需求文件

• 对理解需要产出什么项目结果，需要做什么来交付项目及其最终产品，都非常重要。

# 工具与技术

# 1️⃣ 分解

分解

把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。

创建 WBS，就是要将整个项目工作分解为工作包

工作包 Work Package

• 位于 WBS 每条分支最底层的可交付成果或项目工作组成部分，可对其成本和持续时间进行估算和管理。
• 工作包大小应在 8~80 小时之间。（P-238）

# WBS 分解的 5 步骤

1. 识别和分析可交付成果及相关工作
   • 范围说明书中规定的可交付成果
2. 确定 WBS 的结构和编排方法
   • 范围管理计划是此步的指南
3. 自上而下逐层细化分解
   • 使用分解工具
4. 为 WBS 组件制定和分配标识编码
   • 编码后可以了解哪些工作包是同一层的
   • 可以了解不同颗粒度的可交付成果的层级关系
5. 核实可交付成果分解的程度是否恰当
   • 核实有没有分解错误
   • 核实完成后能不能完成原始需求
   • 所以需要需求文件来核实

# WBS 分解的 3 个方式

1. 把项目生命周期的各阶段放在第二层
   
2. 把可交付成果放在第二层
   
3. 整合可能由项目团队以外的组织来实施的各种子组件（如外包工作）。作为外包工作的一部分，卖方需编制相应的合同 WBS。

# WBS 分解的 6 个原则

1. 100% 原则（包含原则）

   • 仅包括所有可交付成果
   • 所有下一级的元素之和必须 100% 地代表上一级元素

2. 独立责任原则

   • 每个元素有且只有一个人负责

3. 80 小时原则

   • 工作包大小在 8~80 小时之间

4. 4~6 层指导

   • 不宜过细分解
   • 每一层建议 4~7 个元素
   • 超过 6 层仍不能分完，则考虑项目太大，建议分成子项目再分各自的 WBS

5. 滚动分解原则

   • 渐进明细
   • 并非一成不变
   • 暂时分解不了时，可以先放在一边，成为一个规划包，待未来明确后再分

6. 功能或技术原则

   • 分解时需考虑将不同人员的工作分开

# WBS 分解的 6 个注意

• WBS 必须是面向可交付成果的。
• WBS 应包括项目管理工作，也要包括分包出去的工作。
• WBS 的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
• 不同的可交付成果可以分解到不同的层次
  • 并不是分解得越细越好。
  • 过细的分解，资源使用效率低下、工作实施效率降低等等。
• 远期才完成的可交付成果或组件，当前可能无法分解（规划包），需要滚动式规划。

# WBS 的 3 种表现形式

1. 树型结构（组织结构图式）
   • 优点：层次清晰、直观性和结构性强
   • 缺点：不容易修改，很难表示大的、复杂的项目全貌
2. 表格形式（列表式）
   • 优点：能反映出项目所有的工作要素
   • 缺点：直观性较差
3. 鱼骨图
   • 不常用

# 控制账户

控制账户 Control Account

是一个管理控制点（可以与组织的财务程序链接），在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。

• 每个控制账户可能包括一个或多个工作包（或规划包），但是一个工作包只能属于一个控制账户。
• 控制账户设在较高层次上还是较低层次上，就表明项目管理团队想要对项目实施 “粗管” 还是 “细管”。

# 输出

# 1️⃣ 范围基准

范围基准

经过批准的项目范围说明书、WBS、WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。

项目范围说明书

• 是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。
• 包括
  • 产品范围描述
  • 验收标准
  • 可交付成果
  • 项目的除外责任
  • 制约因素
  • 假设条件

WBS

• 全部工作范围的层级分解。
• 有助于防止范围蔓延
• 包括
  • 工作包
  • 规划包
  • 控制帐户

WBS 词典

• 针对每个 WBS 组件，详细描述可交付成果、活动和进度信息的文件。
• 有助于评价变更的影响
• 包括
  • 账户编码标志号；
  • 工作描述；
  • 负责的组织；
  • 进度里程碑清单；
  • 相关的进度活动；
  • 所需的资源；
  • 成本估算；
  • 质量要求；
  • 验收标准；
  • 技术参考文献；
  • 协议信息；

# 监控 控制范围

控制范围 Control Scope

监督项目和产品的范围状态，管理范围基准变更的过程。

本过程的作用

• 在整个项目期间保持对范围基准的维护。
• 确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。

# 工具与技术

# 1️⃣ 偏差分析

• 一种确定实际绩效与基准的差异程度及原因的技术。
• 可利用项目绩效测量结果评估偏离范围基准的程度。

# 监控 确认范围

确认范围 Validate Scope

老版叫核实范围，“客户” 或 “发起人” 正式验收已完成的项目可交付成果的过程。

本过程的作用

• 使验收过程具有客观性；
• 通过验收每个可交付成果，提高最终产品、服务或成果验收的可能性。

# 输入

# 1️⃣ 项目管理计划

范围管理计划

定义了如何正式验收已完成的可交付成果；

需求管理计划

描述了如何确认项目需求；

范围基准

用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防；

# 2️⃣ 需求文件

• 将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施

# 3️⃣ 需求跟踪矩阵

• 含有与需求相关的信息，包括如何确认需求

# 4️⃣ 核实的可交付成果

• 已完成，并由控制质量过程核实为正确的可交付成果；

# 工具与技术

# 1️⃣ 检查

检查（审查、评审、走查、巡检、测试）

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

• 验收测试就是一种典型的确认范围的技术。
• 检查和审计的区别：检查的是结果，审计的是过程。

# 2️⃣ 验收的可交付成果

• 符合验收标准的可交付成果应该由客户或发起人正式签字批准。
• 应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。

# 3️⃣ 变更请求

• 如果未通过验收，处理步骤：
  1. 记录原因；
  2. 提交变更请求；
  3. 进行缺陷补救。

# 总结