準則: 風險清單
這個準則說明如何識別和管理軟體專案風險。
關係
相關元素
主要說明

簡介

「準備就是全部。」- Hamlet V:ii:215

專案和生命一樣,面對著不確定性。我們識別風險,並不是為了風險本身,而是為了預期和緩和風險,或在緩和策略失效時回應風險。

風險驅動著反覆計劃;反覆是環繞著處理特定風險、嘗試限制風險或降低風險而規劃的。風險清單要定期檢視,以預估風險緩和策略的有效性,風險緩和策略則又驅動了專案計劃和後續反覆計劃的修正。

風險管理的關鍵在於等到風險突然出現(並形成問題或造成失敗),才決定要如何處理它。正如同橫貫大陸的航班路徑,僅僅幾度的變更都會造成著陸點的大幅改變,相較於事實發生之後的清理,及早管理風險幾乎絕對是成本最低、痛苦也最少。

風險管理策略

主要的策略有三個 [BOE91]:

  • 迴避風險。重組專案,使它不會受這個風險影響。
  • 轉移風險。重組專案,由其他人或事(客戶、供應商、銀行、另一個元素等)來承擔風險。這是一種特定的迴避風險策略。
  • 接受風險。決定將風險視為偶發事件,而與風險同在。監視風險徵兆,在應變計劃中,決定在風險出現時,要如何面對風險。

如果您決定接受風險,您仍會想緩和風險,也就是說,採取一些即時動作來降低它的影響。

風險類型

區分直接和間接風險,非常重要。簡言之,直接風險是我們多少能夠控制的風險,間接風險是我們無法控制的風險。

我們不應無視於間接風險,但它們很少有實際意義上的結果:由於我們無法變更它們,因此,擔心並沒有太大用處。雖然明天有可能是世界末日,但也可能不是,如果不是,我們最好是過眼前這個世界的生活!

間接風險有時候是偽裝過的直接風險。例如,我們的某個或某組元件也許要依賴某個外部供應商。這似乎是一項間接風險,但這些元件有應變計劃,我們可以控制這個風險;我們可以選擇其他供應商,也可以選擇自行開發這些功能。在許多情況下,我們會有超出我們自認為具備的控制能力!

對於間接風險,您也許必須找出如何在某個程度控制這些風險的方式,或只是記下它們,之後,便繼續往前走。為了無法變更的東西而痛苦,並沒有意義。

資源風險

組織
  • 對這個專案有足夠的承諾(包括管理、測試人員、QA 和其他外部的相關各方)嗎?
  • 這是這個組織嘗試過的最大專案嗎?
  • 有定義好的軟體工程流程嗎? 需求的擷取和管理呢?
資金
  • 完成專案所需要的資金備妥了嗎?
  • 配置了訓練和輔助費用嗎?
  • 有預算限制嗎?系統必須在固定成本之下交付,或有可能取消?
  • 成本預估準確嗎?
人員
  • 有足夠的可用人員嗎?
  • 他們有足夠的技術和經驗嗎?
  • 他們一起工作過嗎?
  • 他們相信專案能夠成功嗎?
  • 使用者代表能夠參與檢視嗎?
  • 有領域專家嗎?
時間
  • 排程符合現實狀況嗎?
  • 功能能夠進行範圍管理來符合排程嗎?
  • 交付日期有多緊急?
  • 有時間「正確做好它」嗎?

商業風險

  • 如果競爭者先上巿,怎麼辦?
  • 如果專案資金有危險,怎麼辦(從另一個角度來看,這就是「充足資金如何保障」的問題)?
  • 系統的預計價值大於預計成本嗎?(請務必計入資金的時間價值及資金成本)。
  • 如果與主要供應商無法簽訂合約,怎麼辦?

技術風險 到頁面頂端

範圍風險
  • 成功能夠測量嗎?
  • 對於如何測量成功有共識嗎?
  • 需求相當穩定,且已獲得妥善瞭解嗎?
  • 專案範圍穩固嗎?還是會持續擴充?
  • 專案開發時間表是否短而不容變更?
技術風險
  • 技術已獲證明嗎?
  • 重複使用目標合理嗎?
    • 工作成果必須先用過一次,之後,才能重複使用。
    • 元件可能需要釋出幾次之後,才會具備重複使用所需要的穩定性,而不再需要大幅度的變更。
  • 需求中的交易量合理嗎?
  • 交易率的預估可信嗎?它們會不會太樂觀?
  • 資料量合理嗎?它們可以保留在目前可用的大型電腦中嗎?如果您因為需求而相信設計將包含工作站或分部系統,資料能夠合理放在那些位置嗎?
  • 有不尋常或具挑戰性的技術需求,因而專案小組必須處理他們並不熟悉的技術嗎?
  • 成功有賴於新的或未嘗試過的產品、服務或技術、新的或未經證明的硬體、軟體或技術嗎?
  • 有對於其他系統(企業外的系統也包括在內)介面的外部相依性嗎?需要的介面存在嗎?或必須建立它們嗎?
  • 有非常固定的可用性和安全性需求(如「系統永遠不能失敗」)嗎?
  • 系統使用者是否熟悉所開發的系統類型?
  • 風險會因為應用程式的大小或複雜度或新技術而增加嗎?
  • 是否需要國家語言支援?
  • 這個系統可能設計、實作和執行嗎?有些系統就是因為太大或複雜而無法適當運作。
外部相依性風險
  • 專案依賴其他(並列)開發專案嗎?
  • 成功是否有賴於現成產品或外部開發的元件?
  • 成功是否有賴於順利整合開發工具(設計工具、編譯器等)和實作技術(作業系統、資料庫、跨流程通訊機制等)。產品的交付有沒有不含這些技術的備份計劃?

排程風險

經驗顯示 85% 的風險會直接或間接影響排程,因而也會隱含地影響成本。可能有 5% 只會影響成本。其餘部分不會直接影響成本或排程,但會直接影響例如品質。

如果截止時間就是截止時間,請利用漸進式交付的方式來平穩處理它。請避免嘗試單次的大量交付以符合排程。

有些專案會有真正的「致命」截止時間。例如,在選舉之夜「實況」分析選舉結果的軟體,如果在選後一星期才出現,就沒什麼價值了。另外,您的軟體也可能會因競爭者而作廢:當您的產品仍在建構中,他們可能啟動了一個更好的產品。於是,您忽然身在事外,無力回天。不過,一般而言,很少專案會有這麼緊急的截止時間。延遲主要是影響成本。

一般而言,請使您的排程承諾等於您的最佳預估,再加上一些合理的偶然情況。

承諾 = 預估 + 偶然情況

有人建議將預期的排程設成等於您的撤退策略,也就是說,以應變計劃為基礎,但這有點太悲觀,因為實際上並非所有風險都會實現。

排程風險整合在某些預估和成本計算工具中。例如,在 COCOMO 模型中,會有許多成本因素,例如:

  • 複雜度 (cplx)
  • 即時限制 (time)
  • 儲存體限制 (stor)
  • 經驗 (Vexp)
  • 好工具的可用性 (tool)
  • 排程壓力 (sced)

實際上都是風險因素。

其他複雜的風險管理技術包括使用 Monte Carlo 模擬,模擬工具會執行大量「情境」來計算整體風險和意外 [KAR96]。