# # #范围管理
概述：确保项目包括且仅包括实现项目成功所需的工作。
项目范围管理需要做以下三个方面的工作：
定义范围内和范围外的项目界限。
确保所有应做的工作都已完成，不再有更多工作要做。对超出范围的额外工作说“不”，停止做额外的工作。
防止项目范围扩大。范围是指未对时间、成本和资源进行相应调整的非受控产品或项目范围的扩大。
# # #产品系列
产品、服务或成果的特点和功能。
产品范围是否完成以产品是否符合产品描述来判断。例如，软件产品是否完成是由软件需求规格说明书来衡量的。
产品范围是项目范围的基础。
# # #项目范围
这是为了交付产品和项目而必须完成的工作。
有时项目范围也称为工作范围。
项目范围是否完成，由范围基准衡量。
项目范围声明
WBS
WBS词典
# # #范围管理的重要性
范围是基本和全面的工作。
1.项目范围来源于项目目标，项目范围的完成是为了实现项目目标。
2.项目范围管理和控制的有效性是衡量项目成功与否的必要标准。
3.在项目中不断重申项目工作的范围是在项目中实施控制和管理的主要手段。
4.项目范围管理可以明确详细的分工接口和职责。
5.项目范围管理可以确定项目边界并定义主要的可交付成果。
6.范围管理可以提高项目成本、进度和资源的准确性。
7.项目范围管理影响项目的成功。在实践中，范围扩展是项目失败的最常见原因之一。
# # #示波器——沙漠综合症有问题
沙漠综合征：失去希望，目光呆滞，反应迟钝，对新事物缺乏热情，容易高兴和烦躁，容易激动或抑郁。
原因：事先没有明确项目范围(目标)，需求和事情是无穷无尽的。
解决方案：重新组织范围，列出里程碑。
# # #项目经理必须从大局出发指挥和控制项目范围。范围管理不好，三军尽废！范围是“牛鼻子”，全身被一个东西碰到。
# # #项目范围管理流程
规划范围管理
管理范围指南管理要求指南
重要输出
范围管理计划
描述如何定义、制定、监控和确认项目范围。
内容：如何制定项目范围说明书；如何创建WBS；如何维护和批准WBS；如何确认和正式接受；如何处理范围变更等。
示例
制定项目范围说明书：
内容：项目范围声明是对项目范围、产品和验收标准、主要交付成果、项目边界、假设和约束的描述。
说明：应根据项目启动期间记录的主要可交付成果、假设和约束条件，编制详细的项目范围说明书。
WBS创建：
角色：与工作包相关的所有项目团队和所有关键利益相关者。
步骤和说明：确定项目工作和所有可交付成果，并使用逐步表格形式进行分解(如模块、文档等。)第二层是可交付成果。
WBS组件的编码规范为：1、1.1、1.2；2、2.1、2.2分步编码法。为了检查较低的组成部分是否充分和必要，WBS组成部分可以划分为个人或组织单位。
交付物的验收：
确定验收时间
确定需要哪些资源投入
确定正式接受范围的标准
确定会议的组织步骤
组织范围确认会议。
验收后，您必须签署《**验收情况表》，填写验收意见和后续事项。
如果验收失败，记录失败的原因，然后重新组织。
范围变更
注：需求的变更和产品功能的增加、修改、删除都属于范围变更。
范围变更程序：
1.变更申请(负责人先沟通了解)
2.提交书面申请
3.所有范围变更应提交给CCB批准。
4.如果是，更新需求文档和范围基准。
5.拒绝的原因和理由应记录并记入变更日志。
6.要进行更改，必须在系统中跟踪更改的实施。
7.总结和归档变更。
需求管理计划
如何分析、记录和管理需求。定义、确定、记录、验证、管理和控制项目要求。
>
– 内容：
1. 如何规划、跟踪和报告各种需求活动
2. 需求管理需要使用的资源
3. 培训计划
4. 项目干系人参与需求管理的策略
5. 判断项目范围与需求不一致的准则和纠正规程
6. 需求跟踪结构
7. 配置管理活动
– 示例
– 需求收集：常用“文件分析、问卷调查、焦点小组、名义小组、引导式研计会”等工具；收集完成后，应填写《用户需求说明书》，并同需求提出人进行签字确认。
– 需求记录：把确定下来的需求记录到“需求文件、需求跟踪矩阵”中，记录需求的时候，会针对部分需求用“系统交互图、原型”甚至把“竞争对手产品或者最佳实践的产品界面功能截图在需求中”
– 需求排序：对需求进行优先级排序，按“非常重要、重要、一般”三个等级进行划分，团队根据客户的需求重要性、紧迫性等综合因素，采用“多标准决策分析、投票”等方法进行排定。
– 干系人参与需求管理的策略：
1. 用户需求说明书：需求人员编写完成后，应同需求提出人签字确认；干系人；需求人员，需求提出人，用户需求审批人；
2. 需求规格说明书：需求人编写完成后，应进行评审通过后方可实施；干系人；需求人员、需求提出人，需求审批人，测试人员、设计人员、开发人员、最终用户。
– 需求跟踪结构：对应《需求跟踪矩阵》，在项目中建立“需求编号、需求说明、功能点、业务设计文档、组件、测试用例”等跟踪属性。将需求与可交付成果、需求与相关方（谁提、谁开发、谁测试、谁确认等信息）关系定下来
– 重要输入
– 项目管理计划
– 项目章程
– 收集需求
– 记录需求 管理需求 获取 分析 定义 验证
– 重要输出
– 需求文件
– 需求清单
– 需求规格说明书
– 业务需求
– 干系人需求（用户需求）
– 解决方案需求（功能和非功能需求）
– 项目需求（服务水平）
– 过渡需求
– 相关假设和约束
– 需求跟踪矩阵
– 将产品从其来源连接到可交付成果的一种表格
– 有助于确保需求文件中被批准的每项需求在项目结束时都能交付
– 为管理产品范围变更提供框架
– 重要输入
– 范围管理计划
– 需求管理计划
– 干系人管理计划
– 项目章程
– 干系人登记册
– 工具与技术
– 访谈
– 结构化访谈：事先准备好一系列问题，有针对进行
– 非结构化访谈：列出一个粗略的想法
– 实际中两者结合
– 准备
1. 了解对象
2. 准备提纲
3. 让被访者上司安排（这样会引起重视）
– 访谈时
1. 两人去访谈（其中一人记录）
2. 聆听而非指导
3. 复述和确认
4. 引导描述事实，把握需求实质
– 结束后
1. 感谢
2. 反馈
– 焦点小组会议
– 预定的干系人和主题专家集中在一起互动式的讨论
– 一般要有一个主题
– 比访谈更加热烈
– 主持人引导
– 多人互动式讨论
– 一般6-10人
– 引导式研讨会
– 跨职能、集中式讨论，比单项会议能更快的发现和解决问题
– JAD 联合应用设计/开发
– 干系人+开发团队
– QFD 质量功能展开
– 客户声音
– 群体创新技术
1. 头脑风暴
– 面对面、畅所欲言、相互启发
– 5 – 10人，时长1小时左右
– 原则：
1. 庭外判决原则，评判必须放到最后阶段
2. 欢迎各抒己见，自由鸣放
3. 追求数量
4. 探索取长补短和改进办法
– 缺点：可能会屈服于权威
2. 名义小组技术
– 通过投票来排列最有用的创意
– 头脑风暴 + 排序
– 步骤：
1. 分小组讨论
2. 主持人询问
3. 评审和排序
3. 德尔菲技术
– 关键词：背对背、匿名，以问卷方式多次征询专家意见
– 过程步骤：
1. 选择专家
2. 专家独立发表书面意见
3. 主持人收集综合专家们的意见后，反馈给各位专家，请他们再次发表意见，如果分歧很大，可以开会集中讨论；否则主持人分头与专家联络
4. 反复多次，最后开成代表专家组意见的方案。
– 特点
1. 充分利用专家经验
2. 能使每一位专家独立做出判断
3. 减轻数据偏倚，防止不恰当的影响。
– 缺点
– 过程复杂、耗时
4. 概念/思维导图
– 又称心智图，从头脑风暴获得创意，用图联系起来，反映共性与差异，引出新创意。
5. 亲和图
– 针对某一问题，充分收集汇总后，按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法
– 核心是头脑风暴
– 主要用来确定范围分解的结构，有助于WBS的制订
– 头脑风暴 + 归纳
6. 多标准决策
– 借助决策矩阵，采用多标准评估和排序方案
– 群体决策技术
– 一致同意
– 大多数原则 （50%以上）
– 相对多数原则（超两个方案时）
– 独裁
– 问卷调查
– 受访者众多
– 地理位置分散
– 受众多样化
– 观察：也叫工作跟踪，直接察看个人在各自的环境中如何开展工作和实施流程
– 可以挖掘隐藏需求
– 原型法：
– 标杆对照：
– 识别最佳实践，开成改进意见
– 系统交互图
– 对产品范围的可视化描述
– 用例图（UML）
– 文件分析：文档考古，分析现在文档，识别与需求相关信息，来挖掘需求。
– 需求跟踪
– 正向跟踪
– 检查需求文件中的每个需求是否能在后继工作产品（成果）中找到对应点
– 以免需求被做漏、做偏
– 反向跟踪
– 检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处（查需求源头）
– 定义范围
– 重要输入
– 范围管理计划
– 项目章程
– 需求文件（收集需求输出）
– 重要输出
– 范围说明书*****
1. 产品范围描述
2. 验收标准
3. 可交付成果
4. 项目的除外责任
5. 制约因素
6. 假设条件
– 助记：产、验、可、除、制、假
– 作用
– 确定范围
– 沟通基础
– 规划控制基础
– 变更基础
– 工具及技术
– 产品分析
– 产品分解
– 系统工程/系统分析
– 价值工程/价值分析
– 需求（功能）分析
– 创建WBS
– 目标和交付物分解，项目工作分解
– 重要输出
– 范围基准
– 已批准的项目范围说明书
– WBS
– WBS 词典
– 工作单元的细节描述，可能包括：
– 账户编码标识
– 工作描述
– 假设条件
– 制约因素
– 负责人或组件单元
– 进度里程碑
– 相关进度活动
– 所需资源
– 成本估算
– 质量要求
– 验收标准
– 技术参考文献
– 协议信息等
– 重要输入
– 范围管理计划
– 项目范围说明书
– 需求文件
– 创建WBS做什么？
– 把项目可交付成果和项目工作分解为更小、更易于管理的组件
– 有什么作用？
1. 明确和准确说明项目范围【明确范围】
2. 清楚地定义项目的边界【定义边界】
3. 为各独立单元分派人员，规定其职责，确定所需求技能和资源【分派人员】
4. 为计划、预算、进度安排和费用控制奠定共同基础【计划基础】
5. 将项目工作和项目的财务账目联系起来【账目联系】
6. 确定工作内容和工作顺序【确定工作】
7. 有助于防止范围蔓延【防止蔓延】
– 工作包
– 是WBS的最低层组成部分
– 在工作包上可对其成本和进度进行可靠估算、控制，便于完整分派给不同组织和个人。
– 特征：具体、能明确责任、逻辑上不能再分
– 分解粒度的8/80经验法则：工作包最小不小于8小时，最大不超过80小时。
– 控制账户
– 是一个管理控制点，在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
– 设置在WBS中选定的管理节点上
– 每个控制账户可以包括一个或多个工作包，但是一个工作包只能属于一个控制账户。
– 规划包
– 出中WBS的组件，位于控制账户之下，工作内容已知，但详细的进度活动未知
– 最终会分解成工作包
– 工具与技术
– 分解
1. 识别和分析可交付成果及相关工作
2. 确定WBS的结构和编排方法
3. 自上而下逐层细化分解
4. 为WBS组件制定和分配标识编码
5. 核实分解的程度是否恰当
– 注意事项
1. 必须是面向可交付成果的
2. 必须符合项目的范围，必须且仅包括为完成项目的活动
3. 100%原则：所有下一级的元素之和必须100%的代表上一级元素
4. 底层应该支持计划和控制
5. WBS中的元素必须有人负责，而且只由一个人负责，此为独立责任原则
6. WBS的指导：WBS应控制在4~6层（每层4~7个新元素）。如果超过6层，可以分解子项目来做WBS；
7. 一个工作单元只能从属于某个上层单元，避免交叉从属。
8. WBS的编制需要所有（主要）项目干系人参与，需要项目团队成员的参与，避免遗漏。
9. WBS并非一成不变的，遵从滚动分解原则。
– 确认范围
– 正式验收可交付成果
– 重要输出
– 验收的可交付成果
– 变更请求
– 工作绩效信息
– 重要输入
– 核实的可交付成果
– 工作绩效数据
– 需求跟踪矩阵
– 需求文件
– 项目管理计划
-工具与技术
– 检查
– 也叫审查、产品评审、走查、审计、巡检。包括测量、测试、检验等活动，判断结果是否符合要求和期望。
– 步骤
1. 确定需要进行确认范围的时间
2. 识别确认范围需要哪些投入
3. 确定范围正式被接受的标准和要素
4. 确定确认范围会议的组织步骤
5. 组织确认范围会议
– 确认范围需检查的问题
1. 可交付成果是可确认和核实的
2. 每个交付成果是否有明确的里程碑
3. 是否有明确的质量标准
4. 审核或承诺是否表达清晰
5. 项目范围是否覆盖了要完成的产品或服务
6. 项目范围的风险是否太高，管理层是否能降低风险的影响
– 确认范围与控制质量
1. 确认范围强调可交付成果获得客户的接受，质量控制强调可交付成果的正确性，并符合具体质量要求
2. 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行
3. 质量控制属于内部检查，由质量部门实施；确认范围由外部干系人（如客户）验收
– 确认范围与项目收尾
1. 确认范围强调的是核实与接受可交付成果（目的是验收），而项目收尾强调的是结束项目或阶段所要做的流程性工作（目的是结束和收尾）
2. 确认范围与项目收尾都有验收工作，确认范围强调验收项目的可交付成果，项目收尾强调验收产品（移交成果、归档、总结经验）
– 控制范围
– 监督范围状态 管理范围基准变更
– 重要输出
– 工作绩效信息
– 变更请求
– 项目管理计划更新
– 项目文件更新
– 组织过程资产更新
– 重要输入
– 工作绩效数据
– 需求文件
– 需求跟踪矩阵
– 项目管理计划
– 工具与技术
– 偏差分析
– 范围变更的原因
1. 政府政策问题
2. 项目范围的计划编制不周密，有一定的错误或遗漏
3. 市场上出现了新技术
4. 项目执行组织本身发生变化
5. 客户对项目、项目产品或服务的要求发生变化
– 范围变更控制的工作
1. 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
2. 判断范围变更是否已经发生
3. 范围变更发生时管理实际的变更，确保所有被请求变更按照项目整体变更控制过程处理。
– 范围蔓延
– 未经过控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）
– 镀金
特指团队成员擅自增加新工作或产品功能（未受控）
