在軟件開發(fā)過程中，經(jīng)常忽略的一個因素——風(fēng)險。風(fēng)險是一把雙刃劍，因為風(fēng)險的另一面就是價值，我們不能因為它的負面影響避而不談。 與熊共舞：軟件項目風(fēng)險管理 就圍繞著風(fēng)險這個東西展開闡述。

此書作者是一個實踐家而不是思想家。在文中他指出了為什么風(fēng)險管理會給忽略，跟著談了如何做合理的風(fēng)險管理。我認為，在現(xiàn)實的環(huán)境中，影響風(fēng)險最關(guān)鍵的還是人，因此作者在序編里面就引用了英國以為思想家William K. Clifford的論文《信仰的論理學(xué)》，這篇論文的確提高了此書的思想深度。看到后面，經(jīng)過反思才覺得這篇論文才最能說明關(guān)于風(fēng)險的問題。一切都是人左右風(fēng)險，試想一下如果所有人都有風(fēng)險的意識，那還擔(dān)心用什么方法去管理嗎？所以此書只是風(fēng)險管理的操作手冊，是術(shù)，非道！

開宗明義，先定義風(fēng)險的概念。本書對風(fēng)險的定義是：（1）未來可能發(fā)生的某一事件，該事件將導(dǎo)致不好的結(jié)果；（2）不好的結(jié)果本身。

我比較喜歡是本書的目錄結(jié)構(gòu)，讓我們來看看。
第一篇 為什么要進行風(fēng)險管理？
第二篇 為什么不進行風(fēng)險管理？（如果向一個尚未做好準(zhǔn)備的企業(yè)引入風(fēng)險管理機制，可能產(chǎn)生一些潛在的副作用。）
第三篇 如何進行風(fēng)險管理？
第四篇 我們的企業(yè)甘冒多大風(fēng)險？
第五篇 如何知道我們的風(fēng)險管理機制是否有效？

如果沒有第二篇，就是一份中規(guī)中矩的文章結(jié)構(gòu)。第二篇對于我來說是挺新穎的，一本提倡使用風(fēng)險管理的書去論述為什么不要使用風(fēng)險管理，的確是很不錯的逆向思維。

本篇中一些反對風(fēng)險管理的理由：
1。顧客還沒有成熟到坦然面對風(fēng)險的地步。
2。不確定性的范圍太廣了。
3。不確定性的范圍會成為低效的借口。
風(fēng)險管理告訴：目標(biāo)只是用于激勵員工拿出最高的工作效率；與此同時，在向顧客和管理層作出承諾時，你還需要一個與目標(biāo)迥然不同的估算計劃。
4。“成功管理”時更好的管理方法。
5。缺乏有效實施風(fēng)險管理所需的數(shù)據(jù)。
6。孤立的風(fēng)險管理是危險的。
無論如何，如果一位項目經(jīng)理的四周充斥著“我能做到”的聲音，風(fēng)險管理對于它是毫無意義的。即使企業(yè)沒有廣泛實施風(fēng)險管理，你仍然可以在項目中使用風(fēng)險管理的一些工具和技術(shù)，但不要把自己的發(fā)現(xiàn)公諸于眾?？杀?，但現(xiàn)實卻是如此！

在最糟糕的企業(yè)里，曲突徙薪的建議會遭到懲罰，引火燒身者卻不會。

第十一章：風(fēng)險：描繪所有可能結(jié)果及由其引發(fā)的相關(guān)后果的加權(quán)圖。

風(fēng)險管理告訴你：目標(biāo)只是用于激勵員工拿出最高的工作效率；與此同時，在向顧客和管理層做出承諾時，你還需要一個與目標(biāo)迥然不同的估算計劃。

出現(xiàn)偏向某一側(cè)的圖形的原因是人們的工作效率也傾向于類似的形狀：快速完成任務(wù)時，人們?nèi)菀准芯?；時間拖得越長，工作效率也越低。

第一類風(fēng)險稱為總風(fēng)險，因為他們將項目作為一個整體看待；第二類風(fēng)險則成為肇因風(fēng)險或者成分風(fēng)險。兩者是緊密相關(guān)的?？傮w結(jié)果的不確定性是各方面不確定性的直接結(jié)果，若干部分的共同作用決定了項目整體的成敗。

通過估算器產(chǎn)生的生產(chǎn)模型和風(fēng)險模型結(jié)合就成為了一個總風(fēng)險模型。

下面是書中一些章節(jié)精彩內(nèi)容的摘錄。

第十三章 軟件項目的核心風(fēng)險

5種核心風(fēng)險：
1。進度安排的先天錯誤；
2。需求膨脹（需求變化）；
3。人員流式；
4。規(guī)約崩潰；
5。低生產(chǎn)率。

其中，只有最后一線是真正與效率相關(guān)的，其余4項幾乎與你工作的努力程度、你的天分和能力完全無關(guān)。之所以強調(diào)這一點，是因為有些管理者擔(dān)心風(fēng)險管理變成低效率的借口。預(yù)先為這些不確定因素做充分準(zhǔn)備，正是風(fēng)險管理的核心。這種預(yù)留的空間不是讓你為自己的失敗開脫；它只是一種儲備，只有當(dāng)某些不確定因素變成實實在在的問題時才能動用。

進度安排錯誤：
如果沒有認真地估算產(chǎn)品的規(guī)模，那么你預(yù)計的進度就是空中樓閣。如果管理者提出或者接受一個存在嚴重問題的日程安排，證明他的工作績效很有問題。應(yīng)該牢記：項目的超期不應(yīng)歸咎于開發(fā)者的低效率。實際上，整個開發(fā)團隊很可能已經(jīng)發(fā)揮出了最高的工作效率——出了管理者之外。

需求膨脹：
“擊中移動的目標(biāo)”是所有人的問題。打算完全按照現(xiàn)在的要求交付產(chǎn)品，而不允許任何變動，這無異于刻舟求劍。
更合理的邏輯應(yīng)該是這樣的：“你說你想要X；經(jīng)驗告訴我們，在開發(fā)過程中需求可能會有些變化，到最后你想要的東西可能跟X稍微有點不同。所以，我們將針對X指定計劃，并且允許一定限度的改變。”
限度有多大？按照上世紀90年代中期，美國國防部提出了一組關(guān)于運轉(zhuǎn)良好的項目應(yīng)有的行為方式的量化數(shù)據(jù)。他們的定量分析結(jié)果是：合理的需求變更應(yīng)該在每月1％以下。如果你的項目有20，000個功能點，為期2年，你就準(zhǔn)備完成25000個功能點。（20000×（1.00+24×1％） ＝ 25000）。

人員流失：
要估算人員流式的風(fēng)險，需要提供下列信息：
◆你公司里技術(shù)人員的年平均流動率；
◆對于新進員工的“上手時間”，你最樂觀的估計。

過去，我們總是不由自主地建設(shè)開發(fā)者都是可以隨便替換的，新員工馬上就可以取代離去的老員工……多么愚蠢的假設(shè)。

規(guī)約崩潰：
這種與其他不同，它是離散而非連續(xù)的。它的結(jié)果只有兩種：要么發(fā)生，要么不發(fā)生。
被掩蓋的問題一時不會來打擾你，但不是永遠。盡管你可以含混地說明一個產(chǎn)品，卻不可能含混地構(gòu)造一個產(chǎn)品。

低效率：
大量的文獻資料表明，開發(fā)者之間的工作效率存在著相當(dāng)大的差異。然而，把項目團隊作為一個整體來考察時，這種差異將在某種程度上被弱化。
這項因素的影響傾向于相對平衡，像這樣趨于平衡的風(fēng)險只會引入噪音：它會擴大不確定性的范圍，卻不會使期望結(jié)果顯著地朝任何一個方向移動。

第十四章 風(fēng)險發(fā)現(xiàn)的詳細過程

有時，企業(yè)文化會使得我們根本不可能談?wù)撊魏握嬲軌蛟斐陕闊┑娘L(fēng)險——我們就像愚昧無知的部落原是人一樣，以為只要不說出魔鬼的名字就不會招來魔鬼。
在工作中，我們都被迫保持“我能做到”的心態(tài)，這也是障礙所在。說出一項風(fēng)險，就等于一次“我做不到”的表態(tài)。風(fēng)險管理與傳統(tǒng)企業(yè)文化一些根本的方面有著深刻的沖突。
由于障礙強大，我需要一個開發(fā)、固定并得到充分理解的過程，這樣員工才有可能開口說出風(fēng)險的存在。
通過三個倒退的步驟來識別風(fēng)險。
災(zāi)難性后果－》情景－》根源
風(fēng)險發(fā)現(xiàn)過程不應(yīng)該只在項目啟動時進行一次，必須盡量保證它成為項目回顧中不斷延續(xù)的一部分。
一般來說，這三個步驟應(yīng)該在同一次會議上進行。但是，每個步驟的技巧是獨立的。

第一步，災(zāi)難頭腦風(fēng)暴
所謂頭腦風(fēng)暴，是指有計劃的集體想象活動：群策群力，發(fā)揮集體的創(chuàng)造性，使新的思想得以浮現(xiàn)。
“頭腦風(fēng)暴之父”的經(jīng)典作品：de Bono, Edward. Lateral Thinking: Creativity Step by Step. New York: Perennial, Harper & Row, 1990.
頭腦風(fēng)暴得用一些小手段來幫助人們度過不可避免的思維短路。
1。以噩夢的形式指明問題：詢問所有人，對于這個項目，他們最擔(dān)心的是什么。如果他們會滿身冷汗地從夢中驚醒，夢中的情景會是什么？
2。使用水晶球：假設(shè)你擁有一個能夠預(yù)知未來的水晶球。
3。轉(zhuǎn)換視角：請大家描述他們對項目最好的夢想，然后把這些美夢全都反過來，大家一齊討論“是什么使美夢不能成真”。
4。尋找不應(yīng)被責(zé)備的災(zāi)難。
5。尋找應(yīng)該被責(zé)備的失敗，只有當(dāng)所有相關(guān)的人都在場時，這招才有用。
6。設(shè)想部分失敗。
頭腦風(fēng)暴是快速而猛烈的，所以你應(yīng)該安排至少一個人來記錄所有的意見。一定不要讓主持人來負責(zé)記錄。

第二步，情景構(gòu)造
根據(jù)記錄下來的災(zāi)難，想想它可能在哪種或者哪幾種情景下出現(xiàn)。

第三步，根源分析
根源分析最好由一組人進行。事實上根源分析并不像乍看上去那么輕松。因為“根源”本來就是一個復(fù)雜的概念（到哪里才算是找到根源了？）。
有幾本經(jīng)典著作分析了根源這個問題。
Andersen, Bjorn,ed.Root Cause Analysis:Simplified Tools and Techniques. Milwaukee:American Society for Quality,1999.
Gano, Dean. Apollo Root Cause Analysis:A New Way of Thinking, ed. Vicki E. Lee. Yakima, Wash.: Apollonian Publications, 1999.