如何进行真正有效果的review (评审)?能不开的会是坚决不能开的

入职不久的一位研发同学希望能组织一个会议讨论评审他做的设计,我告诉他,你先看一下我写的一篇公司内部博客。今天把我写的这篇内部博客公开出来,希望能给业内的研发同学特别是研发负责人一点启发。

我们在实际工作中,经常要做各种review(评审),包括设计、代码、文档等等。大家习惯性的做法,是召集相关的人开会,内容的负责人会走读一次,介绍一下,为什么这么做,这么写,然后汇集大家的意见做些调整。通过多年的实践,我认为这套方法是走过场的,是形式主义的 review,难以达到 review 的目的。表现在几个方面:

  1. review 的人没有做充足准备,思路只能跟着主讲人的思路跑,发现的问题往往是违反规范,或其他显而易见的问题;
  2. review 的人提的问题是现场提的,不是经过思考提出来的,因此有可能是不完整的,甚至不合逻辑或错误的;
  3. 参与开会的人,很多是心不在焉的,整个会议是一句话都不说的,完全没有产出。

那么怎么做有效果的 review 呢?我们需要做到以下几点:

  1. 内容负责人提前准备好内容:对照<Amazon 的秘密管理武器 – 「6 页备忘录」> 检查一下内容是否满足要求。对于特别具体的文档,比如背景、解决的问题或需求大家都十分清晰的,准备的内容可以直奔主题(但建议用参考文档的方式放在内容最后,以免有不熟悉了解的人)
  2. 在 Confluence 的文档里直接 @,或飞书通知相关的人进行 review,并给出需要收到 review 回复的时间。
  3. 所有需要 review 的人,在指定的时间之前,仔细阅读内容,将自己的反馈直接写在 confluence 或飞书文档上。
  4. 内容负责人收到 review 反馈后,看反馈的意见是否可以接受或持不同意见。对于可以接受的,直接接受,更新内容。对于不接受的,或有疑惑的,可以在 confluence 或飞书里互动,但互动回合不宜超过 3 次,过多的话,最好语音沟通,或进行会议。
  5. 内容负责人如果觉得大家的反馈都被吸收、或疑惑都已经解决、澄清,那么无需组织任何会议,review 就完成了。
  6. 如果有书面交流争执不下或模糊不清的,再决定召开会议。召集会议,参会的人,是必须已经提供过书面反馈意见的。没有提过意见的,不应该邀请参会。

原则上,任何交流沟通都应该遵循《如何高效的沟通交流》里定的原则,而且要以书面文字为主,万不得已,不采用会议方式。

这么 review 的好处是:

  1. 每个人是真正的 review 了,而且反馈、互动在系统里都有记录;
  2. 任何时候,任何人都可以参与进讨论,而且不会讨论重复的问题;
  3. 尽可能不组织会议,这样便于远程办公,便于不同时区的人协同工作;
  4. 避免滥竽充数,只听不出的人参加会议。

那么有人总认为,只有会议、语音才能给大家解释清楚自己做的工作、文档、设计或代码,这是错误的认识。任何一项工作、文档、设计等等就必须用文字或代码清晰的、逻辑的表达,只要有模糊不清的地方,一定是自己没有想清楚。你可以明确告知大家,某一块没有想清楚,还模糊,求助大家,或等自己想明白,再清晰的用文字表达,之后请大家 review。

陶建辉

2021 年 10 月 18 日于北京