制定风险应对计划，核心产物是一份可执行的风险登记册加应对动作清单：每条高优先级风险都有触发条件、责任人、策略和完成标志，相关动作进入项目排期，并设定复查节奏与升级路径。本文按字段构成、制定步骤、角色分工、填写示例、复查机制和完成检查的顺序展开，适用于单个项目层面的风险应对，不涉及已发生阻塞的问题处置和项目组合层面的资源调配。
要点总览（TL;DR）
- 可执行的风险应对计划由风险登记册和应对动作清单组成，每条高优先级风险都要有触发条件、策略、责任人、截止时间和完成标志。
- 制定流程分六步：识别并登记风险、评估可能性与影响排序、选择规避/转移/减轻/接受策略、拆解为带责任人的动作、设定触发条件、评审定稿并纳入排期。
- 项目经理维护登记册并主持复查，风险责任人监控触发条件并执行应对，技术或业务负责人提供影响判断，发起人审批需要资源的动作。
- 计划定稿后靠定期复查与事件驱动复查保持有效；风险发生即移交问题清单，应对无效按约定层级升级。
- 合格标准是每条高优先级风险都能回答何时启动、由谁做、做到什么程度算完成，且动作已进入项目排期。
一份可执行的风险应对计划包含哪些内容
风险应对计划的成品形态是一张持续更新的风险登记册，加上从登记册中拆出的应对动作清单。判断它是否可执行，看两个特征：每条风险都能回答“什么信号出现时、由谁、在多长时间内、做什么、做到什么程度算完成”；每个应对动作都能在项目排期里找到对应的时间位置。
风险登记册建议至少包含以下字段，字段之间形成一条完整的判断链：
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 风险描述 | 写“原因—事件—后果”结构，说明什么因素可能引发什么事件、造成什么影响 | 只写“进度可能延误”这类笼统表述，无法判断应对对象 |
| 触发条件 | 可观察的信号，如某任务延期超过3个工作日、某供应商未在约定日期前提交样品 | 写成“情况恶化时”，无法判断何时启动应对 |
| 可能性与影响 | 用团队约定的等级或分值评估，影响需说明维度（进度、成本、质量、范围） | 只评可能性不评影响，或评估口径各人不同 |
| 优先级 | 由可能性与影响共同决定，明确哪些等级必须制定应对动作 | 所有风险同一优先级，资源无法聚焦 |
| 应对策略 | 规避、转移、减轻、接受四类之一，并写明选择理由 | 策略与动作脱节，写了“减轻”却没有具体手段 |
| 责任人 | 单条风险指定一名风险责任人，负责监控触发条件和执行应对 | 写成部门名称，无人真正对结果负责 |
| 截止时间 | 应对动作的完成时点，与项目里程碑或关键路径节点对齐 | 只写“尽快”，无法纳入排期 |
| 完成标志 | 可核验的交付物或状态，如“备选供应商合同签署完成” | 写成“已处理”，无法判断是否真正完成 |
应对动作清单与项目排期的关系需要说清楚：风险应对动作不是登记册之外的附加事项，其中需要投入人力和时间的动作应当作为任务进入项目计划，占用相应资源并接受进度跟踪。只在登记册里写“安排备份方案”，却没有对应的任务、负责人和时间，这类动作在项目紧张时最先被挤掉。
三个相邻概念需要区分边界。风险登记册记录尚未发生、可能发生的事项及其应对安排；问题清单记录已经发生、需要立即处置的事项；风险应对计划则是登记册中高优先级风险对应的策略与动作集合。风险一旦发生，应从登记册移交到问题清单处理，登记册中保留记录并注明转化时间，避免同一事项在两处重复跟踪或两边都无人跟进。
制定风险应对计划的六个步骤
六个步骤形成一条从识别到定稿的连续流程，每一步都有明确输入、动作、输出和完成标志，可以按顺序推进，也可以在评审不通过时回到前一步修订。
第一步：识别风险并写入登记册
输入为项目范围说明、进度计划、外部依赖清单、合同与采购安排，以及以往类似项目的复盘记录。动作是组织项目核心成员做一次结构化识别，按范围、进度、成本、质量、资源、外部依赖等类别逐项排查，把识别结果按统一格式写入登记册。输出为初版风险条目。完成标志是登记册中每条风险都具备描述、初步影响判断和提出人，且没有明显遗漏的类别。
第二步：评估可能性与影响并排序
输入为初版登记册。动作是对每条风险评估发生可能性和一旦发生的影响程度，评估口径在项目启动时统一约定，避免不同人标准不一；再按两者组合确定优先级，划出必须制定应对动作的高优先级范围。输出为带评级和优先级的登记册。完成标志是高优先级风险名单经过项目核心成员确认，且数量在项目能够跟踪的范围内。
第三步：为高优先级风险选择应对策略
四类策略各有适用条件，选择时结合风险性质、可控程度和投入成本判断：
- 规避：调整方案或范围，使风险源不再存在，如更换技术路线、放弃高风险的需求项。适用于风险影响大且团队对成因有控制力的情况。
- 转移：把风险后果及应对责任部分转移给第三方，如购买保险、在合同中约定违约责任、外包给具备相应能力的供应商。适用于后果可量化、存在承接方的情况，需注意转移后仍需监控对方履约。
- 减轻：降低发生可能性或缩小影响，如提前做技术验证、增加备选供应商、关键模块安排交叉评审。适用于大多数可管理的中高优先级风险。
- 接受：不采取主动措施，仅预留应急储备并持续监控。适用于影响在可承受范围内、或应对成本高于损失的风险，接受需明确记录理由和监控方式。
输出为每条高优先级风险对应的策略及选择理由。完成标志是策略与风险描述匹配，且没有出现“策略写了减轻、动作却无从下手”的情况。
第四步：把策略拆成具体动作
输入为策略结论。动作是把每条策略拆成可执行的任务，逐项指定负责人、截止时间和完成标志，需要占用项目资源的动作同步纳入项目排期。输出为应对动作清单。完成标志是每条高优先级风险至少对应一个动作，每个动作都有唯一负责人和可核验的完成标志。
第五步：设定触发条件与预警信号
输入为风险描述和应对动作。动作是为每条风险确定可观察的触发条件，说明信号出现后由谁在多长时间内启动哪项应对动作。触发条件尽量绑定项目中的客观数据，如任务完成率、缺陷趋势、供应商交付节点、预算消耗比例。输出为登记册中的触发条件字段和启动规则。完成标志是触发条件可以由责任人通过日常项目数据直接判断，无需额外专门调查。
第六步：评审定稿并纳入项目计划
输入为完整的登记册和动作清单。动作是组织项目经理、风险责任人、技术或业务负责人及相关管理层评审，确认策略合理、资源可落实、动作已进入排期，并确定复查节奏。输出为定稿的风险应对计划和评审记录。完成标志是评审意见已闭环，应对动作在项目计划中有对应任务，复查时间已写入项目日历。
在风险登记与动作跟踪环节，如果团队使用 ONES，可以把风险应对动作作为工作项纳入项目计划，借助任务依赖和里程碑标记关键应对节点，并通过计划与执行的偏差对比提早发现风险信号。风险登记册的字段设计和评级口径仍需团队自行约定，专门的风险台账能力建议在实际部署时核验。
角色分工与各角色交付物
计划能否执行，取决于每个角色是否清楚自己交付什么、在什么节点交接。以下分工适用于一般规模的项目团队，角色可由同一人兼任，但职责不能空缺。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 项目经理 | 组织风险识别与评审，维护登记册整体质量，跟踪应对动作进度，主持复查 | 风险登记册、评审记录、复查纪要 | 识别会后移交责任人；每次复查后更新登记册 |
| 风险责任人 | 监控单条风险的触发条件，触发后启动应对动作，反馈执行结果 | 风险状态更新、触发记录、应对执行结果 | 触发时向项目经理报告；动作完成后提交完成标志 |
| 技术或业务负责人 | 提供影响判断的专业输入，设计可行的应对方案，评估动作的技术代价 | 影响评估意见、应对方案说明 | 评估阶段提供输入；方案确定后移交责任人执行 |
| 项目发起人或管理层 | 审批需要额外资源或跨部门协调的应对动作，处理升级事项 | 审批结论、资源调配决定 | 评审会上审批；升级时接收决策请求 |
交接的关键在于责任转移有记录。识别阶段由提出人描述风险，评估完成后移交风险责任人，移交时确认触发条件和应对动作已被对方理解；应对动作完成后，由责任人提交完成标志，项目经理核验后更新状态。需要资源投入的动作在评审会上由发起人审批，未获批准的动作要回到策略选择环节重新考虑，不能留在清单里悬空。
示例：一个进度风险如何写成应对计划
以下为演示情景，用于说明字段填写和动作拆解方式，不作为真实案例引用。
风险描述：核心模块依赖的外部组件供应商尚未确定最终交付日期，若其交付晚于计划节点两周以上，将导致联调阶段整体后移，影响上线里程碑。
触发条件：供应商在约定确认日后5个工作日内仍未书面确认交付日期，或确认日期晚于项目计划中的联调开始日前10个工作日。
评估与优先级：可能性中等，影响为进度维度的高影响，触及关键路径，定为高优先级。
策略选择：减轻为主、转移为辅。理由是该组件难以替换，规避成本过高；通过提前锁定交付承诺和准备备选方案降低影响，同时在合同中约定延期责任实现部分转移。
应对动作拆解：
- 动作一：与供应商召开交付确认会并取得书面交付日期，负责人为采购接口人，截止时间为本周五，完成标志为双方确认的交付计划邮件。
- 动作二：评估备选组件的适配工作量，负责人为技术负责人，截止时间为下周三，完成标志为适配评估结论文档。
- 动作三：在合同中补充延期交付的责任条款，负责人为项目经理，截止时间为本月末，完成标志为补充协议签署。
复查与关闭判断：该风险列入每周项目例会的固定复查项。供应商书面确认交付日期且不晚于联调开始前10个工作日时，风险降级并转为常规监控；触发条件满足时，责任人立即启动动作二并上报项目经理；若备选方案评估显示适配工作量超出可承受范围，则提交发起人决定是否调整上线里程碑。
计划落地与复查机制
计划定稿只是开始，保持有效依赖定期复查与事件驱动复查两条线并行。定期复查按项目节奏设定，例如每周例会过一遍高优先级风险的状态和触发条件，每月做一次全量登记册梳理；事件驱动复查在里程碑达成、范围变更、关键人员变动、外部依赖状态变化时立即触发，不等下一个复查周期。
触发条件被满足时的启动流程应当事先写清楚：责任人确认信号成立，在约定时限内启动对应应对动作，同时向项目经理报告；项目经理判断是否需要调整排期或申请资源，必要时提交发起人。启动过程要有记录，便于复查时判断应对是否及时。
风险转为已发生问题时，从登记册移交到问题清单，注明转化时间和已执行的应对动作，由问题处置流程接手。登记册中保留该条记录并标记状态，避免重复跟踪。若团队使用 ONES 的测试管理能力，已发生的缺陷可关联至迭代跟踪处置，与风险登记册形成前后衔接。
应对无效时的升级路径需要提前约定层级和时限：责任人执行动作后风险等级未下降，先由项目经理组织重新评估策略；仍无法控制时升级至项目发起人，由其决定追加资源、调整范围或变更里程碑。升级不是追责动作，判断依据是风险状态数据，而非个人表现。
完成检查：计划是否可执行的判断标准
定稿前逐项核对以下检查项，全部满足才视为达到可执行状态：
- 每条高优先级风险都有明确的应对策略、唯一责任人和可核验的完成标志。
- 需要投入资源的应对动作已进入项目排期，有具体时间点，并与相关里程碑或关键路径节点对齐。
- 每条风险的触发条件可观察、可判断，责任人能通过日常项目数据直接确认信号是否成立。
- 复查节奏已写入项目日历，事件驱动复查的触发情形已列明。
- 风险转为问题时的移交方式、应对无效时的升级层级和时限已明确。
- 计划经过项目经理、风险责任人、技术或业务负责人评审确认，需要资源投入的动作已获发起人审批。
- 登记册与问题清单边界清晰，没有同一事项在两处重复跟踪。
检查中发现缺项时，回到对应步骤补齐：缺触发条件回到第五步，缺排期回到第四步和第六步，缺审批回到评审环节。计划的可执行性最终体现在下一次复查时，每条风险都能给出状态、依据和下一步动作。
常见问题
风险应对计划制定完成后，多久复查一次比较合适？
复查节奏按项目周期和风险密度确定，常见做法是每周例会上过一遍高优先级风险的状态与触发条件，每月对全量登记册做一次梳理。除定期复查外，里程碑达成、范围变更、关键人员变动、外部依赖状态变化时应立即触发事件驱动复查，不必等到下一个周期。复查频率过高会占用过多会议时间，过低则触发条件可能被错过，可以按高优先级风险的跟踪数量调整。
风险责任人应该由项目经理兼任吗？
可以兼任，但要看风险数量和专业跨度。风险责任人需要对单条风险的触发条件持续监控，并在信号出现时启动应对动作，这要求其熟悉该风险涉及的业务或技术细节。项目经理兼任过多条风险的责任人时，监控容易流于形式。更稳妥的做法是把与具体模块、供应商或外部依赖相关的风险交给对应负责人，项目经理保留登记册维护和复查组织的职责。
风险已经发生，登记册里的记录应该删除还是保留？
保留并标记状态。风险发生后从登记册移交到问题清单处理，登记册中注明转化时间和已执行的应对动作，便于后续复盘判断应对是否及时有效。直接删除会导致同一事项在问题清单和登记册之间失去关联，复查时也无法追溯当初的评估是否准确。
应对动作需要资源投入但未获批准，应该怎么处理？
未获批准的动作不能留在清单里悬空。处理方式有两种：一是回到策略选择环节，改用成本更低的减轻措施或转为接受并预留应急储备；二是由项目经理整理影响判断和资源需求，提交发起人重新决策。无论哪种方式，登记册中都要记录最终结论和理由，避免复查时出现“计划里写了、实际没人做”的情况。
用项目管理工具跟踪风险应对动作时需要注意什么？
工具能解决动作进入排期、责任人和时间点可见的问题。如果团队使用 ONES，可以把风险应对动作作为工作项纳入项目计划，借助任务依赖和里程碑标记关键应对节点，并通过计划与执行的偏差对比提早发现风险信号；已发生的缺陷可关联至迭代跟踪处置。风险登记册的字段设计、评级口径和触发条件仍需团队自行约定，专门的风险台账与预警能力建议在实际部署时核验。
