務實看待專案的工作期限

上週有位朋友在Facebook上寫了一大段話，提到他目前專案的一些處境和情況。他這段話破題的第一句就是：「不知道為什麼，這麼多人會相信，設一個超級不合理的期限，就會讓programmer的生產力提升」。但這種設定期限的方式，似乎還有不少人使用，尤其是那種信仰壓力能使木炭變成鑽石的高壓管理派。

設定一個超級不合理的期限，意思就是說，這期限顯然是達不到。既然達不到，那麼為什麼還要把期限設的如此的不合理呢？我想這是因為很多人都相信「取法於上，僅得為中，取法於中，故為其下」的道理。

也就是說，如果事先設定了一個高標準，因為要達成不容易，最後可能就得到一個中等的結果。但若是只設定一個中等的標準，那麼，最後很有可能只有低水平的結果。

因此，不少人會認為，如果我把開發專案的期限設得很短，短到不合理的程度，那麼就會製造出一個很高的壓力，驅使開發人員極力的追趕那個實際上達不到的期限，最後即使達不到這個不合理的期限，也可以盡量縮短時程。

取法於上與取法超上的界線
在之前已經討論過壓力跟工作績效的關係，當然，適度的壓力有助於工作績效的提升。但是，長期的高壓力，有可能帶來工作績效的崩潰。而這種「取法於上」的方法，有時會被誤用為「取法超上」，也就是說，不僅僅只是把標準提高到有機會達成的程度，而是一舉提高到完全不可能達到的境界。

例如，將業務銷售額的目標訂得超高，幾乎難以實現。或者，像是本文一開始就提到的，將軟體開發的時程，訂成一個超級不合理的期限。

「取法於上」的方法不是沒有道理，但是一旦被誤用成「取法超上」時，有可能像長期的高壓力一樣，造成崩潰的效應，最後反而「得乎超下」。

為什麼設定一個不可能達成的標準，有可能會引發崩潰的結果呢？

當你為專案設定了一個超高的期限標準時，一開始開發人員不見得完全明白到那是絕對不可行，樂觀的開發人員甚至還會抱著姑且一試的想法，試著去力拼看看。但是，隨著專案的推進，他們慢慢地，甚至是很快就會察覺到這時程完全不可能實現。

每個人其實都可以試著在心裡模擬一下這樣的情境：當你發現你的工作目標絕對不可能達成時，你會怎麼辦呢？我相信有很多人會選擇「放棄」。因為無論再怎麼努力都達不到，都會得到一個逾期的結果和評價，那乾脆就放棄了。

在這種時候，原先設定一個超高標準的目的是希望「取法超高，得乎其上」，但是，因為造成了實現無望的情況，反而引發了崩潰的效應，使得結果反而背道而馳。

計畫的目的與意義

不合理的期限會造成一件危險的事情。在專案一開始進行時，我們得製作一份專案計畫，裡頭規畫重要的專案工作，以及它們各自的啟動時間、完成期限。當然，評估每個工作所需的人力及時間並不是一件容易的事情，估計可能不那麼正確甚至完全失準，再加上專案的進行中會有各種預期之外的事件以及可能發生的風險，使得各項工作預估的啟動時間，以及完成期限，都有可能做因應的調整，甚至還會衍生出新的工作。因此，專案計畫也會隨著專案的進行的現況，而不斷調整及修改。

對一份計畫來說，最重要的事情莫過於它必須是可以實際據以執行的。我們做計畫的目的是為了協助釐清究竟有那些待執行的工作、安排這些工作的先後執行順序、以及規畫執行這些工作的時間點、執行者，當然，還有預估可能的完成時間。計畫可以說是我們用來輔助專案進行的工具，它代表著對未來可能發生的事情的評估及預測。倘若計畫的評估或預測與現實偏離，那麼就必須回過頭來修改計畫，以使得它能夠在專案接下來的日子裡，繼續輔助我們。

但是，一旦你的專案給定的是一個完全不實際的期限，你要做計畫或者是不做計畫？當然，你不太可能完全不做計畫，但如果你做計畫，是要依據這個完全不實際的期限來做，還是自己設定一個期限來做？你也不太可能自己決定另一個期限，這麼一來，你就得依據一個全然不實際的期限來做計畫，最後當然也就做出一個從頭到尾都不實際的計畫。

我必須說，開發軟體時最棒的感覺之下，就是你看著計畫書，然後發現所預期的工作能夠照著計畫執行、完成。當然，現實不會那麼完美，或許你會遇到一些波折，但是你發現在你做了應變調整計畫之後，還是可以繼續實現計畫的內容。這是所有開發人員都最喜歡的事情——實現計畫。

絕大多數的開發人員都不喜歡工作發生了延遲，絕大多數人都享受如期完成工作的美好感覺。

當你能照著計畫在現實中實現時，那種感覺是絕佳的。一份好的計畫書能讓開發人員對它產生信賴感，因為他會知道照著這份計畫來執行時，很有機會可以實現計畫，即使有所偏差，計畫者也能迅速反應，並且修改計畫，使得之後仍然可以照著計畫來施行。

開發人員喜歡這樣，是因為這可以為他們帶來那種美好的感覺，並且在工作中不斷激勵他們完成工作。

相反的，倘若照著計畫行事，卻始終無法照著計畫的內容來實現，就像是每個工作都發生延遲、都無法如期完成，對開發人員來說，也會產生很大的挫折感。

當然，他們就會愈來愈不信任計畫的內容，這時候計畫的內容就變得徒具形式、虛有其表了。不具參考價值的計畫，等於是不存在。

這其實在現實的開發生活中還滿常看到的，在專案一開始的時候，專案經理洋洋灑灑寫了一份壯觀的計畫書，但不是不能反映現實的情況，就是遇到了預期外的事件後，而沒有做因應的調整。

所以，隨著專案的進行，愈來愈沒有人參考這份計畫書的內容，所有的開發成員開始以一種零亂的方式各自執行各自的工作。專案經理也不做計畫了，開始進入不斷隨機應變的模式，大家可能都無法預期下一週或下兩週，專案會處於什麼樣的狀態。

不信任、絕望下的反應──專案崩潰
而最可怕的是，如果回過頭來看計畫書的內容，很多人的工作都發生延遲的情況。但「延遲」的原因有很多種，其中機會最小的是開發人員偷懶或不認真。但是，一般人在看到「延遲」的情況時，時常會往開發人員身上貼上了負面的標籤，而開發人員最不喜歡被別人說他的工作「延遲」了。

所以，一個一開始就基於不可能實現之期限的計畫，就註定其中許多的工作完成時間檢核點都會被錯過，也就是「延遲」。

「延遲」會讓開發人員不開心，尤其是當他們是那麼全心全意的投入工作時。那麼，既然不論是不是努力投入工作，都會發生「延遲」，那不如開始「擺爛」吧。

當專案中愈來愈多開發人員這麼想的時候，專案就崩潰了。沒有人相信計畫、沒有人相信做計畫的人、也沒有人相信時程，大家開始用低生產力工作，因為反正註定是要延遲的。

長期的高壓力會引發崩潰，信任感的缺乏也會。「取法於上，僅得為中」的道理可以適度運用，但是倘若自行發揮推廣成「取法超上」時，恐怕不見得會帶來正面的效應。