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