入职不久的一位研发同学希望能组织一个会议讨论评审他做的设计，我告诉他，你先看一下我写的一篇公司内部博客。今天把我写的这篇内部博客公开出来，希望能给业内的研发同学特别是研发负责人一点启发。
我们在实际工作中，经常要做各种review（评审），包括设计、代码、文档等等。大家习惯性的做法，是召集相关的人开会，内容的负责人会走读一次，介绍一下，为什么这么做，这么写，然后汇集大家的意见做些调整。通过多年的实践，我认为这套方法是走过场的，是形式主义的 review，难以达到 review 的目的。表现在几个方面：
- review 的人没有做充足准备，思路只能跟着主讲人的思路跑，发现的问题往往是违反规范，或其他显而易见的问题；
- review 的人提的问题是现场提的，不是经过思考提出来的，因此有可能是不完整的，甚至不合逻辑或错误的；
- 参与开会的人，很多是心不在焉的，整个会议是一句话都不说的，完全没有产出。
那么怎么做有效果的 review 呢？我们需要做到以下几点：
- 内容负责人提前准备好内容：对照<Amazon 的秘密管理武器 – 「6 页备忘录」> 检查一下内容是否满足要求。对于特别具体的文档，比如背景、解决的问题或需求大家都十分清晰的，准备的内容可以直奔主题（但建议用参考文档的方式放在内容最后，以免有不熟悉了解的人）
- 在 Confluence 的文档里直接 @，或飞书通知相关的人进行 review，并给出需要收到 review 回复的时间。
- 所有需要 review 的人，在指定的时间之前，仔细阅读内容，将自己的反馈直接写在 confluence 或飞书文档上。
- 内容负责人收到 review 反馈后，看反馈的意见是否可以接受或持不同意见。对于可以接受的，直接接受，更新内容。对于不接受的，或有疑惑的，可以在 confluence 或飞书里互动，但互动回合不宜超过 3 次，过多的话，最好语音沟通，或进行会议。
- 内容负责人如果觉得大家的反馈都被吸收、或疑惑都已经解决、澄清，那么无需组织任何会议，review 就完成了。
- 如果有书面交流争执不下或模糊不清的，再决定召开会议。召集会议，参会的人，是必须已经提供过书面反馈意见的。没有提过意见的，不应该邀请参会。
原则上，任何交流沟通都应该遵循《如何高效的沟通交流》里定的原则，而且要以书面文字为主，万不得已，不采用会议方式。
这么 review 的好处是：
- 每个人是真正的 review 了，而且反馈、互动在系统里都有记录；
- 任何时候，任何人都可以参与进讨论，而且不会讨论重复的问题；
- 尽可能不组织会议，这样便于远程办公，便于不同时区的人协同工作；
- 避免滥竽充数，只听不出的人参加会议。
那么有人总认为，只有会议、语音才能给大家解释清楚自己做的工作、文档、设计或代码，这是错误的认识。任何一项工作、文档、设计等等就必须用文字或代码清晰的、逻辑的表达，只要有模糊不清的地方，一定是自己没有想清楚。你可以明确告知大家，某一块没有想清楚，还模糊，求助大家，或等自己想明白，再清晰的用文字表达，之后请大家 review。
陶建辉
2021 年 10 月 18 日于北京
