談專案的「時程估算」:有哪幾種估算方式?與上級的期望值不符時如何因應?

談專案的「時程估算」:有哪幾種估算方式?與上級的期望值不符時如何因應?

時程估算一向是讓PM頭痛的工作,有多少人和我一樣,經常會陷入期望值和估算值的拔河呢?一般來說,時程估算有幾種方式:

1. 專家判斷 : 顧名思義,可請團隊中對該項任務較熟悉的成員來評估,或者尋求專案外部專案提供意見。

2. 類比估算 : 也就是經驗法則,藉由過去類似性質的專案或工作任務,來推估可能的時間。

3. 參數估算 : 依據歷史數據套用參數來計算,這一種估算法較適用於任務相對單純、工法明確的專案上,例如系統櫃裝設,設計師可能會用櫃位尺寸當作計算基準,由於施作的方式大同小異,所以每單位長度的裝設時間差不多,價格也雷同。但若木工比例越高,因為須配合現場來調整木作,變數也越大,所估算的時間差異也可能增加,便不適用。

4. 三點估算 : 將時間的估算分為「最可能」、「悲觀值」與「樂觀值」三種,這個做法通常用在難見度較差,或者存在風險的專案上,將對於未來的不確定性,分別假想一切順利的情況,以及風險皆發生的情況,做極端的兩種估算。

5. 由下而上估算 : 從WBS中最下層的工作任務開始估算,逐步往上累加。

除了上述的方式之外,相信大家在實務上也有各種不同的做法,以敏捷開發為例,便有一種名為「Poker」的方式,參與估算時間的人員手持代表費式數列(註1)的撲克牌,按自己的理解來估計完成任務所需的時間後,挑選 1 張合適數字的牌,其中數字最大和最小的人代表極端值,必須解釋選擇這個數字的原因,供其他成員參考,接著再次出牌,反覆直到大家的估計值相對差距較小為止。簡單來說,是一種集體討論的共識。

或者我們也可以混合估算,例如將WBS內的工作任務區分為可類比式、可參數式及其他,前兩者可分別透過類比、參數法粗估,再請專家確認。其他類則透過「Poker」形式討論估算,最後再將每個任務的時間,依據時序關聯拼湊出專案時程的全貌。

不論使用何種方式,或者使用哪些方式混合,我們最終都可以得到一個專案預估完成的時間,但它就代表專案時程了嗎?相信不少PM們都會搖搖頭,因為這個由團隊估算出來的時間,通常還需要和主管、公司或Sponsor的「期望時間」進行一場PK,而且誰勝誰負通常是可預期的。

既然如此,又何苦大費周章估算時間呢?的確,這是許多工程師們一致痛苦的心聲,尤其軟體開發就如同前述的木工施作存在許多變數,在規劃階段是不容易估算的。然而站在公司或雇主的立場,卻總是期望專案早日完成、產品盡快上線,導致預期專案交付的時間,通常不是團隊估算出來的「合理」時間,隨後就會衍生專案變更、人員加班等各種問題。

有些PM經過幾次被Sponsor壓榨的挫折後,就會出現「反正講了你們也不聽」的鴕鳥心態,這是「向上管理」最忌諱的現象。管理者有其盲點,這是確認的事實,最熟悉專案、最清楚何時能交付產出的人,絕對是PM和核心團隊成員,因此PM有權責提出「合理」的時程規劃。

若擔心Sponsor對專案時程有情感上的期望,建議使用三點估算法的概念,提出「最可能」、「悲觀值」、「樂觀值」三種時間,更重要的是提出對應的說明,例如悲觀值的推測是來自於哪些潛在風險,樂觀值則是針對這些風險採取什麼應變措施,並且這些措施會衍生什麼影響 (包含可能須加班)。Sponsor情感上的渴望,可能是未充分理解時程風險,所以對於風險的陳述是絕對必要的。

上述的三種時間也可以使用相對機率的概念來表示,從樂觀值至悲觀值中間,都是專案完成的可能時間,但團隊信心度或可掌握度不同,樂觀值可能只有40%,悲觀值為60%,在這之中存在一段區間,是信心度將對較高的階段(例如大於80%),也就是說,最可能的上線時間就若在這個區間內(註2)。

假設Sponsor能夠理解時程提前所需付出的代價,相信應該會做出較為合理的決策,即便最終的結果不變,PM也不要氣餒,畢竟專案瞬息萬變,或許時機成熟的那一刻就會有不同的變化。

 

註1 : 費式數列

最初由義大利數學家Leonardo Fibonacci所提出的概念,描述兔子生長的情況 :

第一個月初有一對剛誕生的兔子,

第二個月之後(第三個月初)牠們可以生育,

每月每對可生育的兔子會誕生下一對新兔子...

結果來說,數列從0和1開始,之後的數字皆由前兩個數字相加而得,因此為0,1,3,5,8,13,21...

 

註2 : 專案完成機率圖的範例

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。