范围基线要写不做什么
只写要做什么，等于给后续追加留了口子。基线里明确列出本期不做哪些功能与场景，并在评审会上逐条确认，后续讨论才有依据，否则每次追加都要从头论证一遍，最后往往靠嗓门和职级决定，参与的人越多越难收敛。
变更走单一入口
所有新增需求进同一个需求池，由产品负责人评估影响后决定是否进入本期。多入口接收需求是范围失控最常见的原因，尤其在有领导直接找开发谈的时候，排期会在不知不觉中被改掉，而其他已承诺的节点没人再跟踪。
变更要标价
每个变更都应给出对工期与范围的影响，哪怕只是粗略量级。没有代价的变更会被无限提出；标价之后，提出方自己会先做一轮取舍，很多需求在这一步就消失，团队也不必反复解释为什么不加，沟通成本大幅下降。
验收前设冻结期
上线前留出两到四周冻结需求，只修缺陷不加功能。没有冻结期，测试永远在追新版本，质量无法收敛，上线日期一再推迟，团队长期处于救火状态，正常迭代能力被消耗殆尽，最后连缺陷也没人认真修。
风险登记册要有人看
把数据、合规、供应商、进度四类风险列成表，标出触发条件与应对人，每周例会上过一遍。只登记不复查的风险表，与没有登记几乎没有区别，还容易给管理层一种已经受控的错觉，真出事时才发现无人准备。
适用与不适用
适合谁
- 需求方多、随时可能追加功能的项目
- 跨部门协作、决策链较长的组织，需要提前设防
- 已经出现延期迹象、需要收紧范围的交付
不适合谁
- 范围已在合同中完全固定且无变更空间的采购
- 尚未确定基线就要求冻结需求的项目
典型场景
某银行的信贷材料辅助项目在第三个月遇到追加需求：风控部门希望增加材料完整性校验。项目组按变更单评估，显示需额外对接两个系统，决定放入二期。同期冻结期开始，团队专注修缺陷，上线时间未受影响，二期需求也在下一轮预算中正常立项，双方对流程的认可度反而更高。
可执行步骤
- 写清本期做什么与不做什么，由双方负责人签字确认后附在合同后面，作为变更评审的唯一基准
- 建立唯一需求池与变更单模板，向所有干系人公布受理方式与时限，避免私下受理
- 每个变更评估工期与范围影响后再决定去留，并记录决定理由，便于事后对账
- 上线前设需求冻结期，只修缺陷不改功能，例外须书面说明并留档，并指定例外审批人
常见坑
- 范围基线只写功能列表、不写排除项，追加时无法拒绝，只能靠加班消化，最后质量与进度一起失守。
- 领导直接找开发提需求，绕过变更流程，排期被悄悄打乱，其他承诺随之失效，团队既难解释，也无法追责。
- 变更不评估代价，团队长期超负荷，质量与士气同时下滑，核心成员往往先离职，项目陷入被动；编制也被迫收缩。
- 风险登记册建完就归档，触发条件出现时无人响应，小问题在两周内演变成事故，还被追问为什么没有预警。
自检与验收清单
- 范围基线是否含明确的不做清单，并由双方签字
- 是否只有一个需求入口与统一格式的变更单，并公布受理时限
- 每个变更是否标注影响量级与最终决定理由，是否留有记录
- 风险登记册是否每周复查并更新应对状态，是否有固定会议
常见问题
业务方坚持要加怎么办？
把变更影响摊开给他看：需要增加多少工期、会影响哪个已承诺的节点，由他决定取舍或申请追加资源。多数争议在信息透明之后会自然收敛，因为追加的代价第一次变得可见，也就有了讨论的基础。
冻结期会不会太僵化？
冻结期只约束功能新增，不约束缺陷修复与合规调整。对确有必要的紧急变更，可以设一个例外通道并要求书面说明，既保留弹性也留下记录，事后追溯时能看清是谁在什么情况下批准的。
小项目也需要变更单吗？
更需要。小项目没有专职项目经理，口头变更最容易失控。一张简单的变更单，写清内容、影响与决定人，成本很低，却能挡住大部分范围膨胀，也方便事后对账与复盘，避免各说各话。