真实问题
“版本延期两周了，研发说需求总变，产品说研发估期不准，怎么办？”
问题判断
延期的核心不是谁背锅，而是范围变更和交付承诺之间没有硬边界。
没有冻结点和变更代价，团队会默认边做边改。继续讨论责任无法恢复进度，必须先重建交付规则。
为什么这是核心问题
估期只能在范围相对稳定时成立。
- 需求持续变化会反复打断开发、测试和联调，原估期自然失效。
- 新增范围没有替代成本，提出需求的人不会感受到交付代价。
- 泛进度会只汇报“完成百分比”，却看不见真正决定上线日期的阻塞。
行动建议
今天先把版本切成一个可控交付面。
重排剩余范围
把所有未完成项分成必须上线、可降级、可后置三类，只保留能完成本版本目标的最小集合。
建立范围冻结点
冻结后新增需求默认进入下个版本。紧急插入必须由结果负责人批准，并砍掉同等工作量。
每天只看关键路径
列出会改变上线日期的任务、负责人和阻塞解除时间，停止用泛进度会替代问题处理。
交付与复盘条件
先让版本落地，再区分估期问题和变更问题。
- 本版本上线条件：必须项完成、关键阻塞清零、降级方案可接受、回滚路径明确。
- 进入下个版本：可后置项和冻结后新增需求，不通过口头承诺绕过排期。
- 上线后复盘：分别统计原始估期偏差、范围新增量、返工量和阻塞等待时间，再修正流程。
常见问题
延期后怎样恢复交付边界？
- 项目延期后应该先追责还是先缩范围？
- 先恢复交付。把剩余功能分为必须上线、可降级、可后置三类，冻结范围并恢复关键路径。版本可控后再复盘估期和变更责任。
- 需求冻结后还能插紧急需求吗？
- 可以，但必须由结果负责人明确同意，并砍掉同等工作量或接受新的交付日期，不能无代价增加范围。