1988年，Peat Marwick針對600家成功公司的調(diào)查結(jié)果顯示，35%的公司有過軟件項目失控的經(jīng)歷。（Rothfeder 1988）
1982年，Allstate公司宣布其公司運(yùn)營全部要實行自動化。他們啟動了一個將耗時5年投資800萬美元的大型項目，而在花費(fèi)了6年和1500萬美元后，Allstate公司重新調(diào)整了目標(biāo)和最終期限，重新調(diào)整后的預(yù)算大約1億美元。
1988年，Westpac Banking公司決定重新設(shè)計他們的信息系統(tǒng)。他們做了5年、8500萬美元的計劃。3年后，在花費(fèi)了1.5億美元卻依然收效甚微時，Westpac Banking公司為了減少損失，取消了這個項目，并為此裁員500人。（Glass 1992）
從項目管理的角度來看，有五大硬性知識領(lǐng)域：范圍管理、進(jìn)度管理、成本管理、質(zhì)量管理和風(fēng)險管理。風(fēng)險會出現(xiàn)在前面四個領(lǐng)域的各個過程中，只有有效地消除可能發(fā)生的危險因素，才能確保項目順利推進(jìn)。項目的風(fēng)險貫穿于整個項目過程，因此整個項目的生命周期都應(yīng)該堅持有效的風(fēng)險管理。
根據(jù)風(fēng)險的內(nèi)容，可以把風(fēng)險歸為以下幾類：
- 產(chǎn)品規(guī)模風(fēng)險：與軟件的總體規(guī)模相關(guān)的風(fēng)險
- 商業(yè)影響風(fēng)險：商業(yè)風(fēng)險影響到軟件開發(fā)的生存能力
- 客戶特性風(fēng)險：與客戶的素質(zhì)以及開發(fā)者和客戶溝通能力相關(guān)的風(fēng)險
- 過程定義風(fēng)險：與軟件過程定義相關(guān)的風(fēng)險
- 開發(fā)環(huán)境風(fēng)險：與開發(fā)工具的可用性及質(zhì)量相關(guān)的風(fēng)險
- 技術(shù)風(fēng)險：技術(shù)風(fēng)險是指在設(shè)計、實現(xiàn)、接口、驗證、維護(hù)、規(guī)約的二義性、技術(shù)的不確定性、陳舊的技術(shù)等方面存在的風(fēng)險
- 人員數(shù)目及經(jīng)驗帶來的風(fēng)險：與參與工作的軟件工程師的總體技術(shù)水平及項目經(jīng)驗相關(guān)的風(fēng)險
軟件項目的風(fēng)險主要體現(xiàn)在四個方面：需求、技術(shù)、成本、進(jìn)度。風(fēng)險管理是一個相當(dāng)重要的話題，但涉及的問題太多，很難在本章中全部囊括，本章主要講述進(jìn)度相關(guān)的風(fēng)險管理。
風(fēng)險管理要素
軟件風(fēng)險管理就是在風(fēng)險成為影響軟件項目成功的威脅之前，識別、處理并消除風(fēng)險?？梢栽趲讉€層次上定位風(fēng)險管理：
1、危機(jī)管理 — 救火模式，即在風(fēng)險已經(jīng)造成麻煩后才著手處理它們
2、失敗處理 — 覺察到了風(fēng)險并迅速做出反應(yīng)，但只是在風(fēng)險發(fā)生之后
3、風(fēng)險環(huán)節(jié) — 事先制定好風(fēng)險發(fā)生后的補(bǔ)救措施，但不做任何防范措施
4、著力預(yù)防 — 將風(fēng)險識別與風(fēng)險防范作為軟件項目的一部分加以規(guī)劃和執(zhí)行
5、消滅根源 — 識別和消除可能發(fā)生的風(fēng)險的根源
本章描述如何定位第4、5個層面上的進(jìn)度風(fēng)險管理。
總體來講，風(fēng)險管理由風(fēng)險評估和風(fēng)險控制組成：
圖 5.1-1 風(fēng)險管理由風(fēng)險評估和風(fēng)險控制組成
1. 風(fēng)險評估
- 風(fēng)險識別：建立一個潛在破壞項目進(jìn)度的風(fēng)險列表
- 風(fēng)險分析：評估每一個風(fēng)險出現(xiàn)可能性及其影響，判定風(fēng)險的級別
- 風(fēng)險優(yōu)先級：按風(fēng)險影響大小排出一個風(fēng)險優(yōu)先級列表，這個列表將作為風(fēng)險控制的基礎(chǔ)
2. 風(fēng)險控制
- 風(fēng)險管理計劃：定制一個應(yīng)對每個重要風(fēng)險的方案，同時應(yīng)確保每一個單獨(dú)的風(fēng)險管理計劃相互之間以及與項目計劃之間保持一致
- 風(fēng)險化解：執(zhí)行每一個重要風(fēng)險所對應(yīng)管理計劃
- 風(fēng)險監(jiān)控：對解決風(fēng)險的過程進(jìn)行監(jiān)控。還包括：識別新的風(fēng)險，并將其加入到正在進(jìn)行的風(fēng)險管理進(jìn)程；在風(fēng)險列表中移除已經(jīng)化解的風(fēng)險等工作
風(fēng)險識別
1. 最常見的進(jìn)度計劃風(fēng)險
- 功能蔓延
- 需求鍍金或開發(fā)人員鍍金
- 質(zhì)量不穩(wěn)定
- 計劃過于樂觀
- 設(shè)計欠佳
- 銀彈綜合癥
- 研究導(dǎo)向的開發(fā)
- 人員薄弱
- 承包人導(dǎo)致的失敗
- 開發(fā)人員與客戶之間發(fā)生摩擦
2. 進(jìn)度計劃風(fēng)險列表
下面列出了詳盡的可能對軟件進(jìn)度有負(fù)面影響的潛在風(fēng)險。除了這里所列出的風(fēng)險，大多數(shù)項目都有其特定的風(fēng)險，如：
“Joe要退出項目組，除非可以允許他帶自己的小狗來上班，而管理層還沒有決定是否同意他這樣做”—— 這樣的風(fēng)險就要靠自己識別了！
潛在的進(jìn)度計劃風(fēng)險： （資料來源：Gilb 1988、Boehm 1989 Pressman 1993、Thomsett 1993、Jones 1994）
類 型 |
風(fēng) 險 |
1、計劃編制 |
1) 計劃、資源和產(chǎn)品定義全憑客戶或上層領(lǐng)導(dǎo)口頭指令，而且不完全一致
2) 計劃是優(yōu)化的，是“最佳狀態(tài)”（但不現(xiàn)實，只能算是“期望狀態(tài)”）
3) 計劃忽略了必要的任務(wù)
4) 計劃基于使用特定的小組成員，而那個小組成員其實指望不上
5) 在限定時間內(nèi)無法建成已定規(guī)模大小的產(chǎn)品
6) 產(chǎn)品規(guī)模比估計的要打（代碼行數(shù)、功能點或與前一產(chǎn)品規(guī)模的百分比）
7) 工作量大于估計數(shù)（代碼行數(shù)、功能點、模塊等）
8) 進(jìn)度已經(jīng)拖延的項目在重新評估時過于優(yōu)化或忽略項目歷史
9) 過度的進(jìn)度壓力造成生產(chǎn)力下降
10) 目標(biāo)日期提前，但沒有相應(yīng)地調(diào)整產(chǎn)品范圍或可用資源
11) 一個任務(wù)的延時導(dǎo)致相關(guān)任務(wù)的連鎖反應(yīng)
12) 涉足不熟識的產(chǎn)品領(lǐng)域，花費(fèi)在設(shè)計和實現(xiàn)上的時間比預(yù)期要多 |
2、組織和管理 |
1) 項目缺乏一個用凝聚力的最高領(lǐng)導(dǎo)人
2) 由于前期乏力，項目長時間被擱置
3) 解雇和削減開支導(dǎo)致項目小組能力下降
4) 僅由管理層或市場人員進(jìn)行技術(shù)決策，導(dǎo)致計劃進(jìn)度延長
5) 低效的項目組織結(jié)構(gòu)降低生產(chǎn)率
6) 管理層審查或決策的周期比預(yù)期的時間長
7) 預(yù)算削減打亂項目計劃
8) 管理層作出了打擊項目組積極性的決定
9) 非技術(shù)的第三方的工作比預(yù)期延長（預(yù)算批準(zhǔn)、設(shè)備采購、法律審查等）
10) 計劃性太差，無法達(dá)到期望的開發(fā)速度
11) 項目計劃由于壓力而放棄，導(dǎo)致開發(fā)混亂低效
12) 管理層強(qiáng)調(diào)英雄主義而忽略客觀確切的狀態(tài)報告，錯過發(fā)現(xiàn)和改正問題的機(jī)會 |
3、開發(fā)環(huán)境 |
1) 設(shè)施沒有及時到位
2) 設(shè)施到位但不配套
3) 設(shè)施擁擠、雜亂或破損
4) 開發(fā)工具沒能及時到位
5) 開發(fā)工具不如期望的那樣有效
6) 開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃要求的性能
7) 開發(fā)人員需要長時間創(chuàng)建工作環(huán)境或切換新開發(fā)工具
8) 新開發(fā)工具的學(xué)習(xí)周期比預(yù)期的長，內(nèi)容繁多 |
4、最終用戶 |
1) 最終用戶堅持新的需求
2) 最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設(shè)計或重做
3) 最終用戶不買進(jìn)項目產(chǎn)品，無法提供后續(xù)支持
4) 最終用戶的意見未被采納，造成產(chǎn)品無法滿足最終用戶的期望而必須重做 |
5、客戶 |
1) 客戶堅持新的需求
2) 客戶對規(guī)則、原型和規(guī)格的審核和決策周期比預(yù)期的長
3) 客戶沒有或不能參與規(guī)劃和原型審查工作，導(dǎo)致需求不穩(wěn)定和耗時的變更
4) 客戶溝通或答復(fù)的時間比預(yù)期長
5) 客戶堅持技術(shù)決策而導(dǎo)致進(jìn)度計劃延長
6) 客戶對開發(fā)進(jìn)度管理過細(xì)，導(dǎo)致實際進(jìn)展緩慢
7) 客戶提供的組件無法與開發(fā)的產(chǎn)品匹配，導(dǎo)致額外的設(shè)計和集成工作
8) 客戶提供的組件質(zhì)量欠佳，導(dǎo)致額外的設(shè)計、測試、集成和客戶關(guān)系管理工作
9) 客戶要求的支持工具和環(huán)境不兼容、性能差或功能不完善，導(dǎo)致生產(chǎn)率降低
10) 客戶不接受交付的軟件，盡管它滿足合同的條款要求
11) 客戶期望的開發(fā)速度無法達(dá)到 |
6、承包商 |
1) 承包商沒有按承諾交付組件
2) 承包商遞交的組件質(zhì)量低下無法滿足要求，必須再花時間改進(jìn)
3) 承包商沒有買進(jìn)項目開發(fā)需要的工具，進(jìn)而無法提供需要的性能水平 |
7、需求 |
1) 需求已經(jīng)成為項目的基準(zhǔn)，但變化仍在繼續(xù)
2) 需求定義欠佳，但進(jìn)一步的定義會擴(kuò)展項目的范疇
3) 添加額外的需求
4) 需求定義含糊的部分需要的處理時間比預(yù)期多 |
8、產(chǎn)品 |
1) 錯誤發(fā)生率高的模塊需要比預(yù)期更多的設(shè)計、實現(xiàn)和測試工作
2) 校正質(zhì)量低下的產(chǎn)品需要比預(yù)期更多的設(shè)計、實現(xiàn)和測試工作
3) 在一個或多個新興領(lǐng)域推過產(chǎn)品技術(shù)使得進(jìn)度延長或不可預(yù)期
4) 由于軟件的功能錯誤使得需要重新設(shè)計和實現(xiàn)
5) 開發(fā)額外不需要的功能（鍍金）延長了計劃進(jìn)度
6) 要滿足產(chǎn)品規(guī)模的要求，需要比預(yù)期長的時間，包括重新計劃、設(shè)計和實現(xiàn)
7) 嚴(yán)格要求與原有系統(tǒng)兼容，需要進(jìn)行比預(yù)期更多的計劃、設(shè)計、實現(xiàn)和測試
8) 要與不受項目組控制的其他系統(tǒng)集成，導(dǎo)致無法預(yù)料的設(shè)計、實現(xiàn)和測試工作
9) 要求在不同操作系統(tǒng)或軟硬件環(huán)境下運(yùn)行將花費(fèi)比預(yù)期更長的時間
10) 在不熟識或未經(jīng)檢驗的軟件環(huán)境中運(yùn)行，產(chǎn)生未預(yù)料到的問題
11) 在不熟識或未經(jīng)檢驗的硬件環(huán)境中運(yùn)行，產(chǎn)生未預(yù)料到的問題
12) 開發(fā)一些全新的功能模塊比預(yù)期花費(fèi)更長時間
13) 依賴未成熟的技術(shù)，使得進(jìn)度延長或不可預(yù)期 |
9、外部環(huán)境 |
1) 產(chǎn)品依賴政府的政策或制度，而政策或制度不可預(yù)期
2) 產(chǎn)品依賴草擬中的技術(shù)標(biāo)準(zhǔn)，而最后的標(biāo)準(zhǔn)不可預(yù)期 |
10、人員 |
1) 招聘人員所花時間比預(yù)期長
2) 培訓(xùn)、工作許可證或其他項目的收尾等作為先決條件的任務(wù)不能按時完成
3) 開發(fā)人員和管理層之間關(guān)系不佳導(dǎo)致決策緩慢影響進(jìn)度
4) 項目組成員沒有全身心投入項目，進(jìn)而無法達(dá)到要求的產(chǎn)品質(zhì)量水平
5) 缺乏激勵措施，士氣低下，降低生產(chǎn)力
6) 缺乏必要的規(guī)范，增加了工作失誤幾率和重復(fù)工作
7) 某些人需要更多時間適應(yīng)新的軟件工具和環(huán)境
8) 某些人需要更多時間適應(yīng)新的硬件工具和環(huán)境
9) 項目結(jié)束前，成員調(diào)離團(tuán)隊或離職
10) 項目后期加入新開發(fā)人員，額外的培訓(xùn)和溝通降低現(xiàn)有成員的生產(chǎn)率
11) 項目成員不能有效地一起工作
12) 項目組成員間有沖突，導(dǎo)致溝通不暢、設(shè)計欠佳、接口錯誤和額外的重復(fù)工作
13) 有問題的成員沒有調(diào)離項目組，損害了其他成員的積極性
14) 項目的最佳人選沒有加入項目組
15) 項目的最佳人選已加入項目組，但因政治或其它原因未能合理使用
16) 沒有找到項目急需的，具有特殊技能的人
17) 關(guān)鍵人物只能兼職參與
18) 項目人員不足
19) 任務(wù)的分配與人員技能不匹配
20) 人員工作的進(jìn)度比預(yù)期的慢
21) 項目管理人員怠工導(dǎo)致計劃的進(jìn)度失效
22) 技術(shù)人員怠工導(dǎo)致工作遺漏和質(zhì)量低下 |
11、設(shè)計和實現(xiàn) |
1) 設(shè)計過于簡單，無法確定主要事件，并導(dǎo)致重新設(shè)計和實現(xiàn)
2) 設(shè)計過于復(fù)雜，導(dǎo)致一些不必要的工作，影響實現(xiàn)效率
3) 設(shè)計質(zhì)量低下，導(dǎo)致重復(fù)設(shè)計和實現(xiàn)
4) 使用不熟識的方法和技術(shù)，導(dǎo)致額外的培訓(xùn)時間
5) 使用低級語言開發(fā)產(chǎn)品，導(dǎo)致生產(chǎn)率比預(yù)期低
6) 一些必要的功能無法使用現(xiàn)有的代碼或庫實現(xiàn)，必須采用新庫或重新實現(xiàn)
7) 代碼和庫質(zhì)量低下導(dǎo)致需要額外的測試、錯誤修正或重做
8) 過高估計了工具對計劃進(jìn)度的節(jié)省量
9) 獨(dú)立開發(fā)的模塊無法有效集成，需要重新設(shè)計或重做 |
12、過程 |
1) 大量的書面工作導(dǎo)致進(jìn)度比預(yù)期慢
2) 進(jìn)度跟蹤不準(zhǔn)確，導(dǎo)致無法預(yù)知項目是否已落后于計劃進(jìn)度
3) 前期的質(zhì)量保證行為不真實，導(dǎo)致后期重復(fù)工作
4) 質(zhì)量跟蹤不準(zhǔn)確，導(dǎo)致無法得知影響進(jìn)度的質(zhì)量問題
5) 不夠正規(guī)（缺乏對軟件開發(fā)標(biāo)準(zhǔn)和策略的遵循），導(dǎo)致溝通不足和質(zhì)量問題
6) 過于正規(guī)（教條地遵循軟件開發(fā)標(biāo)準(zhǔn)和策略），導(dǎo)致過多耗時于無用的工作
7) 向管理層撰寫進(jìn)度報告占用開發(fā)人員的時間比預(yù)期多
8) 風(fēng)險管理不夠重視，導(dǎo)致沒有發(fā)現(xiàn)重大的項目風(fēng)險
9) 軟件項目風(fēng)險管理花費(fèi)的時間比預(yù)期多 |
風(fēng)險分析
1. 風(fēng)險暴露量
一種很有用的風(fēng)險分析方法就是風(fēng)險暴露量。風(fēng)險暴露量就是風(fēng)險發(fā)生的概率乘以損失的程度。舉例來說：如果你認(rèn)為“完成需求分析比原計劃延長4周的概率是30%”，那么風(fēng)險暴露量就是4周*30%=1.2周。
風(fēng) 險 |
發(fā)生概率 |
損失程度（周） |
風(fēng)險暴露量（周） |
計劃過于樂觀 |
50% |
5 |
2.5 |
由于要完全支持自動從主機(jī)更新數(shù)據(jù)而造成的額外需求 |
5% |
20 |
1.0 |
由于市場變化而增加額外的功能 |
35% |
8 |
2.8 |
圖形格式子系統(tǒng)接口不穩(wěn)定 |
25% |
4 |
1.0 |
設(shè)計欠佳——需要重新設(shè)計 |
15% |
15 |
2.25 |
項目審批超過預(yù)計時間 |
25% |
4 |
1.0 |
設(shè)施未能及時到位 |
10% |
2 |
0.2 |
為管理層撰寫進(jìn)程報告占用開發(fā)人員的時間比預(yù)期的多 |
10% |
1 |
0.1 |
承包商的圖形格式子系統(tǒng)推遲交付 |
10~20% |
4 |
0.4~0.8 |
新的編程工具沒有節(jié)省預(yù)期的時間 |
30% |
5 |
1.5 |
表 5.3.1-1 風(fēng)險暴露量
1) 評估損失程度
損失程度常常比發(fā)生概率更容易估算，在表5.3.1-1中，完全可能很精確地估計出由于增加“完全支持自動從主機(jī)更新數(shù)據(jù)”而增加的研發(fā)時間是20個月。如果有時損失程度不容易直接估算出來，還可以把損失分解為更小的部分分別進(jìn)行估算，之后將各個小的獨(dú)立評估結(jié)果累加得出合計估算值。
2) 評估發(fā)生概率
估算發(fā)生概率比估算損失程度更具主觀性。有許多實踐方法可以提高主觀評估的精確度，例如：
- 由最熟識系統(tǒng)的人評估每個風(fēng)險的發(fā)生概率，然后保留一份風(fēng)險評估審核文件
- 每個人對風(fēng)險進(jìn)行獨(dú)立評估，然后討論評估的合理性，直到達(dá)成共識
- 使用“形容詞標(biāo)準(zhǔn)”，如非常可能、很可能、可能、或許、不大可能和不可能等，然后把口頭評估轉(zhuǎn)換成量化的評估
2. 項目的延期和緩沖
由于我們只談?wù)撨M(jìn)度風(fēng)險，所以可以累加所有的風(fēng)險暴露量來得到項目總風(fēng)險暴露量。這個項目的總風(fēng)險暴露量為12.8~13.2周，這意味著，如果不做任何風(fēng)險管理的話計劃可能要延期12.8~13.2周。如果例子中的項目歷時25周，那么超出預(yù)計值12.8~13.2周就很顯然要進(jìn)行風(fēng)險管理了。
風(fēng)險優(yōu)先級
項目通?；ㄙM(fèi)80%的金錢解決20%的問題，所以風(fēng)險管理的重點是關(guān)注那最重要的20%的部分。（Boehm 1989）
如果只關(guān)注進(jìn)度計劃風(fēng)險而不是關(guān)注所有的風(fēng)險，確定風(fēng)險優(yōu)先級的工作就變得比較容易了。在風(fēng)險評估表中按風(fēng)險暴露量從大到小排序看看會得到什么結(jié)果：
序 號 |
風(fēng) 險 |
發(fā)生概率 |
損失程度（周） |
風(fēng)險暴露量（周） |
1 |
由于市場變化而增加額外的功能 |
35% |
8 |
2.8 |
2 |
計劃過于樂觀 |
50% |
5 |
2.5 |
3 |
設(shè)計欠佳——需要重新設(shè)計 |
15% |
15 |
2.25 |
4 |
新的編程工具沒有節(jié)省預(yù)期的時間 |
30% |
5 |
1.5 |
5 |
圖形格式子系統(tǒng)接口不穩(wěn)定 |
25% |
4 |
1.0 |
6 |
由于要完全支持自動從主機(jī)更新數(shù)據(jù)而造成的額外需求 |
5% |
20 |
1.0 |
7 |
項目審批超過預(yù)計時間 |
25% |
4 |
1.0 |
8 |
承包商的圖形格式子系統(tǒng)推遲交付 |
10~20% |
4 |
0.4~0.8 |
9 |
設(shè)施未能及時到位 |
10% |
2 |
0.2 |
10 |
為管理層撰寫進(jìn)程報告占用開發(fā)人員的時間比預(yù)期的多 |
10% |
1 |
0.1 |
表 5.4-1 排序后的風(fēng)險暴露量
排序后的風(fēng)險評估表實際上就形成了一個粗略的風(fēng)險優(yōu)先級列表。如果能成功地處理風(fēng)險列表中的前5個風(fēng)險，就有希望將超出預(yù)期計劃的時間減少10.05周，如果能成功地處理后5個風(fēng)險，則只能將超出預(yù)期計劃的時間減少2.7~3.1周。一般情況下，你的時間最好花在風(fēng)險列表中靠前的風(fēng)險上。
表5.4-1的排序只是粗略的，你可能想將損失更大的風(fēng)險排在優(yōu)先級更高的位置，確保他們不會發(fā)生（如：上表第6個風(fēng)險）。
你也可以把一些關(guān)聯(lián)的風(fēng)險排在比各自優(yōu)先級更高的位置，如表5.4-1中第5和第8個風(fēng)險。讓承包商開發(fā)圖形格式子系統(tǒng)接口，其組合風(fēng)險要遠(yuǎn)大于它們各自的風(fēng)險。
這里確定的風(fēng)險優(yōu)先級是比較粗糙的，因為用于確定風(fēng)險的數(shù)據(jù)都是估計的，因此優(yōu)先級本身也就是個相對主觀的值。所以，對風(fēng)險的客觀公正態(tài)度，是風(fēng)險管理必要的組成部分。
風(fēng)險管理計劃
編制風(fēng)險管理計劃的重點是制定一個計劃，以處理風(fēng)險分析中確定的高優(yōu)先級風(fēng)險。風(fēng)險管理計劃可以簡單地理解為一段一段的風(fēng)險管理描述，如：每個風(fēng)險的起因，表現(xiàn)形式，可能發(fā)生的時間、地點，為什么發(fā)生以及怎樣發(fā)生等。風(fēng)險管理計劃同時也包含：監(jiān)控風(fēng)險，處理新風(fēng)險，關(guān)閉已化解的風(fēng)險等計劃內(nèi)容。
風(fēng)險化解
特定風(fēng)險的化解在許多情況下都決定于特定風(fēng)險本身，下面列出一些化解風(fēng)險的一般方法：
1、 避免風(fēng)險
不要做冒險的活動。例如，你的項目進(jìn)度比較緊，有一個工具提供商聲稱它的工具能提高你的開發(fā)速度，但是你的團(tuán)隊成員從來沒使用過這個工具，這時你就不應(yīng)該冒險采用這個工具。首先該工具不一定像它聲稱的那樣好，其次對工具的學(xué)習(xí)和熟識需要一個過程，如果冒險用它很可能會得不償失。
2、 轉(zhuǎn)移風(fēng)險
有時，項目某部分的風(fēng)險對項目另一部分來說卻不是風(fēng)險，因此可以將它轉(zhuǎn)移到另一部分。例如，可以負(fù)責(zé)大部分的系統(tǒng)設(shè)計工作，但不要承擔(dān)不熟識的部分的設(shè)計工作，讓比較有把握的人負(fù)責(zé)設(shè)計這部分。
3、 購買風(fēng)險相關(guān)信息
如果不能確切知道風(fēng)險的嚴(yán)重性，可以做一些調(diào)研。也可以請外面的咨詢顧問幫你進(jìn)行評估。
4、 消除產(chǎn)生風(fēng)險的根源
例如，系統(tǒng)中某部分的設(shè)計可能面臨嚴(yán)重的問題，可將其作為一個研究項目徹底重新設(shè)計。
5、 接受風(fēng)險
如果風(fēng)險的后果較小，而處理它的成本太高，那么可以接受這個風(fēng)險，不做任何處理。
6、 發(fā)布風(fēng)險
讓上級領(lǐng)導(dǎo)、市場人員、客戶知道有關(guān)的風(fēng)險以及可能的后果。這樣，即使風(fēng)險真的發(fā)生了，他們也不會感到太驚訝。
7、 控制風(fēng)險
定制計劃應(yīng)對風(fēng)險無法化解的情形。例如分配額外的資源來測試設(shè)計中令人擔(dān)心的那部分系統(tǒng)，并留出額外時間處理測試發(fā)現(xiàn)的問題。
8、 記住風(fēng)險
總結(jié)項目相關(guān)的風(fēng)險及其處理辦法、處理效果等，為未來的項目建立一組風(fēng)險管理計劃。
風(fēng) 險 |
控制方法 |
1、功能蔓延 |
a) 使用基于用戶的實踐
b) 使用增量開發(fā)實踐
c) 控制功能集
d) 采取針對變更的設(shè)計 |
2、需求鍍金或開發(fā)人員鍍金 |
a) 修正需求
b) 時間鎖定開發(fā)
c) 控制功能集
d) 使用舍棄原型實踐
e) 基于進(jìn)度表的開發(fā) |
3、質(zhì)量低劣 |
a) 給QA留出時間，注重質(zhì)量保證基礎(chǔ) |
4、計劃過于樂觀 |
a) 采用多估算實踐
b) 多個估算員和自動估算工具有原則地進(jìn)行談判
c) 基于進(jìn)度表的開發(fā)
d) 使用增量開發(fā)實踐 |
5、設(shè)計低劣 |
a) 要有清晰的設(shè)計活動和足夠的設(shè)計時間
b) 進(jìn)行設(shè)計檢查 |
6、銀彈綜合癥 |
a) 要有一定的生成率要求
b) 建立軟件量度計劃
c) 建立軟件工具庫 |
7、研究導(dǎo)向的開發(fā) |
a) 不要試圖進(jìn)行研究的同時強(qiáng)調(diào)加快開發(fā)速度
b) 使用基于風(fēng)險的生命周期模型警惕地進(jìn)行風(fēng)險管理 |
8、人員薄弱 |
a) 招募頂尖人才
b) 項目開始前招聘或預(yù)定關(guān)鍵成員
c) 培訓(xùn)
d) 團(tuán)隊建設(shè) |
9、承包商失敗 |
a) 檢查參考資料
b) 外包前分析承包商能力
c) 積極管理承包商 |
10、開發(fā)人員與客戶發(fā)生摩擦 |
a) 采用面向進(jìn)度的實踐 |
表 5.6-1 常見進(jìn)度計劃風(fēng)險的控制方法
風(fēng)險監(jiān)控
由于風(fēng)險在項目推進(jìn)過程中會增強(qiáng)或減弱，所以需要對風(fēng)險進(jìn)行監(jiān)控，檢查每個風(fēng)險的化解程度，關(guān)閉完全化解的風(fēng)險，添加新產(chǎn)生的風(fēng)險。
1、 前十風(fēng)險列表
最有效的風(fēng)險監(jiān)控手段之一就是建立前十風(fēng)險列表，該表包含每個風(fēng)險當(dāng)前的級別、以前的級別、已經(jīng)上表的次數(shù)和上次審核后風(fēng)險化解的步驟等。
前十風(fēng)險列表最有意義的方面是促使你定期查看和思考這些風(fēng)險，并對重要的變化給予警告。
前十風(fēng)險列表的示例：
表 5.7-1 前十風(fēng)險列表
2、 中間檢查
雖然前十風(fēng)險列表可能是最有效的風(fēng)險監(jiān)控手段，但每個項目也應(yīng)該包括中間過程檢查。在完成每個主要里程碑后進(jìn)行一次小規(guī)模的檢查是非常有益的實踐。
3、 風(fēng)險官員
有時任命風(fēng)險官員很有用，風(fēng)險官員的職責(zé)就是對項目風(fēng)險提出警告，防止項目經(jīng)理和開發(fā)人員忽視計劃中的風(fēng)險管理。
400 186 1886
