项目延期时，真正要复盘什么

项目延期以后，复盘会很尴尬。

因为大家都知道项目没按时交，但每个人都能说出自己的理由：需求变了、接口晚了、测试环境坏了、线上问题插进来了、某个同事请假了、评审时没想到这个边界。

这些理由很多都是真的。

但如果复盘只是把理由摆一遍，最后再说一句“下次注意”，那基本等于没复盘。

项目延期以后，团队最容易陷入一种很累的复盘。

谁慢了，哪里估少了，哪天没有按计划完成，大家一项项往回翻。翻完以后，每个人都觉得有道理，但下次还是差不多。

因为真正的问题通常不在最后几天。

延期往往很早就有信号：需求没定死、依赖没到位、风险没人说、测试介入太晚，只是当时大家都觉得还能扛。

一、先别急着找谁的问题

延期以后，团队很容易进入一种防御状态。

开发怕被说效率低，产品怕被说需求没想清，测试怕被说卡上线，负责人怕被说计划没做好。

这种状态下开复盘，大家会本能地解释自己。

所以我更倾向于先把问题从“谁的问题”换成“系统哪里漏了”。

不是不追责任，而是先看清楚事情怎么一步步走到延期。

一个项目延期，很少只因为某个人慢。更常见的是多个小问题叠在一起：需求不清、依赖没跟、风险没报、排期太满、范围一直变。

二、复盘要看延期信号什么时候出现

项目延期通常不是最后一天才出现的。

它在中间就有信号。

比如：

关键接口一直没有联调。
需求评审后还在频繁补规则。
每日同步里总有人说“差不多快好了”。
测试用例迟迟写不出来。
核心成员开始频繁加班。
负责人需要每天手动协调细节。

这些都是信号。

复盘时要问：这些信号什么时候出现的？当时有没有被看到？看到以后有没有采取动作？

如果信号早就出现了，但团队没有处理，那延期不是意外，是一路放过去的结果。

三、计划有没有把不确定性算进去

很多计划表看起来很认真。

每个任务都有开始时间、结束时间、负责人。问题是它只排了“写代码”的时间，没有排“不确定性”的时间。

需求确认要时间，接口联调要时间，测试环境准备要时间，异常流程补充要时间，线上问题插入也要时间。

如果计划排得太满，任何一个小变化都会把后面全推倒。

复盘时要看：当初排期有没有留缓冲？风险任务有没有提前做？关键依赖有没有单独跟踪？

如果没有，下一次不是让大家更努力，而是计划方式要改。

四、范围变化有没有被记录

很多项目延期，表面看是开发慢，实际是范围变了。

一开始说做列表，后来加导出；一开始说简单审批，后来加撤回、转交、催办；一开始说支持一个角色，后来要支持多个角色。

这些变化每个都不大，但加起来就是另一个项目。

复盘时要把范围变化列出来。

不是为了抱怨，而是为了让团队知道：我们延期的一部分原因，是做的东西已经不是最开始那一版。

如果范围变化没有被记录，延期就会被误解成执行问题。

五、复盘要产出下一次的动作

好的复盘最后要有动作。

动作不要太多，也不要太虚。

比如：

1. 以后超过 3 天的需求，必须写清验收标准。
2. 涉及第三方接口的任务，排期前先做连通性验证。
3. 每周同步会单独检查延期信号，不只同步完成百分比。
4. 所有需求变更都要记录影响范围和是否调整上线时间。

这种动作才有用。

“加强沟通”“提高意识”“提前规划”听起来都对，但落不到团队日常里。

六、小结

项目延期时，真正要复盘的不是谁动作慢了。

更重要的是：目标是不是清楚，范围是不是变了，风险有没有提前暴露，依赖有没有被管理，计划有没有给不确定性留空间。

如果复盘只剩下解释和安慰，下次大概率还会一样。

复盘的价值，是让团队下一次更早看见问题，而不是下一次更熟练地解释延期。

本系列：