【PMP学习笔记】5.项目范围管理

5.项目范围管理5.1规划范围管理5.2收集需求★5.3定义范围5.4创建WBS（工作分解结构）5.5确认范围5.6控制范围

5.项目范围管理

做范围管理的目的：做且只做所需的全部工作

产品范围 VS 项目范围 产品范围：成果所具有的特性和功能（APP的功能） 项目范围：为了交付成果而必须完成的所有工作（为了完成这个APP所做的工作）。产品范围侧重结果，项目范围侧重过程；

原则：确认范围、控制范围、监测范围、范围围绕需求展开

新兴实践：敏捷方法

5.1规划范围管理

定义：创建范围管理计划,书面描述将如何定义、确认和控制项目范围

内容：在整个项目中对如何管理范围提供规范和指导性文件

输出：需求管理计划、范围管理计划

image-20211121133349897

输入：项目章程；项目管理计划：质量管理计划

工具与技术：数据分析：备选方案分析

输出：范围管理计划、需求管理计划

• 范围管理计划：定义如何开展范围的工作

• 需求管理计划：如何开展需求的工作

5.2收集需求★

定义：为实现项目目标而确定、记录并管理相关方的需要和需求“需求的文档化”

内容：为定义和管理项目范围(包括产品范围)奠定基础

输出：需求文件、需求跟踪矩阵★

image-20211121133417174

输入：项目章程；商业文件：商业论证；协议；相关方登记册（记录人以及他们的需求、期望）；

工具与技术：数据收集：头脑风暴、访谈、焦点小组、问卷调查、标杆对照；数据分析：文件分析；决策：投票、德尔菲、独裁型决策、多标准决策分析；数据表现：亲和图、思维导图；人际关系与团队技能：名义小组技术、观察/交谈、引导 ；系统交互图；原型法

• 头脑风暴：发散思维，提创意。

• 访谈：一对一 或 一对多面谈，打电话也是；

• 问卷调查：给一个表，让用户填；使用场景★★：相关方众多，地理位置分散；适合开展数据统计，快速完成数据收集；

• 标杆对照：抄 比如做一个通讯软件，对照微信，看看哪些功能好，抄过来。

• 文件分析：从文件中分析用户需求

• 投票：三个原则：一致同意；大多数同意：50%以上；相对多数同意；

• 德尔菲：匿名(背靠背)的一种技术；避免专家与专家之产生影响，避免因别人的身份，影响到自己的判断；

• 多标准决策分析：多个维度来考虑；

• 亲和图：就是做分组、分类

• 思维导图：从一个点发散思维，对提出的创意做图形化的整理，细化，以便于做进一步分析；

• 名义小组技术：将收集到需求做排序，将最有用的创意拿出来，进一步开展头脑风暴或优先排序；

• 观察/交谈：(不愿说、不能说、说不清)用户无法表达清楚自己的需求，我们可以自己看，看用户怎么工作（也叫工作跟踪），记录下来，再与用户交谈

• 引导★★：跨职能用户在自己的立场上提需求，引导所有用户针对某一功能形成一致认可的结论；会议：引导式研讨会 ；

1. 联合应用开发JAD★：由用户与项目开发团队一起，定义、分析、管理、排序需求，决定要做什么东西；

2. 质量功能展开QFD:将用户需求转化为数字，根据数字进行排序；

3. 用户故事（敏捷）：简单理解为需求；角色，目标，价值；

• 系统交互图：各个系统之间是怎么交互的，系统与人又是怎么交互的。

• 原型法：趋近于敏捷，用户对自己的需求不是很清楚，可以做一个Demo,画一个原型，让用户体验，帮助用户提炼自己的需求。（比如找别人装修房子，都是先做一个设计图，让你看看是不是这样的做。）使用场景：适合迭代项目；

输出：需求文件、需求跟踪矩阵★

对需求做分类，有哪些类型（包括但不限于）：

• 业务需求

• 相关方需求

• 解决方案需求： 功能需求、非功能需求

需求跟踪矩阵RTM：★

• 需求溯源：1、往前追溯：从哪儿来，最早的需求评估（商业论证前的那个需求评估），是不是和业务目标相符合；往后追溯：这个需求有没有开发、有没测试、有没有验收、有没有移交；2、确保每个需求都具有商业价值；3、对需求的优先级进行排序；4、需求的可行性；

• 考点：验收时有个功能不符合业务需求、漏了、没有实现，PM应该拿出需求跟踪矩阵看看。

5.3定义范围

重点： 输出：项目范围说明书的内容★（哪些需求是项目内的，哪些需求是项目外的）

image-20211121133530689

输入：工具与技术：产品分析

• 产品分析：就是分析当前做的这个产品到底有没有价值，它的价值最终体现在哪里?

输出：项目范围说明书★

• 项目范围说明书 内容：（核心考点：背）

• 项目范围描述（渐近明细）：是要开展的工作

• 项目可交付成果

• 验收标准

• 项目排除项（除外责任）：把不做的那些，都写到这里

• 项目产品范围：是产品具体的特性

• 假设条件

• 制约因素

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

定义：就是对可交付成果和项目工作做分解

输出：WBS+WBS字典+范围说明书（定义范围的输出）=范围基准

image-20211121133553152

输入：

工具与技术：分解

• 分解：1、相关方尽可能参与，谁来分解：团队成员（谁熟悉，谁来做分解，这样可行性才高）；2、工作包是最底层的工作组件（没必要再细分、工作包的详细程度根据具体项目来定）；3、至上而下的分解；4、WBS包含了全部的产品和项目工作

• 分解实例：1、可以以项目生命周期的各阶段作为第二层；2、也可以以主要可交付成果作为分解的第二层

• CA控制帐户：绩效审查点；

输出：范围基准★

• WBS: 控制帐户（可能包括一个或多个工作包）、工作包（但是一个工作包只能属于一个控制帐户）、规划包（未来很长一段时间后要做的工作）；

• WBS也是一个渐近明细的工作，近期的工作详细分解，远期的工作先放着。

• WBS是基于范围说明书来的

• WBS词典：就是对WBS做解释和说明（让别人可以看懂WBS）；（解释工作包的内容：谁负责、什么时间完成、怎么验收、发多少成本、要达到什么质量要求、验收标准）

• 项目范围说明书

范围哪里来的？-->商业文件、项目章程、需求文档、WBS、WBS词典、项目范围说明书

CA--->绩效（成本+进度）

5.5确认范围

定义：就是在做验收，验收项目可交付成果

输出：验收的可交付成果★

确认范围的说明：

• 时间：QC内部检验后，项目收尾前

• 人物：★ 客户 或 发起人

• 事件：★ 获得客户或发起人的正式验收（书面签字批准）

image-20211121133632367

输入：核实的可交付成果★

工具与技术：检查、决策（投票）

• 检查：检查可交付成果（范围基准）（工作有没有开展完、可交付成果是不是满足需求）

输出：验收的可交付成果★、工作绩效信息、变更请求

• 验收的可交付成果：给你一个清单，逐一确认签字

• 工作绩效信息：工作绩效数据和计划进行比较 形成 工作绩效信息

• 变更请求：有问题发起变更（验收过程中出现问题，要改，这个时候用的是缺陷补救）

5.6控制范围

主要做的事：维护/管理范围基准的变更；防止项目范围潜变(蔓延)

1、不能做的：

• 范围镀金：项目成员自行添加，想提升客户满意度。

• 范围蔓延：客户提出变更需求，但我们没有遵守变更控制系统，直接进行修改。

2、如果做了怎么办？

• 范围镀金 立即停止 走流程 写申请 是否涉及基准

• 范围蔓延 不能立即停止 先写审批 如果否决再停止

范围控制在整个项目过程随时开展

image-20211121133652491

控制过程有一些常规的输入、输出：就是输入工作绩效数据，输出工作绩效信息。

输入：工作绩效数据

工具与技术：数据分析（偏差分析、趋势分析）

输出：工作绩效信息、变更请求