1、规划范围管理
通常都将项目范围管理成为项目的龙头，只有确定了范围，才可以去确定时间和成本。
产品范围 --- 产品句有的特征和功能。
项目范围 --- 为完成产品的特征和功能所需工作。
输入：
-
项目章程
-
项目管理计划
-
质量管理计划（质量标准的高低直接影响了项目工作量的多少）
-
项目生命周期描述（阶段划分也会影响后续创建WBS中规划包的设置）
-
开发方法（开发方法不同也会影响创建WBS的工作）
-
工具：
-
专家判断
-
数据分析
-
会议
输出：
-
范围管理计划（指导后续范围管理工作如何去做）
-
需求管理计划（如何去确定并实现需求）
2、收集需求
为实现目标而确定（找到需求）、记录（记录需求及特征）、并管理（给需求排序）相关方的需要和需求的过程。
要求所有相关方参与，收集到全部需求。
输入：
-
项目章程
-
项目管理计划
-
范围管理计划
-
需求管理计划（起到指导作用）
-
相关方参与计划
-
-
项目文件
-
假设日志
-
经验教训登记册
-
相关方登记册（相关方登记册中有相关方的联系方式，方便找到所有相关方提供需求； 而且也会记录一些在识别相关方时记录的需求和期望）
-
-
商业文件
-
协议（与客户签订的合同）
工具：
-
专家判断
-
数据收集
-
头脑风暴（产生多种（大量）创意）
-
访谈（通常一对一，也有多对多）
-
焦点小组（相关方和主题专家）
-
注：
-
焦点小组和引导的区别：
-
区别在于参与焦点小组的相关方来自同一职能部门，而引导是跨职能部门
-
-
问卷调查（受众多样化，地理位置分散）
-
标杆对照
-
-
数据分析
-
决策
-
投票
-
一致（不）同意（互不沟通，互不干扰） --- 德尔菲技术
-
大多数原则（通常人数=2）
-
相对多数原则（通常人数≥3）
-
-
独裁型决策制定
-
多标准决策分析（借助决策矩阵）（注：使用多标准决策分析对收集到的需求进行排序，为后续定义范围过程提供决策基础）
-
-
数据表现
-
亲和图（对大量创意进行分组）
-
思维导图（反应创意之间的共性、差异）
-
-
人际关系与团队技能
-
名义小组技术（投票排序最有用的创意）
-
注：亲和图与名义小组技术的区分：
-
名义小组--投票排序； 亲和图--分组分类
-
-
观察与交谈（观察也称为工作跟随）
-
引导
-
联合应用设计或开发（JAD）：软件开发行业，注重把业务主题专家和开发团队集中一起，收集需求和改进软件开发过程
-
质量功能展开（QFD）：制造行业，帮助确定新产品的关键特征
-
用户故事：简单文字描述，产生于需求研讨会
-
-
-
系统交互图
-
原型法
输出：
-
需求文件
-
需求跟踪矩阵（把产品需求从来源连接到能满足需求的可交付成果的一种表格）
3、定义范围
制定项目和产品详细描述的过程。
本过程主要作用：描述产品、服务或成果的边界和验收标准。（需要从需求文件中选取最终版本）
输入：
-
项目章程
-
项目管理计划（指导如何定义范围）
-
项目文件
-
假设日志
-
需求文件（提供挑选内容）
-
风险登记册（包含了可能影响项目范围的应对策略，如缩小或改变项目和产品范围，以规避或缓解风险）
-
工具：
-
专家判断
-
数据分析
-
决策
-
人际关系与团队技能（使用“引导”技能，使关键相关方就项目可交付成果以及项目和产品边界达成跨职能的共识）
-
产品分析（分析技术包括如下：）
-
产品分解
-
需求分析
-
系统分析
-
系统工程
-
价值分析
-
价值工程
-
输出：
-
项目范围说明书（对项目范围、主要可交付成果、假设条件、制约因素的描述）。内容包括：
-
产品范围描述
-
可交付成果
-
产品验收标准
-
项目的除外责任（有效管理相关方的期望）
-
-
项目文件更新
-
假设日志（制定项目章程过程第一次产生假设日志，但内容较少，本过程内容获得大量增加）
-
需求文件
-
需求跟踪矩阵（将确认在本项目中实现的需求做出记录，并在后续的执行和监控工作中进行跟踪，以确保都能够实现）
-
相关方登记册
-
其他知识点：
-
项目范围说明书需要获得关键相关方的审批
-
项目和产品详细描述：
-
确定某项工作是否属于本项目范围内，项目经理需要查询项目范围说明书
-
新人项目经理进入团队后，应手先了解项目和产品情况，需要查询项目范围说明书。（前提项目处于规划后期或执行阶段，如果项目处于早期或者启动阶段，通常查询项目章程）
-
-
产品验收标准
-
在后续控制质量和确认范围都会使用到项目范围说明书中的验收标准
-
客户想确认本项目中总共有几次验收，也查询项目范围说明书
-
如果客户对于项目范围说明书中的验收标准不太认可，需要向前去找客户提供的资料，比如协议中的意向书、合同等内容
-
4、创建WBS（简单可以理解为需求分解）
为什么设置该过程？
项目范围说明书中虽然已明确了项目和产品的描述，并确定了项目的准确边界。但在具体工作时，对于描述每个团队成员的理解会不一致，就会产生分歧甚至冲突。
所以需要提前将需要做的工作细化并达成一致有助于后续工作的顺利开展，一定程度上减少冲突的发生。（本过程也可以看作是一次简单的团队建设）
输入：
-
项目管理计划（定义了如何创建WBS）
-
项目文件
-
项目范围说明书
-
需求文件
-
工具：
-
专家判断
-
分解
-
80小时原则：每个工作包都要求由一个人或一个小组80小时完成（可以与适应性生命周期中每次迭代最短周期2-4周中的2周呼应）
-
100%原则：子要素之和等于母要素，不能在分解过程中增加或缺失一些工作
-
通常分解4-6层：在创建WBS过程中，分解工作包就认为“不可再分”（相对意义上的不可再分，后续定义活动还需要将工作包进一步分解为活动）
-
层次：最顶层是项目可交付成果，第二层可以是阶段或主要可交付结果，最底层为工作包
-
-
滚动式规划：要在未来远期才完成的可交付成果或组件，当前可能无法分解。（考试中，如果选项没有滚动式规划，可以找渐进明细性替代）
输出：
-
范围基准（经过批准）
-
项目范围说明书
-
WBS
-
工作包（带有独特标识的工作包）
-
规划包（工作内容已知，但详细进度活动未知的）。规划包的存在，就证明了该过程需要有滚动式规划这个工具。
-
WBS词典
-
-
项目文件更新
其他知识点：
控制账户（CA）：是一个管理控制点，式项目团队人为设定的，方便统计并主要应用于挣值管理。
-
每个控制账户拥有两个或更多工作包
-
每个工作包只与一个控制账户关联
-
每个工作包和控制账户都有唯一编码
5、确认范围（监控过程组）
确认范围是正式验收已完成的项目可交付成果的过程。
输入：
-
项目管理计划
-
范围管理计划（如何正式验收）
-
需求管理计划（如何确认项目需求）
-
范围基准（与实际结果比较）
-
-
项目文件
-
经验教训登记册
-
质量报告（过程验收或最终验收前，先确认以前是否出现过质量问题，是否已经得到解决）
-
需求文件（承诺的需求是否都实现，与之前定义的是否一致）
-
需求跟踪矩阵
-
-
核实的可交付成果（已完成，并被控制质量过程检查为正确）。经过内部验收通过的产品，放心送去客户验收
-
工作绩效报告
工具：
-
检查（确认范围，控制质量，控制采购三个过程组均使用到该工具）
-
决策
输出：
-
验收的可交付成果（正式签字批准）
-
工作绩效信息（如哪些可交付成果已被验收，哪些未通过验收以及原因）
-
变更请求（未通过验收的记录在案，提出变更请求，开展缺陷补救）
-
项目文件更新
其他知识点：
-
确认范围需掌握
-
确认范围通常由客户或发起人来做验收
-
确认范围一定要有客户或发起人的书面验收文件，强调有签字
-
不止在项目结束前需要确认范围，阶段末也需要由确认范围
-
-
确认范围和控制质量的区别
-
控制质量：团队内负责质量的团队成员实施；可以称为内部验收，通常关注可交付成果的正确性，合格性，也可以验收适用性（可以简单理解为内测）
-
确认范围：客户或发起人实施；可以称为外部验收，通常关注产品的适用性（可以简单理解为公测）
-
通常控制质量在前，特殊情况下，二者可同时进行
-
-
确认范围的时间节点
-
通常通过确认范围后，项目团队可以开始项目的收尾工作（无论是阶段收尾还是项目收尾），在确认范围阶段（或者称为验收阶段）是允许提出变更请求的。
-
6、控制范围
监督项目和产品的范围状态，管理范围基准变更的过程。
控制xx或者监督xx的过程，这些过程的主要工作都可以理解为去找到偏差并通过提出变更请求来解决偏差。
输入：
-
项目管理计划
-
范围管理计划
-
需求管理计划
-
变更管理计划
-
配置管理计划
-
范围基准
-
绩效测量基准
-
-
项目文件
-
经验教训登记册
-
需求文件
-
需求跟踪矩阵
-
-
工作绩效数据
工具：
-
数据分析
-
偏差分析（考虑多个变更请求或偏差造成的累积效应）
-
趋势分析
-
输出：
-
工作绩效信息
-
变更请求
-
项目管理计划更新
-
项目文件更新
其他知识点：
1、范围蔓延和镀金：
-
范围蔓延和镀金都是做了不在项目范围内的工作
-
镀金是范围蔓延的一种特例，只是为了区分特点单独列出来做比较
-
区别：
-
范围蔓延：属于团队外的相关方主动要求做范围外的工作。如何避免发生范围蔓延？建议使用变更管理而非沟通管理。
-
镀金：属于团队成员主动做范围外的工作。问：某个团队成员声称主动在不增加成本和时间的情况下给产品添加了功能，PM应该怎么做？通常建议按顺序去选择：
-
确认镀金是否存在
-
确认镀金是否对项目造成影响，补变更流程
-
-
177
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
