程式開發工作的時程預估

所有的開發專案一定都會要求時程預估,並依預估結果繪製時程表,進行專案時程的管控。然而,大家也都習慣性地把時程表不當一回事。『反正最後一定會 延遲。』『客戶一定會要求修改,我們再來趁機修改時程或刪減功能。』幾乎沒有一位專案經理可以在專案一開始,就相信專案可以如期交付,反正先硬著頭皮做了 再說,等專案真的延遲再想辦法。萬一真的不行,各種外力不可控制的理由紛紛出籠:『這根本是不可能的任務,當初業務就不應該答應。』『公司承諾的人力,因 為卡在某某案子,沒有如期到位。』『設備採購出問題,還要從美國坐船過來,導致後面的時程都受影響。』『系統軟體原廠支援不足,我們光排除安裝問題就多花 了兩個月。』

時程預估的不確定性

專案中的一個程式模組,指派給某個工程師要求預估工時,工程師如果回報的是 4 個工作天,有沒有什麼辦法可以確認這個數字是合理可行的呢?試著把同樣的工作交給另外一個工程師評估,有可能得到的是 9 天,也有可能得到的是 2 天。顯然的,預估工時在程式開發這個領域中是很不科學的,不同的人預估會得到不同的結果。到底我們該不該相信預估的結果?還是有什麼東西是過去一直沒有注 意到的?

程式開發專案中,充滿了各種不可控制因素,除了前面提及的『理由』外,還更多的是來自內部原因,例如:『工程師突然生病請假兩天。』『程式裡有個 BUG 一直找不到,多花了一個星期才找出問題。』本來一個 4 天預估工時的程式,因為發生一個找不到的 BUG,延後超過 9 天是常有的事。對同一件工作,預估工時為 2 天、4 天、9 天,其實都是合理的,只是大家是站在不同的考量點上,有人非常樂觀的預估,假設一切都很順利,只考慮實際上寫程式所需的時間;也有的人是過度謹慎的預估, 把所有可能的風險都列入,並假定這些風險都會發生,估出 9 天也不足為奇。

絕大多數的專案,是以客戶的時程為底線,再將專案工作分解後,硬塞入有限的工時之中,如果塞不進去,才會進一步檢視各個工作項目,是否可以縮減工時 或是提早開工,直到所有工作可以在客戶指定時程內完成為止。這樣的動作其實是非常可怕的,專案只有盲目地壓縮工時,整個過程充滿了『談判』、『協商』、 『要求』,沒有花心力去注意怎樣的時程才算合理。完全忽略了一個導致專案失敗的人性因素:如果預估工時,讓所有人都覺得根本無法達成,努力跟怠惰結果一樣 無法達成任務,大家就會選擇對自己比較輕鬆的方式,開始摸魚,反正都是做不完!

既然個別工作項目都可以三、四倍的預估落差,整個專案加起來也是一樣,不同的專案經理,在沒有時程的壓力下預估的總時程,落差也會很大。由於專案經 理提不出一個科學客觀的時程,只能憑『感覺』去爭取時程,完全沒有說服力,最後只能以客戶的時程為時程,專案經理幾乎沒有爭取時間的籌碼。

由於專案進度的掌控是以工時預估為基準,如果這個基準因為不同的人預估,而存在極大的落差,也會無從進行進度的控制。確實需要一個可以被大家普遍同意的預估方法。

PERT 時程預估法原理

計劃評核術 (Project Evaluation and Review Technique) 最早應用於美國海軍的北極星核子潛艦計劃,用來評估並管理時程難以精確估計的超大型專案。PERT 提出了機率管理的概念,這個方法認為不管第一次預估是 2 天、4 天或 9 天,都有其道理與考量,專案雖然只會有一個完成時間,但還沒開始動手之前,每一個時間都是有可能的,只是機率不同罷了。

PERT 假定工作完成機率的是 Beta 分佈,需要三個參考值,來計算機率的分佈,第一個值是『最快可能完成的時間』,第二個值是『最有可能完成的時間』,第三個值是『最慢可以完成的時間』,我們若分別 2 天、4 天及 9 天代入,可以得到如圖一的機率分布圖。

圖 1
圖 1

其中第二個值是機率最大的時間,所以放在圖中曲線最高的位置,但是其他兩個值的相對機率是多少呢?PERT 的第二項假設是:最快與最慢的機率假設為最可能機率的 1/4。至於這個比值暫時不必去管是出於什麼道理,我們可以依此計算出平均值 ( 2 * 1 + 4 * 4 + 9 * 1) / 6 = 4.5 天。這個平均值是一個相對穩定的值,PERT 即以此平均值做為預估工時的基準。

平均值仍然不夠

雖然 PERT 已經提供了一個較為客觀且變異性不會太大的時程預估方法,但 40 多年來的應用並不普遍(較廣為應用的是 PERT 網路規劃圖及其衍生的要徑法)。原因在於 PERT 預估法只適用於時程變異較大的案例上,例如:太空科技的發展、新藥的研發、軟體關鍵技術的開發 … 等。在軟體開發專案中,並非所有的工作項目都具有很大的變異,例如:硬體設備的採購、使用者訪談、網頁圖素的製作、操作手冊的撰寫 … 等非程式開發項目。

我們再次觀察圖一中的平均值,會發現在平均值 4.5 天之前的曲線圖形面積,約略佔整個面積的 50%,也就是說到第 4.5 天完成的機率,其實只有 50%,另外約有一半的機率是會超過預估時間的。

再從圖中看起來,9 天似乎是一個較為『安全』的預估值,把時間定在 9 天,也許就有九成的把握完成程式項目的開發。4.5 天與 9 天恰好是兩倍的差距,專案經理對此亦相當的為難,定在 4.5 天最能符合客戶的需求,而定在 9 天能如期完成的『把握』較大。

許多專案經理就此放棄 PERT 法,定在 4.5 天風險太大,而定在 9 天根本無法被客戶接受,況且 9 天這個值也不是一個客觀值,由不同的人預估出來的差異很大。

掌握機率要靠控制而不是預估

不管怎麼樣,從 PERT 的模型中,仍可以看出由風險所導致的機率分佈現象,這個機率分佈確實能夠解釋,為什麼不同的時間或不同的人來做同一件事,完成時間會有差異。機率分佈模型 已經明白地告訴我們,精確的預估值其實是不存在的,圖一中的每一個時間都是有可能達成的,只是發生的機率不同,專案經理盲目的要求精確預估,只會是自欺欺 人的作法,怪不得大家都不會相信預估的結果。

如果我們已經承認預估工時不會精準,是否表示以後專案就不需要再作任何預估了?當然不是!工時預估只是作為進行專案資源分配的準備,接下來就是對時程的控制,而時程控制最重要是靠『預估時程表』以及可重分配的『緩衝時間』,隨時監看專案的進展。

當某個工作項目超過預估時程時,不是用任何方法鞭策工作人員,並要求自行加班以趕上專案時程,而該是深入檢討工作程序是否出了什麼問題?是否有已知 或未知的風險轉化成危機,需要立刻進行危機處理?必要時提出部份保留的緩衝時間,投入已延遲的工作中,並重新調整後續工作項目的開始時間點,讓專案能夠順 利繼續進行。要注意:專案的目的是完成工作,不是完成預估。

專注於緩衝時間的運用

專案裡每一個工作項目的預估工時,或多或少都會計算入風險控制工時,或是稱作緩衝工時,以因應風險的發生。這些緩衝工時存在的原因,就是要確保單項工作沒有機會延遲,但是這樣卻是造成整體專案延後的最主要原因:時間會被莫名其妙地浪費。

例如:一個預估工時為 9 天的工作項目,假設是作了最保守的估計,按照 PERT 的估計只需 4.5 天,而事實上程式發生了一點小問題,總共花了 6 天才完成。看起來是提早了 3 天完成工作,然而事實上這 3 天會被浪費掉,因為按照原定計劃,下一個工作項目要 9 天之後才會啟動,多出來的 3 天裡什麼工作也不會發生,即便是整個專案的時程已經很緊了,下一個工作也來不及接手,還是要等到第 10 天才會動手。

在 PERT 提出的 40 年後,制約理論 (Theory Of Constraints) 將最早發展於生產製造的緩衝管理方法,運用到專案管理的領域,認為專案最大的制約項目是時間因素,因此要投注最大的心力在時間緩衝的管理上。

TOC 主張個別工作項目不應該各自擁有緩衝時間,工作項目設定一個較為緊的工時:『約有 50% 的把握如期完成工作』(與 PERT 的預估結果雷同,但不用複雜的機率估計法),專案保留一定比例的緩衝時間 (約為總預估工時的50%),隨時依專案進行的狀況,將緩衝時間分配給已延遲的工作項目運用。以圖一為例,預估工時即為 4.5 天,但另有額外的 2.25 天,提撥到專案統籌管理運用。

(註:有關 TOC 在專案管理的應用,請參考由天下文化出版的『關鍵鏈』一書)

專案經理要改變管理的觀念

由於程式開發的風險很大,要讓專案進行順利,專案經理首先要改變管理的觀念,承認風險的存在,並允許風險在工作項目裡發生的可能。預估工時與實際工 時常有出入,不見得是寫程式的人不努力,也不見得是預估工時的人不專業,主要是風險由可能發生的機率,變成已經發生的事實,進而衝擊到工作的進行。例如: 硬碟故障需要重灌系統而延後兩天,誰該負責呢?

沒有人要對此事負責,但專案衝擊已然發生,整體時間往後遞延兩天,專案經理以及整個專案團隊都要付出代價。在風險管理的前提下,保留的緩衝時間就能夠於此時派上用場。所以專案經理要改變管理的觀念,與其追求精確的預估工時,不如花時間在風險的管理之上。

作者:周旺暾,PMP (台灣微軟應用開發技術經理)
2005 年 1 月

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: