第 5 章 · 范围与变更、配置管理案例套路
案例套路要点
- 范围失控两类：客户不断加需求且 PM 来者不拒＝范围蔓延（被动、未控制）；开发自作主张多做功能＝镀金（主动、讨好）；
- 变更流程落地：任何范围/计划调整都走"提交变更请求 → 影响分析 → CCB 审批 → 实施 → 更新文档基线 → 验证关闭"；
- 配置配套：需求变更后必须同步更新需求文档、设计、测试用例，并重新形成基线、做配置审计，否则"代码与文档两张皮"。
🧪 自编例题（难度 ★★，建议 15 分钟）
题干：某银行客户项目采用固定总价合同。实施中客户要求新增"对账单邮件提醒"功能，项目经理没有上报，直接让团队加班实现；随后客户又口头提出想看看"余额变动短信"效果，开发顺手做了个演示版，客户看后很满意，默认会交付。验收阶段双方就"短信功能是否在合同范围内"发生争执，项目已超支 20 万元。
问题 1：题干中分别体现了哪两类范围问题？各用一句话说明。 问题 2：项目经理在处理客户需求时遗漏了哪些管理动作（至少 4 条）？ 问题 3：针对"短信功能"的现状，给出你认为正确的处理建议。
📖 答案要点（先自己做再展开）
Q1：① 客户新增"对账单提醒"且 PM 未走流程＝范围蔓延（被动接受、失去控制）；② 开发主动做"短信演示版"＝镀金（范围外主动添加，造成期望误导）。 Q2：未提交书面变更请求；未做变更影响分析（工作量/成本/进度）；未提请 CCB/合同方确认；未同步更新需求与配置基线；未就口头需求留下书面确认记录。 Q3：把"短信功能"正式提交变更评估：确认合同条款与工作量/成本影响，由双方协商价格与工期调整并签署书面变更/补充协议后再实施；若甲方不认可付费，应按合同约定处理（可交付演示但明确不承诺正式交付），避免口头默认造成履约争议。
🧠 记忆工具箱
- 辨范围问题先问"谁加的"：客户加＝蔓延（管住变更）；自己加＝镀金（管住手）；
- 固定总价合同尤其要"先变更后干活"：不签补充协议就干活＝白干＋超支；
- 一句话答范围题：
先评估 → 走变更 → 签协议 → 改基线 → 再实施。
⚠️ 易错提醒
- 镀金不是"客户满意就没事"——它破坏范围基线、抬高成本、还可能带来验收争议；
- 口头需求也是变更，书面化是关键动作（写进变更请求才算数）；
- 变更影响分析要覆盖"进度、成本、范围、风险"多维度，只估工作量会漏答扣分。