项目范围管理包括确保项目“做”且“只做”所需的全部工作（即不能少做，也不能多做，如果多做，就要消耗团队额外的时间和资源，并且无法被认可），以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
范围管理过程确保了项目团队和项目相关方就项目的可交付成果以及形成这些可交付成果所进行的工作达成共识。
范围包括产品范围和项目范围
- 产品范围：某项产品、服务 或 成果所具有的特性和功能。
- 项目范围：为交付具有规定特性与功能的产品、服务 或 成果而必须完成的工作。
在交付产品的项目中，项目范围包括产品范围。
目录
一、项目范围管理输入、输出、技术和工具
1.1 规划范围管理
1.2 收集需求
1.3 定义范围
1.4 创建WBS
1.5 确认范围
1.6 控制范围
1.7 管理新实战
1.8 裁剪考虑因素
1.9 敏捷与适应方法
二、规划范围管理
2.1 作用
2.2 范围管理计划
2.3 需求管理计划
2.4 需求管理计划和范围管理计划
2.5 验收文件
三、收集需求
3.1 作用
3.2 需求、可交付成果与项目目标的映射关系
3.3 工具与技术
3.4 需求管理过程
3.4.1 亲和图
3.4.2 思维导图
3.5 需求决策
3.6 需求文件
3.7 需求跟踪矩阵
3.8 敏捷场景下的需求管理
3.8.1 产品属性
3.8.2 精益画布
3.8.3 最小可发布版本
3.8.4 产品待办事项列表
3.8.5 分解和细化产品待办事项列表中的条目
3.8.6 用户故事
四、定义范围
4.1 作用
4.2 项目范围说明书
五、创建WBS
5.1 作用
5.2 分解的基本概念
5.3 分解步骤
5.4 WBS元素
5.5 WBS字典
5.6 控制账户
5.7 规划包
5.8 工作包的分解原则
5.9 范围基准
5.10 WBS的价值
六、确认范围
6.1 作用
6.2 确认范围的步骤
6.3 需要检查的问题
6.4 干系人关注点的不同
6.5 可交付成果的演变
6.6 质量控制和范围确认
6.7 其它知识点
七、控制范围
7.1 作用
7.2 范围蔓延
一、项目范围管理输入、输出、技术和工具
| 概念 | 核心思想 | |
| 规划范围管理 | 指南和方向 | 为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划。 |
| 收集需求 | （甲方）你要啥？ | 易混淆。 收集需求：为了实现项目目标，确定、记录并管理干系人的需要和需要。 定义范围：制定项目和产品详细描述。 |
| 定义范围 | （乙方）我干啥？ | |
| 创建WBS | 细一点 | 将项目可交付成果和项目工作分解为较小的、更易于管理的组件。 |
| 确认范围 | （甲方）你签字 | 易混淆。 确认范围：正式验收已完成的项目可交付成果。 控制范围：监督项目和产品的范围状态，管理范围基准的变更。 |
| 控制范围 | 做且只做 |
1.1 规划范围管理
在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或公在项目的预定义点开展。
1.2 收集需求
为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。
1.3 定义范围
描述产品、服务 或 成果的边界和验收标准。本过程需要在整个项目期间多次反复开展。
1.4 创建WBS
为所要交付的内容提供架构。本过程仅开展一次或仅在项目预定义点开展。
1.5 确认范围
使验收过程具有客观性；通过确认每个可交付成果来提高最终产品、服务 或 成果获得验收的可能性。
1.6 控制范围
在整个项目期间保持对范围基准的维护。
高清链接：项目范围管理输入、输出、技术和工具 密码:X0V8
1.7 管理新实战
需求一直是项目管理的关注重点。项目范围管理的新趋势和新兴实战更加注重与商业分析师一起合作，以便：
- 确定问题并识别商业需要；
- 识别并推荐能够满足需要的可行解决方案；
- 收集、记录并管理干系人需求满足商业和项目目标；
- 推荐项目集或项目产品、服务或最终成果功能应用。
商业分析师的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。
项目经理与商业分析师之间应该是伙伴合作关系。
1.8 裁剪考虑因素
对项目范围管理过程裁剪时应该考虑的因素：
- 知识和需求管理：项目经理应该建立哪些指南？为了未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系？
- 确认和控制：组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？
- 需求的稳定性：项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应弄技术来处理不稳定的需求，直到需求稳定且定义明确？
- 治理：组织是否拥有正式或非正式的审计和治理政策、程序和指南？
1.9 敏捷与适应方法
对于需求不断变化、风险在或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间。
采用敏捷或适用型生命周期，旨在应对大量变更，需要干系人持续参与项目。
- 采用多次迭代，重复开展三个过程：收集需求、定义范围 和 创建WBS。
- 发起人和客户代表应该持续参与项目，重复开展两个过程：确认范围 和 控制范围。
二、规划范围管理
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
2.1 作用
本过程的主要作用是：在整个项目期间对如何管理范围提供指南和方向。
本过程仅开展一次或仅在项目的预定义点开展。
2.2 范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。可以是正式或非正式的，非常详细或高度概括的。
主要内容包括：
1. 如何制定项目范围说明书；
2. 如何根据详细项目范围说明书创建WBS；
3. 确定如何审批和维护范围基准；
4. 如何正式验收已完成的项目可交付成果。
主要解决以下问题：
1. 范围说明书的定义，以及WBS和WBS词典的格式、流程。
2. 范围基准的生成和审批程序。
3. 范围变更管理的规则和程序。
4. 可交付成果的验收标准和流程。
2.3 需求管理计划
需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。主要内容包括：
1. 如何规划、跟踪和报告各种需求活动；
2. 配置管理活动；
3. 需求优先级排序过程；
4. 测量指标及使用这些指标的理由；
5. 反映哪些需求属性将被列入跟踪矩阵。
2.4 需求管理计划和范围管理计划
| Requirements | Scopes |
| 需求管理计划 | 范围管理计划 |
|
|
项目范围来源于需求，但是需求管理计划的目地是记录、跟踪和管理需求，所有需求只要被提出，就应该被有效管理，无论这个需求是否被满足。需求管理计划要定义需求识别、记录、跟踪、报告、变更、排优先级等计划的规则和方法。
范围管理计划就是我们应该如何管理好我们必须做的工作。例如，如何清晰的表述工作范围，如何明确分工，如何管理变更，如何验收确认。
2.5 验收文件
由客户提供，经过客户确认签字的正式文件，用于对项目可交付成果的验收。
三、收集需求
需求具有多样性、复杂性、隐蔽性、差异性、变化性 和 矛盾性的特性。
3.1 作用
本过程的主要应用是：为定义产品范围和项目范围奠定基础。
本过程公开展一次或仅在项目的预定义点开展。
3.2 需求、可交付成果与项目目标的映射关系
1. 并不是所有需求都需要项目组去满足。
2. 需求是否被批准最终由发起人决定。
3. 被批准的需求需要同可交付成果及项目目标之间建立逻辑联系。
3.3 工具与技术
头脑风暴 Brainstorming：一种用来生产和收集项目需求和产品需求的多种创意的技术，通过团队成员集思广益、畅所欲言、互相启发来实现。但是头脑风暴会受与会人员的知识经验所限。
访谈 Interview：访谈有经验的项目参与者、发起人、其他高管以及主题专家，有助于识别和定义可交付的产品特征和功能。
焦点小组 Focus Group：是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
问卷调查 Questionnaire：适用于以下几种情况：受众多样化，需要快速完成调查，受访者地理位置分散，适合开展统计分析。问卷设计应紧密围绕调查目的，而向调查对象，坚持人性化，并优先选经广泛认可的标准量表。
标杆对照 Benchmarking： 将实际或计划的产品、过程和实践，与其他可比组织的实战进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可是内部的，也可以是外部的。
原型法 Prototyping： 指在实际制造预期产品之前，选造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的被我，它使得干系人呆以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。
故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
名义小组技术 Nominal group technique： 用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组是一种结构化的头脑风暴形式。其步骤包括以下四步：
- 向集体提出一个问题或难题，每个人在沉思后写出自己的想法；
- 主持人在活动挂图上记录所有人的想法；
- 集体讨论各个想法，直到全体成员达成一个明确的共识；
- 个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。
为了减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。
联合应用程序开发或设计 JAD：适用于软件开发行业。客户被邀请和开发团队一起，通过二系列的研讨会收集需求和改进软件开发的过程。客户持续参与，有利于客户充分了解项目并及时给出反馈，也有利于团队更深入理解客户的真实需求。
质量功能展开 QFD：这个工具在新产品研发项目中很常用，可以把用户需求转化成产品功能，以便开发出最符合用户需求的产品功能。质量功能展开通常分为以下四个步骤：
- 第一步：产品规划矩阵，把用户需求转化为设计要求。
- 第二步：零件规划矩阵，把设计要求转化为零件特性。
- 第三步：工艺规划矩阵，把零件特性转化为工艺要求。
- 第四步：工艺/质量规划矩阵，把工艺要求转化为生产要求。
3.4 需求管理过程
需求管理中数据表现的工具有：亲和图、思维导图。
3.4.1 亲和图
亲和图法被称为KJ法。通过头脑风暴法把收到的事实、意见和设想等语言文字资料，根据资料间的亲和性将其归类，以便从复杂现象中找出规律、抓住本质、理出思路的一种方法。
再经过分享、讨论、投票待方式，根据需求间的亲和性将其照着，形成若干组需求。
3.4.2 思维导图
表达发散性思维的有效图形思维工具，即运用图文并重的技巧，把各级主题的关系用相互隶属与相互关联的层级图表现出来，并把主题关键词与图像、颜色等建立记忆连接。
3.5 需求决策
当需求众多，需要做出取舍，或者需要结合多人的意见做出决策时，通常采用以下决策技术：
投票：在进行投票之前，要先确定投票的原则。
- 一致同意原则：只有所有人同意，方案才能通过。该方案也叫“一票否决制”。
- 大多数同意原则：只要获取通过半数或超过2/3 的得票，方案即可通过。
- 相对多数同意原则：多个方案中得票最多的胜出，不管得票是否超过半数。
独裁：这种决策技术是由一个人做出最终决定，必要时可起到高效决策的作用。
多标准决策分析：在相互冲突的多方案中进行选择，就是根据准则层的各项准则分别给方案层的各个方案打分，然后汇总分数，总分最高的方案胜出，成为目标方案。
3.6 需求文件
| 类别 | 定义 |
| 1 业务需求 | 整个组织的高层级需要。例如，解决业务问题或抓住业务机会，以及实施项目的原因。 |
| 2 干系人需求 | 干系人的需要。 |
| 3 解决方案需求 | 为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。 解决方案需求又进一步分为功能需求和非功能需求：
|
| 4 过渡和就绪需求 | 描述了从“当前状态”过渡到“将来状态”所需的临时能力。如数据转换和培训需求。 |
| 5 项目需求 | 项目需要满足的行动、过程和其他条件。例如里程碑日历、合同责任、抽纸因素等。 |
| 6 质量需求 | 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。 |
3.7 需求跟踪矩阵
需求跟踪矩阵是把产品需求从来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
需求跟踪的内容包括：（但不限于）
- 业务需要、机会、目的和目标；
- 项目目标；
- 项目范围和WBS可交付成果；
- 产品设计；
- 产品开发；
- 测试策略和测试场景；
- 高层级需求到详细需求。
需求跟踪矩阵中记录了需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性 和 验收标准。需求跟踪矩阵示例如下：（列有相关需求属性）
| 需求跟踪矩阵 | ||||||||
| 项目名称： | ||||||||
| 成本中心： | ||||||||
| 项目描述： | ||||||||
| 标识 | 关联标识 | 需求描述 | 业务需要、机会、目的和目标 | 项目目标 | WBS可交付成果 | 产品设计 | 产品开发 | 测试案例 |
| 001 | 1.0 | |||||||
| 2.0 | ||||||||
3.8 敏捷场景下的需求管理
3.8.1 产品属性
卡诺属性也叫“狩野模型”，将产品属性分为五类，如下图所求：
- 魅力属性 Attractive：让用户喜出望外的属性。即使产品不具备该属性，用户的满意度也不会降低；而如果产品具备该属性，用户的满意度会大幅提升。例如，对大都数用户而言，手机的无线充电功能，屏幕可折叠待功能并不是非有不可，不过，假如手机有这些炫酷的功能，用户还是很开心的。
- 期望属性 One-Dimensional：也叫线性属性，客户满意度与产品的属性呈线性关系。例如，手机待机时间越长、手机的屏占比越大，用户越满意。
- 无差异属性 Indifference：让用户不敏感的属性。无论产品具备还是不具备，用户的满意度都不会改变。例如，手机的线路板是几层的，绝大都数据用户并不关心。
- 必备属性 Must-Be：用户对产品的基本需求。如果产品不具备，用户满意度就会大幅度降低，甚至无法接受。
- 反向属性 Reverse：用户根本没有此类需求。产品所具备的该类属性越多，用户就越不满意。例如，手机里预装的软件越多，就越让用户讨厌。
3.8.2 精益画布
当企业有了一个很美妙的想法时，很多企业会按照流程要求编制内容翔实的商业计划书、可行性研究报告。长达几十页甚至上百页的报告往往要花几周甚至几个月的时间。而在精益创业模式中，使用一张精益画布就可以解决这个问题。
精益画布是从商业模式画布中发展而来的（如上图），包含9个部分，如下图所示：（老人打车精益画布）
| 2 用户痛点
| 3 解决方案
| 4 价值主张
| 9 竞争壁垒
| 1 用户细分
|
| 8 关键指标
| 5 市场渠道
| |||
| 7 成本结构
| 6 收入来源
| |||
3.8.3 最小可发布版本
产品开发经历漫长的过程。对于创新产品来说，如果企业没有发布过一个版本，就没法验证这款产品到底有没有真正的客户。
虽然在商业论证阶段，产品创意已经通过最小可行性产品（Minimum Viable Product, MVP）被验证过了，但MVP和真正的产品不同，MVP是验证假设的试验品，而MMR是真正的可以被客户购买的产品。企业没生产出真正的产品，只是用MVP验证出客户的“购买意愿”，并不代表客户见了产品后会真的购买。
团队需要从产品待办事项列表中精挑细选出最有价值的特性，并做出一个成本最小的产品迅速投放到市场上。
MMR原则如下：
- 最简特性清单：依据精益画布，放弃不属于核心价值主张的特性； 依据卡诺模型，舍弃产品非必需的特性。团队针对每个特性都要问自己：没有它会怎么样？如果没有它并不影响用户使用，那么它就不应该出现。
- 最小特性颗粒：尽力把产品特性拆分出子特性，一直拆分到不能拆分为止（如果继续拆分，就无法为用户提供独立的价值）。
- 最少特性组合：根据莫斯科法则（MoSCoW），把梳理出来的特性清单进一步排优先级，只开发最基本的特性，也就是产品必须有的特性。
莫斯科法则（MoSCoW）如下：
- 必须有的特性：如果没有，产品不可行。
- 应该有的特性：非常重要但不是必需的特性，可以想其他方法替代或暂时不提供。
- 可以有的特性：有了更好，没有也行。只有在时间允许，资源充裕的情况下，企业才会考虑。
- 不该有的特性：不关键、不必要，且不该在这个版本里考虑的特性。
3.8.4 产品待办事项列表
产品待办事项列表的特征如下。
- 详图适当：优先级越高的待办事项，其描述越详细； 反之，描述越简略。
- 经过估算：产中待办事项列表中的条目是经过估算的，这些估算是粗颗粒度的，通常以故事点或者理想人天的形式表达。
- 涌现的：产中待办事项列表中的条目是动态的，不断演化的。根据客户和用户的反馈，随时增减和调整待办事项列表优先级，并且，现有的条目可以不断被修订、细化，甚至移除。
- 按优先级排序：最重要的事项优先级最高，排在产品待办事项列表的最项层，最先被实施。
3.8.5 分解和细化产品待办事项列表中的条目
如下图所示，在下一次迭代开始之前，虽然产品负责人应当准备好足够多的细颗粒条目，但不必把所有条目都分解细化，这样做的目的是把花费在描述产品上的时间和资源降到最低。因为条目是动态的，变化的，所以分解和细化条目的工作也是周期性的。
如果产品待办事项列表中有同样重要的活动，那么团队应该先做哪个呢？
我们可以采取WSJF原则，即“最短作业优先”原则。公式“WSJF = 延期满足的代价 / 这项活动的历时估算” 计算每项活动WSJF 的分数，分数最高的活动就是我们应该优先做的。
3.8.6 用户故事
用户故事是一个表述用户需求的固定语法：作为一个<角色>，我想要<活动>，以便于<商业价值>。
通常团队在识别用户需求时，会用便利贴按照上述语法把用户的需求表达出来，用于看板或产品待办事项列表分析。
四、定义范围
定义范围是制定项目和产品详细描述的过程。这个过程主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排队在项目范围外，从而明确项目、服务或成果的边界。
完整、准确地定义aifl通常是项目成功的前提。范围说明书是定义范围过程的最重要的成果。
4.1 作用
本过程的主要作用是：描述产品、服务或成果的边界和验收标准。
本过程需要的整个项目期间多次反复开展。
4.2 项目范围说明书
项目范围说明是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书详细描述了项目的可交付成果，以及团队为创建这些可交付成果而必须开展的的工作，也代表了项目相关方之间就项目范围所达成的共识。
项目范围说明书是对项目范围、主要可交付成果、假设条件和抽纸因素的描述：
1. 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
2. 可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、服务能力或成果，可交付成果也包括辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
3. 验收标准：可交付成果通过验收前必须满足的一系列条件。
4. 项目除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
5. 制约因素：对项目或过程的执行有影响的限制性因素。列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件，如客户或执行组织事先确定的预算、强制性日期或进度里程碑。如果项目是根据协议实施的，那么合同条款通常也是制约因素。关于制约因素的信息可以列入项目范围说明书，也可以独立成册。
6. 假设条件：在制订计划时，不需要验证假设条件即可将其视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。在项目规划过程中，项目团队应该经常识别、记录并确认假设条件。假设条件的信息可以被列入项目范围说明书，也可以独立成册。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包括高层级的信息，对项目范围的初步表述，除方向的重大变更外，一般项目章程一经制定，就不能频繁地理性项目范围的表述，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细；项目章程是项目范围说明书制定的重要依据，而项目范围说明书需要随项目的发展动态更新维护，渐进明细。就项目范围而言，项目范围说明书是对项目章程的细化和具体化。
五、创建WBS
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
5.1 作用
本过程的主要作用是：为所要交付的内容提供架构。
本过程仅开展一次或仅在项目的预定义点开展。
5.2 分解的基本概念
简单来说，分解就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
分解是一种把范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程序，以实现对项目的高效管理。
工作包的详细程度因项目规模与复杂度而异。
5.3 分解步骤
- 识别和分析可交付成果及相关工作；
- 确定WBS的结构与编排方法；
- 自上而下逐层细化分解；
- 为WBS组成部分制定和分配标识编码；
- 核实可交付成果分解的程度是否失当；
5.4 WBS元素
WBS包含如下几种元素。
1. 可交付成果
可交付成果是团队为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，其包括各种辅助成果，如项目管理报告和文件。可交付成果的描述可略可详。
2. 子项目
子项目是整个项目的一部分。一个子项目是能够被相对独立地作为“项目”来管理的，可由一个专业团队或一个分包组织负责。
3. 控制账户
控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
4. 工作包
工作包是WBS中最低层次的组件，通常表达为可交付成果。工作包可以对相关活动进行归类，以便对工作进度进行估算，开展监督与控制。
5. 规划包
规划包也是WBS的最低层次的组件，位于控制账户之下。它的工作范围是已知的，但所包含的活动或对应的工期和预算是当前未知的，需要随项目的深入进一步确定。
6. 活动
活动是工作包的组成部分，不属于WBS组件。活动描述中包含一个表示其动作的动词，如“开发微信支付接口”。一个活动通常有期望持续时间、期望成本、期望资源需求。活动经常被细分为任务。
7. 任务
任务通常是活动进一步分解的组成部分，不属于WBS组件，由某个团队成员负责。
WBS分解的100%原则：一个WBS元素的下一层分解（子层）必须百分之百地表示上一层（父层）元素的工作，不能有重复，更不能有遗漏。
5.4 WBS结构
- 将项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放第三层。
- 主要可交付成果作为分解的第二层
- 分解的两种表现形式
分组的树形结构（小型项目），特点：WBS层次清晰，非常直观，结构性很强。
5.5 WBS字典
| WBS编码 | 缩写 | 描述 | 标准 | 历时 | 费用 | 负责人 | 依赖 |
| 1.1.1.0 | EA | 这个元素包含可交付成果的培训服务、手册，复检，培训帮助和培训设备，用来指导客户最大效率地学习怎样操作和维护系统。 | CS13 | 3M | ～50K | 李四 | 系统部署完成 |
WBS字典是针对WBS中每个组件，详细描述可交付成果、活动和进度信息的文件。
WBS字典对WBS组成部分（包括工作包和控制账户）进行更详细的描述。
WBS字典中的内容可能包括（但不限于）：
- 账户编码标识
- 工作描述
- 假设条件和制约因素
- 负责的组织
- 进度里程碑
- 相关的进度活动
- 所需资源
- 成本估算
- 质量要求
- 验收标准
- 技术参考文献
- 协议信息
5.6 控制账户
- 控制账户是一个管理控制点。
- 在该控制点上，把范围、预算和进度加上整合，并与挣值相比较来测量绩效。
- 控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联。
- 项目管理实践中，通常控制账户和专业相对应。
5.7 规划包
- 规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
- 一个控制账户可以包含一个或多个规划包。
- 由于当前无法分解到编制项目管理计划所需要的详细程度，规划包是暂时用来做计划的。
- 随着情况的逐渐清晰，规划包最终被分解成工作包以及相应的具体活动。
5.8 工作包的分解原则
- WBS必须是面向可交付成果的。
- WBS必须符合项目的范围。（100%原则）
- WBS的底层应该支持计划和控制。
- WBS中的元素必须有人负责，而且只有一个人负责。
- WBS控制在4～6层：如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。
- WBS应包括项目管理工作，也要包括分包出去的工作。
- WBS的编制需要所有（主要）项目干系人的参与。
- WBS并非是一成不变的。
5.9 范围基准
5.10 WBS的价值
WBS的价值体现在以下五个方面。
1. 基准的来源
范围基准是三大基准之首。有了范围，我们才能确定进度基准和成本基准。
2. 计划的基础
项目进度、成本、质量、风险等所有计划都要依据基准来编制。
3. 工作的展现
WBS把项目所涵盖的工作分层次、结构化地展现出来。
4. 控制的依据
该项工作是否应该做，要对照范围基准，如果范围基准里没有，就不应该做。
5. 团队的指南
团队根据WBS来确定工作的目标和分工。
六、确认范围
确认范围是获得项目发起人或客户对项目可交付成果正式验收的过程。通过项目过程中发起人或客户持续性地验收每个可交付成果，可以保障最终产品、服务或成果获得验收。
6.1 作用
- 使验收过程是有客观性。
- 通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。
确认范围过程应该根据需要在整个项目期间开展。
由主要干系人，尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已圆满完成并通过正式验收。
6.2 确认范围的步骤
- 确定需要进行范围确认的时间；
- 识别范围确认需要哪些投入；
- 确定范围正式被接受的标准和要素；
- 确定范围确认会议的组织步骤；
- 组织范围确认会议。
6.3 需要检查的问题
项目干系人进行范围确认时，要检查的内容：
- 可交付成果是否确定的、可确认的。
- 每具可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
- 是否有明确的质量标准。
- 审核和承诺是否有清晰的表达。
- 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
- 项目范围的风险是否太高，管理层是否能够降低风险发生时对项目的影响。
6.4 干系人关注点的不同
- 管理层主要关注项目范围：是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
- 客户主要关注产品范围：关心项目的可交付成果是否足够完成产品或服务。
- 项目管理人员主要关注项目制约的因素：关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
- 项目团队成员主要关注项目范围中自己参与的元素和负责的元素：通过定义范围中的时间检查自己的工作时间是否足够，自己的项目范围中是否有多项工作，而这些工作是否有冲突的地方。
6.5 可交付成果的演变
- 可交付成果：指导与管理项目工作
- 控制质量：核实的可交付成果
- 确认范围：验收的可交付成果
- 结束项目或阶段：最终的产品、成果或服务
6.6 质量控制和范围确认
确认范围，关注可交付成果的验收。
控制质量，关注可交付成果的正确性及是否满足质量要求。
控制质量过程通常先于确认范围过程，但二者也可同时进行。
6.7 其它知识点
核实的可交付成果：指已经完成，并被控制质量过程检查为正确的可交付成果。
验收的可交付成果：由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
七、控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
7.1 作用
- 在整个项目期间保持对范围基准的维护，并确保所有变更请求、纠正措施或预防措施都通过实施整体变更控制程序进行处理。
本过程需要在整个项目期间开展。
7.2 范围蔓延
未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。
- 狭义的范围蔓延：在客户要求下，未经正常的范围变更控制程序而出现的产品或项目范围的扩大，也叫“范围爬行”。
- 镀金：广义范围蔓延的一种，指在定义范围的工作范围以外，项目团队主动增加的额外工作，但没有经过范围控制程序。
不管镀金还是范围爬行，共同点者是没有经过整体变更控制程序而发生了范围变化。统称“范围蔓延”。
![详解—[C++ 数据结构]—AVL树](https://img-blog.csdnimg.cn/direct/8c551d0403ba426081ad4c526c9d3544.png)
