書摘《與熊共舞》

圖片來源：博客來

這本與《人月神話》都是軟體工程領域知名的書籍，曾從學校圖書館借來看過，但說真的，還沒進入業界，其實很難體會風險是什麼？但... 在業界打滾幾年後，再次回來看這本書時，你會發現風險... 不好說 XD

Part I：為什麼要風險管理

1 擁抱風險

專案充滿風險，正因為裏頭有東西沒人做過，它迫使你使出渾身解數。這意味如果做成功、通過考驗，就能殺得競爭對手措手不及，你的能力會達到一個讓競爭對手招架不住的位置，得來的競爭力將幫助你在市場上建立獨特品牌。 _{p. 25}

在這動盪的時代，勇於冒險的態度非常重要，這關係到許多比效率更重要的東西，效率頂多使你成為一個讓人想取而代之的目標罷了——會超越你的，也許就是某個缺乏效率的競爭者，只因他更積極去冒險。 _{p. 28}

在這個「冒險才有收穫」的時代，逃避風險的公司將落得被瓜分掠奪的下場。 _{p. 29}

2 風險管理是成年人的專案管理

只憑著前途一片光明的景象來作為專案計畫的基礎，就知道這是小孩子才會幹的事，然而，我們卻常常這麼幹。當我們做出這些不成熟的舉動時，還會仗著專業技術的進步，自以為很「成熟」。 _{p. 34}

有關風險的定義，還有另一種拐彎抹角的說法：所謂風險，就是還沒發生的問題；所謂問題，則是已經成形的風險。 _{p. 35}

我個人比較喜歡這樣的說法。

風險管理是在問題發生之前，預先思考應變措施的過程，這還是一個抽象的觀念。而與風險管理相對的危機管理，則是在問題發生之後，嘗試去琢磨該怎麼善後。 _{p. 36}

舒緩不但花錢，也花時間，如果運氣好到沒話說，這些花出去的錢和時間就顯得有點浪費，由此可能會引伸出一個讓你做不好風險管理的謬論。 _{p. 37}

其實我們都知道，對於不想看到的結果，就算宣告它絕不可能發生，也無法把它變成決不可能，但這會使風險變得幾乎無法管理。 _{p. 41}

3 丹佛國際機場的省思

之所以失敗，並非 DIA 的風險管理方法不好，而是它根本就沒花任何功夫在風險管理上。即使是最馬虎的風險管理作為——也許在開始進行風險探索腦力激盪的第一時間——都會把延遲列為重大風險。 _{p. 49}

事實上，5 億美元的額外財務風險應該是由更高層的單位來承擔，誰有風險管理之責，誰就得承擔忽視風險的後果，付這筆錢。 _{p. 50}

4 進行風險管理的理由

風險管理史蹟及得冒險變為可行。這個理由很難被一般組織文化所接受，因為組織很少會鼓勵明確處理不確定性的問題。 _{p. 51}

當然，把未知的範圍挑明之後，客戶可能就跑了，也許他習慣聽到的是不可能的承諾——在專案初期就非常精確地對交付日期做出保證——先把失敗的可能性提出來，對他來說真是太詭異了。 _{p. 52}

如果沒有風險管理的運作機制，誰敢公開提出一個風險 (特別是質疑大頭目們提出的不實夢想)，就會死得很慘，他會被貼上滿腹牢騷的標籤，被視為未盡全力，或專門唱衰公司的人。 _{p. 53}

按照定義，風險準備是可能用不到的時間和金錢，所以，把風險準備納入時程和預算需要很大的勇氣。 _{p. 55}

若不能有效管理風險，公司就會變得過份保守，什麼險都不感冒，玩不了大案子，這表示公司無法繼續擴展新領域。 _{p. 56}

我倒覺得台灣的公司很敢冒險

進行風險管理並不會使問題消失，只能保證不會讓你遭受突如其來的衝擊。 _{p. 57}

Part II 為什麼不管理風險

5 反對風險管理的理由

組織早就習慣了自己騙自己，所以很難接受這種程度的誤差。有些組織不顧一切地相信可以控制一切，即使心知肚明這並非事實，還是慣用控制的假象來蒙蔽現實。 _{p. 63}

大家都會了解，先把牛吹大，也比按時交貨來的重要，任何人都會學到這麼做最有利。如果在這種公司上班，最好順著潮流走，把風險評估收起來，自己用就好。 _{p. 66}

6 不確定性的臭名

失敗是容許的，只要不犯下事先就承認可能會失敗的滔天大罪。換言之，可以 (在事後) 為延誤請求原諒，但是不可以 (在事前) 要求認可。假如組織文化不允許不確定性的存在，風險管理就不用做了。 _{p. 67}

最基本的技巧就是：別理會小問題，鎖定噩夢攻擊，找出真正會影響專案的風險，由果反推出因，堤防即將到來的火車。 _{p. 71}

7 運氣

當你決定忽略某個風險時，就相當於要賭一賭運氣，賭不想發生的事不會發生。對某些風險來說，這非常明智，但並非所有風險都該這麼做。所謂「並非所有」正是此處要講的重點：一般的通病就是全部的風險都在賭運氣。 _{p. 73}

這絕對跟風險管理的精神相違背：風險管理是要你在規劃專案時，把焦點放在一旦某些機會沒有抓住的話該怎麼辦。 _{p. 75}

當你用了激將法，要部屬拚死拚活、搏命演出，擺明要他準時完成專案 (即使時程訂得相當可笑)，你叫必須了解到，這麼做正是把 NASCAR 賽車手擺在團隊中最關鍵的位置，只要有任何機會，他就會去賭，而不顧任何不良後果，為了拚到底——至少拚到死為止——任何一丁點可以投機的機會他都會去賭。這種管理方式你叫它什麼我不知道，但絕不要風險管理。 _{p. 78}

Part III 如何管理風險

8 將不確定量化

軟體開發是高風險事業，因為整個任務都充滿不確定性，任何需要預測的地方，都存在某種程度的不確定。 _{p. 81}

想知道組織是不是夠成熟，不妨看看各階層的管理者在做任何承諾時，是不是會一併把不確定性的範圍明確說出來。 _{p. 85}

不確定範圍要多大才算合理，取決於組織開發程序中干擾或變異的多寡，而非某個人的感覺。 _{p. 88}

干擾有很多，處理線上系統問題、設計變更等等，對於一邊營運一邊開發新功能的團隊來說，干擾與變異都會比較大。

9 風險管理的技巧

大部分專案經理在預估一定要完成的工作上做得還不錯，但預估也許必須完成的工作則做得很糟。 _{p. 90}

昨日的問題就是今日的風險。 _{p. 91}

風險承擔預估並不是非常嚴謹的科學，之所以能求得風險成形的機率，憑藉的也許是業界資料、過去的問題列表、風險庫，或純粹猜測。 _{p. 97}

舒緩是風險成形之前進行，所以，就算風險沒有成形，付出去的舒緩成本也拿不回來。所以，因舒緩而節省下來的抑制成本必須超過新增加的舒緩成本，否則，就不值得花這個錢。 _{p. 100}

假設知道在不久的未來，系統會發生 A 問題，完全解決問題的成本為 X，雖然無法完全解決問題，但可以讓問題發生時的傷害降低的方法成本為 Y，X 一定要大於 Y，不然做 X 就好了。

10 風險管理的處方

由於我們不允許「提前完成」這第三種結果，所以如期交付的勝算已經到幾乎為零，這種不合理的評斷使得時程緊繃成了常態，而非例外。 _{p. 108}

一旦提前完成不再被責難，利害關係人才會開始對如期完成有合理的期望。 _{p. 109}

幸運的是，你可以在時程不確定和功能不確定之間取捨。 _{p. 109}

時程確定，刪功能；功能確定，延長時程；都確定是不可能存在。

11 回到根本

你有必要把這些「我不知道」的問題弄清楚，因為那通常就是風險的所在。無論什麼不知道，只要會造成不利的負面影響，就是風險。 _{p. 114}

第 12 章介紹 RISKOLOGY 和蒙地卡羅取樣等內容，有興趣還是看書吧！搭配圖表比較好懂。

13 軟體專案的核心風險

只要待過軟體界，就知道讓專案遭殃的都是些老問題，時程落後和沒完沒了的需求變動並非遇到一次就免疫，這些問題總是陰魂不散。雖然這種情形大家都知道，但很奇怪，我們就是不會為此預先規劃，老是假裝問題會隨風而逝，當然，這根本是一廂情願。 _{p. 139}

核心風險列表：

1. 先天的時程錯誤
2. 需求膨脹 (沒完沒了的需求變動)
3. 人力流失
4. 規格崩潰
5. 低生產力 _{p. 139}

時程錯誤不僅是真正的風險，也是五個核心風險中對專案衝擊最大的。 _{p. 140}

生氣的高層主管很少會怪時程，相反地，他們會怪人沒有盡力——不管時程訂得有多離譜。 _{p. 141}

加上套用 agile 後，時程是開發團隊自己估的，就更慘了，因為可以說再怎麼離譜的時程都是團隊估的，但事實上是嗎？當一個很大的數字被提出時，很常會聽到：可以縮短嗎？然後就變小了。更不用說，工程師通常是超樂觀派的人...

開發軟體多半是為了滿足某些人的事業領域，可以確定的是，在開發過程中，該領域並不會一直維持不變，它改變的速度取決於市場狀況，以及自身的創新速度。 _{p. 143}

一般人都傾向於促成這個案子，傾向於能合作成功，所以，如果有什麼會讓彼此談不攏的嚴重衝突，往往都是先掩飾起來，於是，專案就在含著缺陷、模糊的目標下前進。 _{p. 147}

文獻中有相當多證據顯示，不同開發人員的工作表現好壞差異相當大，但在團隊裏，個人因素或多或少被中和掉，所以專案團隊之間的好壞差異就沒那麼大了，更何況，有些個人表現差異還是由上述某個核心風險造成的。 _{p. 149}

14 風險探索的明確過程

對於真正讓人擔心的風險，我們的組織文化有時連談都不讓人談，跟原始土人一樣，呼喚惡魔的名字就是禁忌，以為這樣就可以困住惡魔。閉口不談風險，也不會讓風險消失不見。 _{p. 153}

健全的文化會非常地重視「團隊」的概念，被視為「團隊的一份子」是非常重要的，反之則是很嚴重的事。雖然談論風險不該被當成是「唱反調」，但往往被如此看待。 _{p. 155}

在工作上，我們都被要求保有辦得到 (can-do) 的態度，問題就出在這兒——談論風險是一種辦不到 (can't do) 的思維，風險探索更背離了組織的主流意見。 _{p. 155}

建議看一下第 14 章，裡面條列了一些步驟探索風險，但很難摘錄下來。

15 風險管理的動態追蹤

我們總是在專案中期就不再理會風險管理，但那時往往是專案進行不順利、正需要風險管理的時候。 _{p. 163}

16 漸進式風險舒緩

投資，就是舒緩本身耗費的成本與時間；收益，則是當風險發生時所能減少的成本與時間。這是某種加權評估。據了解，擁有最佳投資收益比的風險舒緩策略就是漸進式交付。 _{p. 171}

還記得敏捷的 12 條實踐嗎？

為什麼漸進式法特別符合風險管理者的需要：

• 它可證實專案計畫的假設是對是錯。
• 它迫使你為系統組件進行修先順序排定。
• 它可讓交付出去的部分產品得到最大報酬 (後略) _{p. 172}

假設產品的每個部分都一樣重要，這種謊言充斥於許多專案。 _{p. 174}

排定優先順序揭穿了價值軍醫的謬誤，並有助於進行漸進式成本報酬分析，判斷哪些該納入早期版本，那些該納入後期版本。 _{p. 174}

有風險認知的管理者都會優先考量含有重大技術風險的部分，這非常合理，不過也有違大部分管理者的本性，因為會太早曝露他們在這場競賽中的最大弱點，這就是為什麼對如此棘手的事情，他們總是寧可秘而不宣、一拖再拖。 _{p. 174}

17 終極的風險舒緩策略

首先，我們要反駁一下組織裡的傳統概念——認為建立專案時不預留任何緩衝餘地就是真正勇敢的管理，反之，就是懦弱的象徵。 _{p. 185}

Part IV 該冒多少風險

18 價值的量化

精確成本和模糊報酬造就出不倫不累的成本報酬分析，更重要的是，明智的風險管理也變得不可能。 _{p. 193}

每當聽到只要有 X 功能，A 就會簽約的說法，我通常是持懷疑態度的...

公司最大的風險卻事在價值方面：把功夫浪費在低價值專案而錯失高價值專案，所耗費的機會成本。 _{p. 195}

冒險的積極程度必須由報酬來驅動。你願意冒多少風險，端視你可以得到多少報酬而定。 _{p. 195}

19 價值也一樣不確定

價值預測的第一步，就是要量化最樂觀的期望，以收益、利潤或市場滲透率來表示量化的結過。同樣，也可以量化最不樂觀的期望，而在最樂觀與最不樂觀之間，會有一個可能性最高的期望值。 _{p. 200}

20 敏感性分析

系統真正值錢的，是展現或支援產品核心的重點功能。 _{p. 206}

當交付到版本 n 時，大家都會發現，剩下的東西平均價值/成本比已經很小，這也許是一個趁勢提出結案的好時機，莊嚴、很有面子地宣告成功，然後繼續做下一個案子。 _{p. 207}

刪除系統中屬於低價值/成本比的部分，也許是舒緩時程和預算壓力最簡單、最棒的方法。軟體開發人員應該學著相信「少開發一點軟體」，這很古怪，但很明顯是比較好的做法。 _{p. 208}

21 值不值得冒險

在 IT 產業，情況似乎完全相反：報酬小，就要冒更多險，不然我們怎麼可能把成本壓力到讓專案不賠本？ _{p. 211}

根據經驗，死亡行軍第一個共同特徵，就是預期價值很低。... (中略) ... 死亡行軍的第二個特徵，就是員工成了冤大頭。片他們犧牲小我、完成大我 ... (中略) ... 死亡行軍的第三個特徵，就是專案最後幾乎都出盡洋相。 _{p. 212}

第 22 章改良風險管理的處方，把前面幾章作個總整理，值得看看。

Part V 管不管用

23 風險管理測驗

為何不乾脆信任部屬會自動去把風險管理做好？因為，組織裏誤報的情形很嚴重，而且自我管理都有放水的傾向。 _{p. 221}

222 ~ 223 頁共列了九項指標，建議直接看書吧！這裡就不摘錄了。

這本書不厚，就像開場說的，為進入職場前沒什麼感覺，現在卻是收穫滿滿，推薦給軟體開發相關從業人員。