［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來說，那會是讓事變多好幾倍、功減一大半的行為。

原來真的enjoy就不會覺得累

＝＝＝＝
心理學家契克生米哈利（Mihaly Csikszentmihalyi)稱呼一種不花力氣的注意力狀態叫＜心流＞(flow)，體驗過心流的人描述這種感覺是＜一個完全不花力氣的專注狀態，你深陷其中，完全忘記時間、自己或手邊的問題。＞
＝＝＝＝

我想這就是一種enjoy，一種樂在其中的狀態，即使長時間的專注，也不會覺得累。

工作上曾經有幾次也像這樣進入心流的經驗，感覺真的很棒！
而且當還有人跟你一起有同樣的感覺時，那更是棒極了！

［成長系列］當下與未來

看到一篇小文章，很不錯，跟大家分享一下，
＝＝＝＝＝

[連桂慧管理小品]轉折的智慧

「轉折的智慧」，需要有些正向的思考，與對未知的期待。

當下的挫折與逆境，皆可在轉折處得到不同的體會。

眼前的擔憂與不安，也因柳暗花明而得到疏解。

不要害怕轉折，那是對一成不變的生活最好的禮物。（圖文：連桂慧）

＝＝＝＝＝

轉折可以期待，只要你可以多一點等待。

態度，才能幫你度過當下的黑暗，而智慧的增長，就是你度過之後的果實。

你好，如果對文章有想法或意見，那就留個言吧！

Hi 朋友,

到目前為止，我在部落格上發表了88篇文章，瀏覽次數超過6千次，不過文章的回應卻只有4個，簡單做個統計：
　
每篇文章的回應率只有4/88*100%=4.545%
每次瀏覽的回應率只有4/6000*100%=0.067%

也許會來看文章的朋友都偏工程師，是比較沈默的一群，不過我還是想讓這個部落格可以活絡一點，我其實也比較希望可以跟大家有些互動，因為很多文章在發表時不一定能說的完整，或立場偏激，甚至有些想法不一定是正確或真的有用，也可能隨著時間的變化，原來的觀點也會改變的，不是嗎？

像［成長系列］和［PL系列］，如果你剛好是我想傳達的主要對象，那有沒有打動到你的隻言片語呢？是不是也想說些什麼回應呢？如果是，那就別再沈默了，請在文章的後面留個言，說說你的想法，讓我們做個交流吧。

如果你是我的朋友，按個＜讚＞是不錯啦，不過你知道我更喜歡你的留言的。
如果你我還不認識，歡迎光臨，交流一下，很快就是朋友了！　^_^

Steve