Head First PMP – 5 – 范围管理(Scope Management)

首先我们区分一下产品范围(Product Scope)、项目范围(Project Scope)的概念：

产品范围表示你和你的团队正在构建的产品或服务的特性和功能。
项目范围是建立产品所需完成的全部工作。
本章所描述的范围管理是针对项目范围，而不是产品范围。
范围蔓延(Scope Creep)是指导致团队做额外工作的失控变更(Uncontrolled Change)。

范围管理(Scope Management)就是要做正确的事，在建立产品之前你必须知道要建立什么。这意味着明确哪些超出范围，而不是哪些是属于范围的一部分。范围管理知识领域包括以下6个过程：

计划范围管理(Plan Scope Management)
收集需求(Collect Requirements)
定义范围(Define Scope)
创建工作分解结构(Create Work Breakdown Structure)
控制范围(Control Scope)
核实范围(Validate Scope)

1. 计划范围管理(Plan Scope Management)

输入(Inputs)	企业环境要素(Enterprise Environmental Factors) 组织过程资产(Organizational Process Assets) 项目管理计划(Project Management Plan) 项目章程(Project Charter)
工具或技术(Tools and Techniques)	专家判断(Expert Judgment) 会议(Meetings)
输出(Outputs)	需求管理计划(Requirements Management Plan) 范围管理计划(Scope Management Plan)

计划范围管理过程需要计划出一些方法和途径，用于找出你要做什么以及什么超出了范围，也就是明确指出如何执行范围管理知识领域其他的过程。

2. 收集需求(Collect Requirements)

输入(Inputs)	干系人管理计划(Stakeholder Management Plan) 需求管理计划(Requirements Management Plan) 干系人登记表(Stakeholder Register) 范围管理计划(Scope Management Plan) 项目章程(Project Charter)
工具或技术(Tools and Techniques)	与干系人讨论的工具和技术： 访谈(Interview) 辅助工作室(Facilitated Workshops) 专题小组讨论会(Focus Groups) 群体决策技术(Group Decision-Making Techniques)： 一致同意(Unanimity) 多数同意(Majority)——一件事情多数人同意则通过 少数服从多数(Plurality)——从多件事中挑选多数人认同的事情通过 总裁制(Dictatorship) 群体创新技术(Group Creativity Techniques)： 思维导图(Idea/Mind Maps) 德尔菲法(The Delphi Technique)——群体匿名投票， 适合估算工作量和时间 亲和图(Affinity Diagrams)——需求分组 头脑风暴(Brainstorming) 名义群体法(The Nominal Group Technique)——头脑风暴的一种形式，对头脑风暴的结果进行投票，排序组织 对比分析(Benchmarking) 文档分析(Document Analysis) 上下文图(Context Diagrams)——展示产品范围内的过程和特性之间的关系，以及用户如何与之交互 问卷调查(Questionnaire) 观察(Observation) 原型(Prototype)
输出(Outputs)	需求文档(Requirements Document) 需求追溯矩阵(Requirements Traceability Matrix)

需求文档要列出所有的功能性需求和非功能性需求。
功能性需求(Functional Requirements)一般是指新特性(New Features)、Bug修复(Bug Fixes)、新行为或不同的行为(New or Different Behavior)。
非功能性需求(Nonfunctional Requirements)主要是指产品质量属性，包括性能(Performance)、可靠性(Reliability)、错误处理(Error Handling)和易用性(Ease of Use)。

3. 定义范围(Define Scope)

输入(Inputs)	需求文档(Requirements Document) 组织过程资产(Organizational Process Assets) 范围管理计划(Scope Management Plan) 项目章程(Project Charter)
工具或技术(Tools and Techniques)	辅助工作室(Facilitated Workshops) 产品分析(Product Analysis) 替代方案识别(Alternatives Generation) 专家判断(Expert Judgment)
输出(Outputs)	项目范围说明书(Project Scope Statement) 项目文档更新(Project Document Updates )

项目范围说明书指出你在项目中将要做以及不应做的工作。

4. 创建工作分解结构(Create Work Breakdown Structure)

输入(Inputs)	企业环境要素(Enterprise Environmental Factors) 组织过程资产(Organizational Process Assets) 范围管理计划(Scope Management Plan) 项目范围说明书(Project Scope Statement) 需求文档(Requirements Document)
工具或技术(Tools and Techniques)
输出(Outputs)	工作分解结构(Work Breakdown Structure) WBS字典(WBS Dictionary) 范围基线(Scope Baseline) 项目文档更新(Project Document Updates )

一般有两种分解工作的方式，基于项目或阶段(Project or Phase)和基于可交付成果(Deliverables)。
分解出来的最小单位称为工作包(Work Package)，工作包必须是可计量的(Measurable)。
项目范围说明书、工作分解结构和WBS字典统称范围基线(Scope Baseline)。
为何范围会变化：

好的变化(Good Change)——不需要更多的时间和成本，且对项目质量没有影响
坏的变化(Bad Change)——好注意但是有影响

范围蔓延——一个变更引起另一个变更，另一个变更又引起新的变更
镀金——多此一举，画蛇添足

5. 控制范围(Control Scope)

输入(Inputs)	组织过程资产(Organizational Process Assets) 工作绩效数据(Work Performance Data) 需求文档(Requirements Document) 需求追溯矩阵(Requirements Traceability Matrix) 项目管理计划(Project Management Plan) 批准的变更请求(Approved Change Requests)
工具或技术(Tools and Techniques)	差异分析(Variance Analysis)
输出(Outputs)	工作绩效信息(Work Performance Information) 变更请求(Change Requests) 组织过程资产更新(Updates to Organizational Process Assets) 项目管理计划更新(Updates to Project Management Plan) 项目文档更新(Project Document Updates )

控制范围的目标就是更新范围、计划、基线和WBS信息。
变更的流程：

1) 确实需要一个变更
2) 创建一个变更请求
3) 让变更得到批准——整合变更控制
4) 完成差异分析
5) 重新计划工作
6) 创建一个新的基线

6. 核实范围(Validate Scope)

输入(Inputs)	可交付成果(Deliverables) 工作绩效数据(Work Performance Data) 需求文档(Requirements Document) 需求追溯矩阵(Requirements Traceability Matrix) 项目管理计划(Project Management Plan)
工具或技术(Tools and Techniques)	群体决策技术(Group Decision-Making Techniques) 检查(Inspection)
输出(Outputs)	接受的可交付成果(Verified Deliverables) 工作绩效信息(Work Performance Information) 变更请求(Change Requests) 项目文档更新(Project Document Updates )

正式验收(Formal Acceptance)意味着你已经得到所有干系人的书面确认(Written Confirmation)，证实你的可交付成功满足需求和项目管理计划。
核实范围和控制范围的顺序不确定，因为检查未通过时，要再走控制范围的流程，发起变更请求。



本章完！

http://www.alanz.me/2015/11/head-first-pmp-5-scope-management/