［ PL的Project Management］氣血不通是會生病的

當身體氣血不通的時候，輕微地會造成麻木，嚴重一點的就會疼痛生病，如果還置之不理，可能會有截肢或生命的危險。當Project的working flow和message flow出現扭曲或斷層時，就像身體的氣血不通一樣，是危險的訊號！

常常feature或bug需要跨不同的team處理，一般同team的溝通或協調是容易的，但是一旦跨team，就會變得複雜。例如feature的開發就常發生＜A說他在等B的東西，B說他在等A的東西＞，如果又少了一個強力的人介入協調，這樣的dead lock迴圈就會一直拖到最後關頭才爆炸。又像有些複雜的bug不是一個function的人可以處理，第一個接手的人可能只能澄清不是他的模塊造成的bug，但是卻也不知道是哪邊出了問題，該由誰來接手？或是剛好遇到一個資淺的RD，可能連是不是他的問題都要花很久的時間，而bug就這樣block在他的手上。



過去帶project的經驗，其實有很多時間都花在處理這樣的事情上，而這些事的重點就二個：flow的方向和路徑上的節點。所謂flow的方向簡單的說就是＜規則＞，例如：
＊、跨team的feature開發必須指定一個負責人，他來協調或決定衝突如何處理。
＊、限制嚴重等級較高的bug 幾天之內必須處理，不能處理的bug必須轉回給leader，由leader來處理。
＊、VT發的bug怎麼樣的流程才會轉到RD手上，RD解完bug又如何轉給VT驗證，驗證完又怎麼處理。
＊、每個team都有一個主要的接口負責人來協調處理跨team feature或bug的處理，讓RD清楚知道需要其他team的人幫忙時該找誰。

PL需要定義清楚這些規則，確保工作順利，大家的方向一致。大部份的規則都是繼承之前的project，在RD之間也形成默契，PL也不需要太擔心，除非是你的project有特殊的情況有新的規則，那就要確保整個project team都清楚明白新規則如何運作。

但是再好再完整的規則，都還是會出現問題，原因還是在於人，而人就是所謂的節點。像上面提到的feature負責人、leader、接口負責人，甚至RD和PL本身都是節點。處理人的原則是＜把對的人擺在對的位置上＞，愈是重要的角色，愈應該如此。愈大型的project，PL愈依賴節點可以發揮作用。想把對的人擺在對的位置上必須考量態度和專業。態度決定他是不是用心地想把事情做好，而專業能力愈強，做事愈有效率，而且往往一次就可以做對，少走很多冤枉路。

PL在每天review feature開發的進度或是review bug時，不應只是關注進度的百分比或bug解了沒，而是要從flow的角度切入，注意flow的流向是否正確，注意節點是否有卡住阻塞的現象，即時地改正或提供協助才能真正達到review的效果。例如有些bug很複雜很難找到原因，可能已經在RD之間轉了好幾手，常常聽到RD的說法是＜還沒找到問題原因，需要再多做實驗＞、＜問題已經很多人看過，不過都沒找到問題，我現在也不知道怎麼處理＞，如果沒有意識到這樣的轉來轉去的bug flow是有問題的，沒有意識到是不是沒找到對的人來解問題，那這樣的review就沒什麼效果，對RD也沒什麼幫助。

Working flow和message flow阻塞的現象會造成人力、時間、資源的耗損，大大降低效率和產出。PL要打通任督二脈，一旦氣血通了，相信project也就會順了。