风险应对计划把已识别的风险逐条转成可执行动作：每条风险写明触发条件、应对策略、责任人、完成时点、所需资源和验证方式，并在执行中按节奏复核更新。本文给出字段表、从风险清单到应对动作的操作步骤、角色分工、一条进度风险示例和完成检查清单，适用于项目层尚未发生的不确定性管理。
要点总览（TL;DR）
- 风险应对计划的字段应覆盖风险编号、描述与来源、概率与影响、等级、触发条件、应对策略、具体行动、责任人、完成时点、资源依赖、验证与关闭标准、复核记录，颗粒度以“换人也能执行”为准。
- 做法分五步：汇集确认风险清单、按等级筛选、选择规避/转移/减轻/接受并写动作、把动作挂到任务与责任人、设定触发条件与升级路径。
- 每条风险只设一名责任人，高等级风险方案由项目发起人或管理层审批；技术或业务负责人提供影响判断与资源支持。
- 计划落地靠三件事：应对动作进入任务跟踪、触发条件进入例会核对、风险状态按待应对/已触发/已关闭/转为问题/策略调整流转。
- 定稿前用检查清单验收：高等级风险全覆盖、动作可拆任务、触发条件可判断、资源已确认、复核与升级明确、关闭标准可验证。
风险应对计划包含哪些字段
一份能执行的风险应对计划，颗粒度应达到“换一个人拿到这条记录，也知道什么时候该做什么、做完怎么算完成”。字段不必多，但每个字段都要能支撑判断或行动。下表给出可直接套用的字段结构。
| 字段名 | 填写要求 | 示例值 |
|---|---|---|
| 风险编号 | 与风险登记册一致，全项目唯一，便于引用和追溯 | R-012 |
| 风险描述与来源 | 写“原因—事件—后果”结构；来源注明识别渠道，如评审会、历史问题记录、干系人访谈 | 因第三方接口文档交付延迟，联调阶段可能压缩，导致上线里程碑推迟 |
| 发生概率与影响程度 | 使用团队统一的分级口径（如高/中/低或1—5分），概率与影响分别评定 | 概率：中；影响：高（影响上线里程碑） |
| 风险等级 | 由概率与影响组合得出，作为是否制定应对动作和复核频率的依据 | 高 |
| 触发条件或预警信号 | 写成可观察、可判断的事实，避免“情况恶化”这类模糊表述 | 约定交付日前5个工作日仍未收到接口文档 |
| 应对策略 | 在规避、转移、减轻、接受中选择，并简述选择理由 | 减轻：提前准备模拟接口，降低对单一交付方的依赖 |
| 具体行动 | 拆到可执行的任务级，一条风险可对应多个动作 | 1. 与供应商确认交付计划；2. 搭建模拟接口；3. 调整联调排期 |
| 责任人 | 每条风险一名唯一责任人，负责推动动作和反馈进展 | 后端负责人 |
| 完成时点 | 写明日期或关联的里程碑，避免只写“尽快” | 模拟接口在联调开始前3天就绪 |
| 所需资源与依赖 | 列出人力、环境、外部配合方及前置条件 | 测试环境1套；供应商接口人配合确认 |
| 验证方式与关闭标准 | 说明用什么证据判断应对有效、风险可关闭 | 模拟接口通过联调用例；供应商书面确认交付日期 |
| 复核频率与更新记录 | 按等级设定复核节奏，记录每次状态变化和决策 | 每周例会复核；记录策略调整与关闭时间 |
字段填写有两个常见偏差值得注意。一是把风险描述写成问题描述，已经发生的阻塞应转入问题管理，风险条目只保留尚未发生的不确定性。二是行动栏写成“加强沟通”“密切关注”这类口号，无法分配工时也无法验证，应改写为具体交付物，例如“输出接口对接确认单并由双方签字”。
从风险清单到应对动作的操作步骤
制定应对计划的过程，是把风险登记册中的条目逐条加工成带责任人和时点的动作。以下五步按输入、动作、输出和完成标志展开，可按项目节奏一次完成，也可分批推进。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 汇集与确认风险清单 | 风险登记册、项目计划、历史问题记录 | 核对风险描述、来源和分级口径是否一致，剔除已发生事项 | 确认版风险清单 | 清单中每条风险有编号、描述和等级 |
| 2. 按等级筛选 | 确认版风险清单 | 确定哪些风险需要制定完整应对动作，哪些仅登记观察 | 待制定应对的风险列表 | 高等级风险全部进入列表，筛选规则有书面说明 |
| 3. 选择策略并写动作 | 待制定应对的风险列表 | 逐条选择规避、转移、减轻或接受，写出具体行动和选择理由 | 带策略和行动的风险条目 | 每条风险至少一个可执行动作，接受策略写明理由 |
| 4. 挂接任务与责任人 | 带策略和行动的风险条目、项目计划 | 把动作拆成任务，关联里程碑，指定唯一责任人和完成时点 | 可跟踪的应对计划 | 每个动作有责任人和日期，且出现在任务跟踪中 |
| 5. 设定触发与升级路径 | 可跟踪的应对计划 | 为每条风险写明触发信号、判定人和升级对象 | 更新后的风险登记册与应对计划 | 触发条件可观察，升级路径明确到岗位 |
第2步的筛选规则建议提前约定，例如“高等级风险全部制定应对动作，中等级风险由责任人判断是否制定，低等级风险登记观察”。规则写清楚，可以避免每次评审都重复讨论，也防止重要风险被遗漏在清单里无人跟进。
第3步选择策略时，判断依据是风险等级、可控性和投入产出比。规避适用于后果严重且可以通过调整方案绕开的风险；转移适用于可由第三方承担部分后果的场景，如合同条款或保险；减轻适用于降低概率或影响成本合理的情况；接受适用于影响在可承受范围内、应对成本高于损失的风险，接受也要写明理由和观察方式，不能留空。
第4步是把计划从文档变成执行的关键。动作只有挂到任务、里程碑和责任人上，才会进入日常跟踪；停留在表格里的行动项，往往在项目紧张时最先被搁置。第5步的触发条件与升级路径要成对出现：谁在例会上判定触发、触发后多长时间内启动动作、什么情况下上报给项目发起人，都应写清楚。
角色分工与交付物
风险应对计划涉及制定、审批、执行和复核四类工作，角色不清时最容易出现“计划有人写、动作没人做”的情况。下表按角色列出职责和对应交付物。
| 角色 | 职责 | 交付物 | 时点 |
|---|---|---|---|
| 项目经理 | 组织制定计划，汇总各条风险应对，跟踪整体状态，主持复核 | 风险应对计划汇总、复核记录 | 计划制定阶段完成汇总；按复核节奏更新 |
| 风险责任人 | 执行具体应对动作，反馈进展，判定触发条件是否出现 | 动作完成证据、状态更新 | 按各自完成时点；例会上同步 |
| 技术或业务负责人 | 判断风险影响程度，提供资源和技术方案，评估应对动作可行性 | 影响评估意见、资源承诺 | 计划制定阶段；策略调整时 |
| 项目发起人或管理层 | 审批高等级风险应对方案与资源投入，接收升级事项 | 审批结论、资源决策 | 高等级风险计划定稿前；升级触发时 |
分工中有两个细节影响执行效果。其一，每条风险只设一名责任人，协作人可以多人，责任不能分摊，否则触发条件出现时无人拍板。其二，高等级风险的应对方案需要发起人或管理层审批，因为这类方案往往涉及排期调整或额外资源，超出项目经理的授权范围。审批时点应放在计划定稿前，避免动作执行到一半才发现资源未获批准。
示例：一条进度风险的应对计划怎么写
以下用一条进度风险演示字段如何填写。情景为演示设定：某系统集成项目计划在联调阶段依赖第三方接口文档，供应商交付存在延迟可能。
| 字段 | 填写内容 |
|---|---|
| 风险编号 | R-012 |
| 风险描述与来源 | 因第三方接口文档交付延迟，联调阶段可能被压缩，导致上线里程碑推迟。来源：详细设计评审会 |
| 概率与影响 | 概率：中；影响：高（直接影响上线里程碑） |
| 风险等级 | 高 |
| 触发条件 | 约定交付日前5个工作日仍未收到接口文档，或供应商未给出明确交付日期 |
| 应对策略 | 减轻。理由：无法改变供应商排期，但可以通过模拟接口和排期缓冲降低对单一交付方的依赖 |
| 具体行动 | 1. 项目经理与供应商接口人确认书面交付计划；2. 后端负责人组织搭建模拟接口；3. 测试负责人调整联调用例顺序，优先覆盖不依赖该接口的部分 |
| 责任人 | 后端负责人（整体）；各行动由对应执行人负责 |
| 完成时点 | 书面交付计划在触发条件判定后2个工作日内确认；模拟接口在联调开始前3天就绪 |
| 所需资源与依赖 | 测试环境1套、后端人力约2人日、供应商接口人配合 |
| 验证与关闭标准 | 模拟接口通过联调用例；供应商书面确认交付日期且实际按约交付；联调阶段未因该接口延期 |
| 复核与升级 | 每周例会复核；触发条件出现后由项目经理上报项目发起人，评估是否调整上线里程碑 |
这条示例体现了几个填写要点：触发条件写成可核对的事实而非感受；策略选择附理由，便于后续复盘时判断当时决策是否合理；行动拆到不同执行人，避免全部压在责任人一人身上；关闭标准包含证据，风险关闭时有据可查。升级安排与触发条件相邻写明，触发后由谁上报、上报给谁一目了然。
计划落地与复核机制
计划制定完成后，需要进入项目的日常节奏才能保持有效。落地机制包括三件事：动作进入任务跟踪、触发条件进入例会检查、风险状态按规则流转。
动作进入任务跟踪，是指每条应对行动作为任务出现在项目计划中，有责任人和日期，与普通交付任务一样被查看进度。触发条件进入例会检查，是指在固定例会上逐条核对高等级风险的触发信号是否出现，出现即启动对应动作并按升级路径上报。复核频率可按等级分层设置，例如高等级风险每周复核、中等级风险每两周或按里程碑节点复核、低等级风险每月复核，具体节奏由项目周期和风险密度决定。
| 风险状态 | 进入条件 | 处理动作 | 记录要求 |
|---|---|---|---|
| 待应对 | 风险已识别并完成分级，应对动作已制定 | 按计划执行动作，例会上核对触发条件 | 记录责任人和完成时点 |
| 已触发 | 触发条件出现 | 启动应对动作，按升级路径上报 | 记录触发时间、判定人和启动的动作 |
| 已关闭 | 关闭标准满足，有验证证据 | 停止跟踪，归档证据 | 记录关闭时间和验证方式 |
| 转为问题 | 风险已实际发生并造成阻塞 | 转入项目问题管理流程处理 | 记录转出时间和关联问题编号 |
| 策略调整 | 复核发现原策略无效或风险等级变化 | 重新选择策略并更新动作 | 记录调整原因和审批人 |
复核时要回答三个问题：风险等级是否仍然准确，原策略是否仍然有效，动作是否按计划推进。任何一项发生变化，都应更新计划并保留变更记录，包括调整原因、决策人和时间。变更记录的价值在项目复盘时体现：它能说明当时的判断依据，帮助团队区分“决策失误”和“信息不足”。
当团队使用协作工具承载这套机制时，可以把风险条目、应对动作和复核节奏放在同一处跟踪。以ONES为例，项目计划支持创建工作分解结构并设置任务前后置依赖，用里程碑标记重要时间点，应对动作可以作为任务挂到计划和里程碑上；设置计划与里程碑基线后，可对比计划与执行的偏差，帮助更早发现影响交付的风险；项目列表可查看项目状态、资源投入和当前进展，版本对比可追溯变更细节。这些能力支撑的是动作跟踪和偏差识别，风险台账的字段与状态流转方式需按团队实际配置确认。
完成检查：计划是否可执行
计划定稿前，用以下清单逐项核对。每项给出通过标准，任一项不通过都应返回修改，而不是带着缺口进入执行。
| 检查项 | 通过标准 |
|---|---|
| 高等级风险覆盖 | 每条高等级风险都有唯一责任人和明确完成时点，无遗漏 |
| 动作具体性 | 每个行动可拆成任务、可估算工作量，不出现“加强沟通”“密切关注”等口号 |
| 触发条件可判断 | 触发条件写成可观察的事实或日期，例会上能直接判定是否出现 |
| 资源与依赖确认 | 所需人力、环境、外部配合已确认，依赖方知晓并同意配合 |
| 复核与升级明确 | 复核频率按等级设定，升级路径明确到岗位和时限 |
| 关闭标准可验证 | 关闭标准对应可取得的证据，如测试结果、书面确认、里程碑达成记录 |
| 与登记册一致 | 计划中的风险编号、等级与风险登记册一致，更新已回写 |
清单核对完成后，计划即可进入执行。执行期间若出现新的高等级风险，按同样的字段和步骤补充，不必等待下一个复核周期；已关闭的风险保留记录，作为后续项目识别风险的参考。
常见问题
风险应对计划应该多久复核一次？
复核频率按风险等级分层设置更实用：高等级风险通常每周复核，中等级风险可按每两周或里程碑节点复核，低等级风险每月复核一次。具体节奏由项目周期和风险密度决定，项目临近关键交付节点时可临时加密。复核时重点回答三个问题：风险等级是否仍然准确、原策略是否仍然有效、动作是否按计划推进，任何一项变化都要更新计划并保留变更记录。
风险已经发生并造成阻塞，还留在风险应对计划里吗？
应转入项目问题管理流程。风险应对计划面向尚未发生的不确定性，风险一旦实际发生并造成阻塞，就变成需要处置的问题，继续留在风险台账里会混淆两类工作的跟踪方式。转出时记录转出时间和关联问题编号，原风险条目保留归档，便于复盘时追溯。若风险发生但未造成阻塞，可按实际影响重新评估等级并调整策略。
选择“接受”策略的风险，还需要写应对动作吗？
需要写明理由和观察方式，不能留空。接受适用于影响在可承受范围内、应对成本高于潜在损失的风险，但接受本身是一个决策，应记录判断依据、可承受的损失上限以及由谁在什么条件下重新评估。观察方式可以是定期复核等级、设定预警阈值，一旦条件变化就重新选择策略。没有理由和观察安排的“接受”，在执行中容易变成无人跟进。
应对动作怎么和项目日常任务衔接，避免计划写完就搁置？
关键是把每条应对行动作为任务放进项目计划，有责任人和日期，与普通交付任务一样被查看进度；触发条件则放进固定例会的核对环节，出现即启动动作并按升级路径上报。动作停留在独立表格里、不进入任务跟踪时，项目紧张阶段往往最先被搁置。团队使用协作工具承载时，可以把风险条目、应对动作和复核节奏放在同一处跟踪，具体字段和状态流转方式按团队实际配置确定。
项目执行中出现新的高等级风险，要等下一个复核周期再处理吗？
不必等待。新出现的高等级风险按同样的字段和步骤即时补充：确认描述与分级、选择策略、写具体动作、指定责任人和完成时点、设定触发条件与升级路径，然后纳入例会核对。已关闭的风险保留记录，作为后续项目识别风险的参考。补充完成后同步更新风险登记册，保持计划与登记册的编号和等级一致。
