项目延期以后，复盘会很尴尬。因为大家都知道项目没按时交，但每个人都能说出自己的理由：需求变了、接口晚了、测试环境坏了、线上问题插进来了、某个同事请假了、评审时没想到这个边界。这些理由很多都是真的。但如果复盘只是把理由摆一遍，最后再说一句“下次注意”，那基本等于没复盘。项目延期以后，团队最容易陷入一种很累的复盘。谁慢了，哪里估少了，哪天没有按计划完成，大家一项项往回翻。翻完以后，每个人都觉得有道理，但下次还是差不多。因为真正的问题通常不在最后几天。延期往往很早就有信号：需求没定死、依赖没到位、风险没人说、测试介入太晚，只是当时大家都觉得还能扛。一、先别急着找谁的问题延期以后，团队很容易进入一种防御状态。开发怕被说效率低，产品怕被说需求没想清，测试怕被说卡上线，负责人怕被说计划没做好。这种状态下开复盘，大家会本能地解释自己。所以我更倾向于先把问题从“谁的问题”换成“系统哪里漏了”。不是不追责任，而是先看清楚事情怎么一步步走到延期。一个项目延期，很少只因为某个人慢。更常见的是多个小问题叠在一起：需求不清、依赖没跟、风险没报、排期太满、范围一直变。二、复盘要看延期信号什么时候出现项目延期通常不是最后一天才出现的。它在中间就有信号。比如：关键接口一直没有联调。需求评审后还在频繁补规则。每日同步里总有人说“差不多快好了”。测试用例迟迟写不出来。核心成员开始频繁加班。负责人需要每天手动协调细节。这些都是信号。复盘时要问：这些信号什么时候出现的？当时有没有被看到？看到以后有没有采取动作？如果信号早就出现了，但团队没有处理，那延期不是意外，是一路放过去的结果。三、计划有没有把不确定性算进去很多计划表看起来很认真。每个任务都有开始时间、结束时间、负责人。问题是它只排了“写代码”的时间，没有排“不确定性”的时间。需求确认要时间，接口联调要时间，测试环境准备要时间，异常流程补充要时间，线上问题插入也要时间。如果计划排得太满，任何一个小变化都会把后面全推倒。复盘时要看：当初排期有没有留缓冲？风险任务有没有提前做？关键依赖有没有单独跟踪？如果没有，下一次不是让大家更努力，而是计划方式要改。四、范围变化有没有被记录很多项目延期，表面看是开发慢，实际是范围变了。一开始说做列表，后来加导出；一开始说简单审批，后来加撤回、转交、催办；一开始说支持一个角色，后来要支持多个角色。这些变化每个都不大，但加起来就是另一个项目。复盘时要把范围变化列出来。不是为了抱怨，而是为了让团队知道：我们延期的一部分原因，是做的东西已经不是最开始那一版。如果范围变化没有被记录，延期就会被误解成执行问题。五、复盘要产出下一次的动作好的复盘最后要有动作。动作不要太多，也不要太虚。比如：1. 以后超过 3 天的需求，必须写清验收标准。 2. 涉及第三方接口的任务，排期前先做连通性验证。 3. 每周同步会单独检查延期信号，不只同步完成百分比。 4. 所有需求变更都要记录影响范围和是否调整上线时间。这种动作才有用。“加强沟通”“提高意识”“提前规划”听起来都对，但落不到团队日常里。六、小结项目延期时，真正要复盘的不是谁动作慢了。更重要的是：目标是不是清楚，范围是不是变了，风险有没有提前暴露，依赖有没有被管理，计划有没有给不确定性留空间。如果复盘只剩下解释和安慰，下次大概率还会一样。复盘的价值，是让团队下一次更早看见问题，而不是下一次更熟练地解释延期。本系列：上一篇：代码质量不是靠 Review 喊出来的下一篇：怎么开一个不浪费人的技术会议系列目录：一个技术负责人眼里的软件团队