项目复盘的常识，有一半经不起推敲

先看一句你可能听过的建议。

复盘的结论是『下次注意』，下次照样出问题。

这句话不算错，但它只在一个前提下成立——而这个前提，很多人的场景里并不满足。

先把项目复盘这件事的真实机制说清楚，再讲怎么做。

先说说那个流传很广的说法

只复盘失败，不复盘成功。不知道为什么赢，比不知道为什么输更危险。

这句话之所以流行，是因为它在某种情况下确实成立。但很多人把它当成通用规则，结果就是用错了场合。

真正的机制是这样的：方法本身没错，错在它假设了一个前提——而这个前提在你的场景里不成立。

真正管用的做法

下面这几条，可能和你现在的做法相反。先别急着否定，看完再判断。

1. 用『预期—实际—差异—原因』四问

每一问都要落到具体动作，不要停在『沟通不畅』这种万能结论上。

2. 区分『决策错误』和『执行偏差』

前者要改流程，后者要改工具或人手，两者的解法完全不同。

3. 给每条改进行动配一个负责人和复查时间

没有复查的改进，三个月后自动消失。

4. 复盘文档控制在两页

一页事实与数据，一页结论与行动。写十页没人看。

一个真实的反例

一个上线延期的项目做复盘。

做法是：团队把延期原因拆成三类：需求变更 11 次、测试环境不稳定 5 天、关键人请假 4 天。

结果是：结论只有一条：需求变更超过 3 次必须重新排期。下一版按时上线。

这个例子不复杂，难的是每次都这么做。可以照着做，也可以只挑其中一步先试。

整个过程里没有出现什么复杂工具，改的都是顺序和标准。这也是它能被复制的原因——不需要天赋，只需要不再省那一步。

几个常被问到的问题

问：照着做了，还是没效果，为什么？

答：不要只复盘不复查。三个月后回看，改进行动落实了几个。 先回头检查这一条，多数时候问题在这里。

问：要多久才能见效？

答：第一周通常只是熟悉流程，第二周才开始省时间。如果两周后完全没感觉，回头看看是不是漏了第一步。

问：第一步该从哪里开始？

答：复盘会第一页只放时间线和数据，不放评价。从这一件开始，别一次全上。

问：最容易犯的错是什么？

答：以『谁的责任』开场。一旦开始找人背锅，真话就没了。

几个容易踩的坑

这几条比方法更值得看，因为方法可以慢慢学，坑踩一次就要花时间填。

• 不要让复盘变成追责。一旦有人开始自保，信息就失真了。
• 不要用『沟通不到位』当结论。它什么都能解释，所以什么也解决不了。

明天就能做的事

不用全做，挑一件今天就能开始的。

• 复盘会第一页只放时间线和数据，不放评价
• 每条改进写成『谁、在什么时间、做什么、怎么检查』
• 三个月后设一个日历提醒，回看改进行动

可以直接用的一段话

如果你平时用 AI 帮忙，下面这段可以直接复制，把方括号里的内容换成你的情况。

以下是一个项目的经过，请用『预期—实际—差异—原因』四问帮我梳理，每个原因都要落到具体动作：

最后

反常识的说法值得听，但别急着全盘接受。拿一个你自己的场景试一次，比争论有用。

别急着推翻原来的做法，先试这一件：三个月后设一个日历提醒，回看改进行动。试完再判断。