「準備就是全部。」- Hamlet V:ii:215
專案和生命一樣,面對著不確定性。我們識別風險,並不是為了風險本身,而是為了預期和緩和風險,或在緩和策略失效時回應風險。
風險驅動著反覆計劃;反覆是環繞著處理特定風險、嘗試限制風險或降低風險而規劃的。風險清單要定期檢視,以預估風險緩和策略的有效性,風險緩和策略則又驅動了專案計劃和後續反覆計劃的修正。
風險管理的關鍵在於不等到風險突然出現(並形成問題或造成失敗),才決定要如何處理它。正如同橫貫大陸的航班路徑,僅僅幾度的變更都會造成著陸點的大幅改變,相較於事實發生之後的清理,及早管理風險幾乎絕對是成本最低、痛苦也最少。
主要的策略有三個 [BOE91]:
-
迴避風險。重組專案,使它不會受這個風險影響。
-
轉移風險。重組專案,由其他人或事(客戶、供應商、銀行、另一個元素等)來承擔風險。這是一種特定的迴避風險策略。
-
接受風險。決定將風險視為偶發事件,而與風險同在。監視風險徵兆,在應變計劃中,決定在風險出現時,要如何面對風險。
如果您決定接受風險,您仍會想緩和風險,也就是說,採取一些即時動作來降低它的影響。
區分直接和間接風險,非常重要。簡言之,直接風險是我們多少能夠控制的風險,間接風險是我們無法控制的風險。
我們不應無視於間接風險,但它們很少有實際意義上的結果:由於我們無法變更它們,因此,擔心並沒有太大用處。雖然明天有可能是世界末日,但也可能不是,如果不是,我們最好是過眼前這個世界的生活!
間接風險有時候是偽裝過的直接風險。例如,我們的某個或某組元件也許要依賴某個外部供應商。這似乎是一項間接風險,但這些元件有應變計劃,我們可以控制這個風險;我們可以選擇其他供應商,也可以選擇自行開發這些功能。在許多情況下,我們會有超出我們自認為具備的控制能力!
對於間接風險,您也許必須找出如何在某個程度控制這些風險的方式,或只是記下它們,之後,便繼續往前走。為了無法變更的東西而痛苦,並沒有意義。
組織
-
對這個專案有足夠的承諾(包括管理、測試人員、QA 和其他外部的相關各方)嗎?
-
這是這個組織嘗試過的最大專案嗎?
-
有定義好的軟體工程流程嗎? 需求的擷取和管理呢?
資金
-
完成專案所需要的資金備妥了嗎?
-
配置了訓練和輔助費用嗎?
-
有預算限制嗎?系統必須在固定成本之下交付,或有可能取消?
-
成本預估準確嗎?
人員
-
有足夠的可用人員嗎?
-
他們有足夠的技術和經驗嗎?
-
他們一起工作過嗎?
-
他們相信專案能夠成功嗎?
-
使用者代表能夠參與檢視嗎?
-
有領域專家嗎?
時間
-
排程符合現實狀況嗎?
-
功能能夠進行範圍管理來符合排程嗎?
-
交付日期有多緊急?
-
有時間「正確做好它」嗎?
-
如果競爭者先上巿,怎麼辦?
-
如果專案資金有危險,怎麼辦(從另一個角度來看,這就是「充足資金如何保障」的問題)?
-
系統的預計價值大於預計成本嗎?(請務必計入資金的時間價值及資金成本)。
-
如果與主要供應商無法簽訂合約,怎麼辦?
-
成功能夠測量嗎?
-
對於如何測量成功有共識嗎?
-
需求相當穩定,且已獲得妥善瞭解嗎?
-
專案範圍穩固嗎?還是會持續擴充?
-
專案開發時間表是否短而不容變更?
-
技術已獲證明嗎?
-
重複使用目標合理嗎?
-
工作成果必須先用過一次,之後,才能重複使用。
-
元件可能需要釋出幾次之後,才會具備重複使用所需要的穩定性,而不再需要大幅度的變更。
-
需求中的交易量合理嗎?
-
交易率的預估可信嗎?它們會不會太樂觀?
-
資料量合理嗎?它們可以保留在目前可用的大型電腦中嗎?如果您因為需求而相信設計將包含工作站或分部系統,資料能夠合理放在那些位置嗎?
-
有不尋常或具挑戰性的技術需求,因而專案小組必須處理他們並不熟悉的技術嗎?
-
成功有賴於新的或未嘗試過的產品、服務或技術、新的或未經證明的硬體、軟體或技術嗎?
-
有對於其他系統(企業外的系統也包括在內)介面的外部相依性嗎?需要的介面存在嗎?或必須建立它們嗎?
-
有非常固定的可用性和安全性需求(如「系統永遠不能失敗」)嗎?
-
系統使用者是否熟悉所開發的系統類型?
-
風險會因為應用程式的大小或複雜度或新技術而增加嗎?
-
是否需要國家語言支援?
-
這個系統可能設計、實作和執行嗎?有些系統就是因為太大或複雜而無法適當運作。
-
專案依賴其他(並列)開發專案嗎?
-
成功是否有賴於現成產品或外部開發的元件?
-
成功是否有賴於順利整合開發工具(設計工具、編譯器等)和實作技術(作業系統、資料庫、跨流程通訊機制等)。產品的交付有沒有不含這些技術的備份計劃?
經驗顯示 85% 的風險會直接或間接影響排程,因而也會隱含地影響成本。可能有 5% 只會影響成本。其餘部分不會直接影響成本或排程,但會直接影響例如品質。
如果截止時間就是截止時間,請利用漸進式交付的方式來平穩處理它。請避免嘗試單次的大量交付以符合排程。
有些專案會有真正的「致命」截止時間。例如,在選舉之夜「實況」分析選舉結果的軟體,如果在選後一星期才出現,就沒什麼價值了。另外,您的軟體也可能會因競爭者而作廢:當您的產品仍在建構中,他們可能啟動了一個更好的產品。於是,您忽然身在事外,無力回天。不過,一般而言,很少專案會有這麼緊急的截止時間。延遲主要是影響成本。
一般而言,請使您的排程承諾等於您的最佳預估,再加上一些合理的偶然情況。
承諾 = 預估 + 偶然情況
有人建議將預期的排程設成等於您的撤退策略,也就是說,以應變計劃為基礎,但這有點太悲觀,因為實際上並非所有風險都會實現。
排程風險整合在某些預估和成本計算工具中。例如,在 COCOMO 模型中,會有許多成本因素,例如:
-
複雜度 (cplx)
-
即時限制 (time)
-
儲存體限制 (stor)
-
經驗 (Vexp)
-
好工具的可用性 (tool)
-
排程壓力 (sced)
實際上都是風險因素。
其他複雜的風險管理技術包括使用 Monte Carlo 模擬,模擬工具會執行大量「情境」來計算整體風險和意外 [KAR96]。
|