第 5 章 · 范围与变更、配置管理案例套路
案例套路要点
- 范围失控两类：客户不断加需求且 PM 来者不拒＝范围蔓延（被动、未控制）；开发自作主张多做功能＝镀金（主动、讨好）；
- 变更流程落地：任何范围/计划调整都走"提交变更请求 → 影响分析 → CCB 审批 → 实施 → 更新文档基线 → 验证关闭"；
- 配置配套：需求变更后必须同步更新需求文档、设计、测试用例，并重新形成基线、做配置审计，否则"代码与文档两张皮"。
🧪 自编例题（难度 ★★，建议 15 分钟）
题干：某银行客户项目采用固定总价合同。实施中客户要求新增"对账单邮件提醒"功能，项目经理没有上报，直接让团队加班实现；随后客户又口头提出想看看"余额变动短信"效果，开发顺手做了个演示版，客户看后很满意，默认会交付。验收阶段双方就"短信功能是否在合同范围内"发生争执，项目已超支 20 万元。
问题 1：题干中分别体现了哪两类范围问题？各用一句话说明。 问题 2：项目经理在处理客户需求时遗漏了哪些管理动作（至少 4 条）？ 问题 3：针对"短信功能"的现状，给出你认为正确的处理建议。
📖 答案要点（先自己做再展开）
Q1：① 客户新增"对账单提醒"且 PM 未走流程＝范围蔓延（被动接受、失去控制）；② 开发主动做"短信演示版"＝镀金（范围外主动添加，造成期望误导）。 Q2：未提交书面变更请求；未做变更影响分析（工作量/成本/进度）；未提请 CCB/合同方确认；未同步更新需求与配置基线；未就口头需求留下书面确认记录。 Q3：把"短信功能"正式提交变更评估：确认合同条款与工作量/成本影响，由双方协商价格与工期调整并签署书面变更/补充协议后再实施；若甲方不认可付费，应按合同约定处理（可交付演示但明确不承诺正式交付），避免口头默认造成履约争议。
🧠 记忆工具箱
- 辨范围问题先问"谁加的"：客户加＝蔓延（管住变更）；自己加＝镀金（管住手）；
- 固定总价合同尤其要"先变更后干活"：不签补充协议就干活＝白干＋超支；
- 一句话答范围题：
先评估 → 走变更 → 签协议 → 改基线 → 再实施。
📚 深度精讲（重点精细版）
一、变更影响评估模板（五维度，缺一不可）
| 维度 | 要评估什么 |
|---|---|
| 范围 | 新增/减少哪些可交付成果，是否需要更新 WBS 与基线 |
| 进度 | 影响哪些活动、是否触及关键路径、工期变化 |
| 成本 | 人力与采购增量、预算是否超支、是否动用储备 |
| 质量 | 对测试与验收标准的影响、是否需要补充测试 |
| 风险 | 新技术/新接口带来的新风险与应对 |
二、变更记录必备要素（补充完善题常考）
变更编号、提出人、提出日期、变更内容、影响评估结论、审批人/CCB 决议、实施责任人、计划完成时间、验证结果与关闭状态。
三、配置管理检查清单（考场快速扫）
- 是否建立开发库/受控库/产品库并明确权限？
- 需求、设计、代码、文档是否纳入配置项并编号？
- 变更后是否更新基线并做配置审计（功能审计对需求、物理审计对清单）？
- 测试与交付使用的版本是否一致（有无"版本错乱导致重复测试"）？
四、自编练习（难度 ★★）
情景：某项目验收前，客户提出增加"数据导出 Excel"功能。项目经理口头答应，让开发直接改动并发布，未更新需求文档与测试用例。上线后客户发现导出字段与约定不一致，双方就"是否在合同范围内"产生争议。
问：① 指出问题（至少 4 条）；② 说明正确做法；③ 若已完成开发，应如何补救？
📖 答案要点
① 问题：未提交书面变更请求；未做影响评估（范围/进度/成本/质量/风险）；未更新需求文档与配置基线；未补充相应测试用例；口头承诺造成履约争议。 ② 正确做法：先提交变更请求 → 五维度影响评估 → 报 CCB/客户确认 → 签订变更或补充协议 → 更新文档与基线 → 实施 → 验证关闭。 ③ 补救：补做变更记录与影响评估，与客户书面确认字段与验收标准，补充测试并回归验证，同步更新配置项与版本，必要时签署补充协议明确费用与工期。
五、命题角度与背诵卡
- 命题角度：蔓延/镀金辨识、变更流程顺序、影响评估维度、配置审计类型、补充完善要素；
- 背诵卡：先批后干、书面留痕；影响评估五维度：范围进度成本质量风险；功能审计对需求、物理审计对清单。
⚠️ 易错提醒
- 镀金不是"客户满意就没事"——它破坏范围基线、抬高成本、还可能带来验收争议；
- 口头需求也是变更，书面化是关键动作（写进变更请求才算数）；
- 变更影响分析要覆盖"进度、成本、范围、风险"多维度，只估工作量会漏答扣分。