專案管理不適用軟體專案？

鳥毅在他的網誌中提到他對軟體專案管理的看法：

據在下所知，台灣最早採用專案管理的是營建工程界，由於土木建築設計好後變動性較小，因此使用 WBS 比起軟體容易；軟體有許多不確定性，使用Agile開發後更模糊了設計與開發的界限，因此在下並不覺得 PMBOK 套用到軟體專案也適用。

專案管理不適用於軟體專案？要回答這個問題要先知道什麼是專案管理。依據 PMBOK 對專案管理的定義為「在專案活動中，為了達成專案目標所作的相關知識、技巧、工具及技術的應用。專案管理會完整經歷如專案初始、規劃、執行、控制與監控及結案等五大管理流程的應用及整合」。

專案的管理工作內容有：

1. 識別出需求。
2. 建立清楚與可達成的目標。
3. 平衡品質、規模、時間及成本等專案限制，這些限制是會相互影響的。
4. 為每一個不同考量及期待的利害關係人，調適規格、計劃及方法。

理論上，專案管理與您所開發的產品與服務的內容所採用的方法論沒有關係，所以，對於任何的領域而言，只要專案有明確可行的目標、專案開發的過程中需要規劃、執行與監控及結案等活動，並不會有不適用的問題，即使不同的應用領域會有不同的工程活動（軟體開發流程、軟體工程管理）及一般管理活動，但專案管理流程與這些管理及開發活動是可以相互整合的，所以照理說軟體專案不會有專案管理的不適用問題。

實務上，軟體開發的不確定性確實會使軟體專案的WBS的定義比其它類型的專案來的困難。在這方面，Fowler（2003）認為，採用預測式規劃的解決方案可以將專案分為兩個階段，雖然第一個階段很難對專案做準確的預估，但等到了第二個階段就可以依據前一階段的經驗，做較為準確的預估及規劃；然而，許多人的經驗還是會發現軟體專案規劃真的很難預測，於是會朝著兩種不同思維來改進軟體專案的規劃，第一種思維是朝著改善需求發展過程著手，另一種思維則是採用調整式規劃（adaptive planning）方式以面對改變的思維來進行軟體專案的規劃（趙光正譯，2004）。

Agile開發方法論正是應用固定完成時間的反覆（timeboxed iterative）及演進式開發、調整式規劃、推動交付演進版本以及包括其它鼓勵敏捷的價值與實務－快速而有彈性地回應變化。擁抱改變是Agile開發座右銘，而Agile開發的策略是可操作的（Larman，2003）。

從以上說明並看不出來專案管理與軟體開發在本質上有何矛盾，所以我認為與其說專案管理不適用軟體專案，不如說是軟體專案管理必須加強在專案回應變化的能力，因為不確定性高是軟體開發的特性，尤其是專案經理要注意在軟體規模、複雜度與風險的非線性關係，大專案與小專案的差別，絕對不是大一點而已（曾昭屏譯，2006）。

我們其實可以從 PMBOK 中找到專案管理流程交互整合其基本精神在為 Plan-Do-Check-Act，專案監控流程是接著專案執行之後並且與專案規劃流程在 PMBOK 2000 版是需要相互回饋的，然而在 2004 年第三次改版時，專案監控流程卻變成環繞著其它的專案流程（專案初始、專案規劃、專案執行與專案結案），也就是說專案監控是須不斷要進行的，而且必須與其它流程充分整合。由此可知，專案管理實務絕對不是如照章行事、按圖施工那麼簡單，而是一種如何面對現實問題，把穩方向然後讓我們有效地回應環境的改變，所以它其實是適用在軟體專案的。

專案管理最重要的是掌握好 triple constraint，亦即相互牽制的規模、時程及成本的三重限制，而這三重限制也決定了專案的品質，所以 triple constraint 亦有人稱為四變數（four-variable）。因此如果專案沒辦法做好變更管理，這四變數就會一起來找你麻煩，雖然說全部網羅－難難難（葛迺駿譯，2003）！但這是專案管理的專業（廣度），和軟體開發的專業不一樣（深度），然而軟體專案管理的整合是需要技術的專精，因此工程面（包括新方法論）與管理面是缺一不可，因此專案管理不適用軟體專案，多半是人為溝通的問題，而不是方法論或管理流程的問題，即使在〈Conceptual Integrity〉的討論中，有些網友認為把工程帶入軟體開發是把軟體業當成製造業是痛苦的根源，但這和組織所採用的軟體品質文化模式（曾昭屏譯，2006）有關：如果軟體專案所要解決的問題採用變化無常的開發模式，已經無法勝任時，我們是否要改變開發模式，即使照章行事的開發模式中常衍生出很多的管理問題，然而它卻可以讓我們更明白如何把穩軟體開發的方向。軟體專案的成功，其實是管理與技術層次的有效整合啊！

Please follow and like us: