第九章 范围管理 (2025年详细解析版）

目录

• • • 什么是范围管理？
• 9.1 管理基础
  • 9.1.1 产品范围和项目范围
  • 9.1.2 产品范围和项目范围
    • 管理新实践
• 9.2 项目范围管理过程
  • 9.2.1 过程概述
  • 9.2.2 项目范围管理过程
  • 9.2.3 裁剪考虑因素(了解)
  • 9.2.4 敏捷与适应方法
    • • 总结
• 9.3 规划范围管理
  • 1. 课程目标
  • 2. 过程定义：规划范围管理
  • 3. 数据流向图
  • 4.ITTO
    • 4.1. 输入
      • 项目章程、项目管理计划
      • 事业环境因素、组织过程资产
    • 4.2 工具与技术
      • 专家判断、数据分析、会议
    • 4.3 输出
      • 范围管理计划
      • 需求管理计划
  • 5.核心知识整理
• 9.4 收集需求
  • 1. 课程目标
  • 2. 过程定义 ：收集需求
  • 3. 数据流向图
  • 4.ITTO
    • 1. 输入
      • 项目章程、项目管理计划
      • 项目文件
      • 立项管理文件
      • 协议
      • 事业环境因素
      • 组织过程资产
    • 2. 工具与技术
      • 专家判断
      • 数据收集
        • 访谈
        • 焦点小组
        • 问卷调查
        • 其他
      • 数据分析
      • 决策
        • 投票
        • 多标准决策分析
      • 数据表现
        • 亲和图
        • 思维导图
      • 人际关系与团队技能 ---- 软技能
        • 名义小组技术
        • 观察和交谈
        • 引导式研讨会
      • 系统交互图
      • 原型法
    • 3. 输出
      • 需求文件
        • 需求分类
      • 需求跟踪矩阵
  • 5. 核心知识整理
• 9.5 定义范围
  • 1. 课程目标
  • 2. 过程定义 : 定义范围
  • 3.数据流向图
  • 4.ITTO
    • 1. 输入
      • 项目章程
      • 项目管理计划
      • 项目文件
      • 事业环境因素
      • 组织过程资产
    • 2.工具与技术
      • 专家判断
      • 数据分析
      • 决策
      • 人际关系与团队技能
      • 产品分析
    • 3. 输出
      • 项目范围说明书 ----- 最重要的输出
        • 项目范围说明书四项重要内容(需要背记)
      • 项目文件更新
  • 5. 核心知识整理
• 9.6 创建 WBS
  • 1.课程目标
  • 2.过程定义：创建 WBS
  • 3.数据流向图
  • 4.ITTO
    • 1. 输入
      • 项目管理计划
      • 项目文件
      • 事业环境因素
      • 组织过程资产
    • 2. 工具与技术
      • 分解
    • 3. 输出
      • 范围基准
      • 项目文件更新
  • 核心知识整理
• 9.7 确认范围(其实是验收)
  • 1. 课程目标
  • 2. 过程定义 : 确认范围
  • 3.数据流向图
  • 4.ITTO
    • 1. 输入
      • 项目管理计划
      • 项目文件
      • 核实的可交付成果、工作绩效数据
    • 2. 工具与技术
      • 检查
      • 决策
    • 3.输出
      • 验收的可交付成果
      • 工作绩效信息
      • 变更请求
      • 项目文件更新
  • 5.核心知识整理
• 9.8 控制范围
  • 1. 课程目标
  • 2. 过程定义 ：控制范围
  • 3.数据流向图
  • 4.ITTO
    • 1. 输入
      • 项目管理计划
      • 项目文件
      • 工作绩效数据
      • 组织过程资产
    • 2. 工具与技术
      • 数据分析
        • 偏差分析
        • 趋势分析
    • 3. 输出
      • 工作绩效信息
      • 变更请求
      • 项目管理计划更新
      • 项目文件更新
  • 5.核心知识整理
• 单词

什么是范围管理？

• 项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程

• 范围管理注意以下几点：

  • 全部工作。不能减少或遗漏
  • 做且只做。不能多做，防止范围蔓延
  • 其他管理的基础。变更要走正式变更流程

提示 管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内

9.1 管理基础

• 项目范围管理知识领域的基础
• 概要性的介绍一下知识领域包含哪六个过程 ---- 9.2
• 分别依次来学习这个知识领域的六个过程 ----- 9.3到9.8

9.1.1 产品范围和项目范围

• 范围其实有两个概念,就是不同的人关注不同的范围.

解析

• 产品范围实际上可以认为就是客户最关注的,项目最终要交付的产品,它是某项产品服务或成果所具有的特征或者功能.
• 项目范围实际上是跟产品范围相关的,为了交付左边那个产品范围,项目里边要做的所有工作.
• 本质上这个范围,它是包括产品范围的要交付产品,时间(在一定的时间之内,时间也是一种资源的限制),资源(在一定的真正的人才物的资源范围之内),资金(资金限制之内).

区别

• 客户拿到产品范围,项目管理团队要达成项目范围的要求
• 项目范围包含了产品范围

9.1.2 产品范围和项目范围

管理新实践

• 项目范围管理的核心一直是对需求的关注。商业分析(岗位商业分析师(business)(也叫业务分析师))在项目的需求管理中越来越重要，甚至在项目启动和项目经理任命之前就开始了商业分析活动。

解析

• 很多企业里边多了一个职位,叫商业分析师,商业分析启动要早于项目经理,商业分析的起点是很久很久以前就开始,项目组合或者项目及经理关注商业分析,规划高层次的组合的时候,就开始介入进行商业分析,商业分析中间如果确定启动项目,才进入项目管理,但是最后整个项目关闭或者需求结束的时候,要看一下是不是项目的成果满足了当初的商业需求,最好项目里边专门有一个人担任商业分析师.

为何要注重与商业分析专业人士的合作？(为什么项目方或者项目经理要和商业分析师进行合作?)

• 确定问题并识别商业需要
• 识别并推荐能够满足这些需要的可行解决方案
• 收集、记录并管理干系人需求，以满足商业和项目目标
• 推动项目集或项目的产品、服务或最终成果的成功应用

解析

• 主要是需求,特别是从高层次的商业需求开始确定,通过跟商业分析师合作来确定项目是否能满足这些需求,商业分析师也会参与很细节的需求分析,最后达成MP.

提示 最好的情况是团队内部配备专门的商业分析师，负责需求管理相关的活动

9.2 项目范围管理过程

• 项目范围管理知识领域里边有几个过程,各个过程大体上干什么.

9.2.1 过程概述

• 项目范围管理过程包括：

  • 规划范围管理：为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划。(形成结果很虚,会形成范围管理计划,形成一个怎么管需求的需求管理计划.)
  • 收集需求：为了实现项目目标，确定、记录并管理干系人的需要和需求。(比较实际的要做很多,扎实的巩固,收集需求,项目经理要领着团队成员从所有干系人那收集需求,并且记录到需求文件,需求文章矩阵.
    
    当然不是所有需求这个项目里边都要完成,那么多需求,不同的人提的有合理的,有不合理的,不能都完成了.)
  • 定义范围：制定项目和产品详细描述。(跟干系人达成一致,达成共识,最后确定哪些需求放入项目之内,看哪些需求咱不做,会形成项目的范围说明书)
  • 创建WBS：将项目可交付成果和项目工作分解为较小的、更易于管理的组件。(把范围泛泛的大块范围分解成很小的工作包 (包含:非常重要的一个概念,分解成层次结构,叫WBS工作分解结构.))
  • 确认范围：正式验收已完成的项目可交付成果。(在监控的时候,有一个过程叫确认范围,确认范围是指最后的可交补成果已经交付了,确认范围实际上是一个验收的一个操作,可交补成果是否能获得干系人,特别是客户的批准,那客户会对这个可交付进行验收,这个过程叫确认范围)
  • 控制范围：监督项目和产品的范围状态，管理范围基准的变更。(在整个范围管理的流程当中,随时随地的要关注范围别多做了,别少做了,多做或者少做都不行,范围一旦有变更,要及时的去介入,并且走整体变更流程,这就是是控制范围.)

总结 : 坚决防止范围蔓延或者镀金

图解析

• 确认范围这个验收的操作不是在收尾,而是在监控.(即项目经理进行可交付的验收要尽早进行,千万别推到收尾阶段.)

9.2.2 项目范围管理过程

9.2.3 裁剪考虑因素(了解)

• 进行项目范围管理的时候,每个项目都是独特的,对于项目范围管理做什么,不做什么,执行哪些过程,每个过程的ITTO到底裁剪到什么程度,你要考虑下边几个因素.

• 裁剪时应考虑的因素包括：

  • 知识和需求管理 ：项目经理应建立哪些指南？为了在未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系？

  • 确认和控制 ：组织是否有正式或非正式的与确认和控制相关政策、程序和指南？

  • 开发方法 ：组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？

  • 需求的稳定性 ：项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确？

  • 治理 ：组织是否拥有正式或非正式的审计和治理政策、程序和指南？(要求是什么样(会影响咱们的范围管理),如何对范围进行管理)

9.2.4 敏捷与适应方法

• 敏捷项目在开始时通常无法明确项目的范围，而需要在项目期间逐渐明确(敏捷项目或者适应型项目,这个需求或者叫范围一般是很难确定,要逐步明确的.)
• 敏捷方法缩短了定义和协商范围的时间，增加了持续发现和细化范围的时间(项目开始的时候范围很难确定,就别浪费时间在规划阶段,反正确定不了,
  要缩短规划时间,不要浪费,开始时候的预测到后边肯定会变,缩短了定义和协商范围的时间,随着项目进展,可以不断对需求进行细化,未来会逐渐细化.)
• 敏捷项目中的整体范围分解为一系列拟实现的需求和拟执行的工作（称为产品未完成项）(传统的项目,事先要把收集来的需求真的就是形成项目文件或者项目需求规格说明书(SRS)里边的每个条目就是一个需求,但是敏捷项目一般不是这么处理,一般是收集来的需求(比如:产品负责人或者客户提的需求),形成一个列表(也叫产品未完成项),需求以这种方式记录到Excel表格(产品未完成项)
  
  产品要提供哪些功能,把这些功能记录到产品未完成项文件或者Excel里边,
  最要命的是提需求的客户或者叫产品负责人,他会不断的修改产品未完成项,
  而且会不断的对产品未完成项(待办列表)里边的每一个条目进行重新优先级排序,这是敏捷项目比较特殊的地方.)

总结

• 除了规划范围管理这个过程之外,其他5个过程,在每一次迭代里边都要执行,要收集需求,定义范围,创建WBS,发起人或者客户,也包括项目经理,控制范围是项目经理在做,或者项目管理团队就是客户和发起人,不是要对每个迭代交付的,每次迭代他都得确认范围,都得控制范围.

9.3 规划范围管理

1. 课程目标

• 掌握规划范围管理过程的含义与作用掌握范围管理计划的含义与内容了解需求管理计划的内容

2. 过程定义：规划范围管理

定义

为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划.(这个过程就是为了写范围管理计划,也会完成一个需求管理计划)

作用

• 在整个项目期间对如何管理范围提供指南和方向.(其实是为后边那5个过程提供指南,那5个过程怎么去做)

时机

• 仅开展一次或仅在项目的预定义点开展.(多阶段项目很可能回头再去审查计划的所有子计划)

本过程的主要任务是为如何进行范围管理活动提供规划和指导，不涉及需求收集或定义范围等具体工作！

3. 数据流向图

4.ITTO

记住

• 范围管理计划和需求管理计划

4.1. 输入

项目章程、项目管理计划

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

4.2 工具与技术

专家判断、数据分析、会议

4.3 输出

范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围

• 对下列工作的管理过程做出规定(由范围管理计划指导下边几个如何去做,而不是直接做)：

• ① 制定项目范围说明书

• ② 根据详细项目范围说明书创建WBS

• ③ 确定如何审批和维护范围基准

• ④ 正式验收已完成的项目可交付成果

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的

• 沟通管理计划可能会细节性强一点,那其他管理计划都是很虚的一个东西.

需求管理计划

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。有些组织称之为 " 商业分析计划 "

• 主要内容包括：

  • ① 如何规划、跟踪和报告各种需求活动
  • ② 配置管理活动(如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限)
  • ③ 需求优先级排序过程
  • ④ 测量指标及使用这些指标的理由
  • ⑤ 反映哪些需求属性将被列入跟踪矩阵的跟踪结构

• 需求管理计划里边是指导,如何规划跟踪和报告,需求如何进行配置,管理活动如何进行优先级排序等,现在这个过程还没收集需求,所以只是如何对需求进行各种操作,这种指南写到需求管理计划.

5.核心知识整理

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

• 该过程生成两个项目管理子计划，范围管理计划和需求管理计划

• 范围管理计划是项目管理计划的组成部分，描述将如何进行范围管理

• 需求管理计划是项目管理计划的组成部分，描述将如何分析记录和管理需求

9.4 收集需求

1. 课程目标

• 掌握什么是需求，以及收集需求的定义
• 掌握项目需求和产品需求的区别
• 了解并区分各种收集需求的工具与技术
• 掌握需求文件和需求跟踪矩阵的内容

2. 过程定义 ：收集需求

定义

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

作用

• 为定义产品范围和项目范围奠定基础

时机

• 仅开展一次或仅在项目的预定义点开展

3. 数据流向图

解析

• 主要是在需求管理计划,范围管理计划,两个计划的指导下,还要参考项目章程(因为项目章程里已经有一些高层次的需求),还要参考一些意向管理文件(比如可行性指标报告)这些都是收集需求的指南,收集需求这个过程执行之后,要产生很多需求,输出记录到需求文件,另一个非常重要的文件叫需求跟踪矩阵.

4.ITTO

基本概念 ------ 需求

• 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力(所有干系人把他的想法提出来,项目经理领着团队一一的记录下来,在收集或者记录需求的过程,实际上就是收集需求.)
• 需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望(所有需求最后都得记录到需求文件.(量化实际上就是可核实性,每个需求都应该可核实))

需求的重要性/定义

• 需求是整个项目，特别是后面的创建工作分解结构WBS过程以及规划成本、进度、质量和采购等过程的基础。只有明确需求了，后续工作才能有序进行，项目最终实现的产出才有价值。(AI最基础的模型叫底座模型,可以认为需求就是整个项目的底座或者基础,项目上面的所有的内容包括最后项目的产出都得依赖需求.)

1. 输入

项目章程、项目管理计划

项目文件

项目文件

• 可作为本过程输入的项目文件包括：

  • 假设日志：识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件
  • 经验教训登记册：提供了有效的需求收集技术尤其针对使用选代型或适应型产品开发方法的项目
  • 干系人登记册：用于了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望。

立项管理文件

立项管理文件

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

协议

协议

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

事业环境因素

• 能够影响收集需求过程的事业环境因素包括：

  • 组织文化
  • 基础设施
  • 人事管理制度
  • 市场条件

组织过程资产

• 能够影响收集需求过程的组织过程资产包括：

  • 政策和程序
  • 包含以往项目信息的历史信息和经验教训知识库

2. 工具与技术

专家判断

• 征求专家意见的主题

  • 商业分析
  • 需求获取
  • 需求分析
  • 需求文件
  • 以往类似项目的项目需求
  • 图解技术
  • 引导
  • 冲突管理

跟收集需求或者处理需求相关的一些方面的知识,要请求专家的帮助

数据收集

访谈

• 访谈是一种通过与干系人直接交谈，来获得信息的正式或非正式方法(解析:在收集需求的过程中,访谈特别重要,访谈工具本身很简单,就是项目经理跟团队成员要跟被访谈的或者被收集需求对象之间,一般是面对面的谈话,这种是获得需求最好的方式.)

• 访谈对象：

  • 有经验的项目参与者(跟谁去收集需求,能给项目组提供非常好的信息的,这是重要的干系人)
  • 发起人与其他高管(特别是收集关键需求的时候)
  • 主题专家(非常重要这方面这个领域的专家)

提示：向关键干系人收集需求时通常使用访谈技术((因为访谈技术涉及到大量的人力资源,就是要投入项目经理和团队时间资源,还要约请对方,所以只有针对于关键干系人才采用访谈技术.)

焦点小组

• 焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度.(焦点小组就是专家座谈会,都是针对于某一个领域的专家,对这个问题都很熟悉,他们进行专项讨论,一般来说特别热烈,特别激烈,可能会产生争执,)

• 主持人的角色至关重要(作为项目经理,可能要关注下边协调工作,要确定这次焦点小组会议的内容和这个议题的顺序,还有就是出现大家不愿意发言的情况,要鼓励发言,活跃气氛,如果各方出现争执的时候,要保持中立,这是项目经理在焦点小组会议上应该具备的职责.)：

  • 确定话题的内容、顺序
  • 活跃气氛、鼓励发言
  • 保持中立

提示：焦点小组往往比 “ 一对一 " 的访谈更热烈.(因为都是专家在一块,所以焦点小组肯定比单独对某一个干系人访谈更热烈的.)

问卷调查

• 问卷调查是指设计一系列书面问题，向众多受访者快速收集信息.(终端用户有好几百个上千个人,不可能一一访谈,所以通常采取的手段就是问卷调查,这种技术很简单(因为不光是收集需求,平时很多场景下,甚至都做过这种问卷调查,去制定问卷或者参与过别人的问卷调查)

• 适用于以下情况：

  • 受众多样化
  • 需要快速完成调查
  • 受访者地理位置分散
  • 适合开展统计分析

提示：合理设计问卷，设法提高问卷的回收率(做问卷调查最关键的点,怎么能让大家高兴的配合工作,要合理设计问卷,只有合理设计问卷,才能提高问卷的回收率.
比如参加别人一个调查,别人给你发一个调查问卷,也不好意思不接受,你接了,但是你看调查问卷内容,全是开放性的问题,那就麻烦答卷的人了,(你怎么看待未来的系统,怎么填写得思考10分钟/20分钟再填写(这种叫开放性的问题),你希望这个系统界面做成什么样又是一个开放性问题),如果你去设计调查问卷,尽量设计一些封闭性问题(比如关于界面的风格,喜欢采取古典风格还是现代风格,用户一看一勾就行了,关于系统的功能,希望提供系统是通过手机APP还是微信小程序还是PC客户端,被调查者一选就可以了,减轻回答问题压力,这个问卷回收效率就是极高了.))

其他

• 头脑风暴 : 是一种用来产生和收集对项目需求与产品需求的多种创意的技术
• 标杆对照 : 将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据标杆对照所采用的可比组织可以是内部的，也可以是外部的.(比如用AI做一个社交平台,可以去参考去已经有的做好的程序或项目,像QQ,微信这种平台的一些功能来确定你的需求.
  标杆对照对照范围特别广,可以是同类应用,也可以是不同的应用,也可以是组织内的应用,也可以是组织外的应用.)

数据分析

• 文件分析包括审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求

• 相关的信息来获取需求可供分析的文件包括：

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

决策

投票

• 投票是一种为达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。本技术用于生成、归类和排序产品需求

• 投票技术包括：

  • 一致同意：每个人都同意某个行动方案
  • 大多数同意：获得群体中超过50%人员的支持，就能做出决策，要求参与决策人数为奇数
  • 相对多数同意：根据群体中相对多数人的意见做出决策，在候选项超过两个时使用

提示： 独裁具备权威性，有时可以更方便的集中控制资源，高效率的完成目标，并实行合适的政策.(独裁在很多情况下,是一个很好的技术,特别是做决策的人能力比较强,没有私心,很有经验,效率非常高)

多标准决策分析

• 多标准决策分析借助决策矩阵，月用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意或方案进行评估和排序

• 解析: 多标准决策分析:从多个需求里边看谁最重要,多选一的情况下(比如:表格(如图)里,每一项是要研究的一个需求或者问题,对每一项这四项进行排序,可以从四个角度,每个角度都对现在研究这个需求或者问题给一个打分,四个角度给四个评分乘以对应四个角度的权重,最后得到这个需求或者这个问题的最后重要程度)
  因为从四个角度或者四个标准去进行决策,所以叫多标准决策分析.

数据表现

亲和图

• 亲和图 : 大量创意进行分组的技术，以便进一步审查和分析亲和图针对某一问题广泛收集资料，按照资料近似程度、内在联系进行分类整理归类合并，从而从复杂的现象中整理出思路，抓住本质，并找出解决办法.(亲和图是一种分组或者分类技术
  亲和图实际上非常简单是对大量创意进行分组的技术,这个创意也可以是需求,对大量创意进行分组(就是分类),就是图形里展现出的是需求的分类,分成几类,一般来讲亲和图这个工具很多情况下,都是跟头脑风暴相结合,第一个阶段先头脑风暴一下,(比如:一个标题就是如何能获得女友的好感(如图),然后参与头脑风暴的人七嘴八舌的说想法),头脑风暴就是尽量产生创意,但是它是非常杂乱的,因为都是每个人临时想出来的,方法多.第一步得对各种方法进行分类,图中把情人节圣圣诞节送礼物,什么生日礼物,纪念日礼物,放到一类,叫节日送礼物.分成了5类,画出这种图可以清楚的看到每类下有几种方法,这样的话做决策,到底采取哪种方式获得好感,就可以结合这个图再结合自己的时间,财力,物力,做决策.
  好处可以帮你抓住本质,然后找出解决问题的方法.)

思维导图

• 思维导图 : 把从头脑风暴中获得的创意整合成一张图用以反映创意之间的共性与差异，激发新创意它将中心概念与关联概念连接起来，通过训练运用全脑思考，来刺激想象力和创造力.(思维导图一般是跟头脑风暴相结合使用,它这个是有一个中心的概念,以这个中心为核心,发展二级三级分类.)

人际关系与团队技能 ---- 软技能

名义小组技术

• 名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序.(名义小组按照PMbook指南规范是先做名义小组,接着再做头脑风暴,实际情况不一定,也可以先做头脑风暴,后做名义小组都行,(比如:整个队有40个人,40个人想做头脑风暴非常杂乱,所以可以先分组,分成五组,每组8个人,8个人组内进行头脑风暴,最后把头脑风暴的结果进行排序),实际怎么用特别灵活,教程里的规范是先名义小组,再头脑风暴,考试按照这个来.)

• 由四个步骤组成：

  • ① 提出问题 ：向集体提出一个问题或难题。每个人在沉思后写出自己的想法
  • ② 记录想法 ：主持人在活动挂图上记录所有人的想法
  • ③ 公开讨论 ：集体讨论各个想法，直到全体成员达成一个明确的共识.(传统的头脑风暴不允许讨论,别人不允许批评你想法,但是名义小组可以.(比如 : 把所有想法贴到一个白板上,然后大家对每一个想法公开讨论))
  • ④ 私下投票 ：个人私下投票决出各种想法的优先排序，得分最高者被选出.(对想法进行排序或者选出最后的想法投票,每个人讨论完之后私下投票,最后没有选出最优的想法,可以进行第二轮第三轮.)

观察和交谈

• 观察和交谈是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。(比如去收集需求的时候,被收集需求的未来的系统用户,要调查现在的业务流程,把流程信息化,但是对方各种原因或者不愿意告诉你,就不想使用系统或者说他想告诉你,但是他也说不清,平时没有用计算机辅助,流程特别熟,但是说不出来,那这样的话,就可以采取观察和交谈.)
• 当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节.

解析

• 旁观旁站观察者:就是别人在执行业务流程的时候,你在旁边看着.
• 参与观察: 就是亲自进入到流程环境里,去执行流程,这样的话可以更深刻的体验,就是流程到底怎么走,会挖掘深层次的一些需求.

引导式研讨会

• 引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。也称之为引导式研讨会(引导式研导会可以认为是现实生活中听证会.(比如:公用设施要涨价了,电价要涨了,得有相关部门组织不同角色的群体,有使用电的群众,用电企业,第三个政府代表,供电企业代表,主管部门等)有不同职能的关注点不一样,利益不一样的人参加到一块,一块对电价上涨发表意见,形成一致.)

• 引导式研讨会的三个特点：

  • 能快速定义跨职能需求并协调干系人的需求差异
  • 有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见
  • 与单项会议相比，研讨会能够更早发现并解决问题

系统交互图

• 系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘显示业务系统（过程、设备、计算机系统等））及其与人和其他系统（行动者）之间的交互方式.(在收集需求的时候,要做一个系统,需求阶段,可以事先绘制出未来的这个系统的交互图(类似于房产里的远景图)(交互图是用图形的方式,把系统的输入输出画出来))

• 一般来讲，系统交互图需要显示业务系统的输入、输入提供者、业务系统的输出和输出接收者

微信小程序系统交互图

原型法

• 原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈.(非常常用,比如用墨刀软件画的原型图,)

解析

• 虚拟的模型用于收集用户的早期反馈,其实模型建造好之后交给用户看,用户说这个地方不对需要改,再去修改第二版原型再给用户去看,客户一看不行还得改,直到满意,出第一版.(例如:做个ERP系统可能都不用程序员上手,会用原型图软件的前端的咨询顾问(或者UI或者产品),直接用半个小时,把整个系统包括10-20个界面直接做出来了,客户一看好像真的,系统设计完了,客户说哪个地方不合适,交互怎么怎么样,功能再改,改好就作为开发标准图,就叫原型)

• 它可以以很低廉的成本收集客户需求,但一般来说,敏捷项目都在使用原型法(因为敏捷项目客户最开始也说不清他的需求,得通过原型法去提示他.)

• 原型法最重要的概念是理解支持渐进明细的理念,因为就是想通过原型法不断的让客户提出更明确的需求,所以需要反复执行.(上图第三句背诵)

故事板示例

解析

• 有一种原型叫故事版,故事版是真的通过画图来展现系统的执行顺序,或者展现系统导航路径(导航路径: 为了完成一个功能不断的去点击界面,最后找到需要的那个功能或者信息)(比如:一个搜索系统第一个界面用草图勾勒出来搜索框,搜索框输入之后,它会产生什么结果,搜索框有的情况下可能产生另外的结果.)

3. 输出

需求文件

• 需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化.

解析

• 把确定的明确的需求跟干系人一块达成一致,叫需求基准.
• 从项目管理角度讲,基准就有三个或者3+1,一个是范围基准,一个是成本基准,一个是进度基准还有就是这三个基准合到一块,叫项目的整体绩效基准.
• 没有需求基准,但个别情况下,特别是如果案例题或者论文题专门考需求管理的话,可以认为还可以有一个基准就是需求基准.

需求分类

• 把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求的类别包括(建议记住前三点)：

解析

业务需求

• 业务需求层次很高,跟具体的操作都没有关系,就是从战略上某个系统帮助企业实现战略的机遇,整个组织的高层级需要解决业务问题或抓住业务机会以及实施项目的原因,高层领导提出来了.

干系人需求

• 干系人需求就是真的去调查未来系统的用户,他希望系统有哪些具体的功能比如工作流程,调查出来要辅助10个流程,每个流程都怎么做,叫干系人需求.

解决方案需求

• 这个涉及到技术,就是企业研发的系统为了满足业务需求和干系人需求,应该提供哪些功能或者非功能需求,解决方案需求既包括功能需求也包括非功能需求.(比如:非功能性:系统的并发性如何,响应时间应该短到什么程度等)

过渡和就绪需求

• 未来要做系统上线之前,怎么保证这个系统顺利的上线,或者切换.比如:需求(对原始的历史数据进行整理,然后加工ETL,然后装载进新系统,这样新系统才能就绪),培训(为了系统正常运行,要给各类的使用者进行哪些培训)

项目需求

• 项目需求是指各种制约因素,除了解决方案提到的功能/非功能性需求还有其他的.(比如合同规定的进度要求,成本要求等)

质量需求

• 作为各种产品,产品质量很重要,有一个质量需求专门针对于质量,它就是可交付成果成功完成的条件或者质量标准.

需求跟踪矩阵

• 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格(需求跟踪矩阵:矩阵就是表格,表格就是矩阵,在项目管理领域就这么叫.
  是把产品需求从这来源(需求是怎么来的,要解决什么业务问题)从来源连接到能满足需求的可交不成果(具体的就是最后可交付成果),就从开始到最后的需求,把每一个需求画到表格里的一行,
  这个表格就叫需求跟踪矩阵.)

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

解析

关联标识	需求描述	业务需要\机会\目的\目标	项目目标	WBS可交付成果	产品设计	产品开发	测试案例
2.1.1	需求是什么描述一下	需求是实现或者对应 哪一个业务需要或者业务目标	哪个具体目标 对应到哪个具体的项目上	创建WBS过程把范围分解之后, 要写清楚WBS的哪一个工作包对应了这个需求	设计模块哪个模块对应这个需求	开发的时候,哪个代码片段对应这个需求	测试的时候,哪个测试用力测试的是这个需求

• 随着生命周期的进展,逐渐的把表格填完,就是一个在整个需求的生命周期里,对需求进行全程的跟踪,这是一个矩阵,也可以用Excel实现.
• 表里面的每一列叫关键信息,表肯定是不全面的,这里还应该记录每个需求的重要性(真正在执行开发的时候,才有重点,先做哪些功能后做哪些功能),还要记录每个需求的紧急程度.(紧急的还是可以放缓的)

5. 核心知识整理

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

• 所有干系人都可以提出需求，需求要量化且书面记录(谁可以提需求)

• 需求是整个项目，特别是后面的创建工作分解结构以及规划成本、进度、质量和采购等过程的基础(重要性)

• 收集需求是为实现目标而确定、记录并管理干系人的需要和需求的过程(收集需求的过程)

• 需求文件描述各种单一需求将如何满足与项目相关的业务需求(需求文件)

• 需求跟踪矩阵确保经批准的每一项需求在项目结束时都能得到实现(实现:没有得到实现的需求通过需求跟踪矩阵一眼就发现了)(需求跟踪矩阵)

9.5 定义范围

前景概述

• 项目经理和团队成员通过各种手段收集了很多需求,记录到需求文件,收集来的所有需求并不是都由项目经理都领着团队完成,不都是项目范围.
• 很多需求可能是很多人出于自身的考虑,提出的不切实际或者在项目里难以实现的需求,所以项目经理要跟关键干系人对需求进行整理,特别是对现在这个项目实现哪些需求,不实现哪些需求,最后做一个统一的共识,签一个协议(实际上叫范围说明书),这个过程就是定义范围.

1. 课程目标

• 掌握定义范围过程的定义

• 熟悉定义范围过程的输入、工具与技术及输出的内容

• 了解产品分析这一技术工具

• 熟悉项目范围说明书包含的内容并了解其作用

2. 过程定义 : 定义范围

定义

• 制定项目和产品详细描述

作用

• 描述产品、服务或成果的边界和验收标准

时机

• 仅开展一次或仅在项目的预定义点开展

定义范围过程的主要目的

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

3.数据流向图

4.ITTO

图片解析

为什么要定义范围?

• 因为整个项目最关注的就是这个项目到底要做什么东西,要交付哪些东西,实际上每个项目的范围可大可小,但是从客户或者组织,给项目经理的投入资源肯定是有限的,所以整个项目管理的思维就是有多少钱(有多少时间)办多少事.

• 坚决防止范围蔓延或者镀金(不该项目经理做的不要做.)

1. 输入

项目章程

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

项目管理计划

• 项目管理计划 : 项目管理计划组件包括范围管理计划其中记录了如何定义、确认和控制项目范围

项目文件

• 假设日志 : 识别了有关产品、项目、环境、干系人以及会影响项目和产品范围的其他因素的假设条件和制约因素

• 需求文件 : 识别了应纳入范围的需求

• 风险登记册 : 包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险

• 风险登记册就是项目经理考虑到项目的各种风险,风险可能影响范围,项目范围的扩大或者缩小可能引起风险,所以项目经理定义范围要参考风险登记册,风险和范围之间是紧密相关的.
  比如:项目要做10个模块,其中有一个模块面临要外购(对外采购一些芯片,采购GPU有巨大的风险,美国管控GPU,即使不管控GPU,价格也会不断上涨),10个模块不是有一个模块有设计风险,干脆把范围缩一下,去掉第十个模块,只做9个模块,这就是考虑风险之后,在第一范围这采取了一些措施.

事业环境因素

• 能够影响定义范围过程的事业环境因素包括：

  • 组织文化
  • 基础设施
  • 人事管理制度
  • 市场条件

组织过程资产

• 能够影响定义范围过程的组织过程资产包括：

  • 用于制定项目范围说明书的政策、程序和模板
  • 以往项目的项目档案
  • 以往阶段或项目的经验教训

2.工具与技术

专家判断

• 专家判断 : 定义范围时，应征求具备类似项目的知识或经验的个人或小组的意见

数据分析

• 数据分析 : 数据分析技术包括备选方案分析。备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法

决策

• 决策 : 多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围

人际关系与团队技能

• 人际关系与团队技能 : 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业背景的关键干系人，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识

解析

• 要形成的范围说明书,最后需要关键干系人达成一致的,可以帮助大家达成一致的,就是引导.

产品分析

• 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面.(产品分析是定义范围的,具体要制造一个产品,要看用产品分析来确定产品,将要交付哪些功能)

• 目标把高层级的产品或服务描述转变为有意义的可交付成果.(交付成果应该是可交付成果的描述)

• 具体技术包括(不同的行业做产品分析用手段不一样):

  • 产品分解(做大型的设备)
  • 需求分析(软件行业叫需求分析)
  • 系统分析
  • 系统工程
  • 价值分析
  • 价值工程

• 价值工程是通过集体智慧和有组织的活动对产品进行功能分析，使产品能以最低的生命周期成本可靠的实现其必要的功能，从而提高产品的价值.(花更低的钱达成功能,为企业能创造更大的价值,从而提高产品的价值.)

解析

• 例:客户渴了,提供什么产品能满足他这个需求能不让让他不渴,给他一角钱的一杯水,或者项目经理花4元钱买瓶饮料,或者项目经理去茶社花20或者200买一杯龙井茶.做第一个选择,就可以实现他的功能或者实现他的需求,这是项目经理通过价值工程这种手段来做出的选择.
• 主要思想:哪一种方案可以提高价值

3. 输出

项目范围说明书 ----- 最重要的输出

• 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述

  • ① 记录了整个范围，包括项目和产品范围
  • ② 详细描述了项目的可交付成果
  • ③ 代表项目干系人之间就项目范围所达成的共识

解析

• 不属于本项目范围:产品范围要明确写出来哪些东西不属于本项目的范围,不然,项目未来就是这件事解释不清楚的,如果执行过程当中,有人对团队提出异议哪里应该做什么,为什么没做,项目经理可以以范围说明书已经明确写出来了为依据,作为证据.
• 边界提供基准:到底哪些工作超出范围,哪些不超出范围,可以用项目范围书这进行界定.

项目范围说明书四项重要内容(需要背记)

• 项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度

• 产品范围:就是客户关注的产品范围,最终的项目要提交的对客户有意义的产品/服务或者成果,属于可交付成果

• 可交付成果:产品属于可交付成果,但是可交付成果范围特别广,包括:项目过程当中每一个阶段或者每个过程交付的东西都属于可交付成果.(比如:说项目管理计划文件就是一个可交付成果),项目经理要在项目范围说明书里把可交付成果写清楚.

• 验收标准:不管是产品还是可交付成果都要制定或者写明可交付成果的验收标准

• 项目除外责任:不管是产品还是可交付成果都要制定或者写明可交付成果的验收标准,项目不做什么,项目经理也写清楚

产生歧义

四项内容还包括假设条件和制约因素.为什么假设条件和制约因素没有写到范围说明书里?

• 应该是项目经理把所有假设条件/制约因素已经记录到假设日志里了,假设日志是一个单独的文件,所以就不记录到项目范围说明书.
• 但是范围说明书定义里边包括这个质因因素和假设条件了.

思考

• 项目范围说明书需要由客户签字吗？

  • 是的，而且关键干系人都需要签字。只有明确项目范围，制定详细的项目范围说明书并由客户确认之后，才能开展后面的工作

• 哪个文件能明确客户所要求的工作是否超出项目边界？

  • 范围说明书。我们在编写项目范围说明书的时候，全面的考虑了所有干系人的需求和期望。项目范围说明书也是评价变更或额外工作是否超出项目边界的一个基准。定义的越细致，后面范围变更的可能性就越小

项目章程和项目范围说明书的对比

解析

• 项目章程涵盖的条目非常多,但是哪一项都特别精简,因为它是关于整个项目高层次的描述.
• 项目章程,现在(2024)项目范围说明书专注性很强,只专注描述项目的范围,但是哪一项内容描述的非常详尽.

项目文件更新

• 可在本过程更新的项目文件包括：

  • 假设日志：随同本过程识别出更多的假设条件或制约因素而更新假设日志
  • 需求文件：可以通过增加或修改需求而更新需求文件
  • 需求跟踪矩阵：应该随同需求文件的更新而更新需求跟踪矩阵
  • 干系人登记册：如果在本过程中收集到了现有或新干系人的更多信息，则记录到干系人登记册中

定义范围会对一些文件进行更新,假设日志会把志愿因素和假设条件记录到范围说明书文件,通过定义范围可能会反向修改周期需求的两个输出,需求文件,需求跟踪矩阵.

5. 核心知识整理

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

• 项目范围说明书包括项目范围和产品范围，并明确指出哪些工作不属于本项目范围

• 范围说明书是指导规划、执行、评价变更请求是否超过项目边界的基准（范围说明书属于范围基准,但是它本身不是范围基准,只是范围基准里边的1/3(三个组成部分的一个).）

• 范围说明书必须由关键干系人签字，代表就项目范围所达成的共识

• 范围管理的一个基本思想是给多少钱，办多少事，防止范围蔓延和镀金

9.6 创建 WBS

• 创建WBS是形成了一个以工作包围最低层的一个层级结构.
• 通过定义范围过程形成了范围说明书,范明范围说明书很重要,它代表关键干系人对范围达成了一致,范围说明书存在就可以开始规划进度,规划成本,实际是不行的,因为范围说明书,虽然描述的很详尽了,但是它是作为整体对项目的描述,真正的要把项目分解成更小的部分,才能把每一部分分解,分配给不同的团队成员去做,或者有的部分要外包,光凭一个范围说明书不行,这就需要对范围进一步分解,分解成工作分解结构WBS,就是本章内容.

1.课程目标

• 熟悉工作分解结构和创建工作分解结构的概念

• 了解工作分解结构的作用

• 理解工作包和控制账户的含义

• 理解分解的含义、过程及分解的方式和原则

• 熟记工作分解结构词典(考试出现)的定义及其包含的内容

• 熟记范围基准的定义及其包括的内容

• 熟悉本过程的输入、工具与技术及输出

2.过程定义：创建 WBS

定义

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

作用

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

时机

• 仅开展一次或仅在项目的预定义点开展

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

3.数据流向图

• 既要参考很细节的需求文件,也要参考上一个过程形成的项目范围说明书,通过创建WBS和WBS词典之后,最后形成范围基准.

4.ITTO

基本概念----WBS

• 工作分解结构（Work Breakdown Structure，WBS）是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解.(简化理解: 可以认为WBS就是对范围进一步的分解.)
• WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作.(WBS是在范围说明书的基础之上分解,不能比范围说明书多,也不能比范围说明书少)

注意事项：

• ① 工作分解结构WBS是以可交付成果为导向的，工作不是为创造结果而付出的努力本身，而是经过努力所获得的工作产品或可交付成果，它是名词而非动词.(WBS是指要做的那个工作,而不是付出努力,不是步骤.所以WBS的每一个层次组成元素,都是以名词命名的,因为它不是步骤,所以不是动词.)

• ② 工作分解结构WBS是工作的逐级分解，它每下降一个层次是对上一层的进一步分解，并意味着对项目工作更详尽的定义

• ③ 工作分解结构WBS只包含项目范围内的工作，不包含项目范围以外的工作

WBS的作用(了解)

解析

• 既然是基准那未来监控或者验收的时候,要参考它.
• 因为工作分解结构属于基准,所以未来经过批准之后,如果修改WBS,那就是在变更范围,要走正式流程.
• 对项目的范围有一个统一的认识,其实不只是项目团队,是所有的干系人对项目范围有统一的认识,有了统一认识,最后再制造产品或者最后验收的时候,那就更加方便,有一个统一的视角.
• 用账户编码可以唯一确定工作分解结构的每个单元,就像学号一样.

1. 输入

项目管理计划

• 项目管理计划 : 范围管理计划定义了如何根据项目范围说明书创建建WBS

项目文件

• 可作为本过程输入的项目文件包括：
  • 项目范围说明书：项目范围说明书描述了需要实施的工作及不包含在项目中的工作
  • 需求文件：需求文件详细描述了各种单一需求如何满足项目的业务需要

事业环境因素

• 能够影响创建WBS过程的事业环境因素包括：
  • 项目所在行业的WBS标准这些标准可以作为创建WBS的外部参考资料

组织过程资产

• 能够影响创建WBS过程的组织过程资产包括：
  • 用于创建建WBS的政策、程序和模板
  • 以往项目的项目档案
  • 以往项目的经验教训

2. 工具与技术

分解

• 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；
• (工作包重要性)工作包是WBS最低层的工作,可对其成本和持续时间进行估算和管理(工作包是WBS的最底层元素,在规划进度和成本的时候,可以对工作包的成本或者每个工作包的持续时间,进行估算和管理,工作包的重要性,其实就是为什么要分解成工作包,在进度管理有一个过程叫定义活动,它会把因为工作包是要做什么,是名词如何去做把工作包再分解成活动.
  项目管理进行估算和管理的最小单位,不应该答工作包,应该答活动)

WBS分解到什么程度？

• WBS分解的程度没有统一规定，取决于所需的控制程度，以实现对项目的高效管理

  • 工作分解得越细致，对工作的规划、管理和控制就越有力
  • 过细的分解会造成管理的无效耗费、资源利用率和工作效率降低，同时造成数据汇总困难

• 80小时原则

解析

• 针对项目把WBS分解到什么程度比较合适,没有什么规定,只是一个建议到底分解到什么程度,如果分解的特别细,就WBS把每个工作包分解得非常细腻,那可能好处是未来进行管理可以对每个工作包或者整个项目进行精细化的管理,但是很可能带来的缺点更大,管理代价太大了,每个工作包细致到每个小时完成的工作,每个小时的工作都要进行监控,进行管理,代价太大,实际上到底分解到什么程度,需要做一个权衡,一般来讲正常规模的项目,一般说工作包,每个工作包由一个人或一个团队成员或者一个团队在80小时之内完成,是比较合适的,力度也别太大,别太小80个小时,实际上就是两个星期.

WBS分解依据？(了解)

• 按内容分解
• 按子系统、子项目分解
• 按模块分解
• 按生命周期各阶段分解
• 按地理位置分解
• 按组织单元分解

想对一个项目做分解,用你期望的那种分解方式或者手段做第二层分解就可以了.

分解到工作包的WBS示例

• WBS仅为了说明之用。它无意代表任何特定项目的整体项目范围，也不意味着这是对此类项目组织工作分解结构的唯一方法

以阶段作为第二层WBS示例

• WBS仅为了说明之用。它无意代表任何特定项目的整体项目范围，也不意味着这是对此类项目组织工作分解结构的唯一方法

以主要可交付成果作为第二层的WBS示例

• WBS仅为了说明之用。它无意代表任何特定项目的整体项目范围也不意味着这是对此类项目组织工作分解结构的唯一方法

解析说明

• 教程里给出来的WBS都是树形的结构或者叫层次结构,所有项目必然有WBS,包括你接触过的项目,但是发现好像没见过这种WBS,实际生产中的项目,工作中的项目,WBS实际上都是以列表的形式,以Excel表格或者pdf形式存在,工作包太多了,比如,一个项目里最后有200个工作包,不可能用这种层级结构底层化200个工作包,所以实际工作中为了展现这么多的工作包,都是一行一行的画.

列子实际

飞机系统
项目管理	系统工程管理	支持项目经理活动
培训	设别培训	设施培训	服务培训
数据	技术指令	工程数据	管理数据
航空器	机身	发动机	通信系统	导航系统	消防系统
支持设备	组织层SE	中间层SE	站务层SE
设置	基地建筑	维护设施
测试与评估	实体模型	运转测试	开发测试	测试

分解WBS注意事项

• ① WBS 必须是面向可交付成果的
• ② WBS 必须符合项目的范围
• ③ WBS 的底层应该支持计划和控制
• ④ WBS 中的元素必须有人负责，而且只有一个人负责
• ⑤ WBS 应控制在4--6层
• ⑥ WBS 应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作
• ⑦ WBS 的编制需要所有（主要）项目干系人的参与
• ⑧ WBS 并非是一成不变的(连需求都不是一成不变的,而是渐进明细的,所以WBS必然也会不断的渐进明细.在规划阶段,不是所有内容都能分解成工作包的,有很多东西不了解信息没法分解,所以停留在规划包这个层级,未来再分解,就是规划包.)

滚动式规划/100%规则

解析

• 概念描述: 图片所示,一年的项目要做很多事情,但是不可能直接看到12个月之后具体的每一个细节怎么做,所以就是假如明天就开始执行项目,第一个月就开始了,怎么样把第一个月的要做的工作细化一下详细分解,第一个月结束了再把第二个月的内容开始细化等,就是直到当前的时间要到了,再把最近的这个工作进行细化,远期的留到一个粗略的层级就行,这种手段就叫滚动式规划.
  
• 滚动式规划实际上就是强调的是WBS并非一成不变.
• 100%就是分解出的WBS,应该是在项目范围的基础之上,把范围逐渐的分解,就是不能比范围多了,也不能少了,只不过是细化了,换句话说,最后分解出来的WBS,把底层工作包的内容合到一块不多不少,正好是项目的范围,100%规则就是不多余不遗漏.
• 100%规则实际上体现的就是WBS必须符合项目的范围.

3. 输出

范围基准

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

解析

• 背记上图三个基准
• 项目范围说明书 : 范围说明书是上一个过程,就是定义范围的过程的输出
• WBS : 创建WBS之后显然要形成第二个WBS,WBS只是一个层级结构,就是它很清晰地把整个项目范围分解,最后到底层工作包,但是每一个中间元素或者每一个工作包的描述,那WBS肯定是没有,它是个图形,所以必然就是配合WBS,肯定有一个文字性的描述,这就是WBS词典.
• WBS 词典 : 一个文字性的描述

WBS详解

解析

• 控制账户是一个管理控制点(现在就是项目已经执行了一个月,领导说给我汇报一下项目情况,你跟领导说,我们的项目一共是有200个工作包,第一个工作包进度怎么样,成本怎么样,风险发生了多少等,第二个工作包你汇报了5个工作包,领导就不可能有耐心了,他说那你这么汇报你200个工作包,给我汇报半天可就死定了.)
  什么叫管理控制点呢
• 真正的项目管理者关心的应该是比工作包的层次再高一些阶段,或者比阶段低一些也行,反正不可能是工作包,但是也不一定,如果你这个工作包设置的特别大,也可以把工作包作为控制账户,但是一般不这样.
• 控制账户这这个图形上,它是比工作包层次更高一些,其实生产环境下,很多情况下直接把阶段这把阶段做成控制账户,它是一个管理控制点,然后在每一个控制账户位置向领导汇报(比如领导说你汇报一下这个情况,你说我项目启动阶段这个月正好完成了,应该预计花费25万,结果花费了23.5万等然后没有了,我们下个月准备进入第二个规划阶段,按领导一听这个太简洁了,就是你把阶段作为控制账户了,这样的话,进行这个管理或者高层汇报就是特别方便,如果是特别小型的项目,整个项目就做一个控制账户也可以,到底在哪个位置设定控制账户是由项目经理决定.).
• 规划包它是一种低于控制账户,而高于工作包的WBS组成部分,因为详细的细节不知道,所以未来才可以,或者可能把规划包分解成工作包.

WBS词典

• WBS词典是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件，WBS词典对WBS提供支持.

• WBS词典内容(包括每个WBS的组成信息):

  • 账户编码标识
  • 工作描述
  • 假设条件和制约因素
  • 负责的组织
  • 进度里程碑
  • 相关的进度活动
  • 所需资源
  • 成本估算
  • 质量要求
  • 验收标准
  • 技术参考文献
  • 协议信息

• 提示 ：WBS词典是渐进明细的，最初只有少部分内容，大部分信息在后期添加到词典中.(刚开始分解WBS的时候,可能只有关于前四项(账户编码标识,工作描述,假设条件和制约因素,负责的组织)内容,随着项目进展(比如每个工作包或者下面的活动,已经估算出进度成本了等),那可以把新的信息减回到这个WBS词典,所以这个文件渐进明细.)

项目文件更新

• 随同本过程识别出更多的假设条件或制约因素而更新假设日志需求文件

• 可以更新需求文件，以反映在本过程提出并已被批准的变更

核心知识整理

• 所有的项目都必须有WBS，WBS是以可交付成果为导向的工作层级分解

• WBS只包含项目范围内的工作，不包含项目范围以外的工作

• “ 工作 ” 是经努力取得的成果，是名词，而非 “ 努力 ” 本身

• WBS可按内容、时间、地点和其他方式进行分解

• 控制账户则是一个管理控制点，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效

• 工作包位于WBS的最底层，每个工作包带有唯一的账户编号

• 规划包低于控制账户而高于工作包，未来会分解为工作包

9.7 确认范围(其实是验收)

• 确认范围不是确认一下分解的WBS是不是分解的合理,是不是涵盖了项目的范围,确认范围针对的不是范围规划的结果,针对的是可交付结果,实际上就是WBS形成之后,下一步就开始规划进度,规划成本,规划资源等,开始执行之后,交付的可交付成果再进行确认范围,所以确认范围其实就是验收,验收到什么样的可交互成果,即为本章内容.

1. 课程目标

• 掌握确认范围过程的定义与活动

• 熟悉确认范围过程的输入、工具与技术及输出的内容

• 了解检查这一工具

• 能区分核实的可交付成果和验收的可交付成果

• 能够区分确认范围、控制质量这两个过程

2. 过程定义 : 确认范围

定义

• 正式验收已完成的项目可交付成果

作用

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

时机

• 仅开展一次或仅在项目的预定义点开展

解析

• 参与人员 : 就是谁参与确认范围.
• 确认时机 : 什么时候来进行确认范围.
• 所做工作 : 确认范围要做哪几个活动或者工作.

确认范围的参与人员

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

(结论(需要被))提示：确认范围的主要参与者是客户和发起人，由项目经理协助.

确认范围的时机

• 应贯穿于整个项目生命周期中，建议越早越好。最晚要在项目快结束或每个阶段末期进行

• 假如把所有可交付成果的验收都放在收尾阶段去做，则一旦出现问题时，不能正常收尾的风险极大！(整个12个月的项目,本来前面好多内容都已经开发完成了,结果拖来拖去之后到12月份,才请客户方验收所有的模块,只要有一个模块验收出现问题,那整个项目必然拖延.
  确认范围或者验收这件事是在监控过程组,监控过程不是一个收尾过程,到收尾阶段验收应该已经完成了,对总交付的验收应该早已经完成了.
  假如把所有可交付成果的验收都放在收尾阶段,一旦出现问题,那失败的风险极大,除非跟客户这个关系比较好,不然真的风险极大.)

确认范围所做的工作

• 项目干系人进行范围确认时，需要检查以下6个方面的问题(了解)：
  • 可交付成果是否是确定的、可确认的。
  • 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
  • 是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。
  • 审核和承诺是否有清晰的表达：项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须清晰，并取得一致的同意。
  • 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
  • 项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响

干系人关注点的不同

• 注意在项目里任何一个时间点都得注意不同的人对项目啊关注点不一样,不同干系人利益不一样,位置决定了最后态度.

• 确认范围主要是项目干系人对项目范围所关注的方面是不同的 ：

解析

• 管理层 ( 指项目组织的领导 ) : 项目别超支了,进度别超过期限了.
• 客户 : 产品范围的功能或者非功能是否符合要求,如果有可能的话最好再多加一点功能该多好,客户如果有这种想法相反对项目组可能是有危害的.
• 项目管理人员 ( 就是项目经理 ) : 制约因素就是管理层为项目划定的底线,例如:进度必须6个月完成,成本必须少于50万.
• 项目团队成员 : 每个团队成员都很窄,手头要完成工作,范围中和自己参与的那些内容相关的那小部分,项目里成员的工作完成的怎么样,是不是和其他工作有冲突等.

3.数据流向图

解析

• 它的最重要的输入叫核实的可交付成果,本来指导于管理项目工作,执行的时候产生可交付成果了,可交互成果要交给控制质量,这个过程是组织内部或者团队内部测试人员经过测试,得到符合质量需求的可交互成果,把这个可交付成果变成了核实的可交付成果,经过内部核实之后,才能交给谁客户或者发起人,确认范围,确认范围就是把核实的可交付成果变成了验收的可交付成国,所以确认范围就是在做验收.确认范围作为一个监控的子过程,也是子的监控过程,都是把工作绩效数据,实事求是的数据变成了工作绩效信息.

4.ITTO

1. 输入

项目管理计划

• 项目管理计划组件包括：

  • 范围管理计划 ：项目管理计划定义了如何正式验收已经完成的可交付成果
  • 需求管理计划 ：需求管理计划描述了如何确认项目需求
  • 范围基准 ：用范围基准与实际结果比较以决定是否有必要进行变更、采取纠正措施或预防措施

项目文件

• 经验教训登记册 ：在项目早期获得的经验教训可以运用到后期阶段，以提高验收的效率与效果

• 质量报 告：质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述

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

• 需求跟踪矩阵：需求跟踪矩阵含有与需求相关的信息，包括如何确认需求

核实的可交付成果、工作绩效数据

2. 工具与技术

检查

• 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准 (检查其实很简单,检查是一个非常宽泛的工具和技术,只要是开展测量,审查和确认等活动,检查就是验收的最重要的一个工具, 其判断可交付成果是不是符合需求标准或者验收标准,这个叫检查.
  产品类别不一样检查的称呼也不一样,可以叫审查(就是审查项目管理计划),可以叫产品审查(如果可交付成果是一个具体的有形的产品),也可以叫审计巡检,那如果可交付成果是一段代码/一段程序.检查就可以是黑盒白盒测试等.)

决策

• 可用于本过程的决策技术主要是投票。当由项目团队和其他干系人进行验收时，使用投票来形成结论.(决定一下,可交付物是否通过验收.)

提示 : 检查有时也被称为审查、产品审查、审计和巡检等

3.输出

验收的可交付成果

• 符合验收标准的可交付成果应该由客户或发起人正式签字批准应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程

解析

• 在确认范围的时候,如果通过验收,可交付成果直接进行记录,转给收尾阶段,如果没有通过验收,除了要记录没有通过的原因之外,还要转入实施整体变更控制这个过程,假如现在对这个可交付成果进行验收或者确认范围,发现不符合需求,提变更.变更有4类:预防措施/纠正措施/缺陷补救/更新,确认范围环节里的变更是最不好的一种缺陷补救,因为确认范围针对的就是可交付成果,可交付成果出问题了,所以对可交付成果提的变更,就是缺陷补救.

概念对比：核实的可交付成果Vs验收的可交付成果

核实的可交互成果和验收的可交互成果之间的区别

• 整体来讲核实的可交付成果是由控制质量过程完成的输出,确认范围过程如果验收通过了,会变成验收的可交付成果,可交付成果是一个东西,他经过不同的阶段或者处理叫法不一样.

工作绩效信息

• 工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收哪些未通过验收以及原因。这些信息应该被记录下来并传递给干系人

变更请求

• 对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。变更请求应该由实施整体变更控制过程进行审查与处理.(确认范围一旦验收失败,就会提出缺陷补救的变更请求.)

项目文件更新

• 经验教训登记册 ：更新经验教训登记册以记录所遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法需求文件 ：记录实际的验收结果，更新需求文件需求跟踪矩阵：根据验收结果更新需求跟踪矩阵

概念对比：确认范围Vs控制质量（复习阶段必须掌握--背记理解）

5.核心知识整理

• 确认范围考察的是项目可交付成果的可接受性，其结果是对可交付成果的正式验收
• 确认范围需要客户和发起人参与，越早进行越好，最晚在每个阶段结束时进行验收的可交付成果是符合
• 验收的可交付成果是符合验收标准并得到客户或发起人正式签字批准的可交付成果
• 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求
• 控制质量过程通常先于确认范围过程，但二者也可同时进行

9.8 控制范围

• 整个范围知识领域的第六个过程,处于监控过程中.

1. 课程目标

• 掌握控制范围过程的定义与活动
• 区分范围蔓延和镀金的含义
• 熟悉控制范围过程的输入、工具与技术及输出的内容
• 熟悉偏差分析这一技术工具
• 掌握工作绩效信息及变更请求内容

2. 过程定义 ：控制范围

定义

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

作用

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

时机

• 在整个项目期间开展(几乎所有监控过程都是在项目生命周期里边随时展开)

3.数据流向图

解析

• 工作绩效信息指导于管理项目工作,产生工作绩效数据(数据可以认为就是针对于范围方面的工作绩效数据),经过你项目经理把这个范围的数据跟跟范围基准相比,使用偏差分析技术把比较结果或者偏差记录下来,那形成工作绩效这信息,把数据变成信息了.

4.ITTO

• 偏差分析/趋势分析,工作绩效信息和变更请求而已

  非常重要的考点:控制范围从项目生命周期的角度讲,从项目开始到结束,监控一下范围就是别多做了别少做了?

  • 那如果有范围变更的话,引入整体变更控制流程,关于多做少做这件事,其实控制范围过程根本就不关心是否会范围会少做,会遗漏,不太可能遗漏,因为范围这件事有两个角度,就是一个是收集需求的时候有一个输出叫需求跟踪矩阵,去查看需求跟踪矩阵,哪个需求提出来之后,是不是进行对应到WBS了,是不是进行总体设计,详细设计,编码测试,一眼就看出来哪些需求没实现,所以不太可能遗漏.另外一个角度,创建WBS不是有工作包,看那个工作包列表,最后每个工作包是否完成了,遗漏是很少出现的,怕多做范围,所以控制范围的重点就是防止多做.

基本概念：范围蔓延

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

变更与蔓延辨析

• 有一种情况就是外界环境变化太快,客户经常的就是提变更请求,修改或者追加范围,但是每一个变更请求都由团队进行书面记录,并且都提交给CAB进行这个评估,CAB都同意了,项目变更,客户经常会这样,这都不算范围蔓延,因为这些变更都是走了整体变更控制流程.
• 注意未经过控制的范围扩大才叫范围蔓延,实际上,本质就是范围方面变更失控了,所以会导致就是很多不好的现象.(比如:工期延误,成本超支,质量下降等.)
• 过去很久以前有一种说法就是项目最后拖拖拉拉的变成了胡子工程,就是不太喜欢修理自己,修剪自己的乱糟糟的那个胡子工程指的就是这种情况.(范围蔓延不断的产生,拖延工期延误)

基本概念 ：镀金

• 镀金（Gold Plating）一般指项目团队主动为客户或发起人多做点超出范围定义的事情，即主动增加额外的工作而得不到任何经济补偿的行为.

提示 : 无论是范围蔓延还是镀金，都是项目管理过程中要避免的！

解析

• 实际上镀金就是一种范围蔓延,范围蔓延主要是针对客户方提出来这些需求(比如:他绕过了项目经理,绕过了CCB,直接打电话给负责开发的团队成员,说要加一个功能,团队成员没有经过提变更请求,直接就执行了,他认为就是对进度,对成本没什么影响,但实际上很可能有影响,叫范围蔓延)
• 一种特殊的范围蔓延叫镀金,用五个字形容镀金,就是多做无报酬.
• 无论是项目范围还是镀金,都是项目管理过程中要避免的,从项目管理角度讲二者都是属于项目失败,
• 看问题角度是多种多样的,从一个角度看是坏事,说不定从别的角度看是好事,比如:生产环境下,帮客户做某个产品,某个软件,结果发现客户当初的一个需求提的不是特别合适,稍微修改一下.
• 比如:就是整个界面,界面里边有各种后台的功能只需要就是花费一点点精力,在界面里加一个取消按钮,这样的话用户使用起来就特别方便,一下就退出界面了,不用一步一步回退,多浪费时间,客户看到加这么一个退出按钮特别高兴,一下就节省了10分钟的时间来表扬你,就是急客户之所急,想客户之所想,今后所有的项目都让这个团队开发,从这个角度讲项目是成功的,但如果从项目管理角度讲这是项目失败,因为做了镀金,包括很多企业一个宗旨,一听从项目管理就是镀金,就是超越客户需求,实际上客户不需要超越,只要满足客户需求就可以了.
• 比如:海底捞本来是个餐饮企业,保证大家吃得好喝得好就行,结果他非得派员工跳科目三,非得在门口摆桌子给客户进行美甲,从餐饮角度讲,就是镀金了.

1. 输入

项目管理计划

• 与本过程相关的项目管理计划组件包括：

  • 范围管理计划：记录了如何控制项目和产品范围
  • 需求管理计划：记录了如何管理项目需求
  • 变更管理计划：定义了管理项目变更的过程
  • 配置管理计划：定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程
  • 范围基准：用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施
  • 绩效测量基准：使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施

项目文件

• 经验教训登记册：项目早期获得的经验教训可以运用到后期阶段，以改进范围控制

• 需求文件：用于发现对商定的项目或产品范围的偏离

• 需求跟踪矩阵：有助于探查任何变更或对范围基准的任何偏离对项目目标的影响还可以提供受控需求的状态

工作绩效数据

• 工作绩效数据可能包括收到的变更请求的数量、接受的变更请求的数量，以及核实、确认和完成的可交付成果的数量

组织过程资产

• 现有的、正式和非正式的与范围控制相关的政策、程序和指南

• 可用的监督和报告的方法与模板

2. 工具与技术

数据分析

• 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作，要借助于数据分析技术来实现

偏差分析

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

趋势分析

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

3. 输出

工作绩效信息

• 本过程产生的工作绩效信息是有关项目范围实施情况的、相互关联且与各种背景相结合的信息，这些信息是与范围基准进行了对照比较

变更请求

• 分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求

项目管理计划更新

• 与本过程可能需要更新的项目管理计划组成部分包括：
  • 范围管理计划：可以更新范围管理计划，以反映范围管理方式的变更
  • 范围基准：在针对范围、范围说明书、WBS或WBS词典的变更获得批准后，需要对范围基准做出相应的变更
  • 进度基准：在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更
  • 成本基准：在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更
  • 绩效测量基准：在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更

提示 : 如果项目管理计划中的某个基准偏差太过严重，则需要重新修订该基准

项目文件更新

• 可在本过程更新的项目文件包括：
  • 经验教训登记册：更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施
  • 需求文件：可以通过增加或修改需求而更新需求文件
  • 需求跟踪矩阵：应该随同需求文件的更新而更新需求跟踪矩阵

5.核心知识整理

• 所有范围变更请求需要由实施整体变更控制过程来审查和处理

• 如果变更较大，有可能要开始一个新项目或新合同

• 未得到控制的变更通常称为项目范围蔓延

• 镀金是指项目团队超出范围定义，主动增加额外的工作而得不到任何经济补偿的行为

• 坚决防止范围蔓延或镀金

• 要防止范围镀金和范围蔓延，在变更未获得批准前，不做项目范围之外的工作

总结

• 范围管理六个过程:其中有四个是在规划过程组,先规划范围管理,然后收集需求,定义范围,创建WBS,然后有两个过程是在监控过程组,就是确认范围(实际上是对可交付成果的验收控制范围,是在全生命周期,不允许范围多做或者少做,如果是范围要求有变更的话,要严格的走整体变更控制流程)

单词

序号	单词	简写	翻译	描述
1	business		商业分析师	涉及考试PBA
2	Gold Plating		镀金
3	Work Breakdown Structure	WBS	工作分解结构