close
專案規劃要預估專案範團,時程及成本
專案範圍確定後,就依各種方法來度量專案規模,再來規劃開發時程及限制成本
專案範圍確定後,就依各種方法來度量專案規模,再來規劃開發時程及限制成本
在軟體專案管理裡,有講到很多種專案規模的度量方式,如:
-程式行數
-Function Points功能點(業界最常談到)
-Number of Classes and Objects
-Number of Requirements
等等....
-程式行數
-Function Points功能點(業界最常談到)
-Number of Classes and Objects
-Number of Requirements
等等....
但是,這麼多有理論基礎的專案規模度量方法
軟體界到現在最常用的還是"土法煉鋼"式的度量方法
軟體界到現在最常用的還是"土法煉鋼"式的度量方法
-依個人經驗值來估算專案規模
為什麼Function Points或其它具理論基礎的專案規模度量方法無法套用在實務
這就回到度量專案規模的前一個步驟:專案範圍沒有確定清楚
這就回到度量專案規模的前一個步驟:專案範圍沒有確定清楚
因為客戶需求未能確定清楚,不明確
所以當然任何估算方法也就算不精準
所以當然任何估算方法也就算不精準
--------------------------------
專案範圍(或客戶需求)未能確定清楚又分二種情況:
1.客戶清楚自己想要什麼(需求其實明確)
2.客戶自己想要什麼也不清楚(需求的確不明確)
第一種:客戶清楚自己想要什麼,但開發公司卻未抓到客戶需求
這就是專案經理的問題,因為沒有做好需求分析,所以無法確定客戶需求
這在我上一個"接手需求不定的專案"已經遇過且已解決
講一個老師談到需求明確而成功的案例:
國內某一個政府專案,整價約六億,一開始甲方規劃一個三仟萬的規格標
由得標廠商把該專案需求,功能項目,邏輯規則條件都規劃出來,甚至連操作畫面都拉出來,這樣需求明確後,再發包開發標
國內某一個政府專案,整價約六億,一開始甲方規劃一個三仟萬的規格標
由得標廠商把該專案需求,功能項目,邏輯規則條件都規劃出來,甚至連操作畫面都拉出來,這樣需求明確後,再發包開發標
這樣開發標的得標廠商就有明確的依據,之後確定執行就能依據需求分析與規劃順利的把專案完成.
第二種:客戶自己想要什麼也不清楚,這種專案最令人頭疼
假設客戶的預算是一百萬,專案目標就是增修現有的應用系統功能符合到實際作業流程
但哪些功能不合適需要修改,或哪些功能有缺少,現在還沒使用到那裡所以不知道
要等到有用到該項功能時發現少了什麼功能沒有就去加,遇到哪個功能不好用再去改
遇到這種專案,在一開始做專案規劃,WBS的時候,再怎麼想,也預測不到客戶的想法
(這倒有點像供應鍵管理的CPFR-協同規劃、預測與補貨,理論很充足,但實務上很困難)
依Standish Group 1995調查8000個軟體專案
- 84%在時程落後,預算超支,功能不全的狀況下完成
- 30%的專案在半途被撤銷
- 70%的專案逾時完成,超出預算189%
- 撤銷的專案成本高達81b美元
上述軟體專案不成功的根本原因,就在需求不明確,掌握度不夠
國內大部份的軟體專案也是這樣,客戶想要一開發一套專屬系統,但需求並未分析的很完確就發包
或是客戶自己也不想把需求講明確,因為需求一白紙黑字寫下來,將來系統開發完成後就少了彈性可以大修改
(雖然有15%的增刪空間,但常常會因為沒有好好分析,而要大改功能,客戶承擔不起這樣的責任)
軟體公司接案就只能靠運氣,看是否遇到澳洲來的客人
或是PM要在專案進行當中不斷掌握目前開發情況,不斷與客戶溝通釐需求,把客戶期望拉回與現實相符,讓專案完成結案
同時,在規劃與執行時儘量(標準化),(文件化),把每個環節弄清楚
同時,在規劃與執行時儘量(標準化),(文件化),把每個環節弄清楚
這是專案管理最困難的地方
全站熱搜
留言列表
