##產品設計體會（四三）——說說評審會 我的感覺，評審就是項目相關的幾個小團隊的人坐在一起，一方講，另外幾方聽并確認，統一認識，消除誤解，防止偏差沒有及時發現而隨時間放大。這個過程不做，往往問題到很后才暴露，然后是誰的責任糾纏不清，與其亡羊補牢不如之前就在流程上預防，防病優于治病。 ? 項目過程中，比較大的三方面是PD、開發、測試，所以派生出三次評審，按照項目階段依次為： ? ????????? 需求評審，俗稱UC評審，在需求完成以后，是PD說給開發、測試聽；? ????????? 設計評審，在設計完成之后，是開發把對需求的理解以設計文檔的形式說給PD、測試聽，這部在時間緊的情況下會被省略（代碼評審現在幾乎不做）； ????????? 測試評審，俗稱TC評審，在TC寫完測試開始之前，是測試把對需求的理解以TC的形式說給PD、開發聽。 ? 評審的發起方，可以考慮都由QA發起，作為項目過程管理的一部分。也可以考慮每個評審由每個階段的負責人發起，在阿里通常是這樣做的。 ? 評審的主要過程： ? ????????? 確定參加人員，注意兩種容易被漏掉的角色：一是能做決定的人，因為評審的時候各方不可避免的會對業務有不同理解，從而開始對需求細節進行討論，這時候就需要有人能拍板，有人能負責；二是與此系統有接口的其他項目的成員，我們吃過太晚發現沖突的虧，改起來成本很高； ????????? 協調資源（時間、地點、設備），通常大家都很忙（包括會議室和投影儀），找個時間不容易； ????????? 事先分發文檔，保證參加評審的人有足夠的時間閱讀并思考，每個參加者也要做好功課，帶著問題參加（這點自己做的不好，=,=），避免出現評審會上第一次看到相關文檔的情況發生，否則評審是沒有效率的； ????????? 評審會本身，沒問題就快速的通過，有小問題當場確認，大問題帶回去，需要再次評審；最后是評審結果的發出，項目繼續往下走。