之前的文章中，我们从“问题”和“课题”的区别出发，讲解了课题管理的推进方式。这次作为续篇，将以“风险”和“问题”的区别为主线，清晰地解说风险管理的第一步。

有没有这样的烦恼？

• “风险”是否指所有看起来危险的事情？
• “风险”和“问题”有什么不同？
• 到底应该从哪里入手呢？

阅读本文，你将：

• 能够清晰地理解“问题”和“风险”的区别。
• 理解为何将其视为“风险”并进行管理很重要。
• 学习到可从明天开始使用的风险管理的基本推进步骤。
• 你的项目运营将增添“预见能力”。

让我们一起掌握把“模糊的不安”转变为“具体应对”的技能吧。

作为热身，请想象这样一个场景：在厨房做饭时，你可能不慎将一颗珍贵的生鸡蛋掉落。

• 【A】将鸡蛋从厨房台面掉到坚硬地面上
  在这种情况下，鸡蛋被摔在地板上碎裂几乎无法避免。

• 【B】将鸡蛋从砧板上掉入水槽
  在这种情况下，鸡蛋有可能破裂。
  但落差较小，也许幸运地只会产生裂纹而已。

那么，哪个更适合作为**“风险”**呢？

回答与解说：

答案是 【B】。

风险是指伴随**“不确定性”**的事件。
【A】几乎必定会导致不良结果，更像是“应该避免的危险行为”或“问题”，因此与风险不同。

而【B】则存在“可能发生也可能不发生”的不确定性。
它正是针对未来事件的预防，也就成为风险管理的对象。

通过思维实验，你是否体会到“不确定性”是关键呢？
那么，让我们再次确认“问题”和“风险”的定义，并整理它们的区别。

问题是指“理想状态”和“现实状态”之间的差距，是已经发生的棘手状况。

例如，交期延误或缺陷暴露等已显现的故障，都属于“问题”，需要立即应对。

风险是对目标造成“不确定性”影响。（ISO 31000 / PMBOK®指南）

如图所示，即使看似顺利，也存在“可能无法取得成果”的下行偏差可能性。
这就是风险的概念。

也就是说，将“尚未发生但可能发生的事情”可能对目标产生负面影响的情况称为风险。
※本文主要聚焦于带来负面影响的“负面风险”。

已显现的“问题”通过课题管理进行应对，尚未发生的“风险”则由风险管理来处理。这是基本原则。

当你犹豫“这是风险、还是单纯的担忧，或者是问题”时，可参考以下判断流程图。

graph TD
    A[正在研讨的现象・状况] --> Q1{1 该现象・状况是否有可能影响项目目标？};
    Q1 -- 否 --> NNotRisk1[<u>不是风险</u><br/>（或影响轻微）];
    Q1 -- 是 --> Q2{2 该现象・状况是否为尚未发生的【未来】事件？};
    Q2 -- 否 --> Issue[<u>不是风险</u><br/>如果已经发生则属于问题，应通过课题管理进行应对。];
    Q2 -- 是 --> Q3{3 该现象・状况是否【不确定】会实际发生？<br/>（既不是100%也不是0%？）};
    Q3 -- 是 --> IsRisk[<b>✅<u>属于风险</u></b><br/>请在风险管理表中登记，并研讨对策！];
    Q3 -- 否 --> Q4{4 能否确定100%一定会发生？};
    Q4 -- 是 --> Certainty[<u>不是风险</u><br/>可能是前提条件错误或工作计划不完善所导致的现象。];
    Q4 -- 否 --> NotCertainty[<u>不是风险</u><br/>（确信不会发生的情况）];

风险管理不仅仅是“将危险因素列举并回避”的工作。
软件工程师Tom DeMarco在其著作 SLACK: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ^[1] 中，如下所述：

"Risk management is about planning for failure." ^[2]

也就是说，风险管理就是“以失败为前提进行规划”。
此外，DeMarco还说道：

"Slack is what helps organizations cope with risk. It's the buffer that allows for the unexpected." ^[3]

Slack（余地）正是应对变化和意外状况的“缓冲（余量）”。
如果一味追求效率，组织会失去灵活性，很容易因稍微的变化或意料之外的情况而崩溃。

反过来，通过刻意设置“Slack＝保险”，可实现具有韧性的运营。
由此可见，风险管理是一种面向“可能发生的未来”并且“刻意保留余地”的管理决策。

这种理念为判断风险管理是否正常运作提供了一个有趣的视角。
试想，如果你的项目在预算、进度和人员方面完全没有“余地”，会怎样？

如果项目总是处于紧绷状态，那可以说是非常高风险的状况。
你或许会觉得那些看似低效的“浪费”作业或成本多余。

然而，这恰恰是为应对意外变化而有计划地设置的‘Slack（余地）’。
而这正是风险管理正常发挥作用的证明。

你是将那份“余地”视为浪费，还是看作对未来的保险？
这样的判断力正是项目经理的实力所在。

一旦识别出风险，为了可视化和应对，就要将其登记到“风险管理表”中。
最开始使用Excel或Google表格，以下这样的简单格式就足够了。

• ID：请为风险分配一个唯一的ID（例如：R-001）。
• 风险登记日：记录首次识别该风险的日期。
• 风险内容：将未来可能发生的“麻烦事”具体地以“可能会～”的形式描述。
• 发生概率：评估该风险实际发生的可能性。初期采用“高(3)/中(2)/低(1)”三段评估即可。请基于团队经验及过往案例进行判断。
• 影响度：若该风险发生，评估其对项目目标（如QCD等）造成的负面影响程度。可采用“大(3)/中(2)/小(1)”等评估方式。
• 风险分数：将发生概率与影响度的评分相乘得出。分数越高，表示该风险越应优先考虑对策。
• 应对方针（预防策·减轻策）：
  • 预防策：为降低风险发生概率而采取的具体行动。
  • 减轻策：万一风险发生，能将其影响降至最低的具体行动。
• 负责人：明确负责实施该风险应对措施的责任人，通常需指定具体个人。
• 期限：设置执行应对措施或对该风险进行重点监控的目标日期。
• 状态：记录风险当前的状态（如：未应对、正在研讨对策、进行中、已应对、监控中、已发生（问题化）等）。
• 备注：记录其他特殊事项或关联信息。

将风险的“发生概率”和“影响度”量化并相乘，就能用客观的数值来评估抽象的“潜在危险”。
如此一来，团队更易形成共同认识，也能进行优先对策的探讨和有效的讨论。

基本上，优先考虑预防策是更可取的。
因为若能减少风险发生的可能性，就能大幅降低后续的成本和影响。
但若预防困难或成本过高，就需要准备减轻策。
项目经理的能力就在于如何平衡地考虑两者。

指风险实际发生并开始对项目产生影响的状态。
在这种情况下，该风险不再属于“风险管理”范畴，而是作为“问题”转入“课题管理”流程，需要迅速应对。
风险管理的目的之一就是尽可能防止风险达到“已发生”这一阶段。

即便是精心制作的风险管理表，一旦搁置也会很快形同摆设。
关键在于“定期审查并更新”——仅此一点，风险管理表就能发挥未来预测雷达的作用。

• 新风险要立即登记
  当有人感到“可能需关注”时，立即加入候选。
• 以周或定期会议进行全面检查
  对高优先级风险更新状态；若未应对，也要记录原因。
• 整理已完成应对的风险
  将状态栏更新为“已应对”等以示明确。
• 不再需要的风险“存档”
  可移至另一个表单或底部，以记录历史。

项目每天都在变化。昨日还是低风险的事项，明日可能就成了重大风险。
定期更新才是真正处于“对风险有所准备”的状态。

风险管理不仅是项目经理的工作，
需要全体成员配合。
及时发现、共享并协作对策的意识，
才能实现有效应对。
请使用以下检查清单，团队定期确认风险管理状态。

• 风险是“未来的不确定影响”，与“问题”截然不同。
• “肯定会发生坏事”不是风险，而是“前提”或“问题”。
• 不确定性恰恰是风险的本质。
• 通过评分和分类，你可以冷静地对极端事件（例如：日本消失级别的陨石撞击）进行优先级排序。
  例如，“日本消失级别的陨石撞击”由于发生概率天文数字般地低，因此优先级会降低。
• 刚开始时，使用简单的列表即可。
  关键在于，持续地审查并更新。

针对“问题”发生后进行的课题管理固然重要，
但从根本上防止问题发生、抢先行动的风险管理同样必不可少。

这两者如双轮并行，缺一不可，才能将项目导向成功。
风险管理即是预测未来并进行掌控的行为。

一开始你可能会觉得困难，
但第一步就是发挥想象力：“或许会发生这样的麻烦，
那么现在可以做些什么呢？”

本文介绍的概念和工具仅是基础，
请根据你的项目情况不断自定义。

最重要的是，不要独自承担，
要营造团队共同讨论风险的文化。
一定会有一天，你会庆幸：“那时我好在把风险都列举出来了。”