風險管理的部分大部分科技業會用所謂的NUDD 或是風險矩陣的方式合併Lesson Learnt的方式做處理 但這都是屬於專案前半，執行中發生的任何意外就不是風險，而是危機管理 危機管理的部分通常這類的突發狀況經常性的會連帶到能見度問題 專案管理人員的能見度除了在滅火這件事情外 還有在關鍵時刻比你手頭能處理問題的手法多寡 多寡這回事，不外人事時地 人脈，是否有過往的事件可參考，讓子彈飛，是否別的地方會發生或可以解決 牽扯到的就是整個Solution如何去編織的問題 通常這類問題的報告結構是這樣的 第一頁 開宗明義的先簡略檢視一下問題 問題肇因跟影響範圍 還有可能或是你比較推薦的解法 而至少提出幾種的備案，舉個例子 一種是快，但可能有風險或是費用比較高的 第二種是最慢省錢，但確定是最安全的 通常比較合適的是公司或是部門有Risk Buy而大家都能接受的。 最後才是技術細節，除非老闆是技術控，不然不需要浪費時間 只要跟相關的人等確定沒有問題，有得到背書後在上面提一下就好 通常老闆都會選最快解決問題的方式 但你要把裡面的細節、資源、跟系統風險講清楚 最後在開會的時候如果老闆要求那就以Meeting minutes做總結並核實方案資源 我個人的做法: 通常會有一個樣板，連帶方案跟架構怎麼寫 如果遇到這類Case就把剛剛提到的相對資訊全部填進去就可以 老闆只想知道問題能不能解，至於怎麼拆炸彈 那是要讓老闆買單前你自己得搞定的問題。 不過這種做法，就會讓某些只想抽水的人覺得你很油條難搞就是。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.24.129.7 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/P_Management/M.1685551873.A.B54.html