相信大家都有被壓專案完成時間的經驗,然後為了那個幾近不可能的目標忙得焦頭爛額,甚至變更範疇、增加成本、加班,少數時候還要低聲下氣疏通跨單位協作。雖然專案管理的精神貴在如期如質,並且有許多技巧與執行概念可協助PM進行,例如

專案經理的基本苦工 - 繪製一份實用的甘特圖
浮時及時程估算
看板管理

,但專案要如期完成為什麼總是困難重重? 到底專案deadline的設定出了什麼問題?

專案的規模大小不一,有的為期數週,有的甚至可以是數年,多半的專案至少都是幾個月以上的時間,要在數個月前決定完工時間,如果還能精準命中,豈不是算命仙? 最常使用的估算方式是拆解任務,將每個子任務預估時間加總後,再疊上風險值,但既然都是估算,本來就會有一定的偏差,如同各種統計調查一樣,基於樣本數多寡、填答狀態、問題的取向,最終會在統計結果上註記信心指數或誤差範圍,通常大約在5%水準上下,也就是說,一份80分的評核報告,若實際數字發生在75~85分之內,都算是命中。

舉另外一個生活中的案例,下圖是氣象局在2017年9月9日發佈的泰利颱風預報圖,由於預報準確度會隨著時間拉長而遞減,因此隨著預測天數增加,颱風路徑的扇形面積也會越變越大。所謂的扇形面積,簡單來說,一條預測的路徑,會有南北最極端的兩條偏差線,類似上述的5%統計誤差值,每增加一天,兩條路徑就會偏離越多,而在這南北兩條路徑內所包含面積範疇,都是颱風可能的路徑。當我們回頭檢視泰利颱風的實際路徑,會發現最後泰利颱風轉彎前的走向,其實約莫是落在扇形的最北端,也就是說,它並不算是離譜的預測失誤,甚至隨著時間推進,每一次的預報結果都更貼近最後的實際路徑。

FB_IMG_1505518630194.jpg

6690407.jpg

 

上述兩個案例,都是統計及科學上,為了無法預估的風險所做的輔助說明,專案(尤其是軟體專案)何嘗不需如此!? 

依Tom DeMarco & Timothy Lister與熊共舞(Waltzing with Bears - Managing Risk on Software Projects)一書中所述,我們可以將專案時程的不確定性,改以相對機率的概念來表示,其中N就是開始有機會交付成果的日子,過去我們通常會被要求以此日為Deadline,但其實它的完成率並不高,因此整個專案團隊都為了這個不太可能的承諾人仰馬翻。當我們改以相對機率來表示專案的完成時間,在曲線內的範圍都應該是可被認可的交付日期,其中又以虛線所繪製的時間點機率最高,sponsor可以依此機率分布來衡量專案最後的成效,給予不同的分數評價,而不是以單一時間來評斷專案的成敗。

擷取.PNG
然而,即便我們將專案預計完成日視為一個區間而非絕對值,專案利害關係人是否就會買單? 我想大部分答案都是否定的。我們看看泰利颱風的例子,據新聞報導,中部果農早在颱風接近的前幾天就進行搶收,事後痛批氣象局預測失準,原因是什麼? 我們不深究個案,但大致上不出幾個因素 :


1.專案利害關係人的主觀需求 : 
每個利害關係人在專案的參與程度不同,期望的結果當然也有所差異。果園收成的情況可能會影響果農未來半年的生計,加上台灣近年土石流失嚴重,強降雨也容易氾濫成災,因此會對於預報的準確度有更高的要求 -- 即便這些要求可能超乎科學的範疇。職場上,專案亦是如此,每個關係人(甚至sponsor)對專案絕對有情感上的期望,這些期望會讓他們忽略PM所提供的時程報告,進而開始對專案施壓,要求定義明確的deadline。

2.潛在風險說不清楚 :
雖然利害關係人有著情感上的渴望,但其中一部分原因,是他們未能充分理解時程估算的風險所在(或者PM未能有效溝通)。多數專案對於時程估算的不確定性都沒有提出足夠的證據佐證,總是「以增加人數不能提升效率」
、「技術難度高或經驗不足只能粗略推算」等理由搪塞,這無疑是舖了一條讓sponsor可以肆無忌憚壓榨的道路,因為那表示PM自己對時程也只是粗估,既然如此,sponsor當然會主觀認定專案也有提前的可能性。所以,即便是以時程區間取代完工日,PM也有必要提出合理的假設,例如目前的分工模式,增加人數需多少學習時間? 能分攤哪些工作? 初期的產能多少? 耗費在指導新人的成本又是多少? 越是不確定的項目,越要提出可以用來參考佐證的數據,來說明它的風險是什麼,這樣才能畫出具說服力的時程評估曲線。

arrow
arrow
    文章標籤
    時間管理
    全站熱搜

    victor 發表在 痞客邦 留言(0) 人氣()