风险管理的部分大部分科技业会用所谓的NUDD 或是风险矩阵的方式合并Lesson Learnt的方式做处理 但这都是属於专案前半，执行中发生的任何意外就不是风险，而是危机管理 危机管理的部分通常这类的突发状况经常性的会连带到能见度问题 专案管理人员的能见度除了在灭火这件事情外 还有在关键时刻比你手头能处理问题的手法多寡 多寡这回事，不外人事时地 人脉，是否有过往的事件可参考，让子弹飞，是否别的地方会发生或可以解决 牵扯到的就是整个Solution如何去编织的问题 通常这类问题的报告结构是这样的 第一页 开宗明义的先简略检视一下问题 问题肇因跟影响范围 还有可能或是你比较推荐的解法 而至少提出几种的备案，举个例子 一种是快，但可能有风险或是费用比较高的 第二种是最慢省钱，但确定是最安全的 通常比较合适的是公司或是部门有Risk Buy而大家都能接受的。 最後才是技术细节，除非老板是技术控，不然不需要浪费时间 只要跟相关的人等确定没有问题，有得到背书後在上面提一下就好 通常老板都会选最快解决问题的方式 但你要把里面的细节、资源、跟系统风险讲清楚 最後在开会的时候如果老板要求那就以Meeting minutes做总结并核实方案资源 我个人的做法: 通常会有一个样板，连带方案跟架构怎麽写 如果遇到这类Case就把刚刚提到的相对资讯全部填进去就可以 老板只想知道问题能不能解，至於怎麽拆炸弹 那是要让老板买单前你自己得搞定的问题。 不过这种做法，就会让某些只想抽水的人觉得你很油条难搞就是。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.24.129.7 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/P_Management/M.1685551873.A.B54.html