風險管理是軟體專案管理的第一管理

軟體工程諺語（大意）：

如果你不防範（躲著）風險，那麼風險就會來敲門。

隨意開啟一本專案管理教材，可以發現專案管理涉及的內容很多，其中包含各種要素的管理，而專案管理的知識體系更是相當龐大，需要考證的 PM 們花很多精力來學習，一個知識點、一個知識點地來掌握。

這在實踐工作中很容易讓人產生主次不分的錯覺，甚至會感到無所適從。難道專案管理知識體系中所有這些“管理”要點、知識點都是同等重要的嗎？有沒有一根或幾根主線和關鍵點呢？

我們太極敏捷派認為：

風險管理是軟體專案管理的第一（首要）管理。（不知大夥兒是否贊同？）

得出這個結論的邏輯很簡單。

專案經理的職責是確保專案在給定的時間和資源等約束條件下，成功完成專案，實現既定目標。所以，任何可能妨礙軟體開發專案成功的因素，都可以稱之為風險。這裡我所說的風險及其管理，可能與經典專案管理教材略有不同。

我們可以反問。如果一個專案，不存在風險，無論開發團隊成員們怎麼做，100% 都能夠成功，那麼還需要專案經理幹嘛？可見，作為軟體專案失敗的第一責任人，軟體專案經理的首要職責必然是排除障礙，防範風險，確保專案的成功。

在實際的軟體工程專案管理中，潛在的風險因素其實是非常多的，有需求風險（不知道或不明確地知道做什麼），技術風險（不知道怎麼做，用什麼技術，怎麼用），進度（時間）風險，質量風險，資源風險，人員風險（士氣、內耗） ... 等等。

為什麼軟體開發專案會失敗？回答：因為“運氣不好”，發生了風險，risk 成真，成為了事實。

把風險管理提升到軟體專案管理之首的位置，有很多好處。

回頭看過去 40 年，可以這麼說，軟體工程迄今為止的絕大部分做法都是為了防範專案風險、保障專案成功而總結出來的經驗教訓，抓住了風險預防和管理這根主線，我們就能更好地理解傳統軟體工程和當代軟體工程。

風險驅動是統一軟體過程框架 RUP 的一個顯著特徵，敏捷過程通過短迭代、促進團隊內外的溝通等等具體做法也是為了更好地防範風險。

因此過去幾年中，我也一直建議、提醒客戶和朋友們要儘可能採取迭代、遞增的開發方式，始終維護一張專案的風險清單（Risk List），通過迭代的計劃和評審等活動，不斷地評估和更新專案風險，加強風險的預防措施。

做好風險的預防和管理，是成熟軟體專案經理的一個首要職責。

backlove 的這篇文章《應該重視專案管理中的風險管理》正好與我不謀而合：“我們真的應該把風險管理當做專案管理裡最重要的部分來認真處理”。

敏捷 OO 教練 張恂
www.zhangxun.com
版權所有 2008

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-269234/，如需轉載，請註明出處，否則將追究法律責任。