本文是《技术开发到团队管理》30 天系列的第 26 篇。这个系列关注的不是管理术语，而是技术负责人每天要做出的真实判断。
延期只是结果信号。范围增长、依赖延迟、估算偏差、质量返工和风险晚报都可能导致同一结果，需要不同处理。
这篇文章尝试回答三个问题：这个概念解决什么管理难题，管理者需要采取哪些具体动作，以及如何在真实项目中验证它。
核心观点
今天我们学习「常见场景一」。处理延期不是先追问谁慢了，而是恢复事实、评估影响、保护核心目标，并建立新的可执行承诺。
方法框架
1. 恢复事实
恢复事实：剩余交付物、已知阻塞、关键路径、完成标准和真实进度。
2. 评估影响
评估影响：业务窗口、用户、成本、质量底线及其他项目。
3. 选择方案
选择方案：缩范围、调顺序、补资源、解决依赖、延期或分阶段发布。
4. 重新承诺
重新承诺：同步取舍、负责人、新里程碑、风险和升级条件；完成后复盘机制。
一个具体案例
大促项目不足以按原范围上线。团队保留优惠计算、运营配置和发布保障，延期复杂报表；用真实数据验收并建立每日风险检查。
常见误区
加班和加人不是默认答案。任务不可并行或新人上手成本高时，增加人员会进一步拖慢关键路径。
行动练习
为一个延期项目写一页恢复计划：事实、影响、不可突破底线、三个选项、推荐决定、新检查点。
留给自己的问题
- 发现延期时第一步是什么？
- 我如何区分症状和根因？
- 我会怎样向业务说明取舍而不是只汇报坏消息？
小结
处理延期不是先追问谁慢了，而是恢复事实、评估影响、保护核心目标，并建立新的可执行承诺。