在專案規畫階段,即使大部分專案管理的文書作業都忽略不看,WBS或甘特圖通常還是很重要的一項,因為有了初階的工作計畫,PM才有辦法進行後續的追蹤。既然WBS是規劃的產出,那麼勢必要有參考或估算的基準,也因為估算難免與實際狀況會有些許落差,因此才需要不斷進行監控與改善。我們常說WBS是將專案工作拆解到足以掌控的大小(例如以80小時工作量為一個工作包之單位),但如何拆解成工作包又是一門學問。

雖然專案管理知識告訴我們,進行工作包拆解的過程暫不需考量時間、成本(有其先後順序與相關性),但實務上這些東西都是環環相扣,往往PM能估算的時間有限(今天被接收到專案,過幾天就必須提報規畫初稿),因此PM只能快速、綜合性評估,所以我們在拆解WBS時,也常引用了成本管理中裡常用的類比估算法,也就是拿過去相似的經驗來套用,或是再加上部分的變異參數(例如兩個專案的人員程度不同),快速初估工作項目、時程後,再同樣類比推估出所需的成本。

CMMI(能力成熟度模型)中提供了軟體開發專案的另一種估算方式,叫做功能點數,簡單來說,功能點數是將預定開發的軟體系統,依據系統開發範疇(邊界),將功能區分為外部輸入(External Input File,簡稱EI,例如新增、刪除)、外部輸出(External Output File,簡稱EO,例如訊息輸出)、外部查詢(External Inquire File,簡稱EQ)、外部介面檔案(External Logical File,簡稱EIF,例如與其系統外的資料庫進行介接),以及內部邏輯檔案(Internal Logical File,簡稱ILF,也就是在系統內部自行判斷的邏輯程序),如下圖。透過點數估算出來的專案規模,再引入組織內部的人力產值,即可估出相對應的時間、人力成本。

這種做法有別於實務上的常用方法,實務上雖然也是從功能->工作量->工時->成本的邏輯逐一推算,但大部分取決於技術人員(或主管)主觀對功能難易度的認定,若沒有過去經驗參考,估算的準確度就會有比較大的差異。而功能點數是以使用者角度去檢視專案功能,純粹由上述五個層面去計算專案的規模,這種算法的好處是摒除了主觀意見,但缺點是,主觀意見是由於專案本身由"人"在執行,技術人員(或主管)在估算工作量時,勢必會考量自身的loading、公司的需求、專案的急迫性等各個環節,這些考量雖然沒有量化的數據,但我們不得不認同這些因素真的都存在,一旦我們太客觀去拆解專案工作,很可能又會衍生出其他潛在的風險。

最後,如果您想要朝專案管理之路前進,如果您想要好好的學習專案經理應有的能力,建議您可以參加所提供的[實務專案管理專案營],強化專案經理應具備的軟技巧與硬實力。

作者:Victor

Blog:http://victorhsu0202.pixnet.net/blog

comments

登入

會員消息

最新消息 (站長有話跟你說)

線上直播專區

■追蹤PM編『互動圖文』讓你無痛學習

■註冊為新會員可以獲得專案點數10點

■不要用手機下載範本!

■記得每天登入有一點,

■怎麼註冊?怎麼輸入點數序號?

■忘記密碼嗎?快點來信

■找文章請善用『搜尋』功能

■點我闖關搶點數~

■點我去範本軍火庫