［PL的Project Management］Bug review可不可以不要這樣？

如果說有一種meeting常常讓人覺得浪費時間，卻又不得不參加，我想除了大拜拜的會議之外，應該有不少人會投bug review一票吧。

RD=>Function leader=>PL/PM=>Boss，RD是處於review環節中的最下層，也是實際上解決問題的人。Function leader是最接近RD的專家，不管是在專業上或人力資源上，Function leader是最有可能提供RD直接幫助的人。PL/PM雖然位置又高一些，基本上在專業上能提供的意見有限(除了一些PL本身的專家之外)，但是卻是有能力整合不同團隊，解決資源衝突或短缺的人。Boss關心的是整體的project進展，schedule的狀況，project team的狀態是否異常，對客戶的影響等，必要時對project外在的人力、資源和時間可以提供協助或決定。

了解每個角色可以做的事和專長做的事，對一些bug review時的奇怪狀況，就比較知道問題出在哪了。
Ａ、一個bug，RD要被review好幾次。
　　Function leader review一次問你能不能解，怎麼解，有什麼樣的solution選擇，需不需要某某某來幫忙，什麼時候可以完成。然後PM再來追一次，你的schedule，要你update status，積極一點的PM除了追蹤之外，還會重覆問一次Function leader會問的問題，雖然PM忘了他提供不了實質上的幫助，只是為了要詳細的追蹤和整理報告。然後PL再問一次，也許會多問一些是否需要其他team的人來幫忙之類的問題，但大部份的問題也是在重覆Function leader和PM的問題。
　　不能怪RD覺得很煩，因為一個bug這麼多人在問，又不能不回答，假設每個人問一個bug要花5分鐘，就已經花了15分鐘，更何況身上不是只有掛了一個bug。難怪RD必須要加班才有多一點的時間花在解bug上，這真的是很令人討厭。

　　有效率的review，先減少對RD無謂的重覆review吧！
　　PL必須意識到自己是無法也沒有時間去review project的每一個bug的，善用Function leader，他才是對靠近RD的人。只有在處理很嚴重的bug或已經卡住的bug時，真的有必要深入了解時再接觸的RD吧，不然PL只要跟function leader review就好了。要相信detail的bug review，function leader絕對是可以做得比你更好的。




Ｂ、一堆人一起review跟我沒關係的bug。
　　有些review meeting會找一堆人來一起review bug，而bug沒有先經過分類整理，被叫進來參與review的人關聯性也低，一個bug一個bug的review，有關係的聽，沒關係的就發呆，搞得聽也不是，不聽也不是，整個就像被歹徒綁架在會議室，感覺很差。

　　有效率的review，要避免浪費大家的時間。
　　Function leader、PL和PM要避免利用權力集合大家，只為了方便自己做事。先做好bug的分類，只找相關的人(bug owner、leader、上下游相關或專家)做review，才能真的達到集思廣義的效果，讓不相干的人參與，只會偏離目標而已。

Ｃ、Review只有壓力，沒助力。
　　＜Bug每天都被highlight是必解的issue，每天都被求update status，怎麼就沒人發現我已經掛了幾十條bug了，根本解不完呢！為什麼只是跟我沾上邊而已就是我要解呢？都說了需要誰誰誰來一起看也沒人理我。＞－－RD的心聲。

　　壓力是手段，而解決bug才是目的。壓力是有極限的，當RD真的卡住了，就必須伸出援手，了解RD需要什麼樣的協助才能解掉bug，不然即使再加壓，也只是把RD壓垮而已。PL是來救火的，不該是來放火的。

Ｄ、每個bug都是必解，就是每個都不必解
　　相信大家都明白每個bug的priority是1st priority，就是沒有priority。
　　通常VT已經會對bug做初步的priority或severity做設定，不一定要所有的bug都是high priority，只有夠多的bug是high priority(例如50%)就可能造成priority形同虛設。PL降低high priority的bug數(例如10%)，才能真的集中RD的火力在重點的目標上，即使真的有50%的bug都應該是high priority，PL也要想辦法找出其中最關鍵的10%，否則當RD對priority失去信任時，project的效率也將失去動力。

E、這個bug怎麼會assign給我？
　　很多時候，bug一開始是無法指定給對的人的，常常是最表面或最上層的先處理，而這類的RD也常常身上掛了較多的bug數，而且往往因為bug數太多導致無法即時處理，很多嚴重的bug因此被卡住，拖到很晚才被處理，一不小心很可能就成為project的瓶頸。
　　Function leader和PL除了自己要注意assign bug的準確度之外，也要多關注bug數太多的人是否有未被初步分析的bug，或是已經卡住多天未處理的bug，很可能就是bug找錯人了，該找到對的人才接手才是。


Bug review是為了加速解掉bug，會造成大家困擾或浪費時間的動作都是要避免的，提供協助、找對的人、降低bug卡住、集中火力在重點bug、相信function leader，才能提高bug review的效率。