入職不久的一位研發同學希望能組織一個會議討論評審他做的設計，我告訴他，你先看一下我寫的一篇公司內部博客。今天把我寫的這篇內部博客公開出來，希望能給業內的研發同學特別是研發負責人一點啟發。
我們在實際工作中，經常要做各種review（評審），包括設計、代碼、文檔等等。大家習慣性的做法，是召集相關的人開會，內容的負責人會走讀一次，介紹一下，為什么這么做，這么寫，然后匯集大家的意見做些調整。通過多年的實踐，我認為這套方法是走過場的，是形式主義的 review，難以達到 review 的目的。表現在幾個方面：
- review 的人沒有做充足準備，思路只能跟著主講人的思路跑，發現的問題往往是違反規范，或其他顯而易見的問題；
- review 的人提的問題是現場提的，不是經過思考提出來的，因此有可能是不完整的，甚至不合邏輯或錯誤的；
- 參與開會的人，很多是心不在焉的，整個會議是一句話都不說的，完全沒有產出。
那么怎么做有效果的 review 呢？我們需要做到以下幾點：
- 內容負責人提前準備好內容：對照<Amazon 的秘密管理武器 – 「6 頁備忘錄」> 檢查一下內容是否滿足要求。對于特別具體的文檔，比如背景、解決的問題或需求大家都十分清晰的，準備的內容可以直奔主題（但建議用參考文檔的方式放在內容最后，以免有不熟悉了解的人）
- 在 Confluence 的文檔里直接 @，或飛書通知相關的人進行 review，并給出需要收到 review 回復的時間。
- 所有需要 review 的人，在指定的時間之前，仔細閱讀內容，將自己的反饋直接寫在 confluence 或飛書文檔上。
- 內容負責人收到 review 反饋后，看反饋的意見是否可以接受或持不同意見。對于可以接受的，直接接受，更新內容。對于不接受的，或有疑惑的，可以在 confluence 或飛書里互動，但互動回合不宜超過 3 次，過多的話，最好語音溝通，或進行會議。
- 內容負責人如果覺得大家的反饋都被吸收、或疑惑都已經解決、澄清，那么無需組織任何會議，review 就完成了。
- 如果有書面交流爭執不下或模糊不清的，再決定召開會議。召集會議，參會的人，是必須已經提供過書面反饋意見的。沒有提過意見的，不應該邀請參會。
原則上，任何交流溝通都應該遵循《如何高效的溝通交流》里定的原則，而且要以書面文字為主，萬不得已，不采用會議方式。
這么 review 的好處是：
- 每個人是真正的 review 了，而且反饋、互動在系統里都有記錄；
- 任何時候，任何人都可以參與進討論，而且不會討論重復的問題；
- 盡可能不組織會議，這樣便于遠程辦公，便于不同時區的人協同工作；
- 避免濫竽充數，只聽不出的人參加會議。
那么有人總認為，只有會議、語音才能給大家解釋清楚自己做的工作、文檔、設計或代碼，這是錯誤的認識。任何一項工作、文檔、設計等等就必須用文字或代碼清晰的、邏輯的表達，只要有模糊不清的地方，一定是自己沒有想清楚。你可以明確告知大家，某一塊沒有想清楚，還模糊，求助大家，或等自己想明白，再清晰的用文字表達，之后請大家 review。
陶建輝
2021 年 10 月 18 日于北京
