不切實際的時程規劃表

對程式設計者而言，倘若可以自由自在的、在沒有時間壓力的情況下來撰寫程式、開發軟體，那肯定是相當美好的一件事。但是，在大多數現實的條件底下，軟體的開發，不論精細與否，都有其進行的時程規劃
－ 而其中最重要的，當然是每項工作完成的時間點。有時我們將工作完成的截止時間稱為deadline，從字面上去解讀，那就是「死線」。這字面上的意義彷彿告訴我們，截止的時間就好比在時間軸上劃下一道線，越過了這道線，也就是超出了這個理應完成時間點，那就只有死路一條。

在我們當中的大多數程式設計者，他們的開發生活幾乎可以說是大大小小的各種工作的「死線」所交織而成的。這種無時無刻不在與時間壓力博鬥的工作，有時難免多少減少了幾分程式設計者對程式設計工作的喜愛。

但軟體專案的開發，卻又缺少不了對每項工作的時間起迄規劃（專案的本質就是有固定的開始及結束的時間），不可能在完全沒有時間規劃的情況下進行。事實上，開發時程的擬定與規劃，也一直是軟體開發與專案管理的諸多議題中相當重要的一個，因為它關係到開發專案是否能夠準時如期交付。

在我們的印象裡，似乎滿大比例的軟體專案都無法如期交付，延遲交付似乎是軟體開發專案的常態。而大多數的情況下，當軟體延遲交付時，程式員通常都會成為眾矢之的，擔負起延遲交付的責任。因為，在許多人的認知裡，程式員是開發專案最主要的執行者，他們所撰寫的程式碼則是專案最終的產物，當這個最終的產物無法如期完成時，當然是程式員要負最大的責任。程式員或許偷懶、或許能力不夠，才會無法依照專案的時程規劃完成工作。

或許現實之中，真有一些例子是因為程式員偷懶或者能力不足才造成專案時程的延遲。但以我自己的親身經驗看來，專案時程的延遲，通常都是發生在不可歸疚於程式員的環節之上。

專案時程的延遲，有一個很常見的原因是，時程本身就有問題。許多軟體專案的完成時間規劃，並不是從究竟有多少資源、以及究竟要完成那些工作來進行的。它們通常是已經先假定了必須完成的時間，以及要完成的最終產物，再回過頭來展開其中需要完成那些工作，依照可運用的人力，填入每個工作需要被完成的時間。這種我稱為倒推法的時程規畫方式，要完成的最終產物，以及必須完成的時間，幾乎都是不可以改變的，但資源是有限的，倘若可運用的人力看似不足以在期限內完成時，那又要如何呢？無疑的，你得做些調整和改變。

許多人選擇改變的，並不是最終的產物（也就是縮減開發的範圍）、也不是完成時間，而是壓縮其中工作的完成時間，以便在完成一份能在完成時間結束前，圓滿的達成所有工作的時程規劃表。但問題便出在，其中的工作所需的時間為什麼能夠壓縮？原先預估撰寫一個功能需要十天，為什麼專案經理大筆一揮，把它壓縮成六天，它就能夠變成六天呢？這就是一種過度的樂觀，相信「拼一下」應該就沒問題。你或許可以在專案當中「拼」個幾個工作，但很難從頭「拼」到尾。

當專案經理完成一份洋洋灑灑、編排美觀－而且最重要的是，在預期的期限內結束的時程規劃表時，好似他的工作已經完成，接下來的責任就交給每個工作的執行者了。這樣的時程規劃表不過只是粉飾太平的一份文件，因為它所呈現出來的，只是一個假象。時程規劃表是專案中所有成員所賴以依循，做為導引專案前進之用的一份文件。但，倘若這規劃表裡，充滿了太多對工作時程能夠壓縮的樂觀態度，那麼這樣的文件還有什麼參考價值呢？我們常說照表操課，但可惜的是，有許多人的專案，實際執行的情況，和時程規劃表往往是兩回事，其中最重要的原因，便是這張表本身就無法被執行。

完成一份務實的時程規畫表，對於專案能否如期完成是相當重要的一件事。而一份能實際被使用的時程規畫表，應該要取得專案參與者（當然包括程式員）的承諾。也就是說，專案參與者必須明白他究竟在這個專案中會有那些工作，每個工作他自己是否能夠承諾規劃表裡所假定的完成時間。我們可以看到許多時程規劃表，不過只是專案經理自己一個人的一廂情願，並沒有適度和所有參與的成員溝通，並且取得所有成員的承諾。許多程式員都是被告知工作需被完成的時間點，他們沒有機會表示他們對於時程的看法。但不顧工作執行者對時程的看法，無疑的只是讓這份時程規劃表距離現實更遙遠，愈加的不可執行罷了。我們可以想想，我們要一份不可執行的時程規劃表做什麼呢？

當專案中的工作發生延遲時，很少人歸因於完成期限本身就有問題，而多半認為問題出在執行者身上。但充斥著不合理的完成期限的專案，最終又怎麼有可能如期完成呢？

許多專案經理會樂觀的認為時程可以壓縮，是因為他們相信「加班」這個秘密武器。倘若壓縮後的時程真的趕不及，那就讓程式員們加班吧。每天加班四小時，就等於就多出了原先一半的時間，對於時程，他們當然有樂觀的權利。程式員可都是渾身熱血的動物呀，只要燃燒起來，沒有什麼不可能的。可惜的是，研究指出，長期加班的程式員，其實際的生產力反而比不加班還要糟。雖然工作的時間或許拉長了，但是，每個單位時間能夠產出的有效程式碼卻降低許多。

很少程式員在經歷長期加班的工作後，能夠不感疲累的吧？拖著疲累的身驅及大腦撰寫程式，反而更容易出錯。程式員花了更多的時間，卻無法寫出更多有效的程式碼，這簡直是賠了夫人又折兵。

加班這個武器不是不能用，而是得用在刀口上。加班不適合長期為之，但偶而用於短期衝刺，還是有其效果。但總的來說，對程式員的工作時間安排，應該還是稍微放鬆一點，這有助於產出更良好品質的程式碼。適度的降低對程式員的時間壓力，程式員會拿更好的程式碼來回報的。

開發軟體，必須學習面對現實的時程。而時程也是最現實的，因為無論你有多樂觀，它仍然會忠實的反映它應該要有的面貌。我曾參加過一個嚴重延遲的專案，專案經理為了迎合客戶的心理，刻意的又編排了一個樂觀的時程表，希望可以少受點客戶的責難。當時技術的最高主管看了這一份時程表後說道：「我們又何必自欺欺人呢？」的確，編寫一份不切實際的時程表，只是註定再次延遲，無助於專案準時交付。還不如面對現實，讓大家都相信時程表中規劃的時間，的確都是可以準時完成的，這麼一來，所預估的專案完成時間也才會更合理，更有機會被達成。

Posted at 11:34下午 十月 05, 2009 by Chien-Hsing Wang in General  |  迴響[1]