『聖旨到。』
『吾皇萬歲萬萬歲。』
『奉天承運，皇帝詔曰，本專案應在三個月後準時完成，若有違背者…殺無赦！欽此。』
『臣謝主隆恩。』
宣讀聖旨的公公前腳才一離開，只見專案經理滿臉鐵青，面對滿門老小，不禁仰天長嘆，繼之以涕淚縱橫：『唉，想不到老夫一世英名，今日眼看著就要葬送在這個專案上。三個月…這怎麼可能呢？連測試的時間都不夠啊，眼見著這就是個抄家滅族的欺君大罪了，這可該如何是好啊…』
很多時候，我們所遇到的專案，schedule總是依據某個神奇的因素而訂定下來，可能是客戶跟他的老闆賭咒發誓一定會deliver的期限，也可能是高階主管為了績效硬著頭皮喊出來的時間。不管schedule怎麼訂出來，對於project team來說，感覺上總是覺得遠遠地不足。對大多數沒有機會參與project planning的team member來說，每次接到這種案子，聽到這樣的schedule，心裡面總是涼了半截：『怎麼會有這麼離譜的schedule？』接著就會如喪考妣，好象接到太監公公所宣讀的聖旨一般。只要你一做不好，deadline一到，馬上就要被誅九族。
這讓我想起我的某位客戶：『你所提出來的schedule，就代表了你們公司對於我們的承諾，一旦你給了我們承諾，不管你們要付出多少代價，都應該要誓死完成任務。為什麼你們每次給了我一個schedule，就會一延再延？你們的紀律在哪裡？你們的決心又是什麼？軟體開發哪有那麼困難？這是因為你們都沒有決心，沒有紀律。根本就沒有認真地對待你們所做出來的promise…』事實上很多客戶都有同樣的觀點。
對於大多數的客戶來說，project的schedule是一件很重要的事情。這可能會影響到下列幾個很重要的事情：
Ÿ         我什麼時候可以叫大頭來看demo？
Ÿ         什麼時候系統可以上線？
Ÿ         今年我的考績會是什麼？可以多領多少股票？
Ÿ         你們完蛋了，居然又delay了！
對負責報價的sales來說，schedule則代表了不同的意義：
Ÿ         平均人數 * schedule * 平均薪資 = 報價總金額。Schedule不可以太短，不然會沒錢賺。
Ÿ         Schedule又不可以太長，太長客戶不會把案子包給我們做。而且很有可能搶不贏競爭對手。
Ÿ         Schedule比客戶預定的時間略長一點，這樣雙方討價還價時，就會落到一個比較可以接受的範圍。乘以人數跟平均薪資以後，要讓總金額落在客戶的預算內，並且比對手的略低即可。嗯，我真是個英名神武的超強sales。
對工程師來說，schedule則是基於對於事實的瞭解，以及以往的經驗，所做出來對於未來的一種估計。正因為軟體開發的難度甚高，所以這個估計不準的機會也蠻大的。更不要提大多數時候，專案的schedule常常都跟專案經理或是sales丟骰子、或是射飛鏢的結果有關，跟工程師內心對於schedule的定義或想法完全無關。所以對於大多數的工程師來說，Schedule delay，並不是世界末日的來臨。Well, it’s just another ordinary day。有位朋友，給的答案最為經典：『schedule本來就是訂來要被delay用的，要不然幹嘛訂schedule？』
對於schedule delay，客戶覺得是一種萬惡不赦的罪行，工程師則是覺得這好象是到拉斯維加斯試手氣，又小輸了一把，這是生命的常態，你要學著去接受它，如此而已。對於schedule的認知截然不同，這就造成了『只要有專案delay，雙方就會吵得人仰馬翻』的戲碼不斷地上演。
Delay好象是軟體業界的常態，對很多人來說，做專案沒有不delay的。在寫這章的同時，我非常努力地開始回想：『我是否曾經做過哪個專案，能夠在原先估計的時間內做完？』我用力地想，大力地想，把我家祖宗十八代都找出來問一問，得到的答案是『沒有。』
這或許是因為我做過的案子太少，才會這麼不幸，每個project都delay。不過我仔細地訪談過親朋好友，街坊鄰居，還跑去靈犬萊西的飯桌上問卜，得到的結果一點也不讓人意外。
大多數的project其實都逃不出delay的魔咒。原本要做一年的，結果做了六年；要做半年的做了一年半，預計要做一個月的拖了三個月。每個案子都有屬於它自己的原因，只是結果通通都是一樣：『沒有辦法在預計的時間內，交出原本預期應該交件的成品。』
很多專家學者寫了很多本書跟論文來探討這個問題，提出各式各樣的做法，希望能夠剷除這個軟體業界的陋規。有些人認為是估計的方法有問題，有些人認為是專案管理的方法出問題…每個人的說法，看起來都很像是那麼一回事，我沒有一一驗證過，這是屬於專家學者做的事情，有興趣的人自己去買本教科書來看。
※作者注：對這個主題有興趣的人，可以去參考有關function point，或是其它講software metrics的書籍，我個人蠻喜歡Tom DeMarco的Controlling Software Projects(這本書有一點年紀了喔)。想要找找非資訊界的觀點的話，我推薦高德拉特所寫的Critical Chain，這是從他的限制理論(TOC, theory of constraint)來看專案管理的一本小說，要找TOC詳細的理論或是實行手冊的話，去Amazon上search一下theory of constraint吧。
在這一章裡面，我想談談一旦專案有了delay的跡象，跟這個專案有關的人，會採取什麼樣的對策，以及我自己對於這些典型對策的看法。
一般遇到專案開始有了delay的徵兆時，通常我們會採取的做法不外乎下列數種：
Ÿ         逃避問題
Ÿ         逃命
Ÿ         交相指責
Ÿ         敷衍了事
Ÿ         追求銀子彈
Ÿ         增加status report的頻率
Ÿ         增加人手以及焚膏繼晷
Ÿ         更換專案經理
Ÿ         專注在解決方案上，而非責任歸屬
Ÿ         縮小scope
Ÿ         重新訂定出合理的schedule，並配合適度的專案評估措施
逃避問題
逃避問題其實不是什麼高招，不過在專案delay還不太嚴重的初期，問題還沒有十分彰顯時，常常會受到專案經理的青睞。逃避問題通常可以拖過一段時間，直到問題自然惡化到沒辦法逃時，才需要採取其它的方法。
雖然有句俗話說：『逃的了一時，逃不了一世。』不過最少在逃避的過程中，所有專案的成員，都可以擁有喘息的機會，並且換得一時的平靜生活。所以逃避問題還是十分popular。一般來說，如果可以躲得過，沒有人會往火坑裡跳，況且常看好萊塢電影的人，總會期待上天會眷顧好人，每每到了千鈞一髮之際，就會天降甘霖來個完美大結局，帥哥美女從此可以恩恩愛愛過著幸福的日子。所以只要撐過這一時，達成這個milestone，事情應該就會漸入佳境。就是在這種自我催眠的情境下，我們學會了逃避問題。通常我們會採取下面幾種逃法：
Ÿ         解盤，並且用各式各樣的藉口去延schedule
Ÿ         這個phase喪失的時間，會從下個phase中加班補回來。
Ÿ         拒絕任何明確的承諾
解盤，並且用各式各樣的藉口去延schedule
看過股市分析師解盤嗎？『受到美國Nasdaq指數的激勵，大盤從開盤後就開高走高，現在加權指數來到了四千七百五十八點，成交量目前已經到了九百八十億…』
有些專案經理，一旦看到了delay的徵兆，就會開始嘗試著如同股市分析師解盤一般，每天預測專案到底何時會結束，然後每天更新預測。今天會猜三個月，明天會猜四個月，後天還是維持三個月。
喬安娜：你覺得再多久可以上線？
布魯斯：從我手上經過整理break down到每支程式的結果可以看出來，我們還有一百二十支程式，目前已經有30支完成百分之二十，50支完成百分之八十…(下略，他講了十分鐘)所以一切順利的話，再三個月。
過了三個月…
喬安娜：你覺得再多久可以上線？
布魯斯：根據我手上最新的統計數字顯示…(下略，他講了二十分鐘)，因為…(下略，他講了二十分鐘)，所以時間超出我們原本的預估。如果一切順利的話，再三個月。
又過了一年…
喬安娜：你覺得再多久可以上線？
布魯斯：根據… (下略，他講了三十分鐘)，因為…(下略，他講了二十分鐘)，所以時間超出我們原本的預估。如果一切順利的話，再三個月。
解盤法的奧妙，在於他每次都得要提出一種看起來合理的說法，讓你覺得這次的delay是合理的，並且這次的專案delay，都是因為不可預期的因素所造成的，而這一次的估計應該會比較接近最後的結果。接著要找出各式各樣的理由，來把schedule往後延。例如：
Ÿ         因為美國遭受到911恐怖份子攻擊，所以沒有consultant願意在這麼危險的時候，飛到臺灣來做案子，所以我們原本預估好的人力出了狀況，所以要延schedule。我想應該會延後一個月左右。(看起來無懈可擊)
Ÿ         因為海珊向哈利波特(Harry Potter)借了隱形斗篷，把伊拉克的大規模毀滅武器都藏起來了，所以我們需要找到瘋眼穆敵 (Mad-Eye Moody)，透過他的魔眼，才能找到伊拉克的大規模毀滅武器。所以我想找到伊拉克大規模毀滅武器證據的schedule，應該會延三個月左右。(應該也足夠讓特勤人員製造一些證據出來了。)
(作者注：對於哈利波特不瞭解的人，請參閱J.K. Rowling的著作。Mad-Eye Moody可以參考『Harry Potter and the goblet of fire.』)
如果連哈利波特都要搬出來，你就知道這是一件多辛苦的事情。每次都要想出這麼多看起來合理的理由，並不是一件容易的事。還好大部分時候，都可以推託到專案成員遇到史上前所未有的困難，以至於造成了預測與實情有顯著落差身上。我個人推薦下面的標準說辭：
一直到現在，我們才完全體會到這個系統的business rule有多麼tricky，它的複雜程度，遠遠超出我們一開始的預期，你們的domain knowledge真的是非常地高深，對於系統應有的feature，考慮的真的非常非常地周全。我做過這麼多系統，從來沒有做過考慮這麼周延完善的系統。所以我們在設計相關的程式時，一直希望可以在功能上符合你們的預期，可是另一方面，我們又希望系統可以保有足夠的彈性，因此這個module設計的非常非常地複雜。雖然它很複雜，可是我們的程式設計師不斷地努力，一直加班想要趕上進度，所以在先前我所提供的status report上面，一直沒有把這項功能可能會delay這個issue highlight出來，因為我想我們應該還有meet既有schedule的可能。不過很可惜，雖然我們再三的努力，它還是剩下一些小bug，沒有通過我們內部測試人員的測試。品質不好的產品，我們是不敢deliver給客戶的，因為品質是最重要的。如果草率上線，資料一旦錯亂了，造成的困擾一定是無以復加。為了提供最好的品質，我想我們會需要一點時間。照目前的狀況判斷，我們需要再往後delay三個月的時間。
重點提示：
一、東西很難。你們真厲害，搞得懂這麼複雜的東西。
二、東西很複雜，所以要做很久。
三、這點最重要，我們的人已經不斷地加班了。先前沒提出來這個會delay，是因為想要趕趕看來得及來不及。
四、不管東西寫好多少，都要告訴客戶，現在已經在測試了，只剩下一些小bug。天曉得這個模組到底寫好多少？
五、我們要delay。
解過幾次盤以後，麻煩就開始來了。你必須要提出夠多的猜測，來逼近實際發生的狀況。運氣好的話，總有幾次猜的比較接近一點，這時就可以聲稱自己是多麼地有先見之明。這就跟股市老師在報明牌一樣，用夠多無用的理論，以及各式各樣的專業圖表，堆砌起無數的廢話，然後每天提出一種不同的答案。對於猜測不準的部分，他會輕鬆帶過；對於比較接近的部分，他會努力地宣傳他驚人的預測與執行能力。
這種方法其實有很不好的副作用，就是會喪失信用。每次提出來的資料都不一樣時，會被人質疑你管理專案的能力。就跟股市老師們，如果明牌報不準，就會收不到會員是一樣的。不過對於某些主管來說，這叫做『隨時依據最新的狀況，調整預估的結果，以便讓我們掌握最新的動態。』用投資界的說法是，這就是『隨時依據市場上最新的情勢，調整投資的策略。』
解盤其實還算是認真的，最少你會去找藉口。菜鳥經理們通常會很頻繁地嘗試去解讀所有徵兆，做出最新的預測。只是做的太頻繁了，就會隨著各種預言的失敗，而喪失信用。有經驗的人告訴我們，schedule除非遭受重大變故，不然不要太頻繁地變動。以免接收到訊息的人，感到太過混淆。可是也不要拖太久，例如每次都到要miss某個milestone時，才面有難色地延schedule，這樣一定會被憤怒的客戶狠狠地打到吐血。一般如果project在半年之內，兩個禮拜左右review一次schedule的狀況是很合理的。如果時間更長，大概一個月review一次則是蠻合理的。
當然，有些自視甚高的人，就不用這麼麻煩地解盤了。他們根本就不用觀察真正的schedule到底delay了多少，他們採取的方法是：
這個階段喪失的時間，會從下個階段中加班補回來。
在某次的project review meeting上。
喬安娜：布魯斯，依你的專業，你覺得目前專案的狀況如何？
布魯斯：我想我們在分析這個phase，比原先的預期晚了一個月。
喬安娜：那你有什麼補救措施？你知道這個專案對我們來說很重要。
布魯斯想，我還沒做過那種對於客戶來說不重要的案子哩：我想我們會在後續的設計階段加班，看看是否可以趕上現在的進度。
喬安娜：那就拜託你了。
到了design phase的milestone逼近時的project review meeting。
喬安娜：布魯斯，依你的專業，你覺得目前專案的狀況如何？
布魯斯：我想我們在設計這個phase，應該沒有辦法超前進度一個月。事實上，我想我們應該只能照原有的進度完成。
喬安娜：那你現在打算怎麼辦？
布魯斯想，早知道你會問這個，老子早就準備好答案了：我想我會請programmer現在就開始coding。雖然我們的design還沒有完成，不過主體架構都已經差不多了，只剩下一些很細微的地方需要修改。我們採取pipeline的做法，應該可以爭取一點時間。我想我們原先分析階段delay的時間，應該可以在coding時趕上。我會請我們大陸office也多支援三個人力。
喬安娜：那就拜託你了。
結果Design不但delay，太早進入coding，又面對無數次的design change，看來project應該會delay半年。在這次的project review meeting上。
喬安娜：布魯斯，現在project到底會delay多久啊？是不是你們公司的resource有問題啊？
布魯斯：沒有沒有，絕對沒有resource不夠的問題。
喬安娜：你該不會告訴我你們coding delay的部分，可以在測試階段趕上吧？
布魯斯：我想我們要很專業的來看這個問題。依照目前的狀況來說，應該會delay九個月…(既然要喊delay了，總要抓一點buffer…)
喬安娜：什麼！！！
布魯斯：關於這個問題，我覺得很抱歉…
通常自以為厲害的程式設計師，或是心存僥倖的專案經理，都會抱持著美麗的夢想：『目前delay的進度，應該可以在下個階段迎頭趕上。』通常能力越強的人，越容易犯上這個毛病。很多人會想：『我只要如何如何，再加上誰也怎樣怎樣，咱們來個雙劍合璧，應該就可以順利趕上原有的進度。』
是啦，如果真能雙劍合璧，應該有機會可以達成啦。不過大多數的狀況下，『雙劍合璧』都變成了『雙累何必』。透過神奇的發電機，可以讓專案突然的急加速，接著讓你的專案按照時間準時deliver。這種跟上帝借時間的事情通常並不會發生，就跟男生跟女生接吻不會因此而懷孕一樣。
(作者注：對於雙劍合璧不瞭解的人，請參閱金庸先生所著的『神鵰俠侶』。)
當然，天有不測風雲。感謝聖母瑪莉亞，這個世界上總是會有美好的意外。有些禮物還是會很罕見地從天上掉下來。處女遭受到天主的眷顧，還是可以懷孕。這世上總會有幾個經歷了成員不眠不休，小組通力合作以後，結果可以順利地達成任務的神話。可是在光鮮亮麗的背後，通常都要付出相當慘痛不為人知的代價。最常見的代價，就是把事情做完的人，一把事情做完以後就走人。
以我個人的經驗來說，那種『這個階段的delay，可以在下個phase中加班趕上』的神話，從來都沒有發生過。或許這是跟我的運氣不好，買樂透都不會中頭獎也有關係。不過大多數人，買彩券到最後也都是在做功德，資助那些需要幫忙的人。根據我的觀察，會採取這種掩耳盜鈴的手段的人，出發點多半也不是為了要騙人，主要的原因應該是怕別人失望，所以會想辦法講一些『善意的謊言』，或是『不夠完整的事實』。接著就會想辦法要十分努力去符合別人的期望。這種傾向在那種學校成績特別好的學生上特別明顯。『我怎麼可以讓老師失望呢？這次考不好，我下回一定要加倍努力，交出漂亮的成績單。』
問題是做專案不是在參加考試，這是個團隊合作的成果。沒有良好的規劃與溝通協調，光靠認真，很難把流失的進度追回來。Project會delay，其實有可能的因素非常多。很多在學校表現優異的學生，只要一被老師責罵，就會倉皇失措，如果錯不在己，多半就會變得憤世嫉俗，心存怨懟，到最後終日怨天尤人。
這裡就看出功課不好的人的優勢了，如果你考零分已經習以為常，在你掏出一份delay得超級離譜的schedule之前，你其實已經做過千百次的實戰訓練。客戶無情的炮轟，其實跟小時候考零分被爸媽發現，準備吊起來毒打一頓，是差不多的事情。任何擁有這種經驗的人，應該會比功課優異的天才兒童，更適合擔任軟體業的專案經理。這可能也解釋了白痴為什麼可以當上主管的原因。
(作者注：如果你對於白痴當上主管這句話，沒有任何感覺的話，可以參考一本很棒的書：『呆伯特法則』。)
如果你認為客戶沒有辦法接受真實的狀況，所以會想要說些『被修飾過的真相』，以免他們失望。很有可能唯一沒有辦法接受事情真相的人，就只有你自己而已。有道是『輕諾者必寡信』，不願意接受事實，只想輕易許諾的人，不用太久就會被客戶看穿。
如果你想要不做任何改變，只靠超人加班就可以趕上schedule，要不要考慮花點錢去買樂透？只要你中了頭獎，應該就不用工作了，這樣不是就不用煩惱delay的問題了嗎？
願意承諾下個phase就可以趕上的人，如果不是全然地敷衍的話，最少還會想想怎麼趕上進度。有些人會採取截然不同的角度，他們努力地想，用力地想，可是就是沒有結論。到最後就會採取下面的這個做法：拒絕任何明確的承諾。