隨手扎
【心得筆記】與熊共舞
與熊共舞，這本書的筆記你會發現跟我之前寫的筆記方式有些不同。我對本書有很多感觸，也因此我更想好好的整理。但總拖著，本書我六月份就看完了，也做過一些初步整理，直至今日才來寫寫心得筆記，撰寫之初亦沒有把握這筆記能夠寫得我滿意。不管怎說，這件事總覺得應該做、必須做，有很多東西，也只有做了才知道。
書名：與熊共舞
讀完日期：2020/06/13
推薦指數：★★★★★
(如果你已經帶過幾次軟體專案，我推薦爆表)
關於與熊共舞
在筆記之前，還是得來吹吹這本書的地位。「與熊共舞」和「人月神話」、「最後期限」並列為軟體專案管理，歷久不衰的必讀經典著作，如果你是軟體開發人員，我會額外推薦你閱讀Bob大叔的「Clean Code」。
儘管我聽過「與熊共舞」和「人月神話」好一段日子，但是這是我第一次讀三本中的其中一本。「最後期限」更是本書推薦後我才知道，亦非常期待之後閱讀。
そか～在看其他東西，都忘了我自己還訂了這兩本書單。
本書的副標題揭露的探討的內容：「軟體專案的風險管理」。但我認為其中提到的風險管理概念，不只可以用於軟體專案，對於任何形式的專案都具有幫助。
風險的定義
專案有目標，沒辦法達成目標的潛在因此都是風險。但這麼說對於我這樣沒啥帶專案經驗的人而言，還是頗為難以理解，更別說怎麼去列出風險因子，並加以管理。本書提供了一些解決辦法，這也是我在看本書的重點之一。
那麼，什麼是風險？
所謂風險，就是還沒發生的問題；所謂問題，則是已經形成的風險。
昨日的問題就是今天的風險
歷史總是驚人的相似，透過過往相似專案所發生的問題經驗，就是未來專案的風險。這也是為什麼我推薦閱讀本書的人已經有帶過專案的經驗。就算是僅僅帶過2-3次小專案的我，在裡頭也感受到非常多的東西，但在閱讀本書之前，我害怕再帶新專案，逃避領導(儘管我本就不太喜歡做領導)。
五六個專案後，累積足夠的資料
是的，因為歷史總是驚人的相似，所以經過五六個專案後，會遇到的問題多數都遇過了(八二法則？)。另一種作法是從他人身上吸取經驗，本書提到一些常見的風險。
風險
不確定的臭名
「做錯事情沒關係，就是不可以不確定」
假如這條規則就是貴公司的寫照，那就慘了。
所有專案都存在不確定性，就是因為不確定因子存在，才可能導致專案失敗。確定的計畫，無須成為需要列管的專案。風險就是不確定因子，不確定完成時間、不確定成本、不確定效益，未來幾乎沒什麼是確定的不是嗎？但是：
不做沒風險的專案
「不入虎穴，焉得虎子」。風險與報酬總是焦不離孟，孟不離焦。
正式因為不確定、有風險，其才更存在價值不是嗎？如果想要甩開競爭對手，但所做的事情是輕易任何人都可以辦到的，那對手很快就會跟上來。以我自己學習的經驗上來說：「越容易學習的，越容易忘；越需要花時間理解、練習的，可以記一輩子」。
「沒有一個計畫在與敵人交戰之後還管用」
「沒有一個計畫在與敵人交戰之後還管用」
“No plan survives contact with the enemy”
– Helmut von Moltke 元帥
譯註:因為，無論怎麼計畫（預估），敵人是部會照著計畫與你開打
如果計畫不存在不確定，就無須進行專案管理。很可惜的是往往計畫趕不上變化。這也是進行風險管理的理由之一。
在程序背後，不確定性來源
具備十全十美的軟體交付程序，就可以排除專案中所有不確定性嗎？…我們認為答案是否定的
(Page.45)
作者列出了數項常見的不確定來源：
- 需求(requirement)
專案需求是什麼？ - 匹配(match)
如何與使用者與週邊系統互動？ - 變動的環境(changing environment)
開發期間，需求與目標改變的話，怎麼辦？ - 資源(resources)
專案進行時，哪些關鍵的專業技術是必備的？（若有需要，隨時就能派上用場） - 管理(management)
是否有足夠的管理天份？ - 供應鍊(supply chain)
能如期得到他方支援嗎？ - 政治(politics)
政治力是否可能為專案帶來效益、影響或是限制？ - 衝突(conflict)
不同利害關係人目標彼此衝突時，如何解決 - 創新(innovation)
專案最終成果的各種技術和方案有多麼獨特？ - 規模(scale)
跟去過去經驗，把份量和範圍擴大之後，對專案的執行績效衝擊有多大？
「我不知道」背後的涵義
你有必要把這些「我不知道」的問題弄清楚，因為那通常就是風險所在。
風險存在不確定因子裡，可是連有什麼不確定因此的話，又如何是好？
我也說過，這是我在閱讀本書的一個重點。除了參考別人經驗外，不知道的這一圈外，就是知道的部份。
對於我不知道的東西，我知道什麼（或我能知道什麼）？
近日更有些這樣的感覺。畫圖、學習語言、設計軟體、規劃生活、找工作，是阿！那麼多東西是我嘗試不知道的。從他人身上吸取經驗外，就是可以先淺淺嘗試一下，像是做個簡單的prototype，了解「我可能不知道」的部份。現在回頭想想，我的貪吃蛇小遊戲，就是在為下一個原本更打算做的計畫做準備。透過實踐、調查、反面補足，了解「我不知道」的部份，換句話說，我可以知道些什麼？
專案管理不可能確定每件事情，但是透過過去的資料，可以評估未來的可能性。
沒規劃到的事情
專案偏離時程，陷入泥沼，很少是因為工作比預期的更花時間，多半是為了處理原本沒規劃到的事情。
這或許也是「我不知道」的事情。也應該考慮考慮發生此情況時怎麼辦？
加總風險 & 成因風險
上述及之後提及的，和你自己所在管理的風險因子，都稱作 成因風險(causal risk) ，所有成因風險疊加就是 加總風險（aggregate risk） 。成因風險和加總風險都可以畫成風險圖。
寫在本節最後
風險的定義 ：
風險 n
- 一個可能有在未來造成意外結果的事件
- 意外結果本身
1是因，2是果，兩方面都很重要，但請不要以為自己兩方面都管理的很好。風險管理的事物，注重的就是成因風險(causal risk)的管理。
風險圖
所謂風險圖就是 不確定性圖（風險圖） ：一種平面圖，以橫軸列舉一組可能發生的結果，以縱軸表示每一種結果的相對可能性。
我們可以透過過去經驗知道一地的日照比例、降雨機率，其降雨可能導致某像專案受到影響，存在風險。其降雨發生機率就可以轉換為一個風險圖。
風險承擔
風險承擔(risk exposure)就是風險抑制成本的期望值(expectation)。
風險承擔=成本x機率
風險不一定會形成，其形成機率最為權重，與成本相乘就是風險承擔。所有成因風險的風險承擔，也就是加總風險的風險承擔，即是專案應該準備、管理的風險。
風險圖可以
是否做紓緩措施：透過風險圖分析，是否值得做紓緩措施？
可以透過風險圖分析，粗淺了解是否應該先做舒緩措施。舒緩措施是在風險發生前，提前所作的準備，也是一開始就砸下去的成本。透過適當的風險、利益、成本評估，可以做更好的管理。
蛻變指標的監控
而每一項風險，都應該有一個或多個蛻變指標加以衡量，並時常監控。並不是所有蛻變指標的出現都代表風險的形成，可能誤報。不容易誤報的指標可能可反應時間較短，所以在選擇蛻變指標時，必須在急迫性與誤報成本之間進行仔細評估。
卡車司機的座用名： 「每個滾動的球後面都跟著一位追逐的孩童」
(並不是真的每個滾動的求都代表有個孩童將要被你撞到)
寫在本節最後
風險圖不一定準確(不如說大部份應該都存在不確定)，也不一定有人看…
不過，就算除你之外，都沒人想看，用他來練習量化不確定性，也會很有收穫。
事先布局(set-piece)
現在大部份學生所學到的理論，大概只夠應付實務上的15%…
我得說我忘記當時記下這句的原因是什麼XDD。
進行風險管理的理由
一項工作延誤了，下一向工作又延誤，一直都趕不上進度，付出的巨大代價就是工作士氣。
Charette將這個世界、市場比於為一個逆行向下的風險電扶梯，在電扶梯的頂端有著可以操控電扶梯速度的按鈕。每個在電扶梯上的人都是你的競爭者，如果你不進步，也會自然倒退被追過，而最前面的人可以決定大家要跑多快才不至於落到電扶梯外（因為他掌握者那顆調整速度的按鈕），這也是領先者的優勢。
試想下你正駕駛著一台動力火車，在鐵軌前方冒出另一台火車的陣陣黑煙，預是著又另一台火車正迎面而來。你應該做相對應的處理，而非祈禱火車不會相撞。風險管理就是這麼回事，儘管不是每次通行都會有黑煙，但你應該時刻注意黑煙的出現（蛻變指標的監控）。
風險管理也就是這麼一回事。此外我也推薦閱讀本書的附錄那篇文章。有些風險無可避免，那麼進行風險管理究竟有什麼理由：
- 風險管理使積極的冒險變為可行
- 風險管理使風險不在成為禁忌
- 風險管理把不確定性侷限在一定範圍
- 風險管理提供最小代價的預防措施
- 風險管理可以避免全軍覆沒
- 風險管理擴大了個人成長的機會
- 風險管理可以防止盲目管理的發生
- 風險管理把焦點集中在真正需要注意的地方
- 風險管理使專案是為了成功而努力
一項工作延誤了，下一向工作又延誤，一直都趕不上進度，付出的巨大代價就是工作士氣。
不做風險管理的理由
「風險管理往往能提供超過你想要的更多事實真相。」
“Risk management often gives you more reality than you want”
– Mike Evans, ASC公司資深副總裁
儘管本書的筆記，以及本書的重點都不是不要管理風險。但姑且也記下筆記：
- 有些組織不顧一切地相信可以控制一切，即使心知肚明這並非事實，還是慣用控制的假象來蒙蔽現實。最常見的特徵，就是一開始弄出一個精確到令人可笑得預估結果（一個非常小的不確定範圍），事後證明它跟事實差了十萬八千里。
有點像不確定的臭名。
缺乏能有效管理風險所需的資料
如果你也是因為這樣而不做風險管理，建議你回頭重看下風險的定義，或是去購買本書來看看。
如何管理風險
就算最完美的開發程序，也無法把一個複雜系統開發專案不確定性統統排除掉，只要有不確定性，最會有風險，只要有風險，就有必要付出心力進行理性、周詳的管理。
風險活動不等於擔心
如果只是一昧的擔心就可以做好風險管理，這就不會成為一門學問。因為風險是可能導致專案失敗的原因，故必須做管理，當然也有一種應對方式是甚麼也不做，直接承擔風險(逃避evade，對於風險，你有4種處理辦法)，但這不是什麼好主意。
要做到風險管理，就必須認識到有什麼風險（風險探索）、風險可能造成的影響與程度（承擔分析）、如何應對（應變規劃）、是否應該準備舒緩措施，並且持續監視風險的形成。這些是風險管理的主要活動，你也可以直接看看風險管理基本步驟
風險管理的主要活動
- 風險探索(risk discovery)
- 承擔分析(exposure analysis)
- 應變規劃(contingency planning)
- 舒緩(mitigation)
- 蛻變的持續監視(ongoing transition montoring)
不知道的東西就是不知道，怎麼可能把這種東西量化？
- 五六個專案後，累積足夠的資料。
- 先分析已經知道的部份
- 做點小嘗試，評估不知道的部份
致命風險與專案前提
有時候風險難以評估，因為它們的成本是……所有一切！一旦這些風險形成，不管做何處置，一切都玩完了。致命風險非常特殊，對待的方式也不太相同，他只能夠透過專案前提(project assumption)來管理。
從不同層級上來看風險，可能會有不同觀點。在開發上可能完全無法解覺得技術問題，在營運層面有可能有辦法繞道。有些風險屬於不必管理的風險。
對於風險，你有4種處理辦法
- 迴避(avoid)
不執行專案或部份專案，同時也捨棄完成專案帶來的效益。 - 抑制(contain)
風險發生時，投入的應對措施。 - 紓緩(mitigate) / 轉嫁
風險發生前，降低其發生可能性，或是發生後造成的影響。 - 逃避(evade)
不處理風險，直接承擔風險造成的影響。
風險管理基本步驟
- 風險探索，找出專案面臨的風險，彙整成風險調查報告
- 確定軟體專案的主要風險都已經納入風險調查報告
- 針對每個風險，完成以下事項
- 為風險命名，並賦予唯一的編號
- 進行腦力激盪，找出風險蛻變指標–能夠有效及早預告風險即將形成的事物。
- 預估風險形成對成本和時程的衝擊
- 預估風險形成的機率
- 計算時程和預算的風險承擔
- 預先決定一旦風險蛻變則必須採取的應變行動。
- 敲定為有效執行應變行動而必須預先進行的舒緩措施。
- 把舒緩措施納入專案計畫
- 把所有季節紀錄在一份類似附錄B的制式文件內(附錄B是風險監控範本)
- 指出做為專案前提的致命風險(showstopper)，尋一般正式管道把這些風險往上報
- 假設 不會有任何風險形成 ，估計最早的完成日期。（找到奈米機率日(nano-percent date)）
- 下載 RISKOLOGY。在主工作表上輸入專案參數，盡量客製化，最好從周遭環境、歷史紀錄中找出更可靠的資料，替換預設的業界核心風險數據。如果還追蹤了其他非核心風險，也為它們補上自訂的工作表
- 參考自己或業界的不確定係數
- 利用風險圖比紹所有的承諾，凡是跟規劃日期和預算有關的不確定性也統統明確標示出來
- 建立工作分解結構(WBS)，展現必須完成的工作，不管用什麼方法，把每項工作要耗費的心力都預估出來。這些預估值的用法與傳統的不同：只關心相對權值(weight)，不在乎它實際的值，相對權值將用來計算EVR
- 專案一開始，再難也要敲定淨輸出入資料流定義–要律定到資料元素層級–在專案時程前12% ~ 15%就該搞定，把淨資料流的簽署視為重大里程碑，通不過，後續工作就不要做。記住，這是一個完工量測指標，簽署不成便是一項致命警告
- 再難也要在進行任何實作前做好設計切分，再根據切分結果建立漸進交付計畫
- 設計切分完成後，再把工作分解結構拿出來，重新預估各項工作的權值，以佔剩下未完成工作的百分比來表示
- 以跟成本評估一樣的精確程度來進行價值評估
- 把規格裡的需求細分到最基本的等級，根據對使用者的價值、技術風險這兩項評斷標準，進行優先順序排定
- 建立漸進交付計畫，把產品切成很多版本(多到每周至少一個版本)。按照越優先、越早交付的方式，把所有基本需求配置到各個版本。算出每個版本的EVR，記錄在這份計畫中。把漸進交付計畫當作專案的必備文件
- 建立產品總驗收測試計畫，切分成VAT，為每個版本都安排一個VAT
- 把每個版本的EVR和預定交付日期標示出來，當通過VAT時，把實際結果一併標示在同一張圖上
- 至此一直到專案結束，監視所有風險，注意是否蛻變或解除，一旦成形，便立即啟動應變計畫。注意EVR降落航道，若發現偏離，便是風險出現的徵兆
- 在專案進行時，持續風險探索程序，以對付叫晚才浮現出來的風險。
部份參考 《與熊共舞：軟體專案的風險管理》筆記
風險探索
- 災難腦力激盪
- 以惡夢的形式把問題明確描述出來
- 運用預言
- 切換眼前景象
- 談談不必追究責任的災難
- 談談值得追究責任的失敗 (當確定大家都進入狀況後才有效)
- 想像一下部份失敗的情況
- 情境建立
- 根源分析
軟專的核心風險
- 先天的時程錯誤(schedule flaw)
- 需求膨脹(requirement inflation)（沒完了的需求變動）
- 人力流失(employee turnover)
- 規格崩潰(specification breakdown)
- 低生產力(poor productivity)
成本與報酬都必須律定同樣精確才行。
計算報酬的五個要點
- 開發人員公佈的成本與利害關係人公佈報酬精度要相當
- 成本如標示出不確定性與報酬也應當標示出不確定性(19章節)
- 利害關係人必須評估各系統組件的價值，以利進行版本選擇、敏感性分析(sensitivity analysis)、以及漸進式成本報酬分析(20章節)
- 管理階層在評量專案時，必須根據報酬、成本、以及兩者的不確定性，兩兩仔細比較(21章節)
- 事後，管理階層必須評估報酬實現，並把結果做為事後檢討程序的輸入資料。
版本交付的3項警告
- 這個方法要行得通，必須充分發揮漸進式實做(incremental implementation)，而且要先敲定每個版本的功能。若你只打算交付兩、三個版本，畫出來的不確定性圖就幾乎沒有意義。若很晚決定各版本的功能，使用者也無法評估那薛功能有危險。
- 小心專案表面上是不變得期限(fixed deadline)，但骨子裡完全不是。
- 假如在不變的期限之前，連交出一個本本的可能性都很小話，採用漸進法也無濟於事。
風險管理的測驗
風險管理需要以客觀方法了解是否落實。因為，組織裡誤報的情況很嚴重，而且自我管理都有放水的傾向。
死亡行軍
- 死亡行軍的第一個共同特徵，就是預期價值很低。專案鎖定的目標是非常沒又意義的產品，由於價值很低，若按一般正常專案來處理，成本會明顯高於報酬。 只有超人才可以讓這隻豬飛上天 。
- 第二個特徵，就是員工成了冤大頭。騙他們犧牲小我，完成大我，使他們相信，用這麼點代價卻只能帶給家庭那麼一丁點好處也值得。
- 第三個特徵，專案最後都出盡洋相。糗大了，只做出一點點東西，或什麼也交不出來，每個人都覺得很窩囊、很不爽，覺得應該有更好的做法才對。
其他風險管理的參考
- 就整個軟體產業來看，不確定範圍大多是介於150%~200%之間
- 每月合理需求變更<1%
- 功能特點估算法(function point)
- 生產模型
- 協定資料流到資料元素(data element)層級
其他未列之項
本書作者Tom和Tim在裡頭也寫下不少有意思的話。
TRL：雖然我對你手邊的案一無所知，但我趕打賭，時間到了你還是做不完。畢竟，超過半數的專案都會延誤，或超出約定期限才完成。
TMD有更多我覺得可以筆記下來的：
不必管理的風險
- 風險形成的機率微乎其微，小到可以忽略。（ex: 隕石砸下）
- 一旦形成，投注在管理上的心力，都不再要緊。
- 萬一真的形成，我們也無能為力
- 風險的影響很小，沒有任何舒緩的必要。
- 這是別人的風險
這些就是 專案前提。(當然有些不需要列)
賽車手的終點線
Page. 78
這一頁多的小故事看完後，我想：「我不是賽車手，更像PM」。
雙贏螺旋程序模型
Page. 160
在雙贏模型，專案要開誠佈公地邀請所有利害關係人，就自身的觀點來思考專案成功的贏取條件（win condition）。這套方法中，需求被定義成一組贏取條件；除非被某人確認是贏取條件，否則不會被納入需求當中。
有時，這些條件可能會彼此衝突，尤其當利害關係人較多的時候。這時，造成衝突或對立的贏取條件就是風險
其他裡的其他
- 蒙地卡羅取樣法(Monte Carlo sampling)
- 軟體開發人員應該學著相信「少開發一點軟體」，這很古怪，但名顯示比較好的作法。(事先布局)