第1章 擁抱風險
- Charette的風險電扶梯
- 假如對某個風險拿不出辦法，他就會把它忽略掉。 (錯誤)
第2章 風險管理是成年人的專案管理
- 暫時性定義: 可能會造成意外結果的事物就是風險
- 風險管理的事務，著重的就是成因風險(causal risk)的管理，亦即你能管理的部分。
- 所謂風險，就是還沒發生的問題；所謂問題，則是已經成形的風險。
- 風險探索 - 承擔分析 - 應變規劃 - 紓緩 - 蛻變的持續監視
- 事情做錯沒關係，就是不可以不確定 (錯誤)
(不正視的風險帶來的不確定性) - 在事後為延誤請求原諒，但是不可以在事前要求認可 (錯誤)
- 選擇性短視症 (大家都很小心不讓自己被枕木絆倒，卻沒人發現越來越近的火車)
第7章 運氣
- 一般的通病就是全部的風險都在賭運氣
- 風險管理是要你在規劃專案時，把焦點放在一旦某些機會沒有抓住的話該怎麼辦。
- 做軟體的案子，把失敗的可能性限制在一定範圍內，一般來說，是比追求勝利更重要的事。
第8章 將不確定性量化
- 「把最早講出來的日期訂為最後期限」，基本上就保證到時一定跳票。
- 把不確定性明確標示出來，你便敢放膽冒險。
- 不確定範圍要多大才算合理，取決於組織開發程序中干擾(noise)或變異的多寡，而非某個人的感覺。
- 不確定範圍大多是介於N的150%~200%之間
第9章 風險管理的技巧
- 從專案經理的角度，他所認知的計畫就是一群一定要完成的工作
- 專案偏離時程，很少是因為工作比預期的更花時間
- 「昨日的問題就是今日的風險」 (認知到問題會一再重複出現的本質)
- 把事後檢討的輸出結果當作風險管理的輸入資料
- 迴避風險 - 放棄報酬
- 抑制風險 - 額外準備足夠的時間和金錢
- 紓緩風險 - 降低抑制成本，在風險成形之前採取措施
- 逃避風險 - 祈求老天保佑
- 沒有任何合約可以把全部的責任統統轉嫁給某個單位，不論是客戶，還是承包商，都必須做好某些風險管理
- 風險承擔=成本x機率
- 致命風險 - 確保致命風險不會發生
- 蛻變指標 - 每個滾動的球後面都跟著一位追逐的孩童 (卡車司機座右銘)
- 在專案進行時，持續風險探索程序
- 沒有人會為一個完成可能性保證有75%的目標全力以赴，也沒人會為一個完成可能性大概是零的目標全力以赴
- 規劃專案時程時，把承諾日期和挑戰性目標分開來訂
- 時程 > 目標 > N
- 如果交貨日期完全不能改，改用版本漸近的方式
- 專案在表面上是不變的期限，但骨子裡卻完全不是
- 想平安地公開風險調查報告，除非大家都一起公開
- 把這些「我不知道」的問題弄清楚，因為那通常就是風險的所在
- 「對於我不知道的東西，我知道什麼 (或我能知道什麼) ？
- 不確定性圖 n: 一種平面圖，以橫軸列舉一組可能發生的結果，以縱軸表示每一種結果的相對可能性
- 每個成因風險都是用一張風險圖來描述
- 把一組成因風險轉化為加總風險
- 透過生產模型來預估 N值 (軟體規模參數和技術因素)，再利用風險模型標出不確定性，得到加總風險圖
- RISKOLOGY http://www.systemsguild.com/riskology/
- Monte Carlo sampling
- 五個軟體專案常見風險(先天的時程錯誤、需求膨脹、人力流失、規格崩潰、低生產力)
- 時程錯誤: 專案規模高估的部分，通常都不足以抵銷低估的部分
- 大部分的核心風險都跟團隊績效低落無關，時程錯誤也一樣
- 真正表現不佳的，可能是提出或承諾錯誤時程的管理者
- 開發軟體多半是為了滿足某些人的事業領域
- 被掩飾的問題暫時消失不見了，但不會永遠消失不見。
- 閉口不談風險，也不會讓風險消失不見
- 組織不準大家談論風險 甚至變成一種不成文規定，而成為組織文化的一環
- 需要一個開放、固定、能被諒解的程序，好讓負面言論有說出來的可能
- 風險探索儀式必須讓人很放心地分享恐懼
- 災難腦力激盪 -> 情境建立 -> 根源分析
- 持續監控蛻變指標
- 持續進行風險探索
- 蒐集資料，充實風險庫
- 每天持續追蹤完工量測指標
- 完工量測指標(邊界元素敲定、實獲率)
- 最佳投資收益比的風險紓緩策略就是漸進式交付
- 大部分專案的做法通常都是被動的，這種被動做法完全得不到漸進式的好處
- 假設產品的每個部分都一樣重要，這種謊言充斥於許多專案
- 如果系統有個部分必須仰賴技術上的突破才能完成，就該把它納入早期版本
- 漸進交付計畫(設計藍圖、工作分解結構、一組版本驗收測試)
- 一個版本就是設計藍圖的一個子集
- 能被版本驗收測試證實完成與否的工作才歸屬到同一個版本
- 組織裡的傳統觀念 - 認為建立專案時不預留任何緩衝餘地就是真正勇敢的管理
- 起步太晚是喪失遠見與勇氣的象徵
第18章 價值的量化
- 精確成本和糢糊報酬造就出不倫不類的成本報酬分析，便無法判定風險值是多少，結果，看來只有規避風險最適合
- 成本和報酬都必須律定得同樣精確才行
- 開發經理接下專案，便有義務提出明確的時程和成本預算
- 利害關係人也必須1
- 為預估報酬和實際報酬負責，報酬量化和成本量化的精確程度必須相當
- 若報酬一點量化數據都沒有，就假設是零
- 矯正的時刻：我們無法精確指定報酬的45,328個理由
- 雖然軟體最大的風險要不就在技術(產品方面)，要不就在人為(專案方面)，但是，公司最大的風險卻是在價值方法：把功夫浪費在低價值專案而錯失高價值專案，所 耗費的機會成本
- 冒險的積極程度必須由報酬來驅動
第19章 價值也一樣不確定
- 畫不確定圖
- 只要大一點的風險，都是以價值為核心
- 沒有價值評估，結果就只會是個意氣用事的決策
第20章 敏感性分析
- 想個巧妙的辦法來增加利害關係人負的責
- 價值是非常不平均地分佈在系統中
- 軟體開發人員應該學著相信「少開發一點軟體」
- 系統專案呈現規模不經濟的特徵 (系統規模增加為2倍，則預料系統開發耗費的心力會超過2倍)
第21章 值不值得冒險
- IT產業：報酬小，就要冒更多險，不然我們怎麼可能把成本壓低到讓專案不賠本？
- 死亡行軍專案：這次的任務實在太重要了，重要到全體專案人員最後一滴血也要搾乾。
(既然這個專案有那麼重要，為什麼公司不願分配合理的時間和金錢來做呢？ - 死亡行軍專案特徵：預期價值很低、員工成了冤大頭、專後最後幾乎都出盡洋相
- 真正的專案評量需要在風險和價值之間取得平衡
