10 | 风险管理：冰山下的风险，如何系统化应对？

旧上司曾经说过：不上线的项目说明不了任何技术问题。 前几周对外测试开发了大半年的项目，各种异常和警报不断，正是这篇专栏所提及的风险管理不足的问题。我认真浏览了 风险清单，逐一对照后，发觉项目和团队都存在很多的bug。昨晚临时开会提出了内部沟通问题，今天看了清单，觉得得马上再开一次会。泪崩... 最近算是不断地吃了缺少项目管理经验的亏，今年的开发经历还是让自己成长了很多，在年末可以有蓓蓓姐的专栏辅助整理一年的经历，非常幸运。 现在项目的风险很多： 1、沟通成本过高； 2、人员默契不足，太新； 3、工作流程没被完善和强调，很多问题依靠核心人员的决策而不是流程自动驱使人员去闭环一个个的问题； 4、技术问题上：作为负责人技术构建的框架过于灵活，导致学习成本高，代码审核的难度过大，应该限制灵活性，强调规范。 5、发布工具不足，人手操作，容易手抖。 .... 简直是太多了，项目确实出于危急的状态，希望最后一切能够顺利度过

关于团队内部风险的收集，团队氛围很重要，开放的心态，公开透明，这样才能畅所欲言。 外部风险主要来自需求的变化，需求分析，验收标准，运营数据，持续反馈，提高需求的质量才是根本。

项目中有遇到过需求考虑不充分，调整某一块的功能时，未考虑其它模块，需求评估测试不充分，着急上线，导致某个需求上线后其它模块一堆问题 风险识别最重要的还是做好与项目干系人沟通，做好需求评审和项目上线前的代码评估

蓓格格,你好,在文中你给出了风险评级,但是风险指数如何计算呢? 例如 成本等. 我对今天风险管理的理解: 风险管理有点类似 软件开发过程中最佳实践 -- 问题越早暴露越好. 对于上级来说早知道总比晚知道要好, 对于下级来说早汇报也比晚汇报要好, 至于说担心被BOOS或上级认为自己能力不足? 这一点在我看来完全是不必要的担心,因为就算你隐瞒不报,那么问题还是问题.它还会在哪里,并不会消失不见. 与其寄希望与在别人发现它之前改掉,倒不如提前汇报上去,然后加紧改掉 如此就算万一你在规定时间内没有完成整改导致问题爆发,那对于上级来说他也早有准备. 如果你在规定时间内规避掉了风险,那么上级说不定会对你的能力高看一层

风险管理源自何处？好的监控才能做好风险管理。 我们经常说系统风险。。。风险各种风险，可是任何事情都是有风险的，其实对于风险我们应当如下方式去看待：首先应当确认它有多大的风险，其次对于风险有哪些监控措施/预防措施，最后风险发生了处理风险的流程是怎样。只有整体且全面认识风险，我们才能处理好风险。 以上是个人对此的一些薄见：期待老师下次的分享。

看到风险管理这一课，真应该好好再回顾一下项目干系人这一课，落实好清楚了解发起人对项目真正诉求这点上，就已经能暴露出不少项目风险。

我当前参与的一个项目主要风险如下： 1、不可控因素太多，功能集成和需求设计严重依赖其他部门； 2、项目发起人始终不知道自己想要的产品是什么样的，每次询问，就说让开发自己去想； 目前主要风险识别途径： 1、组织“吐槽大会”； 2、找一两个小伙伴小规模沟通； 3、每日困难反馈。

原来风险管理里填写的内容，我一直不知道怎么填写，写的都是自己因为可能会影响项目进度的事件，虽然填写的都是正规风险管理的表格，听完你的课，感觉自己写的不够饱满、没有层次、不够系统。回头再有机会写的时候，我会回来复盘的。

其实只要不是关系生命安全的领域，风险管理的与追求利益和交付往往更重要。 并不是风险管理不重要，而是团队里很少有人对“风险管理”这件事有深入的了解和思考。 先明确风险管理的范围，就是要管理可控的风险，什么是可控的？可控的就是系统中发生的。而不可控的事系统外，比如政策、市场、竞争对手等等。 总之，我认为PM先要对系统中的风险进行梳理，评估概率和影响，制定应对措施，形成风险登记册，并在项目过程中持续更新风险登记册，总结经验。

识别各个干系人，让我想到了以前在做项目的过程中，有一个大牛跟我说过，在干系人中哪一类的人是最需要被关注的。一定是那个对你项目会造成阻力的人，是需要被特别关注的。因为他有可能会使你的项目失败，所以说这类的人要特别进行管理是一个系统性风险。