與熊共舞：軟體專案的風險管理
Waltzing with Bears: Managing Risk on Software Projects
序言 信仰的道德
事情一旦做下去，是對是錯就已經確定了，就算結果的好壞會有意外，也無法改變事情對錯。這個人並非無罪，只是還沒遭到報應。是對是錯，得看信仰的出發點，而跟信仰本身一點關係也沒有，信仰什麼並不重要，重點在於他是怎麼做才得到這份信仰，這也跟信仰的是真是假無關，而要看他是否有權就這麼相信當前的證據。
Bear: 非常令人深思的文章。船沈了，大家會認為船主有罪；但要是它這次沒沈，一般人又會認為船主無罪。真是奇妙的例子，把人性主觀的天性表達的真好。
對岸翻釋的船主故事
在這篇文章裏，克裏福德聲稱：對信念的選擇不應免受倫理的審判。你的信念可能誘使你作出不道德的行為，而行為的道德與否--用克裏福德的話來說--取決於你"是否有權"相信你所相信的東西。
他舉了這樣一個例子：一位船主就要送他的移民船出海，船上滿載旅客。他知道這船很舊，而且當初造得就不怎麼樣，因此他非常擔心這船是否能夠安全地完成此次航行。但是，一番掙紮之後，船主還是戰勝了自己的疑慮，說服自己相信：再多一次航行也不會有什麼大不了的禍事。畢竟，這艘船也是久經風雨的了，不管遇上多麼惡劣的天氣，它也總能安全回家。那麼，這一次又怎麼會不行呢？
於是，這艘船出海了，然後帶著所有乘客沉入了海底。
"對這個人[船主]我們該說什麼？"克裏福德問道，然後給出了他自己的答案：
當然得這麼說：他對那些人的死負有確鑿的罪責。應該承認，他確實真誠地相信這艘船的牢靠，但是他這個信念的真誠性絲毫幫不了他，因為面對如此虛弱的證據，他無權這麼相信。他關於船不沉的信念，並不是誠實地通過耐心調查而得出的，而是因為他扼殺了自己所有的疑慮。雖說，到最後他認為船不沉這回事確定無疑，但這只是他有意地、欣然地誘導自己做出的結論，他必須對此負責。
隨後，克裏福德又回到了故事的起點，並對結局稍做了一點修改。假如這艘船終於安然無恙地完成了旅行，這是不是就能減輕（甚至排除）船主的罪責呢？
決不。一旦行為完成了，是對是錯也就永遠鐵定了，不可能被行為的善果或惡果偶然沒有達成這一事實所改變。無論船沉或不沉，船主都不會是無罪的，他只可能是作惡而沒被發現罷了。對錯問題，只和信念的根源有關，而與信念內容本身無關；只和船主得出信念的方式有關，而與信念是什麼無關；只和他是否有權從面前的證據中推論出該信念有關，而與信念最後被證明真或假無關。
在克裏福德之前，曾有這樣一種觀點：信念永遠不能被放在倫理的燈下接受拷問；只要你願意，你可以相信任何事。你甚至可以相信絕無可能的事，就像《愛麗絲漫遊鏡中世界》裏的白皇后那樣。當愛麗絲認為"人不能相信不可能的事"時，這位皇后答道：
"我猜你只是缺乏練習……像你這麼大的時候，我每天都會用半小時去相信不可能的事。啊，有時我甚至可以在早餐前相信六件不可能的事。"
不過，對於軟體專案管理者來說，"在早餐前相信六件不可能的事"似乎並不是一種難以企及的能力--我們總在相信著各種各樣不可能的事，例如在極短的時間裏、以極低的預算和極高的效率完成項目。
在做著這件事時，我們與那位對自己的船充滿信心的船主並無太大區別。無疑，作為軟體專案的管理者，你肯定曾經做過這樣的事。這也許是因為旁人的慫恿，例如你的老闆會請求你在耶誕節前完成一個項目--只給你三個人。當然，你會表示懷疑：這點時間夠用嗎？
"那就是為什麼我要選你來管理這個專案。"老闆信賴地對你說。
事情就這麼定下來了：你接受這份工作，接受挑戰，也準備接受榮譽……但你首先必須相信這個日程安排，那就是你必須付出的代價。終於，你艱難地說："我能行。"然後，你開始不斷地鞏固自己的信念。當然能行，不就是耶誕節嗎？為什麼不行？別的項目用的時間還要少呢，不是嗎？沒多久，你就已經充滿信心了。也許時間會證明你的信心毫無根據，但至少現在，你非常肯定：你能夠按時完成任務。
這時，你應該回想一下威廉•金頓•克裏福德的質詢。沒錯，那是你相信的，但你是否有權相信？憑面前的證據，你是否有權相信那個日程安排？
只相信你有權相信的事，這就是風險管理。說到底，風險管理的核心就是克裏福德的"信仰的倫理學"--儘管不確定性的存在使情況愈加複雜，但風險管理要求每個信念必須接受倫理的拷問。它將去除你的工作（例如軟體專案）中曾經充斥著的自欺欺人。除了"在早餐前相信六件不可能的事"之外，你還可以有另一種--更為明智的--選擇。
對岸書評
http://book.douban.com/review/1043890/
對這個船主，我們該說什麼呢？毫無疑問，他對那些人的死負有不可推卸的責任。
反觀我們身處的IT行業，有很多類似這個船長的情況發生。這個行業常常要求我們進入一種狀態，去相信那些隨後被時間證明是不可能完成的任務，比如去相信一個截止時間，相信一個預算，或則其他因素。
很多時候，身處專案中心的你，被你的船長送上了專案的死亡之旅。你也像那個船長一樣，在很多時候，都試圖證明那個最後的代價是可以逾越的。
但是，即使是在最後時刻，你都該確定你是否有權相信那些讓你無法把握的東西。
只相信你有權相信的東西，這就是風險管理。而風險管理的核心就是“信仰的倫理學”-儘管不確定性的存在使情況更加複雜，但風險管理要求每個信念都要接受倫理的考驗。它將去除你工作中充斥其中的自欺欺人，為你提供一種更為明智的選擇。
PartⅠ：為什麼要管理風險
CH1 擁抱風險
P.25
不做沒風險的專案。
P.28
Bob Charette提出一個挺新鮮的想法，幫助大家體會當今環境下的冒險情形。請想像你和競爭者都在爬電扶梯，當然，電扶梯和大家移動的方向相反。電扶梯移動越快，每的腳步就要越快，假如停下來，那怕只是停一下下，就會往下掉。當然，如果停太久，掉到谷底，就再也爭不過人家了。
在Charette的電扶梯世界裡，允許新競爭者從電扶梯的中間開始爬，所以，如果你往下掉，保證新競爭者會從一個高於你的位置起跑。
在每個電扶梯的頂端有一支推桿，可以控制所有電扶梯的速度。如果第一個搶到推桿，就表示你最優秀，有權加速電扶梯，保持上風，而你的競爭者卻不行。
加速其他所有電扶梯，就是你的冒的險，若不冒險，保證你的世界將會由某個競爭者來塑造和支配。在這個"冒險才有收穫"的時代，逃避風險的公司將落得被瓜分掠奪的下場。
P.31
什麼才是風險？管理風險有什麼意義？
風險若不管理，會有什麼後果？
為什麼要費心改變做法？
在進行風險管理時，會遭遇到什麼問題？
該怎麼做？
風險和機會之間，該如何取得一個平衡點？
如何知道風險管理已經落實了？
CH2 風險管理是成年人的專案管理
P.35
可能造成意外結果的事物就是風險。據此，我們暫時定義風險為：
風險n: 01.一個有可能在未來造成意外結果的事件 02.意外結果本身
一是因，二是果，兩方面都很重要，但請不要自以為兩方面都可以管理得很好。風險管理的事務，著重的就是成因風險(causal risk)的管理，亦即你能管理的部分。(至於風險管理的評量，則著重在結果的分析。)
之所以說是暫時性定是因為它假設風險要麼發生，要麼不發生。
有關風險的定義，還有另一種拐彎抹角的說法：所謂風險，就是還沒發生的問題；所謂問題，則是已經成形的風險。
在問題發生之前，風險只是抽象的概念，是某種有可能對專案造成影響的事物，忽視它，可能結果也不怎麼樣，但若不管它，並不代表沒有管理疏失，套句 William Clifford 說的話，只是"還沒遭到報應"
P.36
風險管理是在問題發生之前，預先思考應變措施的過程，這還是一個抽象的概念。而與風險管理相對的危機管理(crisis management)，則是在問題發生之後，嘗試去琢磨該怎麼善後。
想像一下，當原來某些被視為風險的事物突然變成問題時，本來很抽象，只是一種可能性，但現在不再抽象，它發生了，這個時間點我們稱為風險成形(materialize)，即風險蛻變(risk transition)之時。
然而，當要暫緩某些應變措施時，某些方面卻可能不允許耽擱，為了保持決策彈性，並為可能的後續發展進行修正，有些步驟在蛻變前就必須進行，這叫紓緩(mitigation)。
P.39
五個主要的風險管理活動：
一、風險深索(risk discovery)：一開始先進行風險腦力激盪，然後把風險歸類，再訂出一套可長可久的運作機制，使這套程序持續進行下去。
二、承擔分析(exposure analysis)：以風險成形的機率、及其潛在的衝擊程度為基礎，量化每個風險。
三、應變規劃(contingency planning)：萬一風險真的成形，你期望採取的行動。
四、紓緩(mitigation)：在風險蛻變前必須進行的步驟，使事先規劃的應變行動在必要時能發揮作用。
五、蛻變的持續監視(ongoing monitoring)：風險被納管之後，就要進行風險追蹤，留意是否成形。
以上，除第一項是屬於全面性的活動之外，其餘針對的都是個別的風險。
CH3 丹佛國際機場的省思
P.46
就算最完美的開發程序，也無法把一個複雜系統開發專案中的不確定性統統排除掉，只要有不確定性，就會有風險，只要有風險，就有必要付出心力進行理性、周詳的管理。與其問"他們是怎麼開發軟體的？"不如問"他們是怎麼管理風險的？"
P.50
....至此，結論很明顯，把該軟體移出要徑是很關鍵的紓緩策略
CH4 進行風險管理的理由
P.52
....這就是咱們軟體專案經理會贏得爛推銷員稱號的原因。
專案經理常常說，假如讓客戶了解背後的實情，他們將不會花錢做任何案子。
P.53
相反的，假如有位專案經理找你一樣研究，並把案子裡所有的不確定性全盤托出："瞧，這裡是未知的部分，我們已經將把它分門別類，整理出十一個項目"(這時，他端出一份風險列表)"我們一起來看看，根據這些未知的部分，可推導出交付日期的不確定範圍，該範圍內的某些日期您可能無法接受，但請看--事先準備好供您參考用的--為有效抑制並降低各種風險的危害，這裡是我們的建議做法。還有一份是讓您在專案進行濄程中，隨時了解狀況的方式。"此外，如果他還能讓你看看他們以往的專案記錄，藉由實際數據來佐證這些老案子評估不確定性的結果，那麼你便可以開始相信他說的話。
現在，你至少知道自已的位置，你正在冒險，但很清楚這是多大的險，你不妨把案子交給他做。投入這個案子該具備多大的勇氣，取決於你評估、量化、了解風險的程度。
P.54
風險管理創造出一個有限度、無傷大雅的悲觀思維，一旦採取風險管理的運作機制，便等於放手讓底下的人進行負面思考，至少留了這部分的思考空間，肯這麼做的公司，都能理解負面思考是避免專案突然遭受風險衝擊的唯一方法。
P.55
風險管理把不確定性局限在一定範圍內
當你走進一個屍橫遍野的戰場，你本能地就會開始擔心自已的安危，到底這些可憐蟲在臨死前發生了什麼事？會不會也降臨在自己身上？心中的恐懼也許會讓你不想或甚至無法再繼續前進。
如果情況換一下，有可靠的證據顯示，許多戰友走過這裡都沒事，週遭的成堆屍體不過是個意外，形勢就會改觀很多。風險仍然免不了，但有了這些證據，該怎麼走，便可做出較為謹慎而周嚴的判斷。
把不確定性局限在一定範圍內也許讓人害怕--害怕僅憑少量資訊就要把問題解決掉！但是，若連這點資訊都沒有，情況就會更糟。
P.56
風險管理可以釐清隱晦不明的責任歸屬
當開發工作是由眾多單位(如客戶、承包商、轉包商)共同合作，一般來說，各方人馬都得承擔一些風險，遊戲規則就是不論誰負責承擔什麼風險，就得為該風險發生後的結果付出代價。是誰付出代價，就看合約怎麼寫，但記住，簽約是門大學問，很難做到完美。由於誰都不敢擔保零風險，所以大家都應該做好風險管理。
如果不做，往往會疏忽掉難以釐清的責任歸屬問題，例如，當客戶協議要取消應急基金時，就表示他自已要扛下某些風險，這些風險的責任也就從承包商轉嫁(transfer)給客戶了。
P.57
誰願意在一個沒有成長機會的公司上班呢？並非所有員工都會為這個原因離開公司--只會走掉最優秀的。
進行風險管理並不會讓問題消失，只能保證不會讓你遭受突如其來的衝擊。
風險管理是一種聚焦機制，幫你把資源放在該放的地方。
PartⅡ：為什麼不管理風險
CH5 反對風險管理的理由
P.64
你可以管理風險，但不可能使風險消失，"成功管理"(manage for success)若建立在保證風險不會成形的基礎上，只會使專案走向災難。
P.65
假如你鐵口直斷，說交付日期只有10%的勝算，這勢必招來另一位虎視眈眈同儕的爭寵："報告老闆，這事包在我身上，保證給你如期完成。"
在最糟糕的組織中，報壞消息的人會被懲罰，但壞結果卻不會被檢討，當專案失敗時，他們的理由是："嘿！這小子是延誤了，但至少他肯盡力去嘗試。"所產生出來的問題正好讓他們自打嘴巴：大家都會了解，先把牛吹大，也比按時交貨來得重要，任何人都會學到這麼做最有利。如果在這種公司上班，最好順著潮流走，把風險評估收起來，自已用就好。
CH6 不確定性的臭名
P.67
事情做錯沒關係，就是不可以不確定。
假如這條規則就是貴公司的寫照，那就慘了。....失敗是容許的，只要不犯下事先就承認可能會失敗的滔天大罪。換言之，可以(在事後)為延誤請求原諒，但是不可以(在事前)要求認可。
P.68
哦，原來是看不到即將到來的火車
這種病症很明顯：大家都很小心不讓自已被枕木絆倒，卻沒人發現越來越近的火車。
P.71
現在，最基本的技巧就是：別理會小問題，鎖定噩夢攻擊，找出真正會影響專案的風險，由果反推出因，提防即將到來的火車。
CH7 運氣
P.74
假設專案以一種"追求個人挑戰"的方式告訴你："我知道在4月之前做完很難--但這正是我為什麼要交給你做的原因。"
P.76
專案一開始就以個人挑戰的形式出發，便很難再有明智的風險管理，這種專案就是在靠運氣。接到這種案子，你不會有太多轉寰的餘地，只能把經驗留給未來。記住，當有一天由你來主導專案時，就不要把運氣帶到計畫裡，在合理設定挑戰性目標之餘，請確定實際的期望必須為運氣實在很背時保留足夠的空間。
不知道什麼緣故，當乖乖去做一個靠運氣的案子，而運氣又很背時，便假裝自已很驚惶、失望、沮喪，也可以讓你活下去。但如果專案要成功，這樣靠運氣是行不通的，也非常幼稚。
P.74
Indy 500 大賽
....相同的思維放在軟體專案就是災難，當為了贏得成功而賭上每一個運氣時，也許就已經把落後的可能性大幅增加了，遠超過它原來的機率。
以下的道理很奇怪，但千真萬確：做軟體的案子，把失敗的可能產限制在一定範圍內，一般來說，是比追求勝利更重要的事。在這方面，每個組織都嘗過不信邪的苦頭，就算有賭贏了幾次，最不信邪的仍是輸家(像DIA)。
當你用了激將法，要部屬拼死拼活、搏命演出，擺明要他準時完成專案(即使時程訂得相當可笑)，你就必須了解到，這麼做正是把NASCAR賽車手擺在團隊中最關鍵的位置，只要有任何機會，他就會去賭，而不顧任何不良後果，為了拼到底--至少拼到死為止--任何一丁點可以投機的機會他都會去賭。
這種管理方式你叫它什麼我不知道，但絕不叫風險管理。
PartⅢ：如何管理風險
CH8 將不確定性量化
P.84
不確定性圖(uncertainty diagram)，或稱風險圖(risk diagram)
P.85
奈米機率日
曲線與水平線的交點是開始有機會完成的第一天，但只是比零好一點，該點稱為N點，即"奈米機率日"(nano-percent date)，這是因為那天順利交付的機率大概只有十億分之一。
P.88
當不確定性的範圍只佔N的10%~15%，你會覺得很愜意，再大就會感到渾身不自在--事實上，到15%以上你會越來越不自在。
就整個軟體產業來看，不確定範圍大多是介於N的150%~200%之間，所以，若某個專案的點是在第25個月，不確定性曲線的尾巴可能就會拖到第75個月以後。
CH9 風險管理的技巧
P.90
大部分專案經理在預估一定要完成的工作上做得還不錯，但預估也許必須完成的工作則做得很糟。
..
P.91
06.昨日的問題就是今日的風險。
有些人可能會對此有點意見，而把它"更正"為今日的問題就是昨日的風險，或今日的風險就是明日的問題，乍看之下很不錯，但這沒什麼用。就是要把眼前的風險視為過去問題的方程式(換言之，這是認知到問題會一再重複出現的本質)，才會對風險管理有所幫助。
P.93
你可以迴避(avoid)它、你可以抑制(contain)它、你可以紓緩(mitigate)它、你可以逃避(evade)它。
P.94
前三件事都要花錢：迴避成本相當報酬的損失，抑制成本相當於用掉的風險準備(risk reserve)，紓緩成本則是花在降低抑制成本的錢，只有逃避看來是不用花錢的。
風險管理不等於擔心。
我們都逃避過某些風險，並為此慶幸不已，然而，規劃去逃避風險實在不是一個好策略。
P.9
P.9
P.9
CH10 風險管理的處方
CH11 回到根本
CH12 工具和程序
CH13 軟體專案的核心風險
CH14 風險探索的明確過程
CH15 風險管理的動態追蹤
CH16 漸進式風險紓緩
CH17 終極的風險紓緩策略
PartⅣ：該冒多少風險
CH18 價值的量化
CH19 價值也一樣不確定
CH20 敏感性分析
CH21 值不值得冒險
CH22 改良風險管理的處方
PartⅤ：管不管用
CH23 風險管理測驗
