［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的成果很容易被忽略。

［PL的Project Management］關於人月，你要了解的

PL要懂得將project量化，例如code size量化、bug數量化、開發人月的量化等等，量化的目的是讓你對project有較整體性的概念，進而可以較準確的預估project所需要投入的成本(如人力、時間)和產生的結果(如可完成的功能數量、schedule的milestone時間點)。儘管量化的結果不一定準確，但是不可否認地量化愈精細，所考量的因素愈多，則數據的參考價值愈高。所以PL懂得量化project時，就會對project的掌握度愈高。

［讀書樂］愛．無所畏

我喜歡看歷史小說，總會想像自己是故事主角時，會是什麼樣的反應，如果身處當時的事件中，我可能會是什麼樣的角色，又是否可能改變歷史的發展？但是歷史總是歷史，你回不了過去，不能親睹諸葛亮舌戰群儒，也無法身歷其境去感受赤壁火燒連環船的震撼場面 ，讀完歷史總是會有這樣小小地遺憾。

＜愛．無所畏＞不是在說三國的故事，只是在說一群在台東的大人小孩的故事，雖然孩子的書屋是現在進行式，可是這本書卻讓我有讀歷史的感覺，書中每個人都有故事，充滿人生的曲折，每一個篇章都像幻燈片一樣，短短的幾頁中濃縮播放了故事主角的人生重要轉折，仍然不禁會想，如果是我，又會怎樣？跟歷史不一樣的是，我沒有感覺到遺憾，因為他們還沒有結束。有幸見證了這樣的事情在發生，也有幸可以付出一點心力，更有幸可以握住陳爸的手，那雙粗獷、厚實、有力的手仍記憶在我的腦海裡。

他們不是歷史，正在發生，也持續在寫他們的故事。

［PL的Project Management］想知道Project在什麼狀態？前期問RD，後期問測試！

想知道project在什麼狀態？可以簡單的依SW process phases把project分成二個部份，
1. 前期問RD
　Requirement、Design、Implementation的主角都是RD，PL想要掌握project的schedule進度，了解project的風險，知道哪些地方是弱點，不能只看RD的report，不能只看project file的進度完成度，這些是表面的。實際的和表面的存在多少落差，要問RD才能知道。
　Report有時候是不真實的，因為不少RD都不喜歡寫report，認為浪費時間，或不知道怎麼寫，或有些就只是為了應付，不想PL/PM來煩他，可能有多報少或少報多的情形。

［PL的Project Management］Lead and Learn

Project總是讓你學到東西，不管你是新手還是老手。

對於事情，或許你有自己解決的方法，但是因為你是PL，你可能會聽到其他三種不同的解決方法，你要學習分辨出哪一種最適合（不一定是最好）。
對於人，或許你懂得排解自己的情緒問題，但是因為你是PL，困難低落時你要激勵別人，達成目標時你要鼓舞團隊士氣。人的情緒是複雜的，有時完全沒有規則可言，但是你接觸的人愈多，你經驗值就會愈高。

［PL的Project Management］一旦失焦，很容易失火

Project要有焦點，焦點是集中火力投入資源的地方。
焦點對了，project就可以個個擊破，愈來愈順手。
焦點錯了，project就陷入瞎忙困境，愈來愈沒力。
而PL是應該指出焦點的人，指錯了或不指，都是問題。

什麼才是焦點對的位置呢？

＊、焦點放在Project的目的和特性
　　PL最重要的目標就是達成project的目的，了解project的特性才能正確定位project的焦點。
　　例如對平台型的project來說，穩定性和通用性是最基本的要求。平台當然也是希望功能愈豐富愈好，有時候因為客戶的要求把個別客戶的特殊功能加入平台。在Requirement phase時很容易就不小心把一堆不同客戶的功能加進來，這時如果PL沒有考慮好這些功能之間是否具有高度通用性，有沒有衝突互斥的情況，誤以為平台的功能多就是好，失去了平台型project最基本的焦點－穩定、通用，可想見RD要花多少時間和代價才能處理好衝突互斥的問題達到穩定的要求，而且未來客戶開project時，也可能搞不清楚那些功能如何使用。
　　反過來客戶project追求的是獨特性和時效性，沒有特殊差異化的賣點，就沒有市場的亮點。即使技術仍不成熟，穩定性只有80分，為了Time to Market，也是可能要先推出的，如果PL是抱著做平台的心態，凡事都追求一百分，要求完美，很可能就失去了Time to Market的契機。
　　另外其實不管是平台或客戶project，schedule永遠都是老闆會給的壓力，如果PL以schedule為藉口而對平台型的project便宜行事，求快而不求穩，那是不可取的，因為所有不穩定的後果只是延後到客戶的project才爆發，那時的代價會比原本的schedule delay還嚴重很多的。

＊、焦點在解開未知的黑盒子
　　＜未知＞是project最大的風險，PL不需要擔心問題太多，因為至少那些問題已經曝露出來，問題的解決只是時間的問題。PL的焦點要放在解開所有＜未知＞的黑盒子，想辦法把問題都攤在陽光下。

［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絕對是可以做得比你更好的。

［PL的Project Management］要關注bug在質與量的變化

Project的管理在進入Implementation phase(SW process)之後，不管是做Unit Test、Integration Test或System Test，大部份的時間都圍繞著bug打轉。
RD會注意的是自己身上掛的bug，重心自然在思考如何解決bug，然而PL要注意的是所有RD的bug，除了特殊的、嚴重的issue需要PL下decision而深入個案之外，PL應該多花時間關注整體bug在質與量的變化。

有幾個bug的趨勢比較明顯的，例如：
1、Bug發現的數量應該是收斂的　
　　理論上project是要往穩定的方向前進，每個階段或每個版本都應該比之前的完整和穩定，自然RD和VT發現bug的數量是會愈來愈少。
　　反過來如果沒有收斂的趨勢，或反而發散，那很可能出現類似分批健康檢查這樣的操作上的問題，或是沒有照SW process的步驟而引發不可控制的連鎖反應。PL如果放著不管，不即時改正錯誤的做法，那project將陷入無窮的測試迴圈。

［PL的Project Management］RD的schedule不應該是你給的，也不應該是給你的

如果RD給的schedule完全符合PL的原始的要求，PL應該有所警惕：

Ａ、RD是真的遊刃有餘，那有多少多餘的能量可以去幫助其他人？

Ｂ、RD是打腫臉充胖子，想以一天工作二十小時來滿足schedule，雖然勇氣可佳，但PL是必須找資源來幫忙的。

Ｃ、RD並不是明確的計畫，只是應付而已。這類RD的心態是有問題的，做好review的工作是可以把螺絲栓緊一點。

如果一群RD給的schedule完全符合PL的原始的要求，PL應該驚覺project已經危險。

如果PL清楚知道project team成員都是跑百米的好手，跑13秒以內是輕鬆的事，那就沒問題。

但是如果能力高低差異大，功能分工的難易差異也大，就像一場馬拉松跑下來，大家都在同一時間到達終點，可能嗎？

［PL的Project Management］不懂專業沒關係，但要懂人

Project Leader不懂專業沒關係，但要懂人。
這句話並不是說專業不重要，而是現在分工太細，想成為單一領域的專家往往已經要花個三五年的時間，而一個project又需要集各個團隊的力量才能完成，如果要一個PL什麼專業都懂，那是不是要學習個幾十年後再來呢？所以PL本來就不可能什麼都懂，除了原本自己本身的專業之外，其他領域的知識只是皮毛而已，很難比得過在該領域打滾多年的人。

既然如此，那PL要專的就不是業，而是人。
如果你想成為一位PL，＜與人相關的事＞才是你應該學習的專業。