時程估算一向是讓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 : 專案完成機率圖的範例
<文章同時發表於專案管理生活思維，請勿任意轉載>
留言列表
