時程估算一向是讓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 : 專案完成機率圖的範例