5.0范围管理包含的过程
确保项目做且只做成功完成项目所需的全部工作
定义和控制哪些工作包含在项目内，那些不包含在项目内
5.1 规划范围管理：书面描述如何定义/控制项目范围的过程
5.2 收集需求: 为实现项目目标而定义并记录相关方的需求的过程
5.3 定义范围：制定项目和产品详细描述的过程
5.4 创建WBS：将项目可交付成果和项目工作分解为较小的，更易于管理的组成部分的过程
5.5 确认范围：正式验收项目已完成的可交付成果的过程
5.6 控制范围：监督项目和产品的范围状态管理范围基准变更的过程
项目范围管理的核心概念
范围管理强调：不镀金，预防范围蔓延
产品范围，项目范围的概念和区别
产品范围：某项产品、服务或成果所具有的特性和功能，根据产品需求来衡量产品范围是否完成
项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。根据项目管理计划来衡量项目范围是否完成
项目范围管理的发展趋势和新兴实践
需求管理过程始于需要评估，而需要评估有可能始于项目组合规划，项目集规划或单个项目
注重与商业分析人士的合作，以便确定问题并识别商业需要
需求管理过成结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现和维持效益
项目经理与商业分析师之间应该是伙伴式合作关系
裁剪时需要考虑的因素
知识和需求管理、确认和控制、需求的稳定性、开发方法、治理
在敏捷和适应型环境中需要考虑的因素
敏捷方法特意在项目早期缩短定义和协商范围的时间，并未持续探索和明确范围而延迟创建相依过程的时间
敏捷方法有目的的构建和审查原型，并通过多次发布版本来明确需求
在敏捷方法中，把需求列入未完项（backlog）
5.1 规划项目管理
定义：记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划（及需求管理计划）的过程
作用：在整个项目期间对如何管理范围提供指南和方向
发生时间：本过程仅开展一次或仅在项目的预定义点开展
项目管理范围
输入
1，项目章程
2，项目管理计划
—质量管理计划
—项目生命周期描述
—开发方法
3，事业环境因素
4，组织过程资产
工具与技术
1，专家判断
2，数据分析
—备选方案分析
3，会议
输出
1，范围管理计划
描述将如何定义、制定、监督、控制和确认项目范围；项目管理计划有助于降低项目范围蔓延的风险
定义如何完成如下过程：
制定详细范围说明书
根据详细项目范围说明书创建WBS
确定如何审批和维护范围基准
正式验收完成的项目可交付成果
2，需求管理计划
记录如何分析、记录和管理需求；有组织称之为“商业分析计划”
定义如何完成如下过程
如何规划，跟踪和报告各种需求活动；
配置管理活动的要求
需求优先级排序
产品测量指标
列入跟踪矩阵的项
5.2 收集需求
定义：为实现目标而确定，记录并管理相关方得需要和需求得过程
作用：为定义和管理范围奠定基础
发生时间：仅开展一次或仅在项目得预定义点开展
让相关方积极参与需求得探索和分解工作，能直接促进项目成功；需求包括发起人，客户和其他相关方得已量化并记录下来得需要和期望
收集需求从项目一开始就开始进行（分析项目章程/相关方登记册/相关方管理计划中信息）；需求是工作分解机构，成本/进度/质量规划得基础
收集需求
输入：
1，项目章程
2，项目管理计划
3，项目文件
4，商业文件
5，协议
6，事业环境因素
7，组织过程资产
工具与技术：
1，专家判断
2，数据收集
—头脑风暴
自由发言，面对面交流；速度快，但容易受影响；本身不包括投票，排序，分类等过程；常与其他群体创新技术共同使用
常用技巧：不批评，不表扬；以量求质；尽量扩散；最后总结
—访谈
通常一对一，面对面交谈，也可以包括多个访谈者和/或多个被访者；肯能获取机密信息；计划/聆听/引导/总结/安排后续
—焦点小组
一定要有一个受过专业训练得主持人；引导，讨论；强调碰撞，比访谈更热烈；可分成不同小组和主题
—问卷调查
设计书面问题，向众多受访者快速收集信息；适用于：受众多样化，快速完成，地理位置分散，开展统计分析
—标杆对照
概念：实际项目实践与可比项目实践对比（两个项目）
适用范围：组织内部或外部，同一或不同领域
两个目的：识别最佳实践，为绩效考核提供基础
规划质量管理过程也用到了标杆对照
3，数据分析
—文件分析
分析文档，挖掘需求：文件分析需求：头脑风暴+焦点小组会议
可用于分析得文件包括：商业计划、市场文献、协议、建议邀请书、程序和法规文件、用例
4，决策
—投票
一致同意；大多数同意（超过50%，投票者为奇数）；相对多数同意
—多标准决策分析
5，数据表现
—亲和图
—思维导图
将放射性思考（头脑风暴得结果）图形化得方法；反应创意之间得共性和差异，激发新创意；以主题为中心开始，沿着不同分支进行思考；
应用于记忆、学习、思考等得思维“地图”，利于人脑的扩散思维的开展；常用的软件FreeMind/Mindmanager
6，人际关系和团队
—名义小组技术
名义小组技术是一种结构化的头脑风暴形式，由四步骤组成;
STEP1：向集体提出一个问题或难题，每个人在沉思后，写出自己的想法
STEP2：主持人在活动挂图上记录所有人的想法
STEP3：集体讨论各个想法，直到全体人员达成一个明确的共识
STEP4：个人私下投票决出各种想法的优先顺序，可进行数论讨论。每轮讨论后，都将清点选票，得分最高者被选出
—观察与交谈
难以说或者不愿意说；又被称为工作跟随；旁观试观察、体验式观察
—引导
引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调相关方的需求差异。
比单项会议更早发现问题；联合应用设计/开发（JAD）；质量功能开展（QFD）
用户故事：对所需功能的简短文字描述，经常产生于需求研讨会，用于敏捷开发
7，系统交互图
对产品范围的可视化描述；显示业务系统及其与人和其他系统之间的交互方式
显示：系统输入、输入提供者、系统输出、输出接收者
建立了参与者和系统之间的本质关系
最重要的是区分出什么是系统内的，显示出哪些参与者与系统交互
8，原型法
符合渐进明细性；原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述
故事板：通过一系列图像或图示展示顺序或导航路径；广告，电影行业中：利用显示效果的视觉草图；软件开发中：通过实体模型显示网页，屏幕或GUI
输出：
1，需求文件
描述各种单一的需求将如何满足与项目相关的业务需求，包括：
可跟踪的业务目标和实施的项目的原因（业务需求）
相关方对沟通和报告的需求（相关方需求）
功能需求；非功能性需求（解决方案需求）
数据转换和培训需求等（过渡和就绪需求）
验收标准（项目需求）
一开始概括性的需求，然后逐渐细化；只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的、且主要相关方愿意认可的需求、才可以作为基准
2，需求跟踪矩阵（RTM）
需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个项目都具有商业价值；为在整个项目生命周期中跟踪需求提供了一种方法
为管理产品范围变更提供了框架
包括：
从需求到业务需要、机会、目的和目标
从需求到项目目标
从需求到项目范围/WBS中的可交付成果
从需求到产品设计
从需求到产品开发
从需求到测试策略和测试场景/脚本
从高层需求详细需求
5.3 定义范围
定义：制定项目和产品详细描述的过程
作用：描述产品、服务或成果的边界和验收标准
发生时间：仅开展一次或仅在项目的预定义点开展
收集需求过程识别的所有需求未必都在本项目中完成，定义范围会从中选出最终的项目需求，制定出关于项目边界的具体描述；
应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书；
在迭代型生命周期中，现为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围（多次反复）
*产品分析
针对以产品和服务为可交付物的项目
包括产品分解、需求分析、系统分析、系统工程、价值工程和价值分析 价值value=功能fution/成本cost
数据分析：备选方案分析
包括头脑风暴、横向思维和备选方案分析等常见方法
定义范围
输入：
1，项目章程
2，项目管理计划
—范围管理计划
3，项目文件
—假设日志
—需求文件
—风险登记册
4，事业环境因素
5，组织过程资产
工具与技术：
1，专家判断
2，数据分析
—备选方案分析
3，决策
—多标准决策分析
4，人际关系和团队技能
—引导
5，产品分析
输出：
1，项目范围说明书
项目范围说明书是对项目范围、主要可交付成果，假设条件和制约因素的描述，包括：产品范围描述、可交付成果、验收标准、项目的除外责任
制定项目范围说明书时、会产生更详细的假设条件和制约因素；表明相关方之间就项目范围所达成的共识
描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度；注意项目章程与项目范围说明书内容上的差别
2，项目文件更新
—假设日志
—需求文件
—需求跟踪矩阵
—相关方登记册
5.4 创建WBS
定义：把项目可交付成果或项目分解工作分解成较小，更易于管理的组件
作用：为所要交付的内容提供架构
发生时间：进开展一次或仅在项目的预定义点开展
WBS（work breakdown structure）：是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解
工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作；WBS最底层的组成部分叫工作包，可针对工作包安排进度，估算成本和实施监控
“工作”是指作为活动结果的工作产品和可交付成果。而不是工作本身；WBS不表述逻辑关系和历时，只表示范围
创建WBS
输入：
1，项目管理计划
—范围管理计划
2，项目文件
—项目范围说明书
—需求文件
3，事业环境因素
4，组织过程资产
工具与技术：
1，专家判断
2，分解
目的：便于控制
程度：能够可靠的估算工作费用和持续时间
创建WBS的常用方法包括：自上而下、使用组织特定的指南、使用WBS模板、自下而上（用于归并较低层次组件）
可作为分解第二层：项目周期各阶段、主要的可交付物、子项目；不能分解：很远的将来要完成的成果（WBS也是渐进明细的定义）
输出：
1，范围基准
包括：
项目范围说明书、WBS、工作包、规划包、WBS词典
工作分解结构词典对工作分解结构组成部分（包括工作包和控制帐户）进行跟详细的描述
内容：帐户编码标识；工作描述；假设条件制约因素；负责的组织；进度里程碑清单；相关的进度活动；所需资源；成本估算；质量要求；验收标准；技术参考文献；协议信息；WBS词典是最详细的范围描述
2，项目文件更新
3，假设日志
4，需求文件
WBS具有层次结构，由团队成员共同完成制作；
帐户编码COA(code of account)：每个组成部分分配唯一的编码，识别所在的层次和位置
控制帐户（control account）是一种管理控制点，用于挣值分析（高低决定控制粗细）；每一个控制帐户可以包括一个或多个工作包，但是每一个工作包只能属于一个控制帐户
规划包（planning package）：在CA控制帐户之下，工作包之上，知道工作内容，但暂时不确定详细工作分解
工作包（work package）位于工作分解结构每条分支最底层的可交付成果或项目工作组成部分
WBS分解原则
100%包含原则，WBS分支的上下包含关系，WBS整体包含了项目所需的所有工作
MECE（mutually exclusive collectively exhaustive 互斥，完全穷尽）
如果用敏捷的方法，可以将长篇故事分解成用户故事；WBS可以采用提纲式，组织结构图或能说明层级结构的其他形式：不同的可交付成果可以分解到不同的层次
分解到可控层面即可，滚动是规划：远期工作或信息暂时不足的可交付成果，可暂时不分解，等信息充分后继续分解
5.5 确认范围
定义：正式验收项目已完成的可交付成果的过程
作用：是验收过程具有客观性，确认可交付物带来的商业价值，满足项目目标，满足相关方预期的使用需求
发生时间：根据需要的整个项目期间定期开展
确认范围包括与客户或发起人一起审查核实得可交付成果，确保可交付的成果已圆满完成，并获得客户与发起人的正式验收
确认范围与控制质量的区别：
确认范围：可交付成果的验收
控制质量：可交付成果是否正确，是否满足质量要求
控制质量通常先于确认范围进行，也可同时进行
确认范围
输入：
1，项目管理计划
—范围管理计划
—需求管理计划
—范围基准
2，项目文件
经验教训登记册
质量报告
需求文件
需求跟踪矩阵
3，核实的可交付成果
4，工作绩效数据
工具与技术：
1，检查
2，决策
—投票
输出：
1，验收的可交付成果
2，工作绩效信息
3，变更请求
4，项目文件更新
—经验教训登记册
—需求文件
—需求跟踪矩阵
I需求跟踪矩阵
需求跟踪矩阵用于范围管理的两个监控过程，不多不少的完成
T检查Inspection
又是也被称为：审查、产品审查、审计、巡查（review、product review、audit、walkthrous）
O验收的可交付成果
怎样证明验收通过：由客户和发起人正式签字批准的文件
5.6 控制范围
定义：监督范围状态，保持对范围基准的维护，管理范围变更
作用：在整个项目期间保持对范围基准的维护
发生时间：整个项目期间持续开展
未经控制的产品或项目范围扩大（未对时间、成本和资源做相应调整）被称为范围蔓延：变更不可避免，每个项目都必须强制实施某种形式的变更控制
控制范围
输入：
1，项目管理计划
2，项目文件
3，工作绩效数据
4，组织过程资产
工具与技术：
1，数据分析
—偏差分析
—趋势分析
输出：
1，工作绩效信息 工作绩效数据——————> 偏差大——————> 纠正或预防（变更请求）
2，变更请求 偏差分析（比较）
3，项目管理计划更新 项目管理计划 ————>偏差小或无 ————>继续监控
4，项目文件更新
