开会本身很容易

#

结构简单得有点不好意思。冲刺或项目阶段结束后，团队坐下来回答三个问题：

1. 哪些做得好？
2. 哪些没做好？
3. 有什么可以改进？

就这些。关键在于反馈循环：定期停下来，看看实际发生了什么，再把结论装回工作方式里。从不停下来的团队，只会原地打转。

有用的回顾会和吐槽大会的区别

#

首先是坦率。只有确信说出来不会被记账，大家才会讲真正的问题，所以会场的安全感比选了哪种形式重要得多。而且最敏锐的观察往往来自不爱说话的同事——只有组长在讲的回顾会，不过是多了道工序的例会。

另一半在于讨论之后发生什么。值得修的问题，离开会议室时都应该变成有负责人、有截止日期的行动项。然后——多数团队跳过的就是这一步——下一次回顾会，从检查上次的行动项开始。没有什么比大家默默意识到行动项只是摆设，更能快速杀死回顾会。

可以的话，带点数据来。“这个冲刺感觉很慢”这类感想只会绕圈子，一张图表通常就能定案。

常见的翻车方式

#

我近距离见过三种：开成批斗会的（要修的是系统，不是人）；一年到头用同一套形式、所有人进入自动驾驶的（换换花样）；以及完全没有跟进的。如前所述，最后一种是致命伤。

顺带说一句，这不只是软件行业的事。市场活动、活动运营、研究项目、制造业——凡是有重复周期的工作，这套循环都适用。但不管在哪儿开，检验标准只有一个：到下次回顾会之前，有没有什么真的变了？没有的话，那就只是聊了个天。