如何管理好軟體專案的經驗分享
近年我在客戶、企業與電腦公會討論系統開發進度，發現一般人都是將PMP的專案管理方式套到軟體專案，常常就會就產生當整專案進度到百分之80-90%時，工程師才告知主管這軟體專案會延宕，難道是這PMP專案理不好嗎？其實魔鬼藏在細節中(The devil is in the details)不是這管理方法不好，是專案經理要瞭解軟體的特性【1】後，將其特性作調整後就可以改善整個專案管理。
那如何將軟體的特性加到專案管理中，首先需要瞭解軟體特性，你就會發現到傳統專案管理與軟體專案的不同，傳統的專案對於估算與需求是有明確定義且清楚，但是開發軟體系統的需求就沒有這樣簡單，同一個需求每個人所想都有可能不同，舉例我們在蓋房子時會有明確設計圖與規格，需求是地基就地基不會有人將地基想成地下室，因為大家對地基有共識，但軟體的需求確認就很難，當客戶講說要這表單設計不夠精簡時，那精簡要多精簡就很重要，因為軟體開發需要很精準規格，這是形容詞所以系統分析師需要變成更精準用詞，我舉例就要將表單作分析後10個欄位就是精簡在給客戶確認。加上程式開發撰寫過程中是不易看到結果(看不見整體開發生命週期)，因此只要方向錯就到最後的系統測試或實體展示才會發現，這時這軟體專案已經開始出問題。
當然會有人說，這是軟體開發規格不明確的原因，但是要將軟體規格制定很明確是一個很大學問，軟體工程學科發展也不到80年，加上客戶或專案經理(PM)有資訊背景人也不多，就算我在軟體公司上班所碰到本科工程師也未必上過軟體工程【2】，所以不管客戶、專案經理、系統分析師要將軟體開發的功能寫很清楚是很難，通常都是一段文字敘述就代過或拿舊系統畫面跟你說功能要開發成這功能加上他要新功能，請不用期待他們會畫資料流程圖(Data Flow Diagram,DFD)、使使用情況(user case)圖、順序圖(sequence diagram)...等，我在以前公司的工程師它們連聽都沒聽過就當系統分析師。
所以要管理好軟體專案，首先要做好就是管理好客戶需求，這在很多國外的軟體開發標準標準中都有方法如CMMI、IPTL、ISO、Aglile 【3】都有一些定義，當你的軟體開發需求確認不會變動時，恭喜你專案成功率有一半，但是我經驗告知我【4】整個軟體開發的過程中軟體需求不會變動是不可能，客戶需求常看到畫面或時間久就會開始需求的變動，我們只是盡力讓客戶改變幅度較小或可以延後到驗收結束後處理，這就考驗到專案經理的經驗與能力。
軟體開發的過程中當你在需求分析修改需求所花成本假設是10元，當你到測試時需求變動所花成本是50元，當整體完成後交付給客戶會是80元、整系統上線後要析修改成本就要花費120元，你可能會訝異說交付與上線不是一樣嗎？為何會比較多錢？因為當系統資料上線後遇到需求變動時要加上資料轉檔與整合風險，由上而知軟體的需求管理是重要與影響整體專案成本，依照國外經驗大部分的軟體專案延宕初期都是來自於需求不確定因素與工期不合理性【5】，若將這部分排除或管理那用傳統的專案管理的方式就很容易，當然軟體專案管理的複雜度很高，但源頭還是先管理客戶的需求，後續的專案管理上就會容易是很多。
【1】：有關於軟體特性詳細說明，可以參考我另外一篇文章有說明。
【2】：軟體工程課程，目前只有大學資訊工程系可能會是必修，資訊管理系，資訊科學系應該都是選修不一定會開課，以前在軟體公司時要當上系統分析師與專案經理至少要6-8年的程式撰寫經歷，現在的有些公司剛畢業就可以當專案經理，你會寫程式就可以當系統分析師有些人還不是本科畢業。
【3】：CMMI (Capability Maturity Model® Integration，能力成熟度模式整合) 起源於美國國防部與卡內基美隆大學（Carnegie-Mellon University）合作所設立的軟體工程學院（Software Engineering Institute，SEI）。
Agile 敏捷式開發，這是軟體工程中軟體開發模式之ㄧ(台灣常看到有Scrum、DevOps)
ITIL 資訊技術基礎架構庫（Information Technical Infrastructure Library，ITIL）
【4】：個人在軟體公司20多年軟體專案經驗與作過230大大小小個軟體專案，目前擔任米格魯資公司的資訊專案管理顧問也兼任台中科技大學資訊工程系講師。
【5】：國際著名Standish Group研究機構之調查，有84%的軟體計劃無法於既定的時 間及經費當中完成 。
- 1995年，以美國境內8000個軟體專案為調查樣本。
- 超過 30%的計畫執行到中途被取。
- 專案的預算平均超出189 %。
專體專案延宕問題癥結
- 因為需求不明確，無法正確估算與評估，導致軟體公司總是在不合理的期限(Unrealistic Deadline)壓力下進行開發。
- 客戶在專案結束前要求增加新功能，或是給予不明確的需求(Vague Requirements)。
- 軟體本身非常複雜(Complex Structure)，加上有領域的知識因此整體就更加複雜 。
- 由於軟體特性在整專案開發過程中透明度低無法量化數據加上具有許多不確定因素(Numerous Uncertainties)。
