5.项目范围管理5.1规划范围管理5.2收集需求★5.3定义范围5.4创建WBS（工作分解结构）5.5确认范围5.6控制范围
5.项目范围管理
做范围管理的目的：做且只做所需的全部工作
产品范围 VS 项目范围 产品范围：成果所具有的特性和功能（APP的功能） 项目范围：为了交付成果而必须完成的所有工作（为了完成这个APP所做的工作）。产品范围侧重结果，项目范围侧重过程；
原则：确认范围、控制范围、监测范围、范围围绕需求展开
新兴实践：敏捷方法
5.1规划范围管理
定义：创建范围管理计划,书面描述将如何定义、确认和控制项目范围
内容：在整个项目中对如何管理范围提供规范和指导性文件
输出：需求管理计划、范围管理计划
输入：项目章程；项目管理计划：质量管理计划
工具与技术：数据分析：备选方案分析
输出：范围管理计划、需求管理计划
范围管理计划：定义如何开展范围的工作
需求管理计划：如何开展需求的工作
5.2收集需求★
定义：为实现项目目标而确定、记录并管理相关方的需要和需求“需求的文档化”
内容：为定义和管理项目范围(包括产品范围)奠定基础
输出：需求文件、需求跟踪矩阵★
输入：项目章程；商业文件：商业论证；协议；相关方登记册（记录人以及他们的需求、期望）；
工具与技术：数据收集：头脑风暴、访谈、焦点小组、问卷调查、标杆对照；数据分析：文件分析；决策：投票、德尔菲、独裁型决策、多标准决策分析；数据表现：亲和图、思维导图；人际关系与团队技能：名义小组技术、观察/交谈、引导 ；系统交互图；原型法
头脑风暴：发散思维，提创意。
访谈：一对一 或 一对多面谈，打电话也是；
问卷调查：给一个表，让用户填；使用场景★★：相关方众多，地理位置分散；适合开展数据统计，快速完成数据收集；
标杆对照：抄 比如做一个通讯软件，对照微信，看看哪些功能好，抄过来。
文件分析：从文件中分析用户需求
投票：三个原则：一致同意；大多数同意：50%以上；相对多数同意；
德尔菲：匿名(背靠背)的一种技术；避免专家与专家之产生影响，避免因别人的身份，影响到自己的判断；
多标准决策分析：多个维度来考虑；
亲和图：就是做分组、分类
思维导图：从一个点发散思维，对提出的创意做图形化的整理，细化，以便于做进一步分析；
名义小组技术：将收集到需求做排序，将最有用的创意拿出来，进一步开展头脑风暴或优先排序；
观察/交谈：(不愿说、不能说、说不清)用户无法表达清楚自己的需求，我们可以自己看，看用户怎么工作（也叫工作跟踪），记录下来，再与用户交谈
引导★★：跨职能用户在自己的立场上提需求，引导所有用户针对某一功能形成一致认可的结论；会议：引导式研讨会 ；
联合应用开发JAD★：由用户与项目开发团队一起，定义、分析、管理、排序需求，决定要做什么东西；
质量功能展开QFD:将用户需求转化为数字，根据数字进行排序；
用户故事（敏捷）：简单理解为需求；角色，目标，价值；
系统交互图：各个系统之间是怎么交互的，系统与人又是怎么交互的。
原型法：趋近于敏捷，用户对自己的需求不是很清楚，可以做一个Demo,画一个原型，让用户体验，帮助用户提炼自己的需求。（比如找别人装修房子，都是先做一个设计图，让你看看是不是这样的做。）使用场景：适合迭代项目；
输出：需求文件、需求跟踪矩阵★
对需求做分类，有哪些类型（包括但不限于）：
业务需求
相关方需求
解决方案需求： 功能需求、非功能需求
需求跟踪矩阵RTM：★
需求溯源：1、往前追溯：从哪儿来，最早的需求评估（商业论证前的那个需求评估），是不是和业务目标相符合；往后追溯：这个需求有没有开发、有没测试、有没有验收、有没有移交；2、确保每个需求都具有商业价值；3、对需求的优先级进行排序；4、需求的可行性；
考点：验收时有个功能不符合业务需求、漏了、没有实现，PM应该拿出需求跟踪矩阵看看。
5.3定义范围
重点： 输出：项目范围说明书的内容★（哪些需求是项目内的，哪些需求是项目外的）
输入：工具与技术：产品分析
- 产品分析：就是分析当前做的这个产品到底有没有价值，它的价值最终体现在哪里?
输出：项目范围说明书★
项目范围说明书 内容：（核心考点：背）
项目范围描述（渐近明细）：是要开展的工作
项目可交付成果
验收标准
项目排除项（除外责任）：把不做的那些，都写到这里
项目产品范围：是产品具体的特性
假设条件
制约因素
5.4创建WBS（工作分解结构）
定义：就是对可交付成果和项目工作做分解
输出：WBS+WBS字典+范围说明书（定义范围的输出）=范围基准
输入：
工具与技术：分解
分解：1、相关方尽可能参与，谁来分解：团队成员（谁熟悉，谁来做分解，这样可行性才高）；2、工作包是最底层的工作组件（没必要再细分、工作包的详细程度根据具体项目来定）；3、至上而下的分解；4、WBS包含了全部的产品和项目工作
分解实例：1、可以以项目生命周期的各阶段作为第二层；2、也可以以主要可交付成果作为分解的第二层
CA控制帐户：绩效审查点；
输出：范围基准★
WBS: 控制帐户（可能包括一个或多个工作包）、工作包（但是一个工作包只能属于一个控制帐户）、规划包（未来很长一段时间后要做的工作）；
WBS也是一个渐近明细的工作，近期的工作详细分解，远期的工作先放着。
WBS是基于范围说明书来的
WBS词典：就是对WBS做解释和说明（让别人可以看懂WBS）；（解释工作包的内容：谁负责、什么时间完成、怎么验收、发多少成本、要达到什么质量要求、验收标准）
项目范围说明书
范围哪里来的？-->商业文件、项目章程、需求文档、WBS、WBS词典、项目范围说明书
CA--->绩效（成本+进度）
5.5确认范围
定义：就是在做验收，验收项目可交付成果
输出：验收的可交付成果★
确认范围的说明：
时间：QC内部检验后，项目收尾前
人物：★ 客户 或 发起人
事件：★ 获得客户或发起人的正式验收（书面签字批准）
输入：核实的可交付成果★
工具与技术：检查、决策（投票）
- 检查：检查可交付成果（范围基准）（工作有没有开展完、可交付成果是不是满足需求）
输出：验收的可交付成果★、工作绩效信息、变更请求
验收的可交付成果：给你一个清单，逐一确认签字
工作绩效信息：工作绩效数据和计划进行比较 形成 工作绩效信息
变更请求：有问题发起变更（验收过程中出现问题，要改，这个时候用的是缺陷补救）
5.6控制范围
主要做的事：维护/管理范围基准的变更；防止项目范围潜变(蔓延)
1、不能做的：
范围镀金：项目成员自行添加，想提升客户满意度。
范围蔓延：客户提出变更需求，但我们没有遵守变更控制系统，直接进行修改。
2、如果做了怎么办？
范围镀金 立即停止 走流程 写申请 是否涉及基准
范围蔓延 不能立即停止 先写审批 如果否决再停止
范围控制在整个项目过程随时开展
控制过程有一些常规的输入、输出：就是输入工作绩效数据，输出工作绩效信息。
输入：工作绩效数据
工具与技术：数据分析（偏差分析、趋势分析）
输出：工作绩效信息、变更请求
