Appearance
范围管理：把"做什么"钉死
本页导读：范围管理回答"项目要做多少、做到什么边界"。六大过程为：规划范围管理、收集需求、定义范围、创建 WBS、确认范围、控制范围。其中 WBS 分解原则与确认范围的时机/工具是历年高频考点，"镀金（gold plating）""范围蔓延（scope creep）"是案例找错题的常驻嘉宾。本页逐过程精讲并配 ITO 小表，最后给出高频考点与例题。
一、知识框架图
- 范围管理（6 个过程）
- 规划：规划范围管理 → 输出范围管理计划、需求管理计划
- 规划：收集需求 → 输出需求文件、需求跟踪矩阵
- 规划：定义范围 → 输出项目范围说明书
- 规划：创建 WBS → 输出范围基准
- 监控：确认范围 → 输出验收的可交付成果
- 监控：控制范围 → 防止范围蔓延
- 两条线
- 产品范围：产品/服务所包含的功能与特征（对照产品需求度量）
- 项目范围：为交付产品所必须做的全部工作（对照项目管理计划/范围基准度量）
- 主线：怎么管范围 → 要什么 → 边界到哪 → 拆成块 → 正式验收 → 看住不蔓延
二、各过程精讲
1. 规划范围管理
ITO 一览
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目章程、项目管理计划、事业环境因素、组织过程资产 | 专家判断、数据分析（备选方案分析）、会议 | 范围管理计划、需求管理计划 |
要点：范围管理计划描述如何定义、确认、控制范围；需求管理计划描述如何获取、记录、管理需求。两者都是"关于管理的计划"，不含具体需求内容。
2. 收集需求（工具最多的过程之一）
ITO 一览
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目章程、项目管理计划、项目文件（假设日志/干系人登记册）、立项管理文件、协议 | 专家判断、数据收集（头脑风暴/访谈/焦点小组/问卷调查/标杆对照）、决策（投票/独裁/多标准）、数据分析（亲和图/思维导图）、人际关系与团队技能（名义小组技术/观察和交谈/引导）、系统交互（原型法/故事板） | 需求文件、需求跟踪矩阵 |
重点工具辨析（选择题常考）：
- 访谈：一对一深入，适合干系人数少、问题深的场景。
- 焦点小组：同职能/同背景的干系人小组讨论，比访谈快。
- 问卷调查：受众多、地理位置分散、需要快速统计时首选。
- 标杆对照：与最佳实践组织比对找差距。
- 名义小组技术：先各自匿名写想法再排序，避免"权威一言堂"。
- 引导（引导式研讨会）：跨职能快速定义需求（如联合应用开发 JAD）。
- 原型法：需求模糊时先出原型让用户"摸着实物提需求"，含故事板，注意原型是需求获取手段而非最终产品。
需求分类（需求文件的内容框架）：
| 需求类别 | 说明 |
|---|---|
| 业务需求 | 组织为什么要做这个项目（高层目标） |
| 干系人需求 | 各干系人的具体需要 |
| 功能需求 | 系统必须具备的行为/功能 |
| 非功能需求 | 性能、安全、可靠性、可用性等质量属性 |
| 过渡与就绪需求 | 上线切换、培训、数据迁移等临时需求 |
| 项目需求 | 进度、成本、合规等对项目自身的要求 |
| 质量需求 | 验证产品是否合格的条件 |
需求跟踪矩阵（RTM）：把每条需求与其来源、设计、实现、测试用例关联，防止"需求掉了没人发现"；同时为确认范围提供依据。价值：需求→设计→开发→测试全链条可追溯，变更影响一目了然。
3. 定义范围
ITO 一览
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目章程、项目管理计划、项目文件、立项管理文件、协议 | 专家判断、数据分析（备选方案分析）、决策（多标准决策分析）、人际关系与团队技能（引导） | 项目范围说明书、项目文件更新 |
项目范围说明书内容（高频）：
- 产品范围描述
- 可交付成果列表
- 验收标准
- 项目除外责任（明确"不做什么"，防止期望蔓延——考点：除外责任写明不纳入范围的工作）
- 制约因素与假设条件
定义范围的产出是"从需求中筛选出本轮要做的"——备选方案分析与多标准决策用于取舍。
4. 创建 WBS（本领域最重要过程）
ITO 一览
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目管理计划、项目文件（项目范围说明书/需求文件）、事业环境因素、组织过程资产 | 专家判断、分解 | 范围基准 |
范围基准 = 批准的项目范围说明书 + WBS + WBS 词典。
WBS 分解原则（高频考点，逐条背）：
- 100% 原则：WBS 必须覆盖全部工作，不多不少；下层之和 = 上层全部工作，也不包含范围外工作。
- 面向可交付成果分解：按"产出"拆，而不是按职能、部门或生命周期阶段流水账式拆。
- 工作包是最低层：工作包是能够可靠估算成本与历时、可分配给唯一责任人的最小单元；经验法则为"一个工作包 8～80 小时"（8/80 原则，即 1～10 个工作日量级），报告周期一般不超过一个报告期。
- 唯一负责人：每个工作包应有且只有一个责任人（可再逐层分配）。
- 互斥不交叉：同一层次各要素相互独立、不重叠；一个工作包只能隶属一个上层要素。
- 滚动式规划：近期工作拆细，远期工作先粗后细，随信息明朗逐步分解。
- 分解层次适度（主流口径 4～6 层为宜），过细管理成本剧增。
- WBS 词典为每个工作包/控制账户编写详细说明（工作内容、负责人、进度里程碑、成本估算、验收标准等）。
- 经干系人确认、批准后形成范围基线；WBS 一旦成为基线，修改必须走变更控制。
- 控制账户：WBS 中高于工作包的管理控制点，每个控制账户可对应一个或多个工作包；规划包：低于控制账户、内容尚不明确、暂不分解到工作包的单元。
WBS 常见错误清单（案例找错模板）：
- 按组织部门拆分 WBS（应按可交付成果拆）。
- 把"设计、开发、测试"这类阶段动词当交付物拆层。
- 遗漏项目管理工作的分解（违反 100% 原则）。
- 工作包粒度过粗（无法估算与考核）或过细（几十分钟级，管理成本爆炸）。
- 多个工作包内容交叉重叠，责任不清。
- 没有 WBS 词典，工作包描述缺失。
- WBS 改动不走变更控制，随意增删。
5. 确认范围（监控）
ITO 一览
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目管理计划、项目文件（经验教训登记册/质量报告/需求文件/需求跟踪矩阵）、核实的可交付成果、工作绩效数据 | 检查（与开展检查，又称审查/评审/走查）、决策（投票/独裁） | 验收的可交付成果、工作绩效信息、变更请求、项目文件更新 |
确认范围要点（必考）：
- 谁验收：客户/发起人正式验收；项目经理组织。
- 验什么：核实的可交付成果（先经控制质量核实正确性，再提交确认范围正式验收——顺序考点）。
- 用什么验：工具是检查（与开展检查：审查、评审、走查、巡检等形式），依据是需求文件与验收标准（需求跟踪矩阵把需求与验收串联）。
- 验不过怎么办：提出变更请求（返工或调整），并在工作绩效信息中记录。
- 确认范围可以每个阶段/每个交付节点分批进行，不是等项目结束一次性验收。
确认范围 vs 控制质量（超高频对比）：
| 维度 | 控制质量 | 确认范围 |
|---|---|---|
| 时序 | 在先 | 在后 |
| 目的 | 核实可交付成果技术正确性（是否符合质量标准） | 干系人正式验收（是否符合验收标准与范围） |
| 主体 | 项目团队内部质量人员 | 客户/发起人等外部干系人 |
| 输出 | 核实的可交付成果、质量控制测量结果 | 验收的可交付成果 |
6. 控制范围
ITO 一览
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目管理计划、项目文件、工作绩效数据、组织过程资产 | 数据分析（偏差分析/趋势分析） | 工作绩效信息、变更请求、项目管理计划更新、项目文件更新 |
核心概念（案例找错高频词）：
- 范围蔓延（scope creep）：未经正式变更控制，范围被外部悄悄扩大（客户不停加小需求、团队顺手多做）——发现后应记录变更请求走 CCB，而不是默认接受。
- 镀金（gold plating）：项目团队主动交付超出范围的产品/功能（自作多情）——PMI 立场：不允许，镀金不加分。
- 应对：用偏差分析对照范围基准，识别蔓延趋势，及时提出变更请求纠正。
三、高频考点与易错点
- 产品范围 vs 项目范围：产品范围=功能与特征；项目范围=为交付产品所做的全部工作。
- WBS 判断题：WBS 是范围基准的组成；WBS 最底层是工作包而不是活动（活动在进度管理中由"定义活动"从工作包再分解）；WBS 不按部门职能分解。
- 收集需求工具选择题：场景给"干系人多且分散"→问卷调查；"跨部门快速达成需求共识"→引导式研讨会；"需求模糊、用户说不清"→原型法。
- 确认范围顺序题：控制质量（核实）→ 确认范围（验收）；若跳过质量核实直接找客户验收，是典型错误。
- 除外责任：范围说明书里写"不做什么"，考"除外责任的用途是管理干系人期望"。
- 易错点：范围管理计划本身不含需求；需求跟踪矩阵连接"需求→设计→测试"；镀金与蔓延都会导致"范围失控"，但主体不同（团队自加 vs 外部强加）。
四、例题（自编模拟题）
【例题 1】 关于创建 WBS，下列做法正确的是（ ）。
A. 按职能部门划分第一层，再分配给各处室 B. 把"项目管理"工作排除在 WBS 之外，只列入产品工作 C. 分解到工作包，并由唯一责任人负责，遵循 100% 原则 D. 为便于控制，把所有工作包一律分解到 4 小时粒度
答案：C
解析：A 错，WBS 面向可交付成果而非职能部门；B 错，管理工作也属于项目工作，应纳入 WBS 才满足 100% 原则；D 错，过度分解违背 8/80 经验法则，徒增管理成本。C 正确。
【例题 2】 项目按阶段交付。某阶段可交付成果通过了内部质量控制测试，项目经理随后组织客户验收但客户提出若干修改意见。项目经理最应该（ ）。
A. 拒绝修改，因为成果已通过质量控制 B. 让团队直接按客户意见修改后重新提交 C. 记录变更请求，评估影响后按变更控制流程处理，再安排重新验收 D. 视为范围蔓延，直接终止该阶段验收
答案：C
解析：客户验收未通过属于确认范围环节的正常事件：先对照需求文件/验收标准判断差异，是缺陷则返工（走变更流程），是新增需求则必须走变更控制。B"直接改"绕过了变更控制，A、D 处置失当。选 C。
【例题 3】 某团队认为"多送客户一个免费报表功能会提升满意度"，未经批准自行开发并交付。该行为属于（ ）。
A. 范围蔓延 B. 镀金 C. 快速跟进 D. 渐进明细
答案：B
解析：镀金是项目团队主动交付超出范围要求的产品或功能；范围蔓延是外部干系人不断施加的未受控需求扩张。团队"自作多情"加功能属镀金，PMI 立场是不允许。选 B。
五、本页小结
- 六过程主线：规划范围管理 → 收集需求 → 定义范围 → 创建 WBS → 确认范围 → 控制范围。
- 范围基准 = 范围说明书 + WBS + WBS 词典；WBS 分解牢记：100% 原则、面向可交付成果、工作包 8/80、唯一负责人、滚动式规划。
- 确认范围：客户正式验收"核实的可交付成果"，工具是检查；顺序在控制质量之后。
- 控制范围：警惕范围蔓延（外部悄悄加）与镀金（团队主动加），处置手段都是偏差分析 + 变更请求。
下一篇：进度管理。