范围决定进度，进度决定成本
在范围、进度、成本这个铁三角里，范围是必须要先明确的，特别是预测型生命周期。

# 核心概念

• 项目范围管理包括做且只做所需的全部工作。 all & only

• “范围” 包括两重含义： “范围” = 产品范围 + 项目范围。

  产品范围

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

  项目范围

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

• 用项目管理计划衡量项目范围的完成情况，用产品需求衡量产品范围的完成情况。

• 预测型和适应型生命周期之范围管理的对比

# 项目范围管理的 “发展趋势和新兴实践”

1. 讨论 “需求” 和 “范围” 的区别

   需求：需求是一种需要
   范围：范围是满足 “需求” 必须交付的可交付成果和相关工作
   需求决定了范围。

• 需求一直是项目管理中的重点。
  组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。
• 商业分析活动可在项目启动和项目经理任命之前就开始。
  要注重与商业分析专业人士的合作。
• 需求管理过程始于需要评估，结束于需求关闭。
• 项目经理与商业分析师（BA）之间是伙伴式合作关系。
  • 商业分析师负责需求管理相关的活动
  • 项目经理负责确保这些活动
    • 在项目管理计划有所安排，
    • 并且在预算内按时完成，
    • 同时能够创造价值

# 在敏捷和适应型环境中需要考虑的因素

• 特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。

• 有目的地构建和审查原型，并通过多次发布版本来明确需求。把需求列入未完项。

# 规划 规划范围管理

规划范围管理

为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程

• 本过程的作用：
  • 在整个项目中对如何管理范围提供指南和方向。

# 输入

# 1️⃣ 项目章程

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

# 工具和技术

理解为主

# 输出

# 1️⃣ 范围管理计划

范围管理计划 如何管范围

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

• 注意点：
  1. 范围管理计划无范围； 范围在范围基准中
  2. 范围管理计划可以是正式或非正式的，非常详细或高度概括的。

# 2️⃣ 需求管理计划

需求管理计划（商业分析计划） 如何管需求

描述将如何分析、记录和管理项目和产品需求。

• 注意点：
  1. 需求管理计划无需求； 需求在需求文件中
  2. 内容包括配置管理活动、需求优先级排序过程、测量指标等。

# 规划 收集需求

收集需求

为实现目标而确定、记录并管理相关方的需要和需求的过程。

• 本过程的作用：
  • 为定义产品范围和项目范围奠定基础。

项目章程里面的需求是高层级的需求，是一种很宏观的或者很概括的需求，不够详细，不能指导将来的实现。

需求

根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

• 需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。

# 输入

# 1️⃣ 项目文件

相关方登记册

用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

# 2️⃣ 商业文件

• 会影响收集需求过程的商业文件是商业论证
• 它描述了为满足业务需要而应该达到的必要、期望及可选标准。

# 3️⃣ 协议

• 协议会包含项目和产品需求。

# 工具与技术

# 输出

# 1️⃣ 需求文件

需求文件

描述各种单一需求将如何满足与项目相关的业务需求。

• 只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。

• 需求的分类：

  • 业务需求：整个组织的高层级需要
  • 解决方案需求：为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。分功能需求和非功能需求。
  • 项目需求：项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素。
  • 相关方需求：相关方或相关方群体的需要
  • 过渡和就绪需求：从 “当前状态” 过渡到 “将来状态” 所需的临时能力。 例如：数据转换和培训需求
  • 质量需求：用于确认可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认

# 2️⃣ 需求跟踪矩阵

需求跟踪矩阵 需求与成果对应

把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

• 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。
• 提供了在整个项目生命周期中跟踪需求的一种方法（正向跟踪和逆向跟踪）
• 有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
• 收集需求时产生的需求文件和需求跟踪矩阵并不代表项目的真实范围
• 需要进一步明确哪些包含在项目范围内，哪些排除在项目范围外。（定义范围）

# 规划 定义范围

定义范围

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

• 本过程的作用

  • 描述产品、服务或成果的边界和验收标准。
  • 从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。（P151）

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

• 还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。

• 需要多次反复开展定义范围过程（涉及多个迭代）：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。

# 输入

# 1️⃣ 项目章程

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

# 2️⃣ 项目文件

需求文件

识别了应纳入范围的需求。

# 工具与技术

# 1️⃣ 数据分析

可用于本过程的数据分析技术包括：备选方案分析。

# 2️⃣ 决策

可用于本过程的决策技术包括：多标准决策分析。

# 3️⃣ 人际关系与团队技能

在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。

# 4️⃣ 产品分析

产品分析

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

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

# 输出

# 1️⃣ 项目范围说明书

项目范围说明书

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

• 项目范围说明书详细描述了项目的可交付成果，还代表项目相关方之间就项目范围所达成的共识。

• 为了便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

• 详细的项目范围说明书包括以下内容：

补充示例：
高层级需求、需求、范围
用需求跟踪矩阵，连接需求文件与范围说明书

每一个可交付成果都有各自的验收标准
对于整个项目来说，一般不说验收标准，而说项目的成功标准或者退出标准。

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

创建 WBS（工作分解结构）

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

• 本过程的作用

  • 对所要交付的内容提供架构。

• WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作 项目范围说明书只定义范围，没有组织范围

• WBS 最低层的组成部分称为工作包，其中包括计划的工作。

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

# 输入

# 1️⃣ 项目范围说明书

描述了需要实施的工作及不包含在项目中的工作。

# 2️⃣ 需求文件

需求文件详细描述了各种单一需求如何满足项目的业务需要。

# 工具和技术

# 1️⃣ 分解

分解

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

工作包

WBS 最低层的组件，可对其成本和持续时间进行估算和管理。其本质也是可交付成果

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

• 分解的五个步骤

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

• WBS 的结构可以采用如下形式

  • 把项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。
  • 把主要可交付成果作为分解的第二层
  • 纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）

  作为外包工作的一部分，卖方须制定相应的合同WBS。

• 创建 WBS 的四个注意

  1. 如果采用敏捷方法，可以将长篇故事分解成用户故事。
  2. 不同的可交付成果可以分解到不同的层次。
  3. 并不是分解得越细越好。
     过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。
  4. 远期才完成的可交付成果或组件，当前可能无法分解成工作包，此时称为 规划包 ，需要滚动式规划。

• 创建 WBS 的四个主要原则

  1. 必须 100% 原则：无遗漏无多余；
  2. 必须 责任唯一：责任明确原则，有明确责任人；
  3. 建议 80 小时原则：工作包 80 小时，即不超过两周，否则颗粒度过大
  4. 建议 4~6 层原则：根据项目具体情况来，不宜过细分解。

# 输出

# 1️⃣ 范围基准

范围基准

• 经过批准的范围说明书、WBS 和相应的 WBS 词典。
• 范围基准数据是项目管理计划的一部分，故也是由主要相关方批准

哪儿找可交付成果和验收标准：首选范围说明书，次选 WBS 词典，再次选范围基准。

WBS 词典

针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。

控制账户 CA

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

每个控制账户可能包括一个或多个工作包（或规划包），但是一个工作包只能属于一个控制账户。

绩效测量基准 PMB

由范围基准、进度基准、成本基准共同构成

# 监控 确认范围 Validate scope

确认范围

“客户” 或 “发起人” 正式验收已完成的项目可交付成果的过程。

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

确认范围关注可交付成果的验收，而控制质量关注可交付成果的正确性及是否满足质量要求。
控制质量过程通常先于确认范围过程，但二者也可同时进行。

# 输入

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

核实的可交付成果

已经完成，并被控制质量过程检查为正确的可交付成果。

# 工具与技术

# 1️⃣ 检查

检查（审查、产品审查、巡检）

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

# 输出

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

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

# 2️⃣ 变更请求

• 如果未通过验收，处理步骤： 查原因，走变更
  1. 记录（了解）原因；
  2. 走变更流程，进行缺陷补救。

# 监控 控制范围

控制范围

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

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

# 输入、输出

理解为主

# 工具和技术

# 1️⃣ 数据分析

偏差分析

用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。

趋势分析

旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

• 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

范围蔓延

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

镀金

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

范围潜变

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

如果已经出现了范围蔓延，需要补变更流程 (5 个步骤 记录、评估、提交、更新、通知。
如果变更没有获得批准，需要取消不良变更。

# 重点总结

• 范围强调 “做且只做”，要多做、少做都要走变更流程
• “产品需求” 衡量产品范围的完成情况，“项目管理计划” 衡量项目范围的完成情况
• 范围管理计划中无范围，需求管理计划中无需求
• 收集需求的输入、工具、输出
• 定义范围的定义，输入、工具、输出 创建 WBS 的输入、工具和输出
• 确认范围的定义和作用，输入、工具和输出 控制范围的定义，范围蔓延的定义和处理方式

# 敏捷相关

从预测型方法到适应型或敏捷型方法，项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。

采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建 WBS。相反，在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，随同可交付成果的创建提供反馈意见，并确保产品未完项反映他们的当前需求。++ 在每次迭代中，都会重复开展两个过程：确认范围和控制范围。++ 相反，在预测型项目中，确认范围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。

在预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完项（包括产品需求和用户故事）反映当前需求。

• 对应知识点：
  1. 小步快跑，增量交付
  2. Sprint 计划会议
  3. Sprint Backlog
  4. 相关方频繁参与
  5. Sprint 评审会议
  6. 专注于 Sprint 目标