［PL的Project Management］天啊！Schedule！

＜天啊！Schedule！＞，這應該是大家做project最傷腦筋的吧！

當你還是RD時，你討厭老闆、PL、PM來壓你schedule，覺得這麼不合理的schedule怎麼他們不自己來做做看；可是當你是PL時，老闆還是一樣壓你schedule，老闆不合理的要求可能還在，只不過你想把壓力扛在你身上，給member多一點合理的空間，還是把壓力by pass如member呢？亦或是給member的壓力比老闆給你的更大，這樣才能確保你可以在老闆面前輕鬆自在？

你想過schedule的意義嗎？對你的意義、對PL的意義、對project的意義？
是壓榨、欺騙、假象、抗爭的過程？還是承諾、尊重、誠實、信任、互助的基礎呢？是想真實地反應狀況，還是想要漂漂亮亮地粉飾太平？緊一點，亦或鬆一點又會怎麼樣呢？做不到就真的表示你不行、不夠強？會不會換人來做了呢？

老闆要的應該是一個真實的、可執行的、優化過的、可預期的、可靠性高的schedule，可是這樣的要求做起來一點都不簡單，因為它考驗著你的態度和挑戰你壓力的極限。當然，還能讓你看看別人的反應，對真實的人性有一點點的領悟。



剛剛拉出來的schedule是虛的，不論你拉的有多漂亮，多符合老闆的期待，要到最後執行的結果才知道原來一開始的schedule實不實在。
（至於大家會歌頌開始的schedule有多漂亮，還是會檢討為什麼執行結果差很大，就不知道了！）

先說幾個故事：
＜１＞
Ａ：重新評估的schedule達量產標準只需要三個星期，可能嗎？光測試就來不及做完，更不用說加上RD debug的時間了！
ＰＬ：我知道不可能，可是老闆說他要的時間就這樣，我能怎麼辦？
Ａ：既然知道不可能，那就再重拉一個可能達成的schedule給老闆啊。
ＰＬ：...，算了。
（然後～ＰＬ還是被換了，Ａ變新的ＰＬ。）

>>>>
Ａ：新的schedule需要二個月，跟測試部門討論過，投入最大的測試人力和簡化一些已經穩定的功能和不重要test case，可以縮短一些測試時間，但是因為是新的平台，測試至少需要二輪才能保證品質有一定程度的質量。另外以現有的RD人力，已經盡可能壓縮debug的時間，這裡的風險很大，不過抓緊一點，還是有可能的。當然如果有辦法再投入VT和RD，schedule就還有再壓縮的空間。
老闆：二個月...，先這樣吧！

>>>>
老闆：Ａ不知道大老闆跟客戶說的是下個月要量產嗎？這樣二個月的schedule也拉得出來！
ＰＭ：Ａ拉的schedule是經過我們幾個人一起討論的，的確已經是很緊的，還需要抓得很緊，不出現嚴重的問題卡住，才有機會達成的schedule。
老闆：不管，你去給我找Ａ，想辦法pull in。

ＰＭ：是...（OS: 幹嘛不自己去跟Ａ說！）

>>>>
ＰＭ：老闆說這個schedule他不能接受，要再pull in。
Ａ：那天開會老闆沒有意見啊，怎麼正式會議不說，現在找你來跟我說！？你也知道正常情況至少要三個月，已經想方設法壓到二個月了，要達成這個schedule我們大家都必須要付出120%的力氣才有可能了，要大家加班加點地衝刺才行，已經不能再壓了。
ＰＭ：我知道，可是...
Ａ：不用可是了，像這樣要人沒人，要資源沒資源，已經換過ＰＬ了，如果老闆不喜歡這個schedule，ＰＬ可以再換一次。
ＰＭ：嗯，不要說要人要資源了，現在的人力沒被火燒屁股的ＯＯ project拉走就上帝保佑了。
Ａ：要嘛老闆自己找我說，不然私底下透過你來找我，我只能跟你說不行了。而且每個星期都開project meeting，老闆在會議上都沒意見，怎麼每次都要找你來跟我說，真的是很奇怪。是覺得我很麻煩，還是固意要為難你？

＝＝＝＝
也許類似的對話你也遇到過，可以想想以下幾個面向：
Ａ、schedule是真是假，如何呢？
Ｂ、應付也有到頂的時候。
Ｃ、擔當是什麼？你認為的那個人有擔當嗎？
Ｄ、溝通常常沒有想像中直接、容易。
Ｅ、資源分配總是看priority的。
Ｆ、老闆對schedule的態度總是pull in再pull in。



＜２＞
ＰＬ：看得出來這份schedule你是用心的，不過working item A應該是要跟RD Ｘ一起做的吧，你有跟Ｘ討論過了嗎？
ＲＤ：有，我跟Ｘ已經討論好interface，他會先定義好interface給我，讓我可以先開發，然後我們各自開發完後再一起整合，時間順序上也是沒有問題的。
ＰＬ：另外working item B和RD Ｙ的工作內容有點重覆，請先跟Ｙ確認一下，看是不是彼此有重工的部份，協調一下看誰來處理？
ＲＤ：OK，item B會跟Ｙ討論一下，更新後再給你review看看。
ＰＬ：你確定working item C你可以自己做嗎？你之前沒有做過這個部份，我知道RD Ｚ現在工作比較鬆一點，要不要找他來幫你？
ＲＤ：如果他可以幫忙一起做是最好，我是已經有去請教他這部份怎麼做會比較好了，我也知道怎麼處理，所以才會拉出這樣的schedule。
ＰＬ：好，我那跟Ｚ說一下，讓他過來幫你，你們一起做，不過因為還是你的工作，我還是找你check item C的進度。
ＰＬ：另外，我沒看到你把UT和IT排進你的schedule，你怎麼執行你的測試呢？
ＲＤ：啊！我可以把UT和IT的時間排進schedule嗎？之前project拉的schedule都沒有這樣啊。
ＰＬ：那我問你，你實作完後，需要花時間做UT和IT嗎？
ＲＤ：需要啊。
ＰＬ：既然有花時間，那為什麼不拉進schedule？是你已經內含到其他working item裡了，還是你自己有多出時間來做這些事？UT是你個人負責的範圍測試，還不會跟別人有太大的關係，不過IT就跟其他人有關了，我必須知道大家可以一起進IT的時間點，才好把大家做的東西整合起來做簡單的系統測試。
ＲＤ：OK，我知道了，我會再重新評估一下，把UT和IT的時間加進schedule後再找你review。
ＰＬ：之前的schedule看起來還有再優化的空間，尤其是跟其他人相關的working items弄清楚後應該可以縮短不少。不過我還是希望你可以試著再拉緊一點，給自己訂更高的目標，有點挑戰性做起來更有衝勁，不是嗎？

＝＝＝＝

身為PL不是只跟RD要一個schedule而已，PL其實可以做的更好：
Ａ、相信RD給你的schedule，要做的就只是怎麼幫RD優化schedule。
Ｂ、善用、活化PL掌握的資訊和資源來協助RD優化schedule。
Ｃ、確認結構性的問題，如working item是否符合SW process的概念（Requirement => Design => Implementation => Verification）。
Ｄ、思考working item的合理性，確認在與人力、時間、資源上的衝突性、重覆性、相依性等情況。
Ｅ、讓RD感受到你在幫他，而不是在壓他。你尊重他，卻也要求更高。
Ｆ、讓RD自己調整schedule，因為這是他給你的承諾。如果是你幫他訂的schedule，那只是你交代給他的工作罷了。




PL不是一個RD，而是代表一群RD，代表一群參與project的所有人。一個RD的schedule，是他個人的工作計劃，而project schedule是整個project的工作計劃，是所有人的schedule集合。
一個人的schedule很好安排，因為所有可能會發生的資源衝突、人力衝突、時間衝突，還有各個工作的先後順序、相依性等問題是自己最清楚，自己說好就好了。而project schedule的複雜度更高，有時候光搞清楚二個人schedule之間的衝突和相依性情況就很費力了，要解決這些問題又要花很大的力氣，更不用說你的project如果是超過20個人的project了。

Schedule要的是真實的、可執行的、在各方面都優化過的，PL就是要有能力確保這些事。
RD是執行schedule內容的人，如果執行者是有著被壓榨、不被尊重、不能自主的感受，可預期的是效率低落，project management會很辛苦，如果又以高壓的方式來管理project，那低層的反彈會更大（短時間二個月內的高壓衝刺也許有用，但是隨著project時間愈長，反彈會愈明顯），儘管有個漂亮的schedule，project delay也是意料中的事了。


是尊重，還是不尊重
是給挑戰，還是壓榨
是給幫忙，還是自己想辦法
是要一個承諾，還是只許聽我的目標

PL對schedule的態度，就已經決定project是否成功順利了。PL的能力高低，也表現在這裡。