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

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

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

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

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

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

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

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

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

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

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

計畫的目的與意義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


熱門新聞

Advertisement