01 · 先弄清这是什么会
评审做出来的东西，回顾做事的方法
这两个会经常被混在一起。
复杂工作不可能一次计划正确。需求会变，理解会偏，方案要试，人与人的配合也会出问题。所以团队不能只顾着往前冲，还得定期停下来看看：哪里总在浪费力气？什么已经不适合了？
回顾会不是回头算账，
而是给下一轮换一种走法。
02 · 记住这三句话
好复盘，不靠漂亮流程
不怪人，但一定要解决问题
不追着谁犯了错，不等于谁都不用负责。要做的是把事情讲清楚，并一起把下一次做得更安全、更顺。
先问“当时为什么会这样做”
事后看什么都明显。当时的人可能看不到数据、等不到决定，或者以为别人已经检查过。先还原当时的处境，才找得到真正的漏洞。
最后只改一两件事
二十条建议通常等于零。选最重要、团队又能改变的一两件，放进下个 Sprint，还要约好什么时候回来验证。
一个实用的问题：如果把当事人换成另一个普通同事，这个问题还可能发生吗？
如果答案是“会”，就别只盯着那个人。
03 · 三个小故事
真正要看的，是事情背后的规律
总是延期
团队一直以为开发太慢。把时间线摊开才发现：真正开发只有 3 天，等澄清、等接口、等验收和返工用了 9 天。
别再催人快一点。先把等待和交接减下来。
实验没成功
增长实验没有带来购买转化，但点击确实增加了。团队因此发现，真正卡住用户的不是吸引力，而是信任感。
结果没达到，不代表白做；关键是我们是不是因此知道下一步该往哪走。
英雄又救火
骨干熬夜保住了交付。感谢他的担当之后，团队又问：为什么只有他会修？为什么问题总到最后才出现？
要感谢英雄，更要让团队以后不必总靠英雄。
成功也值得回顾。因为成功可能来自好方法，也可能只是有人通宵、碰巧走运，或者把风险留给了以后。把原因讲清楚，偶然成功才会变成团队能力。
04 · 下次直接这样开
60 分钟，够了
一场有用的回顾会
05 · 管理者尤其要注意
你越早下结论，大家越不敢说真话
管理者一开口就说“本质还是责任心不足”，后面的人只会顺着这个答案说。更好的做法是最后发言，先问事实；也可以先说清自己哪里没有做好，比如优先级反复、取舍太慢、授权不清。
还有一件更现实的事：要给改进留时间。如果每次复盘都说要改，下一轮却还是把所有时间塞满业务任务，团队很快就会明白：组织只想听改进，不是真的允许改进。
一场好的回顾会结束时，团队不一定更开心，
但会更清楚：下次准备换哪一种做法。