2011年4月3日 星期日

讀書筆記 - 與熊共舞

第1章 擁抱風險
  • Charette的風險電扶梯
  • 假如對某個風險拿不出辦法,他就會把它忽略掉。 (錯誤)
第2章 風險管理是成年人的專案管理
  • 暫時性定義: 可能會造成意外結果的事物就是風險
  • 風險管理的事務,著重的就是成因風險(causal risk)的管理,亦即你能管理的部分。
  • 所謂風險,就是還沒發生的問題;所謂問題,則是已經成形的風險。
  • 風險探索 - 承擔分析 - 應變規劃 - 紓緩 - 蛻變的持續監視

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

沒有留言:

LinkWithin

Related Posts with Thumbnails