好幾個月沒有出新 post了,幾乎已把這裏荒廢,但這幾個月也一直沒有閒著,先是六月初和朋友吃飯時提到Web Scrape,之後花了六月和七月的時間學習和應用Python,讀取網上的財務數據進行股票分析,後來又完成了一個網上課程,當中也有教授不少關於項目管理和需求分析的要點,稍後會另文分享。
前輩提出的問題是與項目估算有關,究竟兩個不同的項目,可以如何對比其複雜程度,進而評估投放資源和項目時間的合理性。
筆者當時的回答是包括三點考慮,首先是項目開發量,其次是參與項目的團隊數量,第三是受潛在影響而需要Regression Test 的範圍。項目開發量方面,之前的另一篇文章內曾經分享過使用Function Point Analysis (FPA)的方法,用以將項目整體範圍拆細,進而分項評估。前輩就指出這個方法的盲點,在於不同項目經理或團隊,也可以有不同的估算,早年也有人做過實戰測試,找來不同項目經理就同一項目作出評估,大家就可以有截然不同的估算結果。又有人就此就提出同一項目取多個估算作平均,但實戰環境下大家也明白這根本很難做到,結果仍然是各有各估算,難於達致統一標準。
事實上,這個問題之所以難於回答,歸根究底是我們在實際環境下是極難出現兩個一樣的項目,即使例如兩間公司就同一業務目標發展,但基於不同的系統,不同的組織架構或項目團隊,以致不同的流程,還是不同的風險偏好,結果是可以很不一樣。而在同一個機構入面,就更不會同時出現兩個一樣的項目了。但這點既是原因,也是結果,正正是這樣的情況,我們更希望能夠更有效的評估和比較,以判斷投放的資源是否合理。
在最近讀的課程中,就提出了另外兩個方法,一個是PMP中也有提過的PERT estimation,另一個是Fermi Estimate。
PERT對大部份項目經理應該不會陌生,簡單來說就是就每個項目中的task 估算最好,一般和最壞情況,然後取weighted average。PERT 跟FPA 主要不同之處,是FPA將產品 (Product) 拆細成functional 組件,容易忽略項目中其它工作的時間,例如regression test。而PERT 則是從項目 (Project) 角度拆細成tasks,是較好的項目估算工具。通常第一次做項目用PERT會是比較痛苦的過程,要把所有tasks 列出清單進行估算,但當之後再用的時候,很多時會發現task 的估算是可以重用,甚至可用上次項目的實際情況作一些調整。另外,PERT estimation 亦強調項目整體團隊的參與,即團隊合作對task effort 和duration 進行估算,過程可以增加團隊對估算的commitment,亦可以預算評估可發生的風險及相應作出計劃。
另一個Fermi Estimate,相對來說不及PERT 的精準,但卻是做快速ballpark估算的一個好方法,尤其是當面對極為龐大的項目,難以把整個項目拆細至最底層進行估算,就很適合使用。Fermi Estimate 不要求把項目拆細是最底層,而是透過已知的數據對未知的整體進行大致估算。舉例說,如果我們要估算一輛私家車的闊度,我們可以大致計算是 3 個成年人(約每人20吋),加上兩扇門的闊度(每扇6吋),加起來就是大約72吋。而對於項目來說,我們就可以從整體項目中找尋曾經做過類似項目的組成部份構成已知的數據,對於未有數據的部份則再進一步拆細,或找尋最相近的作為比較。
以上無論是FPA,PERT還是Fermi,方法各有不同,但共通之處是都需要把項目分拆細份以方便進行估算。事實上,分拆估算除了在項目計劃時有用,就算在項目執行過程亦有相當幫助,例如可以分項評估各項task 的variance,以便在下次項目上作出調整。
沒有留言:
發佈留言