项目风险应对的核心，是把风险清单里的条目转成有策略、有责任人、有触发条件、有完成标志的动作，并在执行中持续跟踪状态，直到风险关闭或转为已发生问题。本文按“定策略—拆动作—分角色—跟踪关闭—示例—检查”的顺序展开，适用于已经完成风险识别与评估、准备进入应对环节的项目团队。
要点总览（TL;DR）
- 风险应对从策略选择开始：规避、转移、减轻、接受四种策略按风险等级与应对代价选择，每条风险写明策略理由和剩余风险。
- 策略要拆成可执行动作：每步写清输入与输出，触发条件用预警指标、阈值或观察时点表达，并指定责任人与升级路径。
- 角色分工要固定：项目经理维护登记册与跟踪，风险责任人执行动作，职能负责人提供资源，项目发起人审批高等级风险并接受剩余风险。
- 执行期按风险等级设定跟踪频率，状态统一为待应对、应对中、已发生、已关闭并连续记录；转为已发生问题时按边界移交问题管理。
- 用完成检查清单逐项核对策略、动作、跟踪记录与复盘回写，任何一项拿不出记录就说明应对尚未闭环。
风险应对从哪一步开始：先给风险定策略
风险应对的起点是策略选择。一条风险只有满足三个条件，才适合进入应对环节：风险描述具体到能判断影响对象和影响方式；概率与影响已经评估并形成等级；已经指定风险责任人。缺少任一条，先补信息再定策略，否则后续动作容易落空。
四种基本策略各有适用情形和代价，选择时要把代价与风险敞口放在一起比较，而不是一律选“减轻”。
| 策略 | 适用情形 | 主要代价或限制 |
|---|---|---|
| 规避 | 风险影响超出项目可承受范围，且可以通过改变范围、方案、进度或技术路线彻底消除风险源 | 通常伴随范围缩减、工期延长或成本上升，可能影响项目目标 |
| 转移 | 风险后果可由第三方更有效地承担，如外包、保险、合同条款约定 | 需要支付费用或让渡部分利益，责任转移后仍需管理接口与履约 |
| 减轻 | 风险无法消除，但可以通过预防措施降低发生概率，或通过应急预案降低影响 | 需要投入资源，且只能把风险降到可接受水平，不能归零 |
| 接受 | 风险等级低，或应对成本高于风险损失，选择主动接受并准备应急储备 | 需要明确接受的理由和储备额度，并持续观察是否触发升级 |
为每条风险选定策略时，在风险登记册中写明策略和选择理由，理由要指向具体的评估结论，例如“影响等级为高且无法通过测试覆盖，选择规避，调整技术方案”。策略确定后，还要说明剩余风险：采取动作后仍残留的概率与影响是什么，由谁接受。剩余风险说明是后续跟踪的判断基准，不能省略。
这一步的交付物是一份带策略标注的风险清单：每条风险包含描述、概率、影响、等级、责任人、策略、选择理由和剩余风险。
把应对策略拆成可执行动作与触发条件
策略只是方向，落地需要拆成动作。每条风险至少拆出一个动作，复杂风险拆成有先后顺序的步骤，每一步写清输入、动作和预期输出。例如“减轻”策略下的动作可以是“在下一迭代前完成关键接口的压力测试，输出测试报告与瓶颈清单”，而不是“关注性能风险”。
触发条件决定动作何时启动，写法要可观察、可判断。常见写法有三类：预警指标，如缺陷密度连续两周超过约定值；阈值，如关键路径任务延期超过三天；观察时点，如每个里程碑评审前检查供应商交付进度。触发条件应写明由谁观察、在什么时点判断，避免“情况恶化时启动”这类无法执行的表述。
每条动作要指定责任人和协作角色，并约定升级路径：责任人无法在约定时间内完成动作，或触发条件满足但资源不足时，向谁升级、在多长时间内升级。完成标志要可验证，例如“测试报告通过评审并归档”“备用供应商合同签署完成”，而不是“已处理”。
动作还要挂接到项目计划：把应对动作作为任务纳入相应阶段或里程碑，标注前置依赖和计划完成时间，使动作进入团队的日常进度管理，而不是停留在风险登记册里。
这一步的交付物是风险应对计划表，字段包括：风险编号、策略、动作步骤、输入与输出、触发条件、责任人、协作角色、升级路径、完成标志、计划完成时间、关联里程碑。
角色与交付物分工：谁识别、谁决策、谁执行
风险应对常见的问题是责任悬空：清单有人维护，动作没人执行。解决办法是把每个环节的角色和交付物固定下来。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 项目经理 | 组织风险识别与评估，维护风险登记册，汇总应对计划，跟踪整体状态，组织评审 | 风险登记册、应对计划汇总、状态跟踪记录、评审纪要 |
| 风险责任人 | 对单条风险负责，提出策略建议，拆解并执行动作，观察触发条件，及时上报状态变化 | 单条风险的应对计划、执行记录、状态更新 |
| 职能负责人 | 为应对动作提供人员、预算和技术支持，确认本职能范围内的动作可行性 | 资源承诺、技术方案确认、动作验收意见 |
| 项目发起人 | 审批高等级风险的策略与资源投入，裁决跨部门升级事项，接受剩余风险 | 策略审批意见、升级裁决、剩余风险接受记录 |
风险评审的参与角色按风险等级区分：低等级风险由项目经理和风险责任人确认即可；高等级风险或需要跨部门资源的风险，提交项目发起人参与的评审，由发起人做决策。决策权限要事先约定，避免评审会上反复讨论却无人拍板。
风险信息在团队内的同步方式应与项目节奏一致：在例会上通报状态变化和触发条件观察结果，在里程碑评审中复核高等级风险的应对进展，风险登记册保持单一版本、由项目经理统一更新，避免多份清单并存。
执行中的跟踪、升级与关闭
应对动作进入计划后，跟踪的重点是状态是否按预期变化。跟踪频率与风险等级挂钩：高等级风险每个例会周期检查一次，中低等级风险在里程碑节点检查。每次检查的内容包括动作完成情况、触发条件是否出现、剩余风险是否变化、责任人是否需要支持。
风险状态建议统一为四类并连续记录：待应对、应对中、已发生、已关闭。每次状态变化记录变更时间、变更原因和操作人，使跟踪记录可以回溯。状态记录是后续复盘和关闭判定的依据，不能只保留最新状态。
触发条件满足时，按预案启动动作并同步升级：责任人执行预案，项目经理评估对计划的影响，超出授权范围的事项提交发起人裁决。升级要有时限约定，避免风险在等待决策中扩大。
风险转为已发生问题时，移交边界要清晰：风险登记册中该条目标记为已发生并保留历史记录，具体处置转入问题管理流程，由问题责任人跟进解决；风险责任人继续关注同类风险是否再次出现。移交时写清移交对象、移交时间和已采取的措施，避免两边都以为对方在跟进。
关闭判定依据完成标志是否达成、剩余风险是否在可接受范围内、是否还有未完成的动作。关闭时记录关闭理由和复盘结论，复盘结论回写到后续风险识别中，作为检查表和经验条目使用。
在工具层面，风险应对动作需要与项目计划、里程碑和状态记录放在同一处管理。ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，提早识别风险和问题；提供从项目到任务的多层级管理能力，实现自下而上的进度反馈和自上而下的进度监控；并支持通过对比版本细节追溯变更。对于采用瀑布方式管理的项目，这些能力可以承载应对动作的挂接与执行偏差的观察，风险登记与状态流转的具体配置以实际版本为准。
一个完整示例：从识别到关闭的应对过程
以下为演示性示例，用于说明方法如何串联，不代表真实项目数据。
风险描述与评估：某系统集成项目计划在第三阶段完成与外部支付平台的联调，但对方接口文档尚未定稿。评估结论为：发生概率高，影响等级高，风险等级为高，风险责任人为集成负责人。
策略与理由：选择“减轻”。理由是联调无法取消，但可以通过提前锁定接口版本和准备模拟环境降低延期影响；同时保留“接受”部分剩余风险，即对方最终接口变更导致的少量返工。
动作与触发条件：动作一，在第二阶段结束前取得对方接口文档的书面确认版本，输出确认邮件与文档版本号；动作二，搭建模拟支付环境，输出可运行的联调环境；动作三，预留五个工作日的返工缓冲并纳入计划。触发条件为：第二阶段结束前三个工作日仍未取得确认版本，或对方文档版本发生变更。责任人为集成负责人，协作角色为测试负责人和采购接口人，升级路径为触发后两个工作日内上报项目经理，必要时提交项目发起人协调。
执行与关闭：第二阶段中期，触发条件出现，对方未按期提供确认版本。责任人启动预案，先用模拟环境完成内部联调，项目经理同步调整里程碑评审范围。两周后对方提供确认版本，接口差异小于预期，返工在两个工作日内完成。完成标志全部达成，剩余风险在可接受范围内，风险关闭，复盘结论“外部依赖类风险应提前设置文档确认节点”写入后续项目的风险检查表。
完成检查：风险应对是否做到位
项目阶段结束或风险评审前，用以下清单逐项核对，每项都要能拿出对应记录，而不是凭印象判断。
- 每条进入应对环节的风险都有明确的策略和选择理由，剩余风险已说明并由相应角色接受。
- 每条风险都有责任人、可观察的触发条件，以及可验证的完成标志。
- 应对动作已作为任务进入项目计划，标注了计划完成时间和关联里程碑。
- 高等级风险的策略经过有决策权限的角色审批，审批记录可查。
- 跟踪记录连续，状态变化有时间、原因和操作人，没有长期停留在“应对中”却无进展的条目。
- 触发条件满足时启动了预案并完成升级，升级过程有记录。
- 转为已发生问题的风险已完成移交，移交对象、时间和已采取措施清晰。
- 关闭的风险有完成标志达成的证据和关闭理由。
- 复盘结论已回写到风险检查表或后续风险识别活动中，并在下一次评审中被引用。
清单中任何一项无法提供记录，说明该环节的应对工作尚未闭环，应在本轮评审中补齐后再进入下一阶段。
常见问题
风险等级低、选择“接受”策略的风险，还需要指定责任人和跟踪吗？
需要。接受是一种主动策略，前提是写清接受理由和应急储备额度，并指定一名责任人持续观察。跟踪频率可以低于高等级风险，比如在里程碑节点检查一次，但状态记录要保留。当风险等级上升或触发条件出现时，接受策略应重新评估，必要时改为减轻或规避。
触发条件一直没出现，应对动作还要继续准备吗？
要区分两类动作。预防类动作用于降低发生概率，应按计划执行，不依赖触发条件；应急类动作只在触发条件满足时启动，平时保持预案可用即可。如果一条风险长期没有触发，也没有任何预防动作在执行，应在评审中复核这条风险是否仍然成立，或评估结果是否已经过时。
风险转为已发生问题后，原风险责任人还要做什么？
移交后，具体处置由问题责任人跟进，原风险责任人保留两项工作：一是确认移交记录完整，写清移交对象、移交时间和已采取的措施；二是关注同类风险是否会在其他环节再次出现，把这次发生的实际情况回写到风险识别中。两边职责不清是风险与问题衔接中最常见的漏洞。
风险应对动作如何与项目计划衔接，避免只停留在清单里？
把每个应对动作作为任务纳入对应阶段或里程碑，标注前置依赖、计划完成时间和完成标志，让它进入团队的日常进度管理。这样在例会和里程碑评审中检查的是任务进展，而不只是风险登记册上的文字。采用瀑布方式管理的项目，可以用 ONES 瀑布项目管理解决方案设置项目计划和里程碑基线，对比计划与执行的偏差，提早识别风险和问题；具体配置以实际版本为准。
复盘结论怎样才算真正回写到后续风险识别？
可检验的标准是下一次评审能引用到它。做法是把结论转成风险检查表中的具体条目或识别提示，例如“外部依赖类风险应提前设置文档确认节点”，并在后续项目的风险识别会上逐条过一遍。只写在复盘文档里、下次识别时没人翻看的结论，等于没有回写。
