版本要延期了，你怎么处理？

我的处理：先定位原因与影响——是范围蔓延、低估复杂度、资源被抽走还是质量问题；然后重新决策——砍范围保时间是首选，明确这版的 must have 与 can wait；透明同步——干系人尽早知道新时间与原因，附影响面；复盘机制——同样原因的延期不允许第三次出现。核心：延期是事实管理，不是瞒报游戏。

我讲一次处理：版本还剩两周，开发评估核心模块要超一周。我做了三件事：一是拆——把需求拆成『这版必须有』三件事和『可以下版』两件事；二是换——其中一个功能降级为配置开关控制的灰度发布；三是透明——当天同步业务方新计划并给出补偿方案（提前预热物料）。结果按期上线核心价值，下版补齐。复盘发现根因是我验收标准定义太晚导致返工，之后我把验收标准提到开发排期前。

资深视角：延期管理的前置比补救重要。事前——排期用三点估算法加缓冲透明化，需求变更设代价门槛，里程碑中间检查点；事中——尽早暴露风险是美德，我建立风险日历，每周扫一次黄灯项；事后——延期分类统计，范围类问题改需求管理流程，估料类问题沉淀基准数据。另一个视角：延期本身有时是正确决策——为质量延期要敢于承担，关键是区分『该延』与『管理失败』。

追问『业务方不接受延期怎么办』：给选项而非通知——砍范围、加资源、延期、分批上线四个选项让业务方选，决策权交出去；『怎么向上汇报』：事实加原因加方案加新承诺，不解释性铺垫；『开发总低估怎么办』：历史校准数据反馈给团队，排期评审时用类比法（和哪个已完成的类似）而非拍脑袋。