2013年5月29日

[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的焦點要放在解開所有<未知>的黑盒子,想辦法把問題都攤在陽光下。

2013年5月20日

[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時的奇怪狀況,就比較知道問題出在哪了。
A、一個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絕對是可以做得比你更好的。


2013年5月17日

[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將陷入無窮的測試迴圈。

2013年5月16日

[PL的Project Management]RD的schedule不應該是你給的,也不應該是給你的



如果RD給的schedule完全符合PL的原始的要求,PL應該有所警惕:
A、RD是真的遊刃有餘,那有多少多餘的能量可以去幫助其他人?
B、RD是打腫臉充胖子,想以一天工作二十小時來滿足schedule,雖然勇氣可佳,但PL是必須找資源來幫忙的。
C、RD並不是明確的計畫,只是應付而已。這類RD的心態是有問題的,做好review的工作是可以把螺絲栓緊一點。

如果一群RD給的schedule完全符合PL的原始的要求,PL應該驚覺project已經危險。
如果PL清楚知道project team成員都是跑百米的好手,跑13秒以內是輕鬆的事,那就沒問題。
但是如果能力高低差異大,功能分工的難易差異也大,就像一場馬拉松跑下來,大家都在同一時間到達終點,可能嗎?

2013年5月7日

[PL的Project Management]不懂專業沒關係,但要懂人



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

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