交相指責
項目會delay，其實多半雙方都有責任，很難完全歸咎于其中的一方。所以一旦delay時，很多人的重點都會放在『誰應該負責』這個一定會引發爭議的問題上。如果你沒吵過，請仔細注意下列關鍵詞：『負責』與『責任』。
喬安娜：布魯斯，你覺得我們的project為什么會delay？
布魯斯：還不是因為你們user的requirement不停地change。
喬安娜：話怎么能這么說。要不是因為你們的SA太沒有經驗，根本就聽不懂我們的需求，怎么會有這種事情。況且很多根本就不是requirement change。我覺得現在會陷入這樣的困境，SA要負最大的責任。
布魯斯：怎么說不是requirement change？你可以去翻翻會議記錄。都已經是什么時候了，還在改business rule。
喬安娜：你可以去翻翻我們提供的原始文件。哪一個需求不是我們一開始就提出來的？你們自己不認真去讀文件，還怪我們requirement change？根本就不負責任！
布魯斯：你們提出來的文件跟山一樣高，當然會需要你們的幫忙確認啊。SA告訴我，有很多需求，其實開會時你們講的，跟文件上寫的，根本就不一樣。我們跟你們confirm，你們還跟我們說是文件寫錯了。這明明就是你們的問題，怎么可以叫我們負責？
喬安娜：哪有這種事情？喔，你是說我們新來的承辦人雪麗喔。她也是新人啊，自己也沒有完全進入狀況啊，你們怎么可以抓著他的語病，就一路追殺到底？
布魯斯：我們哪有。可是明明user講的就是跟文件不一樣嘛。
喬安娜：那你應該反映在會議記錄里啊。
布魯斯：每次訪談，講的東西那么多，怎么可能全部紀錄下來？
喬安娜：記下來不一致的地方，要求澄清，這不是SA應該做的事情嗎？不然難道要我來寫會議記錄嗎？你連下面的SA這么不專業都沒管好，你PM是怎么當的？你到底有沒有責任感啊？我們的項目delay這么久，你們一點都不緊張，每天晚上九點不到就全部回家了。因為項目delay，讓我們公司的資源在那里虛耗，所造成的損失是要誰來負責？
布魯斯：你講話一點理性都沒有，簡直就莫名其妙。我不要跟你吵架了！再見…
我們小時候都聽過，開會時要對事不對人。不過我們的課堂里，從來都沒有教導過，當跟你開會的對象，開起會來是對事又對人，沒事干就指著你的鼻子罵人時，你該怎么辦？
基本上，當有人不遵照游戲規則時，有些人就會依據直覺來反擊。你兇，我就比你更兇；你狠，我就比你更狠。所以會議一開，雙方就火力全開，開始交相指責。你罵我辦事不力，我就罵你沒有全力配合；你罵我領導無方，我就罵你將帥無能，累倒三軍。凡是delay的很嚴重的project，通常雙方的領導都多少有些問題。互揭瘡疤的結果，通常是兩敗俱傷，搞到最后，關系惡化，常常會拒絕與對方開會。Project如果做到這樣，下場就不言可喻了。
除了互相攻詰以外，文件常常又是另一個爭吵的來源。言語確實是一種非常不精確的溝通工具，不過這不代表使用文件進行溝通，就不會有任何問題。我剛從學校畢業時，就覺得文件應該越多越好，越詳盡越好。
后來工作得越久，就越不是這樣子想。過多的文件，絕對是效率的殺手。你如果有與大公司做案子的經驗的話，你或許可以體會到我為什么會這樣子思考。很多時候，你做一個大案子，可以拿到的文件，可能洋洋灑灑數百頁，甚至上千頁，往來的會議記錄可能是以數百次來計算的。面對這么多的信息，你還得要去把其中的歷史演進給搞清楚，還要把個中互相不一致的地方給挑出來，這絕對是個苦差事。難怪Rational還會專門設計一個管理requirement的tool。
遇到這種被文件淹沒的時候，如果requirement的management出了問題，到了后期，雙方爭吵的重點，通常就是：『這個系統，為什么會做成這樣？』例如這個系統現在的功能，可能是依據1/8的會議記錄修改的，可是1/22時的會議記錄，老早就把1/8的一部份給推翻了。你以為照1/22的改完就ok了？不對。1/29的會議記錄，可能又把1/22的會議記錄再做了一個minor的修訂。等到你按照1/29的做出來以后，有可能主其事者也換了一個人，他可能就會堅稱，原始的需求文件才是對的。
當一個change request來臨時，到底impact到多少東西？有多少文件要改？有多少程序要改？老實說，要是你沒有一套很好的工具，也沒有一套很好的process，這些問題根本就答不出來。當然，這跟requirement management還有change management的process有關。不過再怎么良好的process，還是沒有辦法解決人的問題。
這怎么說呢？就算你有很好的工具，你也采用了一套不錯的process，人的印象，還是很難改變的。當一個人把1/8時的設計，仔細研究，慢慢思考，終于深深地印在腦海里面之后，這時他看到了1/22的會議記錄，于是乎他想了一下，深深地嘆了一口氣，在腦子里面更改了一下原始的設計，接著開始進行修改。可是當他看到1/29的會議記錄時，他的印象搞不好還停留在1/8時的狀態。好吧，這下子搞不好就已經是一團亂了。問題就來了，現在的系統到底會做成什么樣子呢？不一定，可能保有一部份1/22的精神，也有可能保有一部份1/29的request。更不要提，designer在看了1/29的會議記錄，其實有幾段看不太懂，在design時，就別出心裁地做了一些小修改。這一改，很有可能又制造出不少潛在的bug，留給后世的人景仰。
咦，好象離題很遠了。Anyway，互相爭吵對于項目其實一點幫助也沒有。除非你打算打官司，或是只是單純不想讓對方的日子好過，否則厘清責任其實沒有什么幫助。因為重點不應該放在誰該負責，而是在于問題該怎么解決。你可能可以舌戰群雄，技驚全場，讓客戶承認他們該負責。好吧，那又怎么樣呢？該你deliver的東西，還是要你去做啊？把客戶惹毛了，項目會做的比較順利嗎？我可不這么認為。
敷衍了事
大多數的項目，都有個共同的特點，就是『Deadline將屆之日，才是大家各顯神通之時。』這跟考試之前大家都會熬夜念書臨時抱佛腳是相通的道理。每每到了期限快到時，每個人都會想出各式各樣的方法，來想辦法meet schedule。面對超高的壓力，以及項目經理殷切的期盼，所投注出來的關愛的眼神，engineer常常會在這樣的狀況下，走一些前所未有的快捷方式。我最常看到的現象，就是『隨便做一做，做一個長的很像的東西交差了事。』
難做的功能，如果有些小問題，多半也不容易在第一時間內測試出來。就算是測出來了，那也不過就是個bug。真要來不及的時候，沒魚蝦也好。先求有，再求好。所以engineer常常會在時間壓力下，做個看起來是對的，骨子里全然不是那么一回事的東西來交差。有責任感一點的，內心還會想說，如果度過了這一關，我回頭再來把它做到好，雖然大多數人，根本就不會有這個再來把它改到好的機會。不過最少這些人還算是有良心。有些人根本交完差以后，就愉快地去過他的生活了。
這種狀況在于那種完全采用WBS(Work Breakdown Structure)來進行項目管理下的project最明顯。如果你沒聽過WBS，我在此做個簡單的說明。WBS就是把你所要做的工作呢，不斷地細切，切到每個工作都是一個很小很小，可以管理的單元為止。項目經理要做的事情呢，就是先把工作切一切，割一割，再發下去給engineer一個一個完成。這種approach，原則上符合所謂的divide and conquer(各個擊破)的道理。我記得在學校寫作業時，常常就是你寫第一題，我寫第二題，他寫第三題，接下來大家抄來抄去，抄完以后，每個人作業也就都寫完了。
因為這跟很多人的生活經驗相符合，所以對這些人(尤其是客戶)來說，這樣的做法很好，這樣就有一個量化的指針可以遵循。例如：這個項目總共有一百支程序要寫，現在已經寫了70支了，所以coding就已經完成百分之七十。
一旦編出一個量化的指針之后，大家的重點，就會放在這個數字到底完成了多少，對于實際上的進度是否可以用這樣的一個數字來代替，那就是另外一個問題了。這樣一來，除了大家在壓力之下會傾向于虛報進度，以及實際上項目真正的進度很難具體量化以外，最大的問題就在于這些程序可能在進行單元測試(unit test)時，都可以順利運作，一旦整合起來，就狀況百出。當你進一步去探究這個問題的根源時，你會發現，很多程序設計師，會在時間緊迫的狀況下，走很多快捷方式。
走快捷方式本身不見得會有問題，可是如果其中的一個選擇是做一個看起來很像的東西，那問題就很大了。也有些時候，programmer不是刻意地去抄快捷方式，而是對于design或是requirement不夠清楚，所以自己會自做主張地做了一個假設。接下來一忙，就把這件事情完全地忘掉了。沒有關系，不管是刻意的，還是無心之過，這兩者造成的結果是相同的。
例如在某個人的程序里面，可能寫了這樣的statement。
//lfTaxBasicRate這個變量應該去讀稅率設定文件里面的數據。
//來不及了，用現在政府的稅率頂著先。Demo過后再來改。
lfTaxBasicRate = 0.05
他信心滿滿地想著，等到我有空時，我再來改。Tester測試時，因為沒有更改稅率設定文件的資料，也就沒有發現這個問題。接下來一忙，他自己就把這件事情給忘了。一直到了UAT，user覺得很奇怪，怎么改過稅率以后，這個功能還是不work，是不是計算應納稅額的模塊出了問題？還是稅率文件的資料出了問題？還是…。于是就把問題踢回給development team的tester。development team的tester會先想：『哪有這種事？我測的時候就沒有問題？是不是你操作程序有問題？是不是version control有問題？』接著就在測試環境整個重新確認過一次，發現：『啊！該死！真的會有問題。』最后就又把問題丟回去給原作者—如果他還在這個team里面的話。
你要找出這種問題，要付的代價很高。首先你要浪費測試人員的時間來找出這個問題，這可能需要透過很多測試個案的排列組合才有辦法找到。接下來你可能還要花很多后續的時間，在程序代碼中不斷地尋找，才可以找出這個問題。
咦，如果這個是刻意的遺漏，當事人應該可以很快地找出問題啊。或許你會說，自己埋下的炸彈，自己怎么會忘記呢？怎么還要花很多時間呢？沒錯，即使是我們自己，都有可能要花很多時間才會找得到自己在寫程序時，為了趕時間，所做的故意的省略。這就跟花心的男人，跟女朋友吵架時，會下意識忘記昨天晚上十點時，他沒有打電話給她時，到底在做什么是一樣的道理。有時候是即使記得清清楚楚，也不可以坦白招供。老實招認那時在酒店花天酒地，會得到比較多的諒解嗎？
更何況有很多時候，即使是當事人，即使是每行程序都有批注，也不見得可以在第一時間內找到他自己在先前趕工時，偷工減料的部分。這完全取決于找到這個bug的時間，與他抄快捷方式的時間點距離多遠有關。如果他走快捷方式的年代已經十分久遠，他可能要花不少時間找一找，才找得到他自己埋下來的地雷，更不要提如果已經換成另外一個人來修改的話，會有多大的麻煩。最后要付出的代價，就是還要把程序改成是對的邏輯。
當然，這個問題可以透過code review，或是pair programming等等方法來加以避免。找些人幫你看看，最少在抄快捷方式時，會比較收斂一些。不過對于大多數的軟件公司來說，code review是什么東西？又該怎么做呢？
另外一種敷衍，則是在流程上的敷衍。最常見到的現象就是，design沒做好就直接coding，unit test沒完全就直接來integration test，integration test也沒做好就卯起來進user acceptance test。基本上的想法呢，就是既然已經懷胎十月，不管是畸形兒，還是連體嬰，該出娘胎時，還是要出來看看他的老子。這時候最常聽到的幾句話就是：
????????? 丑媳婦總是要見公婆。
????????? 伸頭也是一刀，縮頭也是一刀。
????????? 早死早超生。
很多人到了快要miss原先所訂下來的milestone時，選擇面對壓力的方法就是宣稱這件工作已經如期完成了，接著再想盡辦法來圓這個謊。這在測試階段特別容易發生。反正所有的東西是否有完整地經過測試人員測試，光看測試人員的臉是否面有難色，其實是很難看出來的。有經驗的人會去看看defect的時間曲線是否收斂。不過大多數team member的想法，到這個節骨眼就會傾向快刀斬亂麻，這個時候就會努力說服自己：『我們寫出來的軟件品質不好，客戶一直還不是那么清楚，如果他們到最后一刻才發現這個問題，這樣子其實不是很好。不如早點給客戶知道真實的狀況，這樣他們才有心理準備。好吧，我們就開始UAT吧。』
每次我看到了為了趕milestone，決定要讓user提早開始UAT的項目，就會感到無比的惋惜。趕上了schedule，喪失了品質，與雙方的信任，這樣又獲得了什么呢？
另外一種常見的流程省略，就是該做的review沒有做，風險評估也好，項目評估也好，不是直接從時間表上勾掉，就是三兩下草草了事。依據我個人的經驗來說，很多必要的工作，一旦省略，或是做的不確實，短期內所帶來的縮短時程，其實要付出數十倍的長期代價。為了meet一時的milestone，做出許多不利于整個project schedule的事情，其實是非常不智的行為。
追求銀子彈
人類一直在追求科技上的進步，新發明，新創見，新的生產方式，新的開發技術，一直都帶領著我們不斷地往前走。然而project一旦開始delay，很多人，尤其是高階主管們，在沒有更好的解決方案下，多少總會期盼科技的創新，可以帶來立即而有效的效果。
某一次status review meeting中。
吉娜：布魯斯，從你的status report看來，目前項目的進度已經落后了百分之六十。你有沒有什么對策？
布魯斯：看來目前的項目已經再次上軌道了。可是如果想要趕上進度，老實說，還是比較困難。
吉娜：現在的狀況的確是比以前要來的好。不過我們不可以就這樣自滿，況且，這個案子已經嚴重地超支了，我們做這個案子，已經是虧本在做。要是可以的話，當然要盡量超前原有的進度。對了，前一陣子我去參加seminar，我聽說現在有一種叫做extreme programming的方法，要不要試試看？
布魯斯嘆了一口氣：我會找時間去survey看看。看看有沒有什么可以用在我們這個案子上的。
吉娜：好極了，我就知道你最有冒險犯難，勇于創新的精神。
對大多數的人來說，大膽的創新與愚蠢的不自量力之間的分野，其實是挺模糊的。老實說，即使采用相同的開發方法，應用在不同的團隊身上，就會有截然不同的效果。對于一個只懂得用COBOL寫Main frame上面程序的團隊來說，要他們在一夕之間，改成用J2EE連Oracle數據庫，寫web application，還外加采用OOAD加上RUP混合著extreme programming的做法，光用聽的，就覺得這票人根本就是自掘墳墓，想要來個出師未捷身先死。
新科技、新工法的引進，其實最好是能夠用漸進的方法比較恰當。除非你打造的是全新的團隊，否則太過激烈的變革，會很容易造成消化不良。這就跟吃到飽餐廳一樣，有很多人只考慮到要盡可能的吃掉最多的美食，卻沒有考慮到自己的消化器官，有沒有辦法經得起這樣的折騰。于是乎吃完之后，馬上往廁所報到。
是因為美食不新鮮嗎？大多數的狀況都是因為你的身體沒辦法負荷這么多的食物。引進新的科技也是一樣。除非你打造了一個全新的團隊，而這個團隊的大多數成員，都擁有所需要的經驗。否則，在同一個項目采用太多的新工法，新技術，除了team member本身的抗拒心理需要克服之外，對于項目其實都是負面的影響遠遠多過于正面的效應。
我個人比較建議如果有新的領域要嘗試的話，除非這個項目的成敗，你完全不在乎，否則，一次不要嘗試超過一個新技術；反過來說，如果你做的只是個pilot project，這個project本來就是拿來練兵用的，Well, have fun. You could try as many as you want.
銀子彈存在嗎？我想答案是肯定的。不過對于已經delay的project通常是無效的。因為project會delay，多半都是管理上的問題，與技術全然無關。管理上的問題，又多半不是引進一個管理上的新思維，或是引進一種技術上的創新，就可以解決的。任何管理上的新想法，通常需要經歷過組織的學習，以及在實際工作上不斷的練習與修正，才有辦法順利落實。這個過程通常要花很長的一段時間，所以根本就來不及解救眼前delay 的project。
更何況大多數時候，經理人們想引進的，都是新的工程技術，而不是什么革命性的管理觀念。新技術，遇上舊思維，原本存在的問題依然存在，而有限的時間與精力又拿去花在嘗試這些新的技術上，這些因素加起來的結果，通常會讓已經delay的project，delay的更嚴重。所以每次我聽到高階主管要在已經快要滅頂的項目中來個大革命，心中總是會默念阿彌陀佛，愿真主保佑你們，阿門。
增加status report的頻率
在某次的project review meeting上。
喬安娜：布魯斯，依你的專業，你覺得這一次，schedule還會再delay多少？
布魯斯：根據我跟我們team member的討論，我認為需要最少再給我們五個月的時間，才能順利上線。
喬安娜：五個月？這怎么可能？這種schedule我根本沒有辦法接受！這個project原本預估是六個月就要結束了，現在已經過了十一個月，而你告訴我還要五個月？！你有沒有搞錯啊。你們公司前一任的那個史黛拉，還告訴我們上個月就可以結案了，結果她做了兩個月就走了，你一開始接PM的時候，不是說再給你三個月嗎？我想你那時候對狀況不太了解，我可以接受你估的時間會比較不準確。可是上個月你不是說再給你四個月嗎？這段期間，有發生什么突發狀況嗎？結果今天，你居然跟我說你們還需要五個月的時間！
喬安娜想，你們這些渾蛋。自從接了這個project以后就倒霉到家。看來今天我的考績跟股票就這樣子去了…于是乎，憤憤不平地繼續說：我不管了，你們的項目管理不好，我就來幫你做。我要你整理出來，每個人每天應該要完成的工作，也就是說你要給我一份daily schedule。你每天要準備一份status report，我才有辦法每天跟我們的senior management update最新的status。我們兩個人每天最少要開會一次來review status。只要進度一落后，你們就立刻要提出action plan，說明怎么樣可以追上落后的進度。我想不這樣做，我們沒有辦法掌握你們的進度。不做daily review，這一次一定還是會delay。
接著氣沖沖地走了出去，留下一臉無辜的布魯斯。
當你擺在寫報告的時間越多，可以拿來寫程序的時間就越少。這好象不需要太高的智商，就可以推論出來。不過對于很多客戶來說，他們會覺得delay的原因就是因為他們沒有掌握最完整，最詳細的信息，以至于他們沒有辦法針對最新的情勢，做出最有利的處置。只要他們掌握了最豐富，最實時的信息，就可以順利地透過他們非凡的才智，做出對于項目最有利的決策。只要他們做了這么完美的決策，整個項目的進度，就會跟不斷轉動的飛輪一樣，邁向一個光明的未來。
好吧，類似的故事我在股票市場上常常聽到。掌握最完整最豐富信息的人，跟對了老師，就可以擁有超高的獲利。所以有很多人，日以繼夜地收集信息。然后呢，急急忙忙就跟著他所收集到的信息去做反應。所以短線不斷進出，殺進又殺出。一般來說，除非他們本身就是擁有內線消息，或是專門炒作股票的作手，否則這種人都很少賺到什么錢。
不過對于客戶來說，他們不會這樣思考。對他們來說，一定是因為有某些人在該做事情的時候偷懶，或是沒有全力在為他們做事，項目才會delay。直接可以推導出來的結論就會是，『我們需要時時刻刻保有最新，最實時的status report，才可以做好項目管理。』如果這些人剛好又是WBS的信徒的話就更慘。他們通常會要求項目經理先把系統切成許多細小的program，然后要天天提供by program的status report。然后就張大眼睛在看著這每一個小小的program，是否每支都可以如期完成。
對這些人來說，項目管理是一件再簡單也不過的事情了，你只要先把工作切割，然后交給team member，接著只要把team member的進度每天收集起來，經過復雜的數學公式運算以后，就可以得到一個簡單的指針，例如『今天已經完成了整個項目的百分之八十七。』接下來的工作，就是每天盯著這個指針，一手拿著皮鞭，另一手拿著紅籮卜，努力地鞭策著team member做事就好了。『喂，今天預定的進度是要完成百分之九十，沒做到不準下班。』
我還真有過一個這樣的客戶。當然她必定會覺得我過于簡化這個問題。不過對她來說，項目管理的博大精深之處最少應該還包含下列三點：
1.????? 要出錢買晚餐或是宵夜給team member吃。以犒賞他們加班的辛勞，因為他們一定要加班才可以趕上進度。
2.????? 要事先幫on site人員申請他們公司的通行證，以免警衛不讓他們進去。
3.????? 要熟背本日進度，以免高階主管臨時垂詢時，無法在一秒內立刻回復。
當status report的頻率增高時，其實就是指你每天要花更多的時間，來說明目前自己現在的進展如何，遇到的困難是什么。以便于讓管理階層，可以更迅速地掌握動態，并且更迅速地解決你所面臨的問題。
然而項目通常最大的困難就是時間不夠，更多的status report，就表示要開更多的會議來報告進度，并且要開更多的會，來討論怎么樣追上落后的進度。這必然就會造成更少的工作時間，也表示要趕上進度得要加更多的班。
如果project manager被逼著要每天報告進度，那么他最典型的反應就是要屬下也要每天做一次status report。這就跟大魚吃小魚，小魚吃蝦米，蝦米就只好去寫status report的道理是相通的。增加status report的頻率，其實就是讓整個開發的成本增高。Project manager要可以報出一個今日最新開發進度，后面當然會有一堆幫他收集資料的engineer。你讓team member花越多時間來幫你準備各式各樣的進度報告，他們能夠投注在實際開發工作上的心力就一定會比較低。
當然，頻率的高低其實并沒有一定的標準。對于某些人來說，daily review進度是一件習以為常的事情；對于某些人來說，一個禮拜，或是幾個禮拜才review一次進度，才是正常的狀態。在不同的phase，也可能會有不同的標準。在開發階段，可能兩個禮拜才review一次進度；在UAT時，可能每一天就review一次進度。
任何與team member的習慣或是與他們預期所不同的頻率調整，除了要花費比原來多的時間在做『非生產性的工作』以外，還得要考慮對于士氣會造成多大的影響。任何要調整頻率的措施，都應該要經過謹慎的思考與充分的溝通后，才付諸實現。
話說回來，每個禮拜知道一次進度，跟每天知道一個編造出來的進度，差別真的有那么大嗎？自己營造緊張氣氛來嚇自己，又會有什么好處呢？當你花太多時間在做micro-management，你就不會有心思去做真正的management。
增加人手以及焚膏繼晷
進度落后了？加班吧？人力有沒有問題？要不要增加一些幫手？沒錯，這是project delay時，最典型的思維模式。增加人手，其實并不是always是壞事。對于那種人力嚴重不足的項目來說，這有可能會是一場及時雨。增加人手的確可以解決問題。
很多人聽過man-month myth，就會有一種無論如何，都不應該加人的錯覺。直接推論的結果，得到的結論就是：任何項目只能一個人從頭做到尾。否則，增加任何一個人，都會延遲項目的schedule。
當然這不是一個正確的論點。所以大多數人還是會想要增加人手。只是如果對于一個人數充足，甚至原本就已經是過多的項目來說的話，增加人手會帶來的負面效應，則會遠大于正面效應。事實上，如果人數多到項目經理沒有力氣進行管理的話，要嘛就是要想辦法再增加管理的層級，不然則應該是要減少項目成員才是正途。
有些時候，加入新的成員，可以大幅減輕現有成員的負擔；有些時候，增加新的成員，反倒會大幅增加現有成員的負擔。怎么做才比較好，個中巧妙，存乎一心。這倒是沒有什么標準做法可以依循，每個案子都會有不同的狀況要考慮。雖然我不是這個領域的專家，不過在此分享一下我通常會考慮的幾個方向：
1.????? 現有成員的工作量是否已經超出他們所能夠負荷的工作量？
如果每個人看起來就是一副心力交瘁的模樣，那么不找人來幫忙，大概就要準備收辭呈了。
2.????? 新成員的加入，會需要多少既有成員的傳承？要占掉多少時間？
如果找到的人，沒有辦法上手，反倒是需要人一直去教他，這時候我會請這? 個人去做一些他可以勝任的工作。或者是干脆就請他離開這個team。除了怕主要成員花太多時間去教他以外，明顯的勞逸不均更是要避免的情況。
艾佛森：布魯斯，為什么那個布萊德可以擔任資深工程師，而我只是個工程師？他到我們這個案子來，什么都不會，教他又聽不懂。我們現在已經delay了，我沒有辦法自己去寫程序就算了，還要照顧他。自己都已經累得半死了，還要一直花時間教他，最氣人的是，他的職等還比我高，領的薪水還比我多，這是什么道理嘛？
布魯斯：沒辦法。布萊德是名校畢業的博士，這剛好是吉娜的最愛。雖然他沒有什么實際的工作經驗，可是吉娜一直覺得以他的學識，假以時日，他一定會有所貢獻。現在剛好是他學習的時候。
艾佛森：這一點道理也沒有。我們已經delay的這么慘了，還要帶個拖油瓶。
布魯斯：話也不是這樣說，你盡量看有什么可以讓他做的。反正我們現在人手不足，不然你找些打雜的事情叫他做好了。他要覺得沒興趣，就會自己想要離開了。
艾佛森：不然以后我有那種要改message，還是改GUI的工作就交給他好了。即使出了什么狀況，也不會造成太大的危害。
3.????? 現有成員短期內會不會有異動？會不會想要離職？轉調？是否還有其它人熟悉他現在手頭上的工作？
任何一個手頭上綁著工作的人離職，都會對項目造成影響。所以任何時候只要聽到有人想要離職，那表示跟他喝喝咖啡，談談是非的時候又到了。項目做久了，慢慢了解到生命的真實現象：『任何一個你覺得百分百可以配合，絕對沒問題，會跟你一起奮戰到底的人，都有可能會在一夕之間離開。』
有些人是出于主動的意愿，像是離職、轉調；有些人則會是遭受意外的打擊。像是家中遭遇變故，或是生了重病，突然之間發作出來。你對他的倚賴越深，失去他的打擊就會越大。所以最少要有幾個人可以相互backup，這樣一來，只要不要911來襲時，剛好整個team都在世貿大樓，否則應該可以順利從成員的流失中存活。不過在臺灣，人力不足是家常便飯，要能讓engineer互相backup，這簡直是癡人說夢。
我在學校時，總是覺得，只要有了文件，萬事都ok。只要離開的人，留下夠多的文件，人員的更替就不會有問題。現在就明白自己年幼時，是多么地無知識淺。任何時候，走掉一個經驗豐富的人，即使他留下再多的文件，都沒有辦法彌補這種損失。接手的人，常常光是要把文件看過一次都要很久的時間，更不要提如果你現在遇到一個狀況，得要在很短的時間內找到正確的文件，這件事到底有多困難了。
文件并沒有辦法取代經驗，當然，并不是所有資深的人，都擁有過人的經驗與智能。不過有經驗的人，在他離開的那一剎那，絕對是他人無法取代的。許多有智能的人，都是從實際的教訓中，學到在困境中存活的智能與經驗。這些人常常只要透過直覺來判斷，就可以做出正確的決策。對于企業來說，唯一的困難應該是在于，一個人是否具有智能，并不會寫在臉上。
一個人如果下定決心真要走，跟天要下雨，女兒長大要嫁人一樣，是攔不住的。能夠做的，舊是找人想辦法去跟他辦理交接。很多時候，我們都是在重要成員要離職時，才努力地思考怎么交接。然而再怎么交接，其實效果都有限。還不如平時就多想想，要怎么做才能讓這些人愿意留下來一起奮斗。
4.????? 目前處于項目的哪個階段？如果已經是處于項目的末期了，有沒有必要加入一個新的面孔？
有些時候，高階主管會因為現在有個人頭多出來沒事做，就詢問項目經理要不要讓這個人加入一個項目。老實說，有些事情，過了那個時間點，其實就不是那么重要了。每次看到這種到了最后一刻才想到該加入的人，就像是看到這樣的場景：
男女雙方，在經歷了一場床上大戰后，開始在床上抽煙談天，此時男方忽然悠悠地冒出了一句：『什么，今天不是安全期喔，那我剛剛是不是應該戴上套子啊？』
這就跟已經過了UAT，才指派了一個SA加入這個團隊一樣：『你現在才講這個，會不會太晚了一點啊？』
就項目而言，晚來的support，有時候還不如干脆就沒有support。做很多事情，時機是非常重要的。一個人如果沒有在適當的時間，加入這個項目，那就真的要好好考慮，還有沒有讓這個人join的必要了。即使他的能力再強都一樣。
5.????? 新人的加入，會不會造成組織的政治關系產生變化？會不會加入一個人以后，反倒是衍生出很多問題要我去處理？例如韋君與紹洋正在熱戀，韋君已經在team里面的話，我就會避免把紹洋也找進來，不然小倆口整天打情罵俏情話綿綿，讓大家雞皮疙瘩掉滿地，這可受不了。如果韋君跟佑威怎么樣都處不好，三天一小吵，五天一大吵，我一定也會避免把佑威找進來。
除了增加人手以外，最常看到的就是加班。偶一為之的加班，可能會對生產力有幫助，太過頻繁的加班，對于士氣與實際生產力，則都會有負面的影響。我并不建議在任何delay的項目中，都把加班當作是一個有效的趕上進度的方法。如果只需要偶一為之，短期的加班方案，或許還可一試。
目前為止，我所提出來的解決方案，都沒什么實際上的功效，拿來當笑話看看就好了。不過接下來的這幾個方法，則是我覺得實務上真的可以發生一些效用的方案。
更換項目經理
對于一個已經delay的項目來說，其實換人做做看，不見得是一件壞事。只是要下這種決定，需要非常非常謹慎的思考。當事人的意愿尤其重要。遇到那種異常艱辛的項目，其實有許多項目經理是巴不得可以趕快抽腿。對于繼任的人來說，則是要接下一個燙手山芋，所以對于要交接的雙方，都需要仔細的思考。如果你有好幾個項目要傷神，我建議你優先考慮那種長期處于資源不足的項目。
對于很多項目經理來說，人手不足，時間不夠，是家常便飯。可是在普遍都很慘的狀況下，總有一些項目經理的日子，過得就是比別人都來得艱辛。所以相對地，這些人內心的不滿，也就會比別人來得深刻。這跟這個人的EQ高低，其實只有間接的關系。直接關聯的就會是這個案子資源短缺的情況，到底有多么地嚴重。當一個人感到孤立無援的時候，內心的怨懟與不滿，常常會對于項目采取相當負面的態度。一旦到了這個時候，就該考慮更換PM了。
我個人建議在下列的情況下，可以考慮更換項目經理：
1.????? 與客戶的關系已經勢如水火
2.????? 項目經理已經開始失去理智，無法心平氣和的處理事情，而是采取非常激進暴躁的手段來進行管理
3.????? 項目經理明顯無法負荷，已經沒有辦法針對現有項目進行適當的管理措施
4.????? 項目經理明顯怠職
5.????? 大多數團隊成員提出離職或是轉調部門的申請
更換項目經理，不管是在任何一個時間點來說，都絕對是著險棋，有可能會讓項目浴火重生，也有可能讓項目萬劫不復。任何一個新任PM，都會有適應上的問題。如果他跟大多數的team member，沒以共事過的經驗，那也會有工作默契上的問題。如果隨著他的到來，空降了很多國王的人馬，那潛在的問題可能會更多。因為更換PM的結果很難預料，如果可以不換的話，最好還是原班人馬，一路到底比較妥當。可是如果項目經理的存在，已經沒有辦法對于團隊有任何正面的效益的話，那么及時更換項目經理，就是一個必要的措施。否則問題會持續蔓延下去，到最后要收拾就很困難了。
專注在解決方案上，而非責任歸屬
某次的project review meeting，喬安娜的老板麥克與吉娜都列席參加。
麥克：布魯斯，你能不能告訴我，我們現在會delay的ROOT CAUSE是什么？
布魯斯很緊張地說：目前我們會delay的root cause，都是因為requirement不清楚所造成的。User在開發的過程中，提出太多的requirement，完全沒有節制。
喬安娜：這種說法一點也不公平。都是因為你們的SA換人的關系…
布魯斯說：我們SA都有進行完整的交接啊。我覺得最大的問題，還是因為使用者的需求一直沒辦法確定下來…
麥克打斷布魯斯跟喬安娜的話：沒關系，你們先不要激動。如果這就是root cause，布魯斯，你有沒有什么相對應的SOLUTION？
布魯斯：當然有。我想最好的方法就是用我們現在的prototype跟user重新進行訪談。然后再請我們的SA把use case仔細地寫下來，跟user好好溝通。
麥克再次打斷布魯斯的話：沒有關系。既然你已經有了solution，我想你得要跟喬安娜好好討論你們的ACTION PLAN，包含整個resource上的重新規劃、schedule重新擬定。我想下個禮拜，就可以看到你們完整的plan。不知道吉娜，你有沒有什么看法？
吉娜：今天我來，是抱著一個學習的心理來列席的。很抱歉我們這個案子會造成大家這么大的困擾。我們當然是抱持著戒慎恐懼的心理來做這個案子，也很謝謝麥克能夠給我們一個將功贖罪的機會。我想布魯斯跟喬安娜都這么優秀，一定可以把這個項目順利告一段落…(好吧，她繼續打了十分鐘的官腔，因為官很大，所以大家都只好列席點頭不已。)
<商用英語教學>請問在上述的對話中，聽到哪些企業主管常用英文字匯呢？
<正確答案>所有的關鍵詞都用大寫標明出來了，就是Root cause, solution, and action plan。你猜對了嗎？
如果你手頭上有個已經delay的案子，客戶的高階主管要你針對這個案子的狀況進行報告，那么很有可能，你就會聽到這幾個字眼：『Root cause, solution, and action plan』簡單的說，就是為什么你的案子，會變成今天這個田地？有沒有什么根本的問題？面對這個問題，你有沒有答案？如果有的話，你打算怎么去解決這個問題？有沒有詳細的計劃？
我自己開過不少次這種會議，當然，雙方如果關系不甚融洽，可能在討論目前的項目為什么會這么慘時，就開始交相指責，開始對罵。所以光是root cause的討論，就會是一片刀光血影。
開這種會的重點，不是要找誰該負責，而是要找問題在哪里。一直要到大家把討論的重心放在怎么找出問題，并且要如何解決問題時，項目的情況才會獲得改善。對于不懂IT的高階主管來說，其實他們在乎的，不是責任的歸屬，而是現在的狀況是什么？你們建議的solution是什么？有沒有什么潛在的問題？目前又打算做些什么？
老實說，這是比較正面的看法。通常只有這樣子做，項目才可以從瀕臨死亡中復活。當雙方都一直爭論到底責任應該歸屬在哪一方時，如果沒有訴訟的可能性的話，我建議你可以試試認錯的方式。不管錯在哪一方，通通假設是錯在我們身上，先把推過諉責的循環打破。
<推過諉責的循環>
客戶：這都是你們的錯。
PM：哪有這種事情，明明就是因為你們的錯而引起的。
客戶：我們怎么可能會有錯？我們就是因為不會，才要花錢請你們過來。請你們來了以后，哎呀呀，居然都是我們的錯，真是花錢找罵挨。這分明都是因為你們的人太差才會變成現在這副德性。
PM：你講話很不客觀喔，這是直接的人身攻擊喔…
客戶：我哪有？
PM：你就是。
客戶：我哪有？
PM：你就是…
好吧，小學生吵架差不多也是這副德性。當你批評別人講話不客觀的時候，你算不算在進行人身攻擊呢？不過在吵的不可開交天昏地暗的過程里，通常我們不會顧慮到這一點。
<打破推過諉責的循環>
客戶：這都是你們的錯。
PM：既然我們公司接下了這個項目，我想關于這個案子的成敗，我們確實要負全部的責任。不過我們比較在乎的是怎么樣可以解決目前現有的問題。
客戶：你們要是早一點發現問題就好了。對于我們公司形象上的損失，這是多么嚴重的一件事情？真要負責，你們可以負什么責？
PM：我想問題這么嚴重，我們確實也沒有辦法給你們一個滿意的交代。不過我希望我們現在可以先把重心，放在怎么解決問題，讓大家都得到一個滿意的結果上。至于我們該怎么補救，該做的，我們一定會做。
客戶：你有什么建議？
當你承認錯都在你時，其實這個互相指責的爭論就可以告一段落了。很多時候，就只有在這樣的狀況底下，雙方才有辦法往前繼續邁進。如果討論的重點，不在于應該要誰來為現在的場面負責，而是在于要怎么樣才可以改善我們現在的處境，那么要找出雙方都可以同意的solution，應該就指日可待了。
縮小scope
對于一個delay的project來說，還有什么真正有效的solution呢？釜底抽薪來說，把要deliver的東西變少，應該就有機會可以趕上schedule。當然這里可能會牽涉到合約，或是其它雙方對于scope以及schedule的協議，需要重新訂定。
在這里唯一要注意的就是，把scope縮小，應該是把整個項目的scope縮小，而不是把這個phase的scope縮小，另外多增加幾個phase，或是把現在這個phase的功能，移到下個phase去。
如果你做的是把這個phase的scope縮小，那么對于整個項目來說，其實你只是把一部份的工作給延后了。會衍生的問題，通常就會是開發經費會大幅飆高。整個project的開發時間，有可能不會提前而會往后延。好處當然是可以符合使用者的需要，讓他們提早用到他們想用的功能。不過一個原本要分兩個phase作完的案子，如果多切了一個phase出來的話，直接的影響是什么？
答案是整個project的schedule跟開發經費都會無法避免地升高。很多人其實沒有警覺過，增加phase對于項目到底會有什么影響。增加一個phase，表示又多一個版本需要control，又多一個獨立的版本需要跟其它不同phase的系統進行整合，也表示需要獨立的測試人員進行獨立的測試。無形之中，也增加change發生的可能性。因此到后來，可能整個project的schedule跟經費都會往上延伸。
所以如果以整個project來看的話，把scope往后推到不同的phase中deliver，并不見得是好事。只有把整個項目的scope給縮小，才會有真正的幫助。不過對于臺灣的項目來說，這個機率其實是蠻小的。因為大多數的項目，都有一定的商業上策略的考量。這個時候為什么需要推出這些功能，除了一般人員的業績以外，高階主管多半都會有一些自己的想法與策略，希望能夠搭配這個schedule以及這樣的scope來進行。所以任何schedule與scope上面的異動，都有可能會沖擊到這些人內心既有的想法，而這個才是最難解的部分。軟件項目的開發，問題多半是在管理與政治面。真正技術上的難題好解，政治的問題才是真正棘手的部分。
況且大多數時候，scope其實是明確地記載在雙方的合約中，要變更的話，就更加困難了。所以在大多數的狀況下，修改scope只能拿來當成備案之一，而無法當成是主要的解決方案。
重新訂定出合理的schedule，并配合適度的項目評估措施
從事軟件項目開發，事情不如預期的可能性通常都很高。自欺欺人應該不是什么高明的策略，盡管你可能是抱持著蠻崇高的理由才會說一些『善意的謊言』，不過這種策略通常會有很多負面的效應。我個人認為絕對的誠實會比較恰當，把所有的問題跟真相攤在陽光下，才是最好的解決方法。
估schedule，其實跟在競標商品一樣。你想用100塊去標，有人喊了101，你會不會想要再往上加一點？每次要不要往上加碼，其實都是一個判斷的機會。這兩者除了schedule越估越久，跟標價會越喊越高很像以外；要隨時依據市場上的狀況，提出最新的標價，其實也是很相似的。項目經理其實隨時都應該要依據現在的狀況，評估整個schedule會不會受到什么影響，接著做出應有的決策。如果你只是很簡單地把現在這個phase的delay，推到下一個phase去的話，除了會喪失再次練習做評估與預測的機會之外，也喪失了隨著事情的發展調整你的策略的可能性。
所以在項目進行的過程里面，其實需要在適當的時機，持續地進行項目的評估。與解盤法最大的不同，其實主要是在于心態上面。不斷地評估項目情勢并不是為了要找借口，也不是在預測項目結束的落點，而是在找目前還有什么問題是應該要獲得解決，以及各個resource應該要在什么時候投入項目的開發。
當項目經理開始認真地評估項目進行的狀態時，這時候解決方案的核心，就會在于該如何才能與客戶敲出一個雙方都可以接受的schedule。大多數時候，基于利害考量下的妥協，雙方多半都只能商量出一些對于短期有利，可是對于長期有害的solution。例如最常見的方法就是，我們增加一個phase，先把user比較急迫的功能，在這個phase中deliver。在已經delay的項目中，雙贏的方案幾乎是不存在的。
最好的結果，當然是顧客與廠商之間坐下來好好談談，這個項目主要的目標是什么？要達成目標，在有限的時間內，又可以完成些什么？以及整個項目要順利結案，大概會花多少的時間？畢竟在項目開始，一片混沌時的估計，本來就應該要進行某種程度的修正，才會比較符合實際的狀況。只有雙方坐下來，將雙方需要完成的目標攤開來，務實地討論，重新訂定schedule，并且訂定適當的項目評估措施，這樣子即使delay，最少也是在一個可以控制的范圍內。
至于怎么評估，怎么樣進行控制會比較好呢？我想推薦一種我沒有完全實際用過，只有從書上看來的方法：『Critical Chain Project Management』(作者注)。在我自己讀過相關書籍以后，管理項目時，通常就會清楚地把focus，聚集在critical path以及resource的availability上面。這些concept通常在軟件工程的書籍里面，是找不到的。
※作者注：真的有本書就叫做這個名字：Critical Chain Project Management。只是我還沒時間拜讀就是了。如果你對于怎么安排schedule有興趣，我建議你去看看TOC的書。在此再次推薦高德拉特所寫的Critical Chain。不過因為這是本小說，所以我建議你可以找些相關的延伸閱讀。我自己讀過的是Project Management in the Fast Lane。里面的觀念，對我還蠻有用的。:-)
結語
曾經有段時間，我接到一個全新的案子，一開始項目只有三個人在撐。后來miss掉蠻多milestone，被客戶罵到狗血淋頭，我就開始不停地工作，日以繼夜地加班，唯恐整個項目，就毀在自己的手里。與我一起工作的伙伴，也都處在我所施加的潛在壓力下，非常艱苦地長時間工作。到最后，那個項目meet某一個delay過后的milestone，也deliver出一些看起來很像是系統的東西。可是大部分的team member都走光了。對我來說，雖然看起來我們好象完成什么東西，可是team member的相繼離開，讓我覺得這個項目是一個徹底的失敗。
當你看到一個manager，逼迫著team member不停地加班，潛藏在他內心深處的，就是一個害怕失敗又不知所措的靈魂。很多時候，當你越在乎項目的成敗，越被schedule引領你所有的行為，你的思考就會變得越狹隘。
怎么樣才可以跳脫這個困境呢？換個角度吧。先假設你手頭上的案子是全然的失敗，delay遠遠超出你的想象，想想你會有什么下場？公司會受到多大的打擊？先試著去接受這個事實，接著請想想，你有沒有什么可以做的事情，可以讓這個項目脫離這么完全又徹底的失敗？有沒有什么是還有機會改善？不管是多小的改善都好。
通常經過這樣的思考，就有機會從完全不一樣的觀點來看待事情了。Delay就delay吧，那又怎么樣呢？大不了就是這個project fail，當作是公司付給你很高的學費嘛。So what？當你能置之死地之后，就有機會可以浴火重生。
每個人對于一件工作要做多久，都會有不同的想法。因為每個人的能力與經驗不同，同一件事情交給不同的兩個人進行估計，很少會估出完全相同的schedule。再加上把大家的東西整合起來，到底需要多少時間，就是一個更難預測的問題。
以產業界目前流行的方法來說，如果你是個用傳統結構化系統分析開發系統的人，可以用function point來幫忙估計；用UML + OOAD的人，可以試試用use case point來進行估計。這些方法最少背后還有一套理論根據。如果你對于你想要開發的系統已經了然于胸，你當然也可以使用WBS來進行規劃，只要記得加上讓大家的東西整合在一起的時間就好了，不過這個時間通常都不短。
不管你用哪種方法，持續地收集這方面的信息都是必要的。這會讓你有鑒往知來的機會。不過不管你采用哪種方法，其實都不能保證你估出來的schedule，就會準到哪里去。因為每個不同的團隊，在不同的項目下，都有屬于他們自己的故事。
估計其實只是項目管理中的一環，很多時候，不管你做了再多學理上的研究與分析，客戶想要8月上線，這個就必然會變成是預期的deadline。不管你花再多時間進行估計都沒用。怎么面對即將delay的schedule，才是我們每天生活要面對的問題。
對我來說，項目管理除了軟件工程上的理論以外，實際工作的體會，才是讓我自己收獲最多的。很多體會都是在實際工作的過程中，做了很多傻事，不斷地修正自己的看法，才慢慢形成的。而這個修正的過程，雖然很痛苦，其實事后看起來，還是一件很有趣的事情。
當我在思索該怎么面對delay的schedule時，忽然想起電影鐵達尼號里的樂師。在鐵達尼號快要沉沒時，還能悠哉悠哉，氣定神閑地彈奏音樂，如果一個人可以修養到這種地步，或許就可以心平氣和地面對所有不可預見的風險吧。
另一個腦中浮現的人物則是金庸筆下的韋小寶。他像是一只打不死的蟑螂。在相同的時間內，他要面對各式各樣不同的項目，而且到最后，大多數的項目都可以順利deliver，沒有deliver的也獲得了客戶的肯定。除此之外，在項目deliver之后，他還可以從中獲得不少好處。他對于資源巧妙的運用，簡直是令人嘆為觀止。走筆至此，不禁跟呂留良有相同的慨嘆：『百無一用是書生。』或許我們應該少讀點書，多學學躺在地上裝死，以及睜眼說瞎話的技巧，這樣才能當做一個更稱職的項目經理吧。
※作者注：關于呂留良的慨嘆，請參考金庸先生所著，鹿鼎記第四十回。

?

總結

以上是生活随笔為你收集整理的Delayed Project(下)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。