［PL的Project Management］Review是你的武器

Project management有一個威力強大的武器－－Review。

依project的life cycle，一般RD都會經歷requirement review、design review、code review、bug review，也會有schedule review、risk review、document review等等不同的review。Review的時間點可能是daily review、weekly review或是依事件發生點來review。而review的參與者至少有owner和reviewer，常常也會有其他相關人員或專家參與。然後review會有記錄，會有actions。

Review是一個同步大家的認知並達成共識的過程，也是一種認證和背書的行為，目的是為了藉由不同人角度儘早發現問題，降低做錯而重做的程度和次數。當然review是要付出代價的，先不論owner準備review要花的功夫，光review這個動作就會佔用owner和reviewer的時間。Review的代價是顯而易見的，大家都看得到，也感受地到，但是review的成果卻是隱性的，除非有人把成果量化並且做出比較，不然review的成果很容易被忽略。


我們先借用一下The Math Behind Agile and Automation文章裡的三張圖，藍色線代表的是解決一個bug所需要的成本，可以看得出來愈後期cost愈高，而且決不會是簡單的線性關係。舉個簡單的狀況說明一下，例如在coding phase，RD是自己實作自己測試，發現bug時就自己解決就可以了，但是如果該bug沒有被RD發現而是一直等到testing phase時，由VT測試人員發現，該bug還是要回報給RD處理。簡單的流程，但是在成本上就有很大的差異，就project的角度來看，在coding phase解決bug的人力成本只需要RD而已，但進testing phase解決bug的人力成本就需要RD和VT。再來看時間成本，因為系統的整合關係，愈後期bug的複雜度愈高，RD需要更多的時間才能解決bug，而且bug解完了還需要交由VT花時間去驗證。而且實際project的操作上VT發現bug後，並不會馬上交給原本的RD，常常是需要經過好幾位RD的分析才知道造成bug的原因是什麼，最後才交給原本的RD處理。當然有時候也會由其他的RD找出其他的方法解決，只是要承擔這種非正解可能有side effect的後果。影響這麼多人，花了這麼多分析、溝通、驗證的時間，成本的差異相信是很明顯的。到出貨階段回報的問題，影響人就包含客戶、FAE、Sales、VT、RD，甚至可能嚴重到影響彼此的合作關係或賠上公司信譽，那成本就更可怕了。

而紫色線代表的是找到bug的分布，Figure A是一般project的情況，在測試資源加入後，會大量發現bug。將紫色線的bug數量乘上藍色線成本，全部加總起來就是全部解bug的成本，是project成本的重要指標之一。由圖可以看得出來，如果可以將紫色曲線往左(前期)移動，如Figure A移動到Figure B，成本就可以大大降低。甚至再把紫色曲線扁平化(愈早發現bug)，如Figure C，成本又會更低。好的project management就是把紫色曲線往左(前期)移動，再把紫色曲線扁平化(愈早發現bug)，project成本就可以大大降低，提高效率。Review是最簡單又直接的方式，review可以早期發現bug達到左移的效果，也因為有reviewer的參與，可以發現更多潛在的bug達到扁平化的效果，而且review還有很多附帶的好處，我們下一篇再來談這一塊。

Figure A

Figure B

Figure C

談這些圖形，其實是希望PL對review要有宏觀的概念，從大局來看，review是可以幫助project降低成本，提高效率的。有些人會認為review只是一種保險，做了常常白做，並沒有多發現什麼bug，在owner實作的品質很高時，的確有可能會沒發現什麼bug，但是過去project的實務經驗，這樣的比例很少，常常能力很強的RD在review時也會被reviewer發現bug，或是自己過程中先意識到潛藏的bug，而一般的RD就更不用說了。之前的project，有個RD一直被bug所苦，bug數一直高居榜首，而且每天解bug的速度還追不上VT發新bug的速度，RD都快被壓力壓得喘不過氣了。後來有幾次我幫忙做bug review，發現RD在把舊平台的AP翻譯成新平台的寫法時，對原本AP的設計邏輯不求甚解，所以寫出來的程式漏洞百出。這樣一個一個抓bug不是辦法，必須從根本著手，所以即使已經在測試階段了，我跟RD二個人辛苦地花了一個星期的時間一起去了解原本AP的設計邏輯，並且從頭到尾一行一行地做code review，意想不到的結果是還真的找出了二百多個bug (這麼多bug，我也真是嚇了一大跳)，其中包含了VT發的90%以上的bug。而review的過程中同時也把邏輯搞通了，bug也就順便解了。而在code review之前，RD一天差不多可以解5~6筆bug，一個星期也不過30筆左右，以RD人力成本來看，至少省了23個人天(我跟RD二個人花一個星期，2x5=10。RD自己解bug需要200/6=33。33-10=23)。

以RD的角度，就是發現bug，解決bug。解決bug跑不掉是要落在RD自己身上，但是對於發現bug，有些RD就會認為交給VT，用VT的時間來省自己的時間！這樣的做法無疑是把圖形中的紫色曲線右移(後期)了，對解bug的成本是大大增加的，是很不可取的，如果發現這樣的情況，PL應該要立即糾正。再從做事的態度來看也是一種不負責任的且自私的態度。PL應該要去了解RD會這樣做的原因，如果因為RD的loading太重了，造成他不得行此下策，那就要想辦法幫他分擔loading，如果發展是普遍的風氣，那就要想辦法灌輸正確的觀念和做事態度，或是更落實review的機制，透過制度面來減少這樣的漏洞。

Review是你的武器，用得好會加速你的project，但是濫用的話，也是會傷了你的project。幾個review常見的問題和陷阱，在這也做個提醒：
Ａ、Review流於形式，有制度卻沒效果
　　Review是專業的行為，是要能找現問題，而不是reviewer簽個名做做表面功夫。會流於形式表示大家還不認同review，需要多花時間在教育和溝通上，只有重視review並認真review時，才會看見效果。

Ｂ、Review沒有重點
　　剛開始review，會不知道怎麼review，該review什麼，重點在哪裡。Project可以針對不同的review定義各自的review重點。例如design review可以著重在solution的優劣選擇、架構設計、模組切割、Flow chart、Command/Data的sequence flow、Interface的定義等等。也可以整理出常犯的錯誤做為review的重點。一旦有review的重點，也可以提升review的效率。

Ｃ、找不到reviewer來review
　　Reviewer通常是找專家來擔任，但是有可能專家太忙，沒時間幫owner review，或是新的feature，沒有專家可以當reviewer。當沒有足夠的專家資源可以做reviewer時，leader、資深RD、能力強的RD或是feature相關的RD也可以當reviewer。Reviewer找相同function team的成員在review的溝通上會比較順暢。

Ｄ、Review成為一種干擾
　　Review的主角是owner和reviewer，基本上是二方協調好reviewer的時間地點就可以了。但是如果owner每實作一小部份就找reviewer做review，也會因為太過頻繁而中斷原本reviewer的工作。累積到適當的量或實作到某一個階段再來做review，才能有較整體的review，也不會讓review成為一種負擔。