PMP達人-專案管理經驗成長與學習 IT肥蝦個人的專案管理經驗與心得記事與分享。

67愛的鼓勵 2訂閱站台

肥蝦今日幫一位好友填寫開放式問卷，肥蝦這位朋友的研究主題是承攬後，或說得標後的專案進度衡量與估算。其實該友已是一位浸潤於軟體專案管理與系統分析多年的專家了，就只為了湊一下訪談人數，只好把肥蝦這濫竽拿來充數；肥蝦為了義氣，也只好厚顏的忝充一下【專家】(好像唸高中同學間為了考卷上的簽名只好彼此充當對方家長一樣)。因為問題還蠻有意思的，因此肥蝦就更無恥的把肥蝦的回應潑到部落格來一同與大家討論與分享！

為了尊重好友的智慧產權,肥蝦就搞了一個山寨版的問卷。

 

開放問卷的回答

==============

問題一：肥蝦對不同類型的案子是否有不同的進度衡量標準？

回答：沒有針對不同類型的專案訂出不同的標準。原則上採行統一定義的標準，但會根據不同類型給予不同的權數或比重，尤其是對於完工的定義採行不同的百分比法。

 

問題二：您用的有哪些方式?優缺點？

回答：如果對於程序型的軟體開發專案就以WBS下各Package的完工進度加總後作為衡量；如果是產品客製化的專案，就以完成的交易數作為衡量的基準。

以Package的完工進度加總計算優點是各負責人責任明確，回報容易；缺點就是擔心各負責人隱藏訊息。

以完成的交易數作為衡量，優點是客戶容易明瞭，而且有明確的感受；缺點就是客戶看不到的部分，如：架構、品質…等工作難以反應，易造成給客戶沒有進度的感受。

但以上兩者都有一個重大的問題，就是實際進度的衡量基準與專案預估時的方法與基準不同，對後續新專案時程與成本預估的Lesson Learned幫助有限。

 

問題三：能反應實況嗎?

回答：應該可以反應實際狀況的百分之七十到百分之八十或九十，實際狀況要視配合同仁彼此間的合作氛圍與默契。比如就以交易數為例，有些同仁認真負責，瞭解交易的目的與重點，進度的顯示會同時真實反應品質等問題，而有些同仁的作法就有可能增加後續的修改時間。

 

問題四：影響進度度量的因素有那些？

回答：就軟體開發案來說，個人以為最主要的還是人的問題。

從一開始的Initial階段，參與人員的經驗是否足夠？參與人的是否明確研議招標書，審慎評估專案的風險，研議合約？對於合作的廠商與專案人員是否有正確的評估？

planning階段參與分析的規畫人員是否深入瞭解User的需求？，瞭解產品的架構？是否真實的反應哪些RFP項目是可能有困難的？進一步負責的擬定分析書與設計書？User參與人員是否全心投入？是否對於提出的需求有明確的認識？並且可以與廠商一同以完成專案目標為前提下，探討這需求是否在合約或RFP的範圍內？

Executing階段，公司主管是否認真看待本案？對於人力與資源的分配給予穩定的承諾？還是常常臨時變更指定人員？負責實作與執行的人員是否能確實研究分析人員開列的文件與要求？真實的陳報開發進度與反應問題？

Monitor時，最擔心就是怕因應公司或內部主管的想法就要求變更專案進度與文件，甚至管控方法與記錄？或者主管對專案不明瞭，對於專案的範圍、成本、進度與品質等要件有自己的看法？專案成員是否私下進行承諾？

在Closing階段，比較麻煩的就是先前各階段的人員是否真得write down下符合要求的相關文件？業主與廠商參與驗收的人員是否與先前配合的人員是否一致？如果人不一樣，那要求與重點是否差異太多？

 

問題五：那些階段估算容易失真？為何？

回答：一般來說，比較容易失真或出現失真是在Executing階段。其次是Planning階段或所謂的需求分析階段。但是最可怕的是失真問題出現在Closing階段。

就軟體估算來說，最常發生的就是規畫之時受到不同因素的干擾，對於專案範圍或要項有意或無意的疏漏，導致Executing之時還得不斷回頭重新進行分析，更甚者還必須變更整體的架構。其次，就是配合的廠商與人員不如原先的期待，導致增加的時程或成本遠超出原先的估算，更可怕的就是加時程或成本也無法解決，必須重新更換合作廠商或人員。

 

問題六：有更好的建議？

回答：軟體開發的平台，在目前的環境下多不是問題，【人】還是整個專案問題的核心！是否有足夠適當的人員參與？業主與廠商間的人際互動是否良善，並真實的立基於合約的規範？

目前任何的度量方式如：EVM是用換算成金額的方式來度量，功能點是將專案交付物各要項轉成另一個所謂點數方式，…是依據外顯的特性進行計算與度量。但是軟體專案不似其他土木建案或舉辦party的專案，軟體的特點在於依賴深度的人力與能力，並且一般單一軟體系統專案所交付是一個整體性的產品，各軟體組件間密切相關，難以明確快速替換。

因此，加求度量的方式不是設法強化人的約束，朝向所謂的『工程』導向，如：印度。不然就是設法改善人員的態度，如Google的人性化。期盼藉由人態度的正向改變來確實反應出度量的計算方式。

TOC理論提議了所謂『時間-金錢』計算單位，也許軟體進度度量單位可以設計一個『人性-時間-金錢』的度量單位。