［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，＜與人相關的事＞才是你應該學習的專業。