書摘《與熊共舞》

閱讀時間約 13 分鐘


這本與《人月神話》都是軟體工程領域知名的書籍,曾從學校圖書館借來看過,但說真的,還沒進入業界,其實很難體會風險是什麼?但... 在業界打滾幾年後,再次回來看這本書時,你會發現風險... 不好說 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 頁共列了九項指標,建議直接看書吧!這裡就不摘錄了。

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

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
《鳳凰專案》讀後感
閱讀時間約 6 分鐘
書摘《約耳趣談軟體》 下篇
閱讀時間約 14 分鐘
《人月神話》讀後感
閱讀時間約 3 分鐘
書摘《約耳續談軟體》 上篇
閱讀時間約 17 分鐘
書摘《約耳續談軟體》 下篇
閱讀時間約 15 分鐘