夜行貨車－Jemmy Walker

像是追著疾駛的貨櫃車的長途跑者，車上的貨沒有綁著牢靠，車上的驗貨員在疾駛的情況開箱驗貨。有時還沒開好箱子就被貨櫃車的反作用力抛出車外，長途跑者氣踹吁吁的撿貨，有時貨物還會被抛到跑者的後面，只好回頭先撿最遠的掉貨。撿貨的同時，還常被車上的驗貨員叫說先撿哪一個比較重要，常打亂跑者原先心中規劃的最佳撿貨順序。後來發現撿貨員只有一個人手不足，再增加撿貨員，原先最年長跑者還得面對新來的跑者撿了後該怎麼做，真想說就拿在手上，雖然知道驗貨員已經比較常叫新來的跑者撿貨。但老跑者與新跑者對於同樣要撿的貨，都被賦予不一樣重要順序。不同的驗貨員心裡規劃驗貨順序也不相同。

司機為什麼不停下來呢？而且不但不停下來還排高檔疾駛。司機只想出一趟貨即可節省成本，而且不當承諾，縱使換了司機又如何，明明貨物可以分批送卻要一次送，明明可以搭飛機卻選擇了開貨車。只因為司機只會開車，不會開飛機。好像專案沒有CMMI/PMP就無法Go下去一樣。司機唯一肯停下來的時刻就貨車沒油，當然司機不是跑者，不會因為筋疲力盡而停下來歇息。

最近看了Peopleware這本書，照理說CMMI層級越專精，專案風險也越大，可是事實卻相反，所採取的策略也越保守，越不敢冒險。SA以為SA Phase後就沒事了，PM以為做好數字管理就沒事了，QC以為要求每樣東西都要做到UT就沒事了，只有TPM變成了GC－Garbage Collection。待事情一來，各有自己的優先順序盤算。Garbage越積越多，說是team work，同一個team，事實上追著夜行貨車的長途跑者，一直以來都是孤單的，看透事情徵兆，也有解決腹案，所缺者，是一個有Guts的PM。以前在Fubon專案秉持一步一步來的態度，到Vibo來則土崩瓦解，甚至增加了新跑者，就認為老跑者應該有時間了，連想停下來喝口水都還得在意別人的眼光，除了倒下。

(停下來喝口水的時間，最想做的是什麼？不是休息，想把Framework規劃得更好。對司機而言，規劃的時間不如用來撿貨，雖然司機不認為自己超速是違法的。)

貨品來源有精品也有瑕疵，從不認為短時間趕工會有多少良率，雖然司機與驗貨員也是這麼想，做卻不是這麼做。當初在規劃專案時，我希望能夠使用Yahoo! UI的Ajax套件，但因為會的人不多，在PM們採取保守策略，禁止使用。如今貨品我看了，雖然難能可貴的是良率也不算少，禁止了Yahoo! UI，結果不但有人用，還有人用Yahoo! UI以外的Ajax套件如AjaxTag，Dojo等。雖是看出開發者可以延伸多元觸角，卻也因為當初沒有定於一尊導致出貨規格各自標準，恐埋下日後不相容的危機，身兼貨品工頭的長跑者，難卸監工不力之嫌－雖然我很希望能夠被安上這樣的罪名，到真的要走心理也舒坦。

事實上當初要求改用飛機，貨分批送也是在做了，但司機為了向車行老板交待，做出仍然是一次出貨全數到位的樣子。四個模組先上是貨分批送，也是XP的Small Release，API Meeting是XP的客戶參與開發。事實上Vibo還不算真的很爛的客戶，只是司機只有一條動線會走，只有貨車會開，XP是一架飛機，只因怕失事而不敢開，怕失事是因為不了解，不了解是因為不信任，不信任是因為不肯潦下去，不潦下去是因為身段與撇清干係。當初就明瞭Vibo只會在驗收前夕才會對本身提供的API認真，需求訪談/系統分析，客戶未必能了解自己想要什麼，這個情況正適合XP運作。

溫伯格在專案管理學有言：最好不要為了如期完成而加太多班，即使那是一個當你無法如期完成時可以卸責的藉口。

想到明天又要被逼著加沒有Guts的班。現在這位長途跑者當初長跑的目的也是追夢，想完成優質與符合客戶需要甚至信賴的系統，專案做到最後似乎失去當初追夢的動力，一如不願做假測試而離職的QC。