编辑导语：任何项目都存在或大或小的风险，而项目的成功与风险的控制与预防有很大的关系。本文作者总结了自己在阿里的项目管理经验，为我们进行了分享，看看风险管理这场实战如何才能打赢。
互联网公司的业务成功离不开一个个大大小小的战役和项目的成功交付，而这些战役和项目成功交付的一个重要前提就是对风险进行了有效的管理。
对于项目管理者来说，交付项目的过程犹如在大海中掌舵航行，除了规划好既定的路线，而管理风险就好比是在整个航行过程中，能提前规划好风险的应对策略和方案，及时发现航路上的暗礁和突如其来的风暴，有条不紊的采取预案措施，提升项目交付的成功率。
一、“项目风险源于任何项目中都存在不确定性”
互联网项目处在变化越来越快和复杂的环境里，更多的一些则处在高度竞争的红海中，更有一些跨境的业务场景。
因为法务，合规，国际形势等多方面的因素，都增加互联网项目的不确定性和复杂性，用VUCA这个词（中文发音为“乌卡”- 20世纪90年代起源于美国军方，是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的缩写）来形容今天的项目管理者要面临的局面再贴切不过。
此外项目的一个重要特征就是不确定性，VUCA的内外部环境和一些项目本身的创新要求也不断加剧了不确定性和风险的产生。
二、什么是风险？
风险：造成项目目标无法达成的可能性及其产生影响大小（可能性 x 影响大小）的事件或条件。
需要注意的是风险来源于不确定性，所以风险其实是一个一体两面的概念，一面叫威胁，另一面叫机会。所以好的项目经理在面对风险的时候，不仅要能够转危为安，更有佼佼者能够做到转危为机，把一个风险转变为对项目交付有利的因素或机会。
三、互联网项目风险来源
这里提及的项目风险仅仅是列举出来了一些典型的可能的共性风险来源，不同公司，不同的业务形态，组织阵型和产品技术特点会有不同的风险来源，需要一一识别，并把这些风险来源作为组织的资产输入到新的项目以帮助提升对风险认知和识别能力。
四、风险应该由谁来识别上报？
在互联网公司的战役（项目集）和项目交付过程中，会有两种较为典型的交付方式，一种是有项目经理进入战役和项目，直接承接项目管理的相关工作，另一种是由产品或技术同学来兼任项目经理。
但无论是由专职的项目经理来管理项目，还是兼职的项目经理，风险的识别和上报都应该是一种全员行为，而不应该是单个个人。
还是拿航行来做比喻，每个船员在船上各司其职，一旦有人发现了船体本身可能触礁或者漏水，发现者都应该第一时间，主动进行风险事件的上报。以风险管理为中心，以全员参与为基础才有可能最大程度的预知风险。
风险由项目所有成员识别。识别到风险事件的项目成员需在识别到风险事件的第一时间，主动进行风险事件的汇报（形式不限）。
构建风险处理的中枢：
- 在实际的项目管理过程中，有项目经理投入的战役/项目，以项目经理为风险管理的中枢；
- 在无项目经理投入的战役/项目中，构建风险管理的“铁三角”：产品、技术、测试负责人，为风险管理的中枢。
五、风险上报应该包含哪些内容？
一个完整的风险上报内容应该包含如下内容：
- 风险编号：ID
- 风险描述：风险的背景，引发风险的原因等
- 风险类型：属于范围/成本/质量等方面的风险
- 风险发生的概率：高中低
- 风险影响评估：高/中/低
- 上报人：谁进行的风险上报
- 风险应对措施：采取怎样的措施来进行风险的应对处理
- 风险应对措施负责人：谁负责解决该风险
- 预期解决时间：预计应对措施实施的完成时间
- 当前进展：进行中，处理中，已关闭
- 备注：其他备注信息
实践过程中，我们抽象出风险上报的核心要素来简化为来降低全员理解和上报风险的成本。
风险上报内容包含：
- 风险描述
- 风险发生概率的评估（已发生 / 发生的可能性）
- 风险影响评估（事件发生带来的结果、对上下游依赖事件的影响、对项目交付影响的初步评估）
- 风险应对措施（可选）
这些上报上来的风险通常会有如下一些问题，比如风险描述不够准确，评估不够量化和定性，临时的处理措施不一定非常恰当。
还有一些属于局部可能的延期风险，但在局部负责同学的眼中可能就是一个高风险，但并非在项目交付的关键路径上，对项目里程碑等关键节点也无影响，也可能会造成对风险的优先级定义不准确，一定程度称为风险信息噪音；
所以在风险上报上来之后，项目经理和项目铁三角在风险上报后进行的应对驱动，对于非疑似风险问题进行筛选，同时对于风险事件描述和影响评估的准确度进行评估。并最终根据根据风险发生的概率和对项目整体交付造成的影响对风险定级，并制定对应的应对处理措施。
六、风险定级和定量分析
风险的定级一般通过概率和影响矩阵来判断和分析，在一个较大的团队范围内，为了方便全员对于风险有一个清晰的定级，我们简化为一个3X3的风险等级矩阵，并且用一些易于理解的概率和影响描述来加深理解，建议在实施的过程中，增加一些实际的案例加深认知。
下面我们来看两个风险案例：
1. 风险案例一
1）引发风险的原因
- 测试人员总共5个人，主要负责功能A和功能B功能测试；
- 2个测试同学需要在下周一参与临时高优先级项目保障，影响本项目测试投入15人日；
- 综合a和b条件，业务功能测试工作量共55人日，根据项目提测时间，只能覆盖25人日（在加班情况下），但仍存在有30人日测试缺口。
2）对关键时间节点的影响预估（可能对关键时间节点的达成造成X天的延期等）
基于现状测试资源情况，当前只能确保“功能A”在既定发布时间上线。功能B无法确保在8月20日发布上线，按现有人力重新预估发布时间需延期至9月10日。
这是一个定性和定量详细分析风险事件的例子，该风险评估为高风险（发生概率非常大，影响程度很大）。
2. 风险案例二
【XXX项目】XXX领域技术人员5月30日之后才能投入，会造成项目延期。这个风险上报非常模糊，不明确的人员投入缺口，模糊的项目影响，以至于看到的时候没法准确评估该项目的风险等级。
定性和定量分析是一个风险解决的一半，只有定性定量对关键里程碑和项目目标的达成影响才会让项目利益相关方有体感和触动！制定应对措施才会有的放矢。
七、如何应对风险？
1. 对风险应对措施的持续跟踪管理
首先要明确的是风险应对措施一旦制定出来，那么对于风险应对措施的结果就要进行持续的跟踪和回溯。
因为当下制定的风险应对措施不一定是能够缓解和解决风险问题，这也是风险应对过程当中的不确定性造成的。如果发现当下的应对措施并没有有效缓解或解决风险的发生，就需要及时思考更多的对策。
2. 建立风险的上升机制
在项目初期，和项目团队约定风险的上升机制会让你在风险升级的过程中不脚忙手乱，也能找到对应的更高阶的处理人及时介入。
3. 调整应对风险的心态
1）修正免责心态
在一个矩阵或是项目制的组织结构中，很多项目的负责人在风险应对过程中的心态是免责，风险上报，采取了一些不痛不痒的措施就万事大吉了。风险应对的的目标是缓解或者解决可能产生的风险，一定是在期望解决的时间得到既定的措施实施。
2）英雄主义心态
风险应对从来都不是一个人的是事情，一些同学习惯于自己独自应对风险或问题，但当这个风险无法解决或者单凭个人无法解决的时候，已经需要投入更多的人力和成本去解决了。英雄主义，单兵作战都是不可取。
4. 听取其他项目成员的意见
他山之石可以攻玉，在一个较大的组织内，有很多坑或者是风险是其他团队已经趟过一遍的了，不管你知道不知道，经验就在那里，需要把视野打开，去听取更多外部的建议。
5. 实时的沟通和同步
在项目交付过程中，和相关的干系人保持好及时的沟通和同步，尤其是一些高危风险出现时候，沟通和同步的频次都需要增加。
一般的原则是：
- 高危风险的处理结果和进展每日进行核心小组同步；
- 中低风险的处理结果和进展每周或项目例会上进行同步；
八、总结
祝愿每个在带领项目前行的“船长”们都能如约交付，安全抵达。
本文由 @拾初 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。