我参加过不少回顾会，聊得都挺尽兴，最后什么也没变。问题从来不在形式，而在会后的跟进。最近轮到我来主持团队的回顾会了，把目前的想法写下来。
开会本身很容易#
结构简单得有点不好意思。冲刺或项目阶段结束后，团队坐下来回答三个问题：
- 哪些做得好？
- 哪些没做好？
- 有什么可以改进？
就这些。关键在于反馈循环：定期停下来，看看实际发生了什么，再把结论装回工作方式里。从不停下来的团队，只会原地打转。
有用的回顾会和吐槽大会的区别#
首先是坦率。只有确信说出来不会被记账，大家才会讲真正的问题，所以会场的安全感比选了哪种形式重要得多。而且最敏锐的观察往往来自不爱说话的同事——只有组长在讲的回顾会，不过是多了道工序的例会。
另一半在于讨论之后发生什么。值得修的问题，离开会议室时都应该变成有负责人、有截止日期的行动项。然后——多数团队跳过的就是这一步——下一次回顾会，从检查上次的行动项开始。没有什么比大家默默意识到行动项只是摆设，更能快速杀死回顾会。
可以的话，带点数据来。“这个冲刺感觉很慢”这类感想只会绕圈子，一张图表通常就能定案。
常见的翻车方式#
我近距离见过三种：开成批斗会的（要修的是系统，不是人）；一年到头用同一套形式、所有人进入自动驾驶的（换换花样）；以及完全没有跟进的。如前所述，最后一种是致命伤。
顺带说一句，这不只是软件行业的事。市场活动、活动运营、研究项目、制造业——凡是有重复周期的工作，这套循环都适用。但不管在哪儿开，检验标准只有一个：到下次回顾会之前，有没有什么真的变了？没有的话，那就只是聊了个天。