關於評審--從思想到落地

本文來自網易雲社區

做者：劉煦萍

近期筆者所在的團隊對評審這件事兒有些頭疼，一方面是評審質量，另外一方面是流程不夠明確。哪些要作評審？哪些能夠不作？要作的必需要誰參加？達到什麼效果？若是全部內容都要評審，並且全部人都要參加，那麼一個2周的版本中間光全體評審會就要開至少4次，再加上站會、小結會等，這樣的節奏團隊沒法承受。今天筆者就這個問題跟你們談談本身的想法（全部的實踐也都是筆者親身嘗試過），但願能有所幫助。

工做中咱們常見的評審可能有：需求評審、交互稿評審、視覺評審、研發設計評審、測試用例評審、代碼評審、上線計劃評審、運營推廣計劃評審等等。但是每一個版本若是都這麼走一遭的話，還快的起來嗎？特別是在不少互聯網公司有些小版本也就5-10個工做日，這麼搞彷佛吃不消啊。

那怎麼辦？接下來就跟着筆者的思路走一遭吧，相信中間有些點你也深有同感。

1.      直面問題

讓你們直面問題，對於評審須要獲得團隊的共同承認以及對評審文化的真正理解，寫在最前面也是決定後面成敗的最重要一環。筆者會發現不一樣的企業文化對此的認知差異很大，並且接受程度也有很大差距。即使同一企業不一樣項目，對此的認知和認同也會不同。因此若是想能往下走，最重要的一步就是團隊共同承認，承認的基礎是理解爲何這麼作以及所闡釋的理念。

評審的目的是基於你們對評審內容的理解後爲了發現問題，提升評審內容的質量，確保接下來在作你們共同承認的事。評審後的輸出則是全部評審人員共同的輸出物，全部評審人員共同爲此負責，而非只是owner。這點很重要，並且不少人都認爲那是owner的事情，我只是去了解是什麼，而後以爲哪裏不合適提提意見。因此會發現不少評審上風平浪靜，等交互案、視覺稿出了，反過來講這樣設計不合理，blabla……回過頭再去作重複功的狀況時常發生。

只有獲得團隊的承認和真正理解，接下來的事才能輕鬆且有效的往下走（這裏的輕鬆是指你們共同承認後的執行會更順暢，讓發起者更輕鬆）。而要讓團隊承認和真正理解，每每的實際狀況是團隊在此確實遇到了問題，痛了，不然可能會認爲竟是些有的沒的浪費你們時間的東西。因此讓團隊承認和理解這件事所選擇的時機其實也很重要，若是是讓團隊本身發現並拋出來的效果每每要比旁觀者去講的效果要好的多。因此筆者所建議的形式是，在實際的工做過程當中去發現，而後讓團隊參與去分析和解決，中間去引導你們觸類旁通，最終達成你們所提出的共同承認的方式。

2.      團隊確認流程

2.1  確認必定要有的評審

在獲得認同的狀況下，由團隊或核心成員共同決策項目過程當中各類評審的必要性和級別，有些是必定要有的，有些是在必定狀況下要有的，有些則可選（通常可選的每每都是不會被執行的）。

必要性和級別的肯定會根據當前團隊和項目類型及所處的階段不一樣會有所不一樣，好比，有些團隊在測試用例評審環節老是會發現不少問題，他們會將此評審優先級做爲必選。有些項目是偏視覺的好比官網風格等，則視覺評審變得很重要。有些項目是底層存儲數據類項目，設計文檔以及上線計劃的評審是必須的等等。因此不一樣團隊、項目類型及所處階段不一樣會對此有不一樣的要求，須要團隊確認當前狀況下項目過程當中各評審的優先級。

2.2  肯定評審的類型和必須參與的角色

a)      肯定評審類型。

須要先了解評審對象的重要性和複雜度，下一步要確認不一樣重要性的評審所採用的方式，多是最爲正規的會議評審，多是略微輕鬆的站會評審，多是郵件評審等；

這裏須要介紹下幾類評審的區別。

第一類最嚴肅的會議評審。相對正式，提早發出會議邀請和評審內容，經過正式會議的形式讓評審員共同確認評審對象並對有疑義的地方作確認，從而輸出你們共同承認的評審對象。

第二類站會評審：相對形式活潑些，時間和地點都比較隨意，比較適合非關鍵性或很小的內容確認，幾我的在座位上一同確認評審對象並達成一致。

郵件/線下評審：經過郵件的形式，在郵件指定的時間範圍內，各自進行評審，並反饋意見。

b)      肯定評審角色。

不一樣的評審對象所要求的評審成員多是不一樣的，好比視覺評審，可能視覺主管、產品是必須的，交互、開發、測試是可選的；對於開發設計評審，可能對應開發主管和測試同窗是必須的，交互、視覺是可選的。

因此要針對本身的項目和團隊組成狀況，對不一樣評審內容的角色進行肯定，如下圖爲例，能夠在團隊中共同確認這個表格，做爲後面參考的標準。 

對象 角色	需求案評審	交互案評審	視覺稿評審	開發設計評審	測試用例評審
策劃	P0	P0	P0	P1	P1
交互	P0	P0	P0		P1
視覺	P1	P0	P0（視覺主管）
開發	P0（開發主管）	P0（開發主管）		P0	P0
QA	P0（QA主管）	P0（QA主管）		P0	P0
運營	P0（運營主管）	P1

2.3  關於執行

a)      評審會前

• 肯定是會議評審仍是郵件評審？

• 將評審材料提早至少一天發出，便於參會人提早了解評審內容；

• 全部關鍵評審員都要確承認以參加評審會議；

• 開會前收到全部關鍵評審員的反饋，此項標爲可選項，由於會發如今不一樣類型的項目以及不一樣的團隊，所適用的狀況是不同的。

以前有嚴格按照此來作的，即用此環節來確保每一個關鍵評審員都有提早看過材料，從而會上能夠只針對問題展開討論，大大提升評審會上的效率，若是有人在會前沒有反饋那麼會延遲會議併發郵件說明是由於什麼而延遲，這樣下次基本就不會再出現這種狀況。

而有些項目多是一次性且週期很短的狀況，當場講述比寫詳細的文檔更高效，因此評審的材料會當場講述，而後你們提出疑義和反饋意見，可能會出現的狀況是，短暫的會議時間想到的點不全，會後就過去了，或者會後再提出再進行溝通討論。

你們須要根據本身項目的類型以及團隊實際狀況選擇適合的方式。

b)      評審會

• 按照會議議程有序進行

• 將全部的comments用相應的工具記錄下來以便會後跟蹤

• 爲保證會議高效，每一個議題應控制在3~5分鐘

• 除了主持人，其它人員不準帶電腦

• 整個會議最好是1小時之內，不要超過2小時

若是發現critical或者block級別的問題，則團隊會上當即商議是否須要第二次評審會。

c)      評審會後

• 做者根據評審會上接受的建議進行更新

• 全部會上未有結論的議題，會後有公告，並將更新後的材料發出再次郵件確認

• 全部關鍵評審員對更新的材料進行再次審覈，沒有異議則Done.
  

執行流程確認後，能夠作個簡單的checklist進行確認

檢查表
1	肯定進行哪一種類型的評審？	正式會議
2	肯定關鍵評審人員	xx、xx、xx
3	至少提早一天發出郵件	√
4	全部關鍵評審員是否能夠參會？	√
5	開會前收到comments？P1	X
6	進行評審會
7	經過？Or 不經過？
8	全部待跟進問題解決了？

在現實的工做中會發現，評審會後的跟進每每容易被輕視，特別是一些未肯定但不會影響當前進展的問題，每每是到了開發在作的時候再次被提出進行討論確認，甚至這些問題可能會引發更多問題，致使開發測試的重複功，因此待跟進問題的落實在團隊共同肯定執行方式時也須要引發重視。

以上即是筆者關於評審各環節的一些認知和實際作法，從團隊共同承認（承認並深入理解評審文化：你們共同對評審內容負責，而不是僅做者），到團隊共同確認流程（哪些類型是要作評審的，以及是何種程度的評審），再到具體執行（執行方式的選擇和確認），這些環節中最重要的就是第一步：團隊共同承認！只有你們真正承認和理解這件事，後面肯定流程以及執行才能更深刻人心。固然團隊的執行力也不容小覷，再完美的方案也須要落地才能見到效果。

 

網易雲大禮包：https://www.163yun.com/gift

本文來自網易雲社區，經做者劉煦萍受權發佈

相關文章：
【推薦】 3分鐘掌握一個有數小技能：回頭客分析
【推薦】 30分鐘，讓你完全明白Promise原理
【推薦】 wireshark抓包分析——TCP/IP協議