近期筆者所在的團隊對評審這件事兒有些頭疼，一方面是評審質量，另一方面是流程不夠明確。哪些要做評審？哪些可以不做？要做的必須要誰參加？達到什麼效果？如果所有內容都要評審，而且所有人都要參加，那麼乙個2周的版本中間光全體評審會就要開至少4次，再加上站會、小結會等，這樣的節奏團隊無法承受。今天筆者就這個問題跟大家談談自己的想法（所有的實踐也都是筆者親身嘗試過），希望能有所幫助。
工作中我們常見的評審可能有：需求評審、互動稿評審、視覺評審、研發設計評審、測試用例評審、**評審、上線計畫評審、運營推廣計畫評審等等。可是每個版本如果都這麼走一遭的話，還快的起來嗎？特別是在很多網際網路公司有些小版本也就5-10個工作日，這麼搞似乎吃不消啊。
那怎麼辦？接下來就跟著筆者的思路走一遭吧，相信中間有些點你也深有同感。
1. 直面問題
讓大家直面問題，對於評審需要得到團隊的共同認可以及對評審文化的真正理解，寫在最前面也是決定後面成敗的最重要一環。筆者會發現不同的企業文化對此的認知差別很大，而且接受程度也有很大差距。即便同一企業不同專案，對此的認知和認同也會不一樣。所以如果想能往下走，最重要的一步就是團隊共同認可，認可的基礎是理解為什麼這麼做以及所闡釋的理念。
評審的目的是基於大家對評審內容的理解後為了發現問題，提高評審內容的質量，確保接下來在做大家共同認可的事。評審後的輸出則是所有評審人員共同的輸出物，所有評審人員共同為此負責，而非只是owner。這點很重要，而且很多人都認為那是owner的事情，我只是去了解是什麼，然後覺得**不合適提提意見。所以會發現很多評審上風平浪靜，等互動案、視覺稿出了，反過來說這樣設計不合理，blabla……回過頭再去做重複功的情況時常發生。
只有得到團隊的認可和真正理解，接下來的事才能輕鬆且有效的往下走（這裡的輕鬆是指大家共同認可後的執行會更順暢，讓發起者更輕鬆）。而要讓團隊認可和真正理解，往往的實際情況是團隊在此確實遇到了問題，痛了，否則可能會認為竟是些有的沒的浪費大家時間的東西。所以讓團隊認可和理解這件事所選擇的時機其實也很重要，如果是讓團隊自己發現並丟擲來的效果往往要比旁觀者去講的效果要好的多。所以筆者所建議的形式是，在實際的工作過程中去發現，然後讓團隊參與去分析和解決，中間去引導大家舉一反三，最終達成大家所提出的共同認可的方式。
2. 團隊確認流程
2.1 確認一定要有的評審
在得到認同的情況下，由團隊或核心成員共同決策專案過程中各種評審的必要性和級別，有些是一定要有的，有些是在一定情況下要有的，有些則可選（一般可選的往往都是不會被執行的）。
必要性和級別的確定會根據當前團隊和專案型別及所處的階段不同會有所不同，比如，有些團隊在測試用例評審環節總是會發現很多問題，他們會將此評審優先順序作為必選。有些專案是偏視覺的比如官網風格等，則視覺評審變得很重要。有些專案是底層儲存資料類專案，設計文件以及上線計畫的評審是必須的等等。所以不同團隊、專案型別及所處階段不同會對此有不同的要求，需要團隊確認當前情況下專案過程中各評審的優先順序。
2.2 確定評審的型別和必須參與的角色
a) 確定評審型別。
需要先了解評審物件的重要性和複雜度，下一步要確認不同重要性的評審所採用的方式，可能是最為正規的會議評審，可能是略微輕鬆的站會評審，可能是郵件評審等；
這裡需要介紹下幾類評審的區別。
第一類最嚴肅的會議評審。相對正式，提前發出會議邀請和評審內容，通過正式會議的形式讓評審員共同確認評審物件並對有疑義的地方做確認，從而輸出大家共同認可的評審物件。
郵件/線下評審：通過郵件的形式，在郵件指定的時間範圍內，各自進行評審，並反饋意見。
b) 確定評審角色。
不同的評審物件所要求的評審成員可能是不同的，比如視覺評審，可能視覺主管、產品是必須的，互動、開發、測試是可選的；對於開發設計評審，可能對應開發主管和測試同學是必須的，互動、視覺是可選的。
所以要針對自己的專案和團隊組成情況，對不同評審內容的角色進行確定，以下圖為例，可以在團隊中共同確認這個**，作為後面參考的標準。
物件角色
需求案評審
互動案評審
視覺稿評審
開發設計評審
測試用例評審
策劃p0
p0p0
p1p1
互動p0
p0p0
p1視覺
p1p0
p0（視覺主管）
開發p0（開發主管）
p0（開發主管）
p0p0
qap0（qa主管）
p0（qa主管）
p0p0
運營p0（運營主管）
p12.3 關於執行
a) 評審會前
之前有嚴格按照此來做的，即用此環節來確保每個關鍵評審員都有提前看過材料，從而會上可以只針對問題展開討論，大大提高評審會上的效率，如果有人在會前沒有反饋那麼會延遲會議並發郵件說明是因為什麼而延遲，這樣下次基本就不會再出現這種情況。
而有些專案可能是一次性且週期很短的情況，當場講述比寫詳細的文件更高效，所以評審的材料會當場講述，然後大家提出疑義和反饋意見，可能會出現的情況是，短暫的會議時間想到的點不全，會後就過去了，或者會後再提出再進行溝通討論。
大家需要根據自己專案的型別以及團隊實際情況選擇適合的方式。
b) 評審會
如果發現critical或者block級別的問題，則團隊會上立即商議是否需要第二次評審會。
c) 評審會後
執行流程確認後，可以做個簡單的checklist進行確認
檢查表
確定進行哪種型別的評審？
正式會議
確定關鍵評審人員
xx、xx、xx
至少提前一天發出郵件
所有關鍵評審員是否可以參會？
開會前收到comments？p1
x進行評審會
通過？or 不通過？
所有待跟進問題解決了？
在現實的工作中會發現，評審會後的跟進往往容易被輕視，特別是一些未確定但不會影響當前進展的問題，往往是到了開發在做的時候再次被提出進行討論確認，甚至這些問題可能會引起更多問題，導致開發測試的重複功，所以待跟進問題的落實在團隊共同確定執行方式時也需要引起重視。
以上便是筆者關於評審各環節的一些認知和實際做法，從團隊共同認可（認可並深刻理解評審文化：大家共同對評審內容負責，而不是僅作者），到團隊共同確認流程（哪些型別是要做評審的，以及是何種程度的評審），再到具體執行（執行方式的選擇和確認），這些環節中最重要的就是第一步：團隊共同認可！只有大家真正認可和理解這件事，後面確定流程以及執行才能更深入人心。當然團隊的執行力也不容小覷，再完美的方案也需要落地才能見到效果。
網易雲大禮包：
關於整合測試 同行評審
整合測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求組裝成為子系統或系統，進行整合測試。整合測試目標 按照設計要求使用那些通過單元測試的構件來構造程式結構。整合測試兩種技術 1 功能性測試。使用黑盒測試技術針對被測模組的介面規格說明進行測試。2 非功能性測試。對模組的效能或可...
Charpter7 關於同行評審
1 目的 同行評審的目的是盡早地發現工作成果中的缺陷，並幫助開發人員及時消除缺陷，從而有效地提高產品的質量。2 定義 pdp project define process 專案自定義過程。3 過程概要 同行評審為了提高軟體質量和提高程式設計師生產率而被普遍應用的評審方法，在業界已取得很好效果。同行評...
關於物件導向思想
理解物件導向 物件導向是一種思想，是基於面向過程而言的，就是說物件導向是將功能等通過物件來實現，將功能封裝進物件之中，讓物件去實現具體的細節 這種思想是將資料作為第一位，而方法或者說是演算法作為其次，這是對資料一種優化，操作起來更加的方便，簡化了過程。物件導向有三大特徵 封裝性 繼承性 多型性 其中...