［PL的Project Management］續談Review

延續上一篇［PL的Project Management］Review是你的武器，再從其他角度來談談review這件事。

１、是浪費還是節省？
　　Review是需要人和時間的，reviewer至少一位，是否需要多個reviewer，可以視重要程度調整，像project前期的requirement phase和design phase、key feature、跨team合作複雜度高的，就值得多投入幾個reviewer。
　　Requirement phase要的是明確的需求，沒有模糊空間，而design phase要有清楚易懂的設計，並且確實可行，還要讓介面明白與其他人溝通合作沒有問題。過去開發平台時，在requirement phase和design phase我自己小team內的人都是reviewer，5~6個reviewer也許多了，但對於平台的基礎建設我們願意這樣做，而且其實佔用reviewer的時間並不多，owner 3~5天的工作量，reviewer花1~2個小時offline review加上1個小時review meeting就可以review完了，約多花了20%左右的人天成本做review。而投入的20%成本找出來的問題，可以期待節省未來5倍以上的debug時間(上一篇我多花了5人天review，至少節省了23人天的debug)。
　　在project schedule上，一般PL/PM如果沒有review的觀念，看到RD在working item上列OOO review和XXX review等等，會很緊張，因為他看不到review所節省下來的debug時間，只看到的schedule多了20%。而通常project schedule從requirement、design到implementation是較可以精確估算的，所以PL/PM甚至老闆會誤以為project在implementation結束就可以等著準備量產了，所以會非常計較那多出來的20%，認為project因此delay了20%的時間，而忘了verification的測試階段才是真的見公婆的時間（如果公司內部的VT權力不夠大，那就只好遞延到客戶的測試才算公婆了）。有個真實的案例，該project的人天成本分布比例是(requirement+design+implementation phase) : verification phase = 1 : 3，而且在bug數比是內部project : 客戶project = 5 : 4 (以前project平均是5 : 1)。數據其實也容易取得，大部份公司對bug都是有控管記錄的，用點心檢視一下就知道了，project phase的時間點也有清楚的milestone，加上每個phase投入的人力就可以計算出人天成本了。我們先不管project management方面的問題，很明顯地該project就是忽略下圖藍色曲線代表的成本觀念，在前期requirement phase和design phase投入的成本cost是最最最便宜的，所以不在這時間多撿便宜多抓bug，那才真的是叫浪費。

２、Review會遇到的阻力
　　相信我，阻力不會來自下面的RD，只會來自上面的PL/PM和老闆。
　　RD是很容易配合接受做review的，因為都知道review是在幫他解決問題。
　　PL/PM和老闆的阻力，根本的原因還是因為不了解上面圖形的關係，看不到review的價值，所以就會以schedule的壓力、客戶的壓力為藉口而不做review。而且因為PL/PM和老闆是有權力左右project的人，一旦他們不同意，review就會無法進行。
　　想要排除阻力，只能從觀念下手。當老闆、PL/PM了解review不但不會讓project delay，更會大大縮短project周期，才有可能認同review，去建立review的機制。
　　如果你有心，可以試著統計過去project的數據(man-day、schedule時間、bug count、bug cost per phase等等)，拿數據給老闆看，會更容易說服老闆。

３、Review對Function team有什麼好處？
　　一般project team是從function team編組而來的，project上的review其實也是function team RD的review，只是review的內容是project的feature罷了。Project team的review效果，要依賴function team對review的落實程度，這裡function leader就變成了主角，因為這關係到function leader希望他的team變成什麼樣子。
　　其實以之前提到review可以降低project成本和增加project效率為理由，function team就應該全力配合了，但是實際上review所帶來的好處，遠遠是function team得到的比project team多！為什麼呢？因為Project team時暫時的編組，Function team才是組織圖上的常態單位，不管project有多重要，project一旦結束，project成員全都歸建回原function team。RD在project時的能力累積，最後全都回饋到function team。
　　撇開project來說，Function team重視review又會有什麼好處呢？列幾點給function leader參考一下：
Ａ、建立Backup人選
　　Reviewer就是owner最好的backup人選，尤其是固定review該function的reviewer。
　　當project很多事情很多事，function leader最常遇到的困擾就是人力不足，但是跟老闆說要補人卻總是被打搶。其實function leader可以思考一下，是真的人力不足，還是人力分配不均？是否過度依賴某幾個關鍵人力？是否只有少數人懂關鍵feature，其他人也幫不上忙？有沒有X某某感冒請假，ＯＯＯ feature就開天窗了？這些問題，透過review可以幫你解決。
　　過去我的member中有二位女生，都發生過因為生小孩休假而有快二個月的空窗期，一次是由我自己cover其中一位的工作內容，因為我一直是她的reviewer，大致了解她負責的feature，負責期間不只負責maintain，還開發了新的功能。而另一次則由其他幾個member分別share她的工作內容，當然工作不是不管接得人懂不懂，而直接硬塞給他，而是因為大家分別都擔任不同feature的reviewer，即使不是實作的人，但是review的過程中都了解feature的設計邏輯，甚至特殊使用的技巧，接手過程並沒有什麼大問題，頂多就是考慮大家loading均不均衡的問題，而並不需要考慮專業能力是否足夠的問題。
　　Review是建立backup人選很好的方式，它是循序漸進的，接的人不會錯愕，原本的owner也會放心，不會擔心回來會需要收拾爛攤子。當每個function都有backup的人選時，function leader在人力的配置上就更有彈性了，像上面提的問題，就很容易有解決的方式。

Ｂ、訓練溝通表達能力
　　Owner要說清楚，reviewer要聽明白。一說一聽之間，角色再互換一下，每一次的review都在訓練溝通表達能力。

Ｃ、增加相互學習機會
　　Review時會提出質疑，可能是從你沒想過的角度切入，每一次的質疑都是衝突，會引發你思考是要同意或反駁。Owner和reviewer都可以在review過程中有所收穫。

Ｄ、增進彼此感情和信任感
　　當RD在feature A是owner，但在feature B是reviewer時，他會感謝feature A的reviewer在幫他，同時也會願意花時間去幫feature B的owner (我相信大部份的人是這樣)。Review可以透過feature建立RD之間的連結，連結愈多，感情會愈好，信任感也會增加，甚至會不自覺地就會形成一種團隊中的默契。

Ｅ、當Reviewer是一種肯定
　　當一個RD從一直被review到可以成為reviewer去review別人時，那是一種肯定，一種promotion，一種脫離菜鳥的象徵。對企圖心強或學習慾望強的RD，當reviewer更是跨出自己領域的機會。所以review也幫function leader創造了無形的獎杯，善用獎杯可以刺激RD的熱情和動力。

Ｆ、養成良好的習慣
　　大部份的RD自尊心是很強的，沒有人希望在review時被找出一堆問題，那會感覺很丟臉。這種不想丟臉的感覺，會自己要求RD做好自己該做的事，久了就會成為一種習慣。
　　你會發現公司內有些team讓人的感覺就是很專業，合作起來會很愉快，反之也會有些team讓人認為不專業也不想合作的，比較一下，應該會找出一些好習慣和壞習慣的差異，當然把習慣換成態度也是一樣的道理。

Function team是一組織的單位，只有一個function team做review，只能改善一個function team，有幾個function team做review也只是區部改善而已。Project中100個feature都沒問題，只要有一個feature出狀況，它就是critical path，就是bottleneck，整個project schedule仍卡在這裡。組織也像project，function team就是feature，一個function team不配合做review，對老闆來說，整個組織也會卡在那裡。簡單的說，想要推展review，由下而上的效果只是獨善其身而已，而由上而下要求review，才是兼善天下的做法。