控制范围是什么
控制范围监督范围状态并管理范围基准的变更：核对交付物是否与范围基准一致，把未经批准的扩张挡在开发之外。范围蔓延是进度与成本失控最常见的根源，它的危险之处在于每次增加都很小、理由都很合理，累计几个月后团队才发现工期已经被悄悄吃完。
基本信息
| 所属过程组 | 监控（5.6 控制范围） |
|---|---|
| 管理对象 | 范围基准与所有范围变更请求 |
| 主要工具 | 偏差分析、趋势分析、需求跟踪矩阵比对 |
| 主要输出 | 工作绩效信息、变更请求、项目管理计划更新 |
典型使用场景
- 需求评审：区分本次范围内与后续版本的需求，明确不进本期的内容
- 开发过程中临时需求：统一登记，评估后决定是否插入当前迭代
- 阶段验收：用需求跟踪矩阵核对每条需求是否都有对应交付物
- 验收争议：以范围说明书与 WBS 词典为判据，而不是口头承诺
- 外包范围界定：把边界写进合同，避免完工后被追加免费工作量
三个概念区分
| 概念 | 特征 | 处置方式 |
|---|---|---|
| 范围蔓延 | 未经批准、逐步增加的小需求 | 回归变更流程并评估影响 |
| 镀金 | 团队主动添加未被要求的功能 | 按范围基准剔除或走变更流程 |
| 范围变更 | 经批准的正式变更 | 更新范围基准与相关子计划 |
范围失控的常见路径
| 路径 | 表现 | 后果 |
|---|---|---|
| 顺手做一下 | 口头答应小改动不留记录 | 累计工作量无人统计 |
| 口径不一致 | 需求描述含糊，各人理解不同 | 交付物与预期不符，返工 |
| 镀金表彰 | 把主动加功能当积极性 | 团队形成随意扩范围的惯例 |
| 验收滞后 | 做完不验收直接推进 | 问题在后期集中暴露，返工成倍 |
范围控制检查要点
范围控制检查要点
交付物与 WBS 的对应关系是否完整 # 逐条核对，避免漏项
验收记录是否覆盖每个交付物 # 没有记录的交付物等于没验收
未批变更是否明确标注为不进开发 # 待办里要能一眼看出状态
需求变更影响是否同步到进度与成本基准 # 只改需求不改基准等于没有控制
# 检查频率：至少每个报告周期一次，变更密集期缩短落地要点
- 给范围扩张留合法出口：建立一个待评估队列，让合理诉求有地方放
- 把验收标准写进需求条目，避免交付后对是否达标各执一词
- 需求跟踪矩阵要实时更新，滞后维护的矩阵没人会信
- 对镀金行为从绩效评价上明确态度，否则口头劝阻无效
范围蔓延通常发生在「顺手做一下」的场景；需要明确的例外处理与登记机制，而不是靠个人自律抵抗组织惯性。
把镀金当积极性表彰，团队会形成随意扩范围的惯例，后续再想收紧边界时会遭遇强烈抵触。
范围控制也需要与业务方对账：把已批准、待评估与被拒绝的需求都列出来给对方看，比单方面宣布不做的阻力小得多。