入職不久的一位研發(fā)同學(xué)希望能組織一個會議討論評審他做的設(shè)計，我告訴他，你先看一下我寫的一篇公司內(nèi)部博客。今天把我寫的這篇內(nèi)部博客公開出來，希望能給業(yè)內(nèi)的研發(fā)同學(xué)特別是研發(fā)負(fù)責(zé)人一點啟發(fā)。

我們在實際工作中，經(jīng)常要做各種review（評審），包括設(shè)計、代碼、文檔等等。大家習(xí)慣性的做法，是召集相關(guān)的人開會，內(nèi)容的負(fù)責(zé)人會走讀一次，介紹一下，為什么這么做，這么寫，然后匯集大家的意見做些調(diào)整。通過多年的實踐，我認(rèn)為這套方法是走過場的，是形式主義的 review，難以達(dá)到 review 的目的。表現(xiàn)在幾個方面：

1. review 的人沒有做充足準(zhǔn)備，思路只能跟著主講人的思路跑，發(fā)現(xiàn)的問題往往是違反規(guī)范，或其他顯而易見的問題；
2. review 的人提的問題是現(xiàn)場提的，不是經(jīng)過思考提出來的，因此有可能是不完整的，甚至不合邏輯或錯誤的；
3. 參與開會的人，很多是心不在焉的，整個會議是一句話都不說的，完全沒有產(chǎn)出。

那么怎么做有效果的 review 呢？我們需要做到以下幾點：

1. 內(nèi)容負(fù)責(zé)人提前準(zhǔn)備好內(nèi)容：對照<Amazon 的秘密管理武器 – 「6 頁備忘錄」> 檢查一下內(nèi)容是否滿足要求。對于特別具體的文檔，比如背景、解決的問題或需求大家都十分清晰的，準(zhǔn)備的內(nèi)容可以直奔主題（但建議用參考文檔的方式放在內(nèi)容最后，以免有不熟悉了解的人）
2. 在 Confluence 的文檔里直接 @，或飛書通知相關(guān)的人進(jìn)行 review，并給出需要收到 review 回復(fù)的時間。
3. 所有需要 review 的人，在指定的時間之前，仔細(xì)閱讀內(nèi)容，將自己的反饋直接寫在 confluence 或飛書文檔上。
4. 內(nèi)容負(fù)責(zé)人收到 review 反饋后，看反饋的意見是否可以接受或持不同意見。對于可以接受的，直接接受，更新內(nèi)容。對于不接受的，或有疑惑的，可以在 confluence 或飛書里互動，但互動回合不宜超過 3 次，過多的話，最好語音溝通，或進(jìn)行會議。
5. 內(nèi)容負(fù)責(zé)人如果覺得大家的反饋都被吸收、或疑惑都已經(jīng)解決、澄清，那么無需組織任何會議，review 就完成了。
6. 如果有書面交流爭執(zhí)不下或模糊不清的，再決定召開會議。召集會議，參會的人，是必須已經(jīng)提供過書面反饋意見的。沒有提過意見的，不應(yīng)該邀請參會。

原則上，任何交流溝通都應(yīng)該遵循《如何高效的溝通交流》里定的原則，而且要以書面文字為主，萬不得已，不采用會議方式。

這么 review 的好處是：

1. 每個人是真正的 review 了，而且反饋、互動在系統(tǒng)里都有記錄；
2. 任何時候，任何人都可以參與進(jìn)討論，而且不會討論重復(fù)的問題；
3. 盡可能不組織會議，這樣便于遠(yuǎn)程辦公，便于不同時區(qū)的人協(xié)同工作；
4. 避免濫竽充數(shù)，只聽不出的人參加會議。

那么有人總認(rèn)為，只有會議、語音才能給大家解釋清楚自己做的工作、文檔、設(shè)計或代碼，這是錯誤的認(rèn)識。任何一項工作、文檔、設(shè)計等等就必須用文字或代碼清晰的、邏輯的表達(dá)，只要有模糊不清的地方，一定是自己沒有想清楚。你可以明確告知大家，某一塊沒有想清楚，還模糊，求助大家，或等自己想明白，再清晰的用文字表達(dá)，之后請大家 review。

陶建輝

2021 年 10 月 18 日于北京