项目风险应对要落到可执行的动作：为每个风险写清触发条件、影响对象和责任人，从规避、转移、减轻、接受中选择策略，再拆成任务、时间点和预算，按周期回看触发信号。风险发生转入问题处置，未发生则更新概率与影响。本文按识别登记、动作拆解、角色分工、跟踪回看、示例和检查的顺序展开，覆盖单个项目内的风险应对操作。
要点总览（TL;DR）
- 风险应对从结构化风险条目开始：每条风险写清触发条件、影响对象、概率与影响判断依据和一名具体责任人，再进入策略选择。
- 策略选择看三个问题：能否通过改变方案消除风险、谁最适合承担后果、剩余部分能否用前置动作降低，对应规避、转移、减轻、接受四类策略，可组合使用。
- 应对动作按输入、动作、输出、完成标志四段拆解，并挂到项目计划对应里程碑；触发信号要写明看什么、谁看、多久看一次。
- 项目经理牵头登记与回看，风险责任人监测信号并推动动作，职能负责人提供资源与验收，涉及预算追加或范围调整的方案由决策层审批。
- 风险按待评估、已定策、监测中、已发生、已关闭流转；信号确认风险成真后转入问题处置，风险条目保留并与问题条目关联，便于复盘。
风险应对先做什么：从风险登记表到应对策略
风险应对的起点是让风险条目具备可判断、可分配的条件。一句“供应商可能延期”无法直接安排动作，需要补充触发条件、影响对象、概率与影响判断、责任人四个要素，才能进入策略选择。
风险登记表的必要字段
风险登记表是后续所有动作的输入。字段不必多，但每个字段都要能支撑一个决策。建议至少包含以下内容：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 风险编号与名称 | 简短命名，便于在会议和任务中引用 | 唯一标识，避免口头描述漂移 |
| 风险描述 | 写“什么事件可能导致什么结果”，包含原因与后果 | 判断影响范围 |
| 触发条件 | 可观测的信号，如“关键物料到货晚于某日期”“接口联调连续两次失败” | 决定何时启动应对动作 |
| 影响对象 | 具体到交付物、里程碑、预算项或团队 | 确定应对动作的作用点 |
| 概率与影响判断 | 用高、中、低或团队约定的分级，注明判断依据 | 排序与选择策略 |
| 风险责任人 | 一名具体的人，负责监测信号和推动应对 | 避免责任悬空 |
| 应对策略与动作 | 策略类型加具体动作，后续章节展开 | 连接决策与执行 |
| 状态 | 待评估、已定策、监测中、已发生、已关闭 | 跟踪流转 |
概率与影响判断要写依据，例如“依据上季度同类供应商平均延期两周的历史记录”，而不是只填一个等级。依据让判断可以被复核，也方便风险变化时更新。
四类应对策略的适用情形
策略选择取决于风险是否在项目可控范围内、应对成本与潜在损失的比例，以及团队是否具备相应权限。四类策略的对照如下：
| 策略 | 适用情形 | 典型动作 | 需要注意 |
|---|---|---|---|
| 规避 | 风险后果严重且无法承受，或改变方案的成本低于承受损失 | 调整范围、更换技术路线、取消高风险环节 | 规避往往改变项目计划，需要决策层确认 |
| 转移 | 风险由第三方更有能力承担，或合同、保险可以覆盖 | 签订带违约条款的合同、购买保险、外包关键模块 | 转移的是财务后果，责任协调仍在项目内 |
| 减轻 | 风险无法消除，但可以降低概率或减小影响 | 增加测试轮次、提前备货、安排备份人员 | 要明确减轻到什么程度算完成 |
| 接受 | 风险影响在可承受范围内，或应对成本高于损失 | 预留应急预算、设定容忍阈值、持续监测 | 接受不等于不记录，仍需触发信号和责任人 |
一个风险可以组合使用多种策略，例如对核心模块同时采取减轻（增加测试）和接受（预留缓冲工期）。选择时先问三个问题：这个风险能否通过改变方案消除；如果不能，谁最适合承担后果；剩余部分能否通过前置动作降低。三个问题的答案通常直接指向策略类型。
把策略写成具体动作
策略名称本身不是动作。“减轻供应商延期风险”无法执行，“在合同签署前完成两家备选供应商的样品验证，验证不通过则启用第二供应商”才是可执行的动作。判断一条应对描述是否合格，可以看它是否包含动作对象、执行时点和完成标准。缺少任何一项，都容易在执行阶段变成口号。
把应对策略拆成可执行动作与触发信号
策略确定后，需要拆成有输入、有输出、有完成标志的动作，并设定触发信号。动作进入项目计划，触发信号进入监测清单，两者共同构成风险应对的执行层。
应对动作的拆解方式
每条应对动作按四段式填写：输入是什么、动作做什么、输出是什么、完成标志是什么。以“减轻关键人员流失风险”为例：输入是当前关键岗位清单和交接文档现状；动作是为每个关键岗位指定备份人员并完成一次交叉培训；输出是备份人员名单和培训记录；完成标志是备份人员能独立完成该岗位的核心操作并通过负责人确认。
拆解时容易出现的偏差是把动作写成持续状态，例如“持续关注人员稳定性”。持续关注无法判断是否完成，应改为有明确终点的动作，再配合触发信号做长期监测。
触发信号的设定与监测频率
触发信号要可观测、可记录，并且与风险描述直接相关。设定时回答三个问题：看什么指标或事件、由谁看、多久看一次。监测频率与风险的时间窗口匹配：临近里程碑的风险按周甚至按日回看，远期风险按月回看即可。
触发信号可以分为两类。一类是先行信号，出现在风险发生之前，例如供应商产能利用率上升、需求变更单数量连续两周增加；另一类是结果信号，风险已经部分发生，例如某任务实际进度落后计划超过约定天数。先行信号用于提前启动应对，结果信号用于确认风险是否已经转为问题。
与项目计划的衔接
应对动作需要进入项目计划，否则会在执行中被日常任务挤掉。衔接方式包括：把应对动作作为独立任务挂到对应里程碑下，标注风险编号；为需要预算的动作预留费用项；为需要外部配合的动作提前约定对方的时间窗口。采用瀑布或阶段式管理的项目，可以把应对动作纳入阶段计划，并用计划基线对比实际执行偏差，作为风险信号的一部分。ONES 瀑布项目管理支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，帮助团队更早看到需要关注的风险点；其项目计划支持按目标、交付物或阶段分解工作，便于把应对动作放到对应位置。
角色分工与交付物：谁负责、谁审批、谁跟踪
风险应对的责任要落到具体角色和具体交付物上。常见的问题是风险登记表由项目经理一人维护，应对动作却无人推动。明确分工后，每个环节都有对应的产出和确认人。
四类角色的职责
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 项目经理 | 牵头风险登记与排序，组织定策评审，维护状态和回看节奏 | 风险登记表、回看议程、状态更新记录 |
| 风险责任人 | 监测触发信号，推动应对动作执行，判断风险是否发生 | 触发信号监测记录、应对动作进展、风险发生报告 |
| 职能负责人 | 提供应对动作所需的人员、预算和技术方案，确认完成标准 | 资源承诺、技术方案确认、完成验收意见 |
| 决策层 | 审批涉及范围调整、预算追加或跨部门协调的应对方案 | 审批结论、决策记录 |
风险责任人应由最接近风险信号的人担任，而不是默认由项目经理兼任。例如技术风险的責任人可以是架构师，供应商风险的责任人可以是采购负责人。项目经理的角色是确保每个风险都有责任人，并让责任人按时回看。
各环节的交付物与审批路径
识别环节的交付物是完整的风险登记表，由项目经理汇总，风险责任人确认描述和触发条件。定策环节的交付物是应对计划，包含策略、动作、时间点和预算；涉及预算追加或范围调整的方案提交决策层审批，其余由项目经理和职能负责人确认。执行环节的交付物是动作进展和信号监测记录，由风险责任人更新。回看环节的交付物是回看纪要和状态变更记录，由项目经理归档。
升级路径需要提前约定：触发信号出现但应对动作未按计划启动时，风险责任人向项目经理升级；应对动作需要超出原定预算或跨部门资源时，项目经理向决策层升级。升级条件写进风险登记表，避免临时判断。
执行与回看：风险应对的跟踪节奏和状态流转
风险应对在执行期间需要固定的回看节奏和清晰的状态规则。回看解决“信号有没有出现”，状态流转解决“这个风险现在处于什么阶段、下一步交给谁”。
回看节奏与会议形式
回看频率按项目节奏设定。处于关键阶段的项目可以每周一次风险回看，每次不超过三十分钟，只覆盖状态为监测中和已定策的风险。议程建议固定为四项：上周触发信号监测结果、应对动作完成情况、需要升级的事项、本周新增或关闭的风险。回看输出纪要，记录状态变更和新增动作，而不是重复讨论已经定策的内容。
除定期回看外，里程碑评审和阶段验收也是自然的回看节点。这些节点上项目计划和实际执行的偏差集中暴露，适合集中更新风险的概率与影响判断。
风险状态的流转规则
| 状态 | 进入条件 | 离开条件 |
|---|---|---|
| 待评估 | 风险被识别并登记 | 完成概率影响判断和责任人确认 |
| 已定策 | 选定策略并形成应对动作 | 应对动作进入项目计划并开始执行 |
| 监测中 | 应对动作执行中或已就绪，等待信号 | 触发信号出现，或风险窗口过去且影响消除 |
| 已发生 | 触发信号确认风险成为现实 | 转入问题处置并完成交接 |
| 已关闭 | 风险窗口结束且未发生，或问题处置完成 | — |
状态变更要有记录人和时间。风险从监测中转为已发生时，风险责任人提交风险发生报告，说明实际影响、已执行的应对动作和剩余缺口，然后按问题处置流程交接。
风险转为问题后的交接
风险与问题的边界在于不确定性是否已经消除。风险发生时，不确定性变成确定的影响，后续工作转为问题处置：明确问题现象、影响范围、临时措施和根本原因分析。交接内容包括风险编号、已执行的应对动作、当前影响和责任人变更。风险条目保留并标记为已发生，问题条目单独建立，两者通过编号关联，便于复盘时看到风险应对是否起了作用。
在工具层面，风险登记、应对任务和状态更新需要有共同的承载位置。ONES 支持从项目到任务的多层级管理，统一安排工作任务并形成自下而上的进度反馈，应对动作可以作为任务挂到对应计划下；ONES Wiki 支持文档关联项目任务，风险登记表、回看纪要和复盘记录可以放在同一页面树中，并保留页面版本，方便追溯每次状态变更的依据。
一个完整示例：从识别到关闭走一遍
以下为演示情景，用于说明各字段如何填写和流转，不对应真实项目。
风险描述与策略选择
某系统升级项目计划在第三阶段完成数据迁移，依赖外部供应商提供迁移工具。项目组识别出一条风险：供应商迁移工具交付延迟，导致数据迁移窗口压缩，影响第三阶段验收。影响对象是第三阶段里程碑和验收计划，概率判断为中，依据是供应商上一版本工具曾延期十天交付；影响判断为高，因为迁移窗口压缩后回滚测试时间不足。风险责任人为采购负责人。
策略选择减轻加接受：减轻方面，提前要求供应商提供工具测试版本，并在内部环境完成一次试迁移；接受方面，在第三阶段计划中预留五天缓冲，并设定容忍阈值——工具交付晚于约定日期超过五天即启动备选方案。
应对动作、触发信号与责任人
| 要素 | 填写内容 |
|---|---|
| 应对动作一 | 输入：供应商合同交付条款；动作：要求供应商在约定日期前两周提供测试版本；输出：测试版本及试迁移记录；完成标志：内部环境试迁移通过，迁移负责人确认 |
| 应对动作二 | 输入：备选迁移方案清单；动作：评估并确认一套备选工具；输出：备选方案评估结论；完成标志：技术负责人确认可用 |
| 触发信号 | 供应商未在约定日期前两周提供测试版本；由采购负责人每周五确认一次 |
| 升级条件 | 工具交付晚于约定日期五天，采购负责人向项目经理和决策层升级 |
风险发生后的处置与关闭记录
执行到第三周时，供应商通知测试版本延迟十天，触发信号出现。风险状态从监测中转为已发生，采购负责人提交风险发生报告，说明试迁移尚未开始、备选方案已确认可用。项目经理决定启用备选工具，同时与供应商协商正式版本的交付时间。风险条目保留并关联新建的问题条目，问题处置由迁移负责人牵头。最终迁移在缓冲期内完成，第三阶段验收通过。关闭记录写明：风险实际发生，减轻动作中的备选方案评估起了作用，试迁移动作因信号出现过早未执行；复盘建议把供应商测试版本交付节点提前到合同签署时约定。
完成检查：风险应对是否做到位
以下清单用于阶段评审或项目收尾时逐项核对。每项都应有可查的记录，而不是口头确认。
风险条目与责任
- 每条风险都有触发条件、影响对象、概率与影响判断及判断依据。
- 每条风险都指定了一名具体责任人，责任人确认过描述和触发条件。
- 涉及预算、范围或跨部门协调的风险，审批记录可查。
应对动作与触发信号
- 每条应对动作写明了输入、动作、输出和完成标志。
- 应对动作已进入项目计划，挂到对应里程碑或阶段，需要预算的已预留费用项。
- 每个触发信号可观测、有监测人和监测频率，升级条件已写明。
回看与关闭证据
- 回看按约定频率执行，纪要记录了状态变更和新增动作。
- 状态为已发生的风险都有风险发生报告，并与对应问题条目关联。
- 已关闭的风险有关闭记录，写明未发生或处置完成的事实依据。
- 项目收尾时完成风险复盘，记录哪些应对动作有效、哪些信号设定需要调整。
清单核对中发现缺项，回到对应环节补齐即可，不必重做整套流程。风险应对的质量体现在每个风险都能回答三个问题：谁在看、看什么信号、信号出现后做什么。
常见问题
风险责任人应该由谁担任，项目经理可以兼任吗？
风险责任人应由最接近风险信号的人担任，例如技术风险由架构师负责、供应商风险由采购负责人负责。项目经理可以兼任部分风险的责任人，前提是他确实处在能第一时间看到信号的位置。项目经理更核心的职责是确保每条风险都有人负责，并在回看时检查责任人是否按时更新。若责任人长期无法推动应对动作，应考虑调整责任人，而不是让风险条目停留在无人推动的状态。
触发信号一直不出现，风险条目什么时候可以关闭？
关闭条件有两个方向：一是风险窗口结束且影响已消除，例如相关里程碑已完成、外部依赖已交付，此时由风险责任人提出、项目经理确认后关闭；二是风险已经发生并转入问题处置，问题处理完成后关闭对应风险条目。关闭时要在记录中写明依据，例如“第三阶段验收通过，供应商工具已交付并完成迁移”，避免只写“已关闭”三个字。长期挂着的风险应重新评估概率与影响，判断是否仍值得保留在登记表中。
风险发生转为问题后，原来的应对动作还要继续执行吗？
需要区分动作性质。已经执行且产生效果的动作，在风险发生报告中记录结果即可；尚未执行但仍有价值的动作，例如备选方案验证，可以并入问题处置继续推进；针对“防止风险发生”的预防性动作，风险成真后通常失去意义，应停止并在记录中说明。交接时把风险编号、已执行动作、当前影响和责任人变更一并写入问题条目，复盘时才能看清哪些应对起了作用。
小团队人手有限，风险登记和回看可以简化到什么程度？
可以简化形式，保留关键要素。风险登记表至少保留风险描述、触发条件、责任人、应对动作和状态五项；回看可以并入现有的周会，用十分钟过一遍监测中的风险，不单独组织会议。策略选择也不必每次都写完整对照，口头确认后把结论和依据记一行即可。需要保留的底线是：每条风险有具体的人负责、有可观测的信号、信号出现后有约定的动作，这三点缺失时简化就会变成无人跟踪。
应对动作需要预算或跨部门资源时，走什么流程？
这类动作超出项目经理的常规权限，应在定策阶段就提交决策层审批，审批材料包含风险描述、策略选择理由、动作内容和所需预算或资源、不处理的潜在影响。审批结论和决策记录归档到风险条目下。执行中如果实际需求超出原批准范围，按同样的路径重新升级，并把升级条件提前写进风险登记表，例如“备选方案启用需追加费用超过约定额度时升级”，减少临时判断。
