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

［ 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在他的手上。

說清楚不容易，講明白也很難

最近一位朋友為了工作上的事很生氣，起因是因為一早到公司就發現桌上多了二台機器，看起來是希望朋友幫他測試，只是桌上就只有二台機器，沒有任何字條或留言，查看email，也沒有任何通知或關於這二台機器的mail。雖然覺得莫名其妙，手上測試工作也排得滿滿的，但直覺告訴他不能不管這二台機器，所以就還是發了一個mail給可能相關的人，問問看是誰放在他的桌上，然後需要做什麼事。果然有工程師回信說那是他放的，需要測試，很急，還問朋友什麼時候可以給他測試結果。然後在幾個來回的mail中，雙方的老闆都被loop進來了，沒有交集之外，還搞得一肚子火。

朋友感嘆：＜為什麼工作上的專業不難，反而是跟人溝通就這麼難啊！？＞

其實專業不難嗎？當然也不是不難，隔行隔山，只是專業上的門檻對有心學習或學習能力強的人是容易跨越的。更何況如果本來就是本身專業領域的範圍，即使是新的事物，也很快就能上手。

溝通很難嗎？真的很難，只要面對的是＜人＞，從來都不是容易的事。
朋友生氣的原因，其實也就只在意二點：
１、不受尊重
　　工程師不尊重測試單位似乎是一般公司普遍的現象。但是如果連基本做人做事的道理都沒有，那就真的太過份了。像那位工程師需要人家幫忙測試，事先不僅是不按照測試申請流程走，甚至連句話或一封mail通知都沒有，事後還認為幫他測試機器是應該的，劈頭就要如測試的結果。無怪乎朋友的同事會說：＜請董事長來說，就幫你測。＞

系統測試就像健康檢查

很多人都有做健康檢查的經驗，一次健康檢查會包含身高、體重、肝指數、膽固醇、胸部Ｘ光等等基本項目，可能有時你還會額外再多檢查腸胃鏡之類的項目。不過不管有多少檢驗項目，都是一次做完的。

之前曾有過project在搶快，不管有些功能還沒做完，就硬要進VT的系統測試，還要求先給一版已經完成的功能先測試，過一陣子等其他功能完成了再給一版測試，如果有功能比較慢可能還會有第三版。老闆只看到project進入測試階段，卻不知道只是表面功夫。開始測試時沒什麼問題，然後等後來版本進測試時才發現原本測試過沒問題的case又有問題了，就這樣來來回回搞得測試時間都跟開發時間差不多了,還是沒辦法有效收斂。

［ PL的Project Management］知道就做得到？

接續上一篇［ PL的Project Management］順序很重要，Requirement=>Design=>Implementation
後面的問題，為什麼這麼簡單又直覺的邏輯和做事步驟，真的在project執行時卻很難做到呢？

先來看看幾個對話：
＜１＞
RD：VT測試發現的這個問題是因為之前interface沒有考慮好相容性的問題，現在要嘛把interface改得更完整，只是接口二邊的模塊也都要動到，schedule一定會受影響，不然就還是用舊的，新的功能就先disable，等以後接口改好了再enable。
PL：這不是給我找難題嗎？怎麼都測試一半了才發現這個問題，設計和實作時怎麼都沒發現功能有問題？而且這個功能是客戶指定要的，怎麼可以disable呢！要改，schedule會delay；不改，又要想辦法說服客戶project沒有這個功能。天啊～～

＜２＞
PL：這個功能一定要現在project後期加進來嗎？為了這個不重要的功能影響project進度，很不值得。
Sales/Boss：很多客戶都要，不在這次平台版本加進來，就要等下一次，那些客戶都等不及了，很可能會轉單到對手那邊去。
PL：這次版本release的主要目的就是給大客戶的，但是大客戶並不要這個功能，是不是可以先找人開發這個功能，但是等這個版本release後，再把功能整合進來以patch的方式release？這樣既不影響現在project的進行，也可以很快讓其他客戶有這個功能。

［ PL的Project Management］順序很重要，Requirement=>Design=>Implementation

SW process的第一個phase並不是implementation phase，而是requirement phase，也就是說如果project一開始就朦著頭就開始實作階段，那是錯的，也是假的，因為連要做什麼都不知道，又怎麼可能開始做呢，先搞清楚requirement是什麼才是最重要且第一個要做的事。

有的PL為了搶快，或是為了讓老闆看得見產出，即使在做什麼都不明確的情況下，project就投入人力開始implement，這是錯的，也是假的。為什麼是錯的？簡單的邏輯－清楚要做什麼(What to do) ==> 才思考應該怎麼做(How to do) ==> 然後才是開始實作(Do it)，對應的SW process順序就是Requirement phase ==> Design phase ==> Implementation phase。客戶明明要的是要＜重型機車＞，結果你自己很高興地做了一個＜很重的機車＞，然後才發現做錯了，你能要求客戶把需求改成＜很重的機車＞嗎？所以順序不對，就不合理，就是錯的。那為什麼是假的呢？因為現在實作完成的東西，會因為requirement不對、design不合而需要修改，甚至重來，看起來已經完成100%的工作都可能要再歸零重做，也就是現在完成的工作可能都是白工，所以是假的。

Requirement phase (What to do) ==> Design phase (How to do) ==> Implementation phase (Do it)，簡單的邏輯，淺顯易懂，不過＜知易行難＞，看過很多project直接就要開始進入implementation，忽略requirement、跳過design，妄想要一邊實作一邊釐清需求，一邊實作一邊修改設計，這樣的做法或許對很小很小的task有用(因為重工的代價很小)，但對於project來說，那會是讓事變多好幾倍、功減一大半的行為。