项目风险应对计划模板可以用一张表承载：风险编号、风险描述、风险类别、发生概率、影响程度、风险等级、应对策略、具体应对动作、责任人、触发条件、完成时限、验证方式和状态。其中风险描述、应对策略、责任人、触发条件、验证方式五项最容易写得含糊，本文给出空白表、逐字段填写口径和一条完整示例，照着填即可。
要点总览（TL;DR）
- 模板用一张表承载：风险编号、风险描述、风险类别、概率、影响、等级、应对策略、具体应对动作、责任人、触发条件、完成时限、验证方式、状态，另加备注与更新日期。
- 风险描述按“原因—事件—后果”三段写；应对策略从规避、转移、减轻、接受中选一类并写明理由；责任人填单一到岗人。
- 触发条件写成可观测的阈值或事件，并与风险描述中的原因对应；验证方式写清证据、确认人和确认时点三要素。
- 必填字段覆盖编号、描述、类别、概率、影响、等级、策略、责任人和状态；具体应对动作、触发条件、完成时限、验证方式按策略与风险等级条件必填。
- 模板按项目规模裁剪列，按周或里程碑评审更新状态，关闭需验证证据，已造成阻塞的条目转入问题管理并保留记录。
可复制的风险应对计划空白模板
下表可直接复制到文档或表格工具中使用。列顺序按“识别—评估—应对—跟踪”排列，填写时从左往右推进，避免只写风险名称就跳过应对设计。
| 风险编号 | 风险描述 | 风险类别 | 发生概率 | 影响程度 | 风险等级 | 应对策略 | 具体应对动作 | 责任人 | 触发条件 | 完成时限 | 验证方式 | 状态 | 备注 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | ||||||||||||||
| R-002 | ||||||||||||||
| R-003 |
表格之外建议保留三项表头信息：项目名称、模板版本号、最近评审日期。这三项不占行，放在表格上方，便于归档时区分不同项目、不同版本的风险清单。
字段较多时，可把“备注”和“更新日期”合并为一列“跟踪记录”，按日期追加简短说明，适合条目多、更新频繁的项目。字段名保持一致，后续汇总和筛选才不会错位。
各字段的含义与填写口径
字段填写的共同要求是写到“别人接手也能执行”的颗粒度。下面按字段说明写什么、写到什么程度，重点展开五个易错字段。
风险描述：按原因—事件—后果三段写
风险描述要让人看清风险从哪来、可能发生什么、造成什么影响。推荐句式：“由于〔原因〕，可能发生〔事件〕，导致〔后果〕。”例如“由于核心接口依赖的外部服务未承诺响应时长，联调阶段可能出现接口超时，导致上线日期推迟”。原因写可控或可观察的来源，事件写尚未发生的不确定情形，后果写对进度、成本、质量或范围的具体影响。只写“接口有风险”无法支撑后续应对设计。
应对策略：四类选其一并写明理由
应对策略从规避、转移、减轻、接受四类中选择。规避是改变方案消除风险来源；转移是把后果和责任部分转给第三方，如合同条款、保险；减轻是降低发生概率或影响程度；接受是不主动采取动作，但保留监控。填写时在策略后补一句理由，例如“减轻：提前锁定备用供应商，将单点依赖降为双源”。只填类别不填理由，评审时无法判断选择是否成立。
责任人：填单一到岗人
责任人填一位具体到岗的人，不填部门或团队名称。部门无法被追问进度，也无法在触发条件出现时第一时间响应。若一项风险需要多人协作，责任人填牵头人，其余角色写入具体应对动作或备注。责任人应具备调动相关资源的权限，或在备注中注明升级路径。
触发条件：写成阈值或可观测事件
触发条件回答“什么时候启动应对动作”。写成可观测的阈值或事件，例如“供应商周报连续两周延迟超过3个工作日”“关键路径任务偏差超过5个工作日”“缺陷密度达到每千行8个”。避免写“情况恶化时”“进度紧张时”这类无法判定的表述。触发条件与风险描述中的原因对应：原因指向什么，触发条件就监控什么。
验证方式：写清证据、确认人和确认时点
验证方式说明应对动作执行后，用什么证据证明风险已被控制或消除。三要素缺一不可：证据，如测试报告、合同补充条款、供应商书面承诺、连续两周的进度数据；确认人，通常为责任人的上级或质量角色；确认时点，如“应对动作完成后3个工作日内”或“下个里程碑评审时”。只写“跟踪观察”不构成验证。
概率、影响与等级的评级口径
概率和影响建议用统一的三级或五级刻度，并在模板附注中固定含义。例如概率分高、中、低，分别对应“大概率在本阶段发生”“有可能发生”“发生可能性较小”；影响分高、中、低，对应“影响里程碑或关键交付”“影响局部计划”“影响有限可内部消化”。风险等级由概率与影响交叉得出，可先用简单矩阵：高概率高影响为高，其余按组合降级。刻度一旦确定，全项目统一使用，避免不同人各按各的标准打分。
必填与选填字段的划分
字段不必一次全部填满，但核心字段缺失会让风险条目失去跟踪价值。按下表划分三档，项目启动时可先按必填字段建表，随风险等级上升逐步补齐。
| 字段 | 填写要求 | 说明 |
|---|---|---|
| 风险编号 | 必填 | 唯一且不复用，关闭后编号保留 |
| 风险描述 | 必填 | 按原因—事件—后果书写 |
| 风险类别 | 必填 | 进度、成本、质量、范围、资源、外部依赖等 |
| 发生概率 | 必填 | 按统一刻度评级 |
| 影响程度 | 必填 | 按统一刻度评级 |
| 风险等级 | 必填 | 由概率与影响交叉得出 |
| 应对策略 | 必填 | 四类选一并写理由 |
| 责任人 | 必填 | 单一到岗人 |
| 具体应对动作 | 条件必填 | 策略为规避、转移、减轻时必填；接受时可写监控动作 |
| 触发条件 | 条件必填 | 策略为减轻或接受时必填；已提前完成规避动作的可注明“不适用” |
| 完成时限 | 条件必填 | 有明确应对动作时必填 |
| 验证方式 | 条件必填 | 中高风险必填；低风险可简化为评审确认 |
| 状态 | 必填 | 开放、监控中、已触发、已关闭、已升级 |
| 备注 | 选填 | 记录升级路径、关联事项等 |
| 更新日期 | 选填 | 建议每次修改时填写 |
高风险条目加严要求：具体应对动作、触发条件、完成时限、验证方式四项全部必填，且验证方式须写明确认人；同时建议在备注中记录升级路径，明确风险扩大时向谁报告、在多长时间内报告。低风险条目可只填必填字段，状态保持“监控中”，在例行评审时复核。
一条完整填写示例：从风险描述到验证方式
以下示例为演示情景，用于说明字段之间的联动关系，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 风险编号 | R-007 |
| 风险描述 | 由于支付渠道方尚未确认新结算规则的生效时间，上线前可能出现结算金额计算错误，导致首月对账返工并影响回款 |
| 风险类别 | 外部依赖 |
| 发生概率 | 中 |
| 影响程度 | 高 |
| 风险等级 | 高 |
| 应对策略 | 减轻：提前取得渠道方书面规则说明，并在测试环境完成对账演练，降低上线后返工概率 |
| 具体应对动作 | 1. 向渠道方索取结算规则书面确认；2. 按新规则在测试环境跑通一笔完整对账；3. 准备回退到旧规则的开关方案 |
| 责任人 | 结算模块负责人（到岗人姓名） |
| 触发条件 | 上线前10个工作日仍未收到渠道方书面规则确认，或测试环境对账结果与预期差异超过1笔 |
| 完成时限 | 上线前5个工作日完成全部应对动作 |
| 验证方式 | 以渠道方书面确认函和测试环境对账通过记录为证据，由项目质量负责人于上线前3个工作日确认 |
| 状态 | 监控中 |
| 备注 | 若触发条件出现，升级至项目负责人决策是否延期上线 |
| 更新日期 | 示例日期 |
这条示例体现了三组对应关系。风险描述中的原因“渠道方未确认生效时间”对应触发条件中的“未收到书面确认”；风险描述中的后果“对账返工、影响回款”对应影响程度评为高。应对动作中的“取得书面确认、跑通对账、准备回退开关”对应验证方式中的“确认函与对账记录”，验证证据正是应对动作的产出物。责任人填到岗人，备注写升级路径，触发条件一旦出现即可按路径上报。
模板的调整与维护方法
模板用起来之后，需要按项目规模裁剪字段，并按固定节奏更新状态，否则风险表会变成一次性文档。
按项目规模增减列
小型项目可合并概率与影响为一列“风险等级”，保留风险描述、应对策略、责任人、触发条件、验证方式、状态六列即可运转。中大型项目保留完整字段，并增加“关联里程碑”“升级对象”两列。跨团队项目可再加“影响范围”列，标注受影响的团队或系统。裁剪时保持字段名不变，便于不同项目之间汇总。
评审节奏与状态更新
建议在每周例会或每个里程碑评审时过一遍风险表，逐条确认状态是否变化、触发条件是否出现、应对动作是否按期完成。状态更新规则固定为：新识别为“开放”；应对动作在执行中为“监控中”；触发条件出现为“已触发”，此时启动应对动作并记录启动日期；验证通过为“已关闭”。更新日期随每次修改填写。
关闭与升级为问题
风险关闭需有验证证据，不能仅凭主观判断。触发条件出现且已造成实际阻塞的事项，转入项目问题管理流程跟踪处置，风险表中该条状态改为“已升级”，并在备注中注明关联问题编号，保留记录以便复盘。已关闭和已升级的条目不从表中删除，按状态筛选查看。
版本与归档管理
模板本身建议标注版本号，字段调整时升版并在表头记录变更说明。项目收尾时，将最终版风险表随项目文档归档，保留关闭条目的验证证据链接或编号。归档后的风险表可作为同类项目识别风险的参考，但评级刻度需按新项目重新确认。
当风险条目需要承载责任人、状态和评审流转时，可以把这张表落到工作项或项目文档中管理：每条风险作为一个工作项，责任人、状态、完成时限成为可筛选的字段，评审时直接按状态和等级查看待处理条目。ONES 支持围绕项目计划、任务和进度开展协同管理，并可通过计划与执行偏差的对比辅助识别风险；使用 ONES Assistant 时，还可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议，帮助管理者在风险扩大前介入。具体采用哪种承载方式，取决于团队已有的协作工具和评审习惯。
常见问题
风险描述里的“原因”和触发条件是不是重复了？
两者相关但作用不同。风险描述中的原因说明风险从哪里来，是识别阶段的判断；触发条件说明什么时候启动应对动作，是执行阶段的监控信号。写法上让触发条件监控原因所指的对象即可，例如原因写“外部服务未承诺响应时长”，触发条件就写“上线前10个工作日仍未收到书面响应时长承诺”。原因可以写得概括，触发条件必须可观测、可判定。
应对策略选了“接受”，还需要填具体应对动作和验证方式吗？
接受表示不主动改变方案，但仍需保留监控。此时具体应对动作可写监控安排，例如定期查看某项指标、在评审会上复核；触发条件通常必填，因为接受策略依赖触发条件来决定何时改变主意。验证方式在中高风险条目上仍建议填写，写明由谁在什么时点确认风险仍处于可接受范围。低风险条目可简化为评审确认。
一条风险涉及多个团队，责任人怎么填才不落空？
责任人填一位牵头到岗人，其余协作角色写入具体应对动作或备注。牵头人应具备调动相关资源的权限；若权限不足，在备注中写清升级路径，明确向谁报告、多长时间内报告。跨团队项目可增加“影响范围”列标注受影响的团队或系统，但责任人列仍保持单一姓名，便于追问进度和触发响应。
风险已经发生并造成阻塞，还留在风险表里吗？
转入项目问题管理流程跟踪处置，风险表中该条状态改为“已升级”，备注注明关联问题编号，记录保留不删除。这样既区分了尚未发生的不确定性与已发生的阻塞，也保留了复盘线索。已关闭条目同样保留，按状态筛选查看即可。
模板字段太多，小项目能不能只留几列？
可以裁剪。小型项目可把概率与影响合并为一列“风险等级”，保留风险描述、应对策略、责任人、触发条件、验证方式、状态六列即可运转。裁剪时保持字段名不变，便于与其他项目汇总。中大型项目保留完整字段，并可按需增加“关联里程碑”“升级对象”“影响范围”等列。
