项目风险清单用于逐条登记尚未发生的不确定性，让团队在风险变成问题之前就能判断概率、影响和应对动作。一张可用的清单通常包含风险编号、风险描述、触发条件、发生概率、影响程度、风险等级、应对策略、责任人、复查日期和当前状态。本文提供一份可直接复制到表格工具中的空白模板，并说明每个字段的填写口径、必填项取舍、一条完整示例以及后续维护规则。
要点总览（TL;DR）
- 空白模板按“识别—评估—应对—跟踪”四组排列，共12列：风险编号、风险描述、触发条件、发生概率、影响程度、风险等级、应对策略、应对措施、责任人、复查日期、当前状态、备注。
- 必填项为风险编号、风险描述、发生概率、影响程度、风险等级、应对策略、责任人、复查日期、当前状态；触发条件与应对措施建议必填，备注选填。
- 填写顺序是先写清不确定事件及其后果，再评估概率与影响得出等级，然后选定规避、减轻、转移或接受并落到可验收的动作，最后指定责任人与复查日期。
- 维护上按等级设定复查周期，风险一旦实际发生就转为问题管理，原风险行关闭并注明去向；字段增删需同步更新填写说明。
- 清单需要多人协作时，可放入团队文档空间统一版本、分配读写权限，并与项目任务和计划偏差信息放在同一处对照。
可复制空白项目风险清单模板
下面的表头按“识别—评估—应对—跟踪”四组排列，复制到 Excel、在线表格或文档表格中即可使用。第一行是字段名，第二行起每行登记一条风险。示例行仅示意行结构，正式使用时替换为实际内容。
| 风险编号 | 风险描述 | 触发条件 | 发生概率 | 影响程度 | 风险等级 | 应对策略 | 应对措施 | 责任人 | 复查日期 | 当前状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | （填写不确定事件及其可能后果） | （填写可观察的预警信号） | 高/中/低 | 高/中/低 | （由概率与影响共同判定） | 规避/减轻/转移/接受 | （填写具体动作） | （填写姓名或角色） | YYYY-MM-DD | 待评估/跟踪中/已缓解/已关闭 | （选填） |
字段分组对应填写顺序：风险编号、风险描述、触发条件属于识别阶段；发生概率、影响程度、风险等级属于评估阶段；应对策略、应对措施、责任人属于应对阶段；复查日期、当前状态、备注属于跟踪阶段。复制模板后，向下插入空白行即可扩展，每条风险独占一行，编号连续递增，避免中途插入导致编号重复。
如果项目较小、风险数量有限，可以先把“备注”列隐藏或删除，保留其余列；如果风险需要跨团队汇总，建议保留全部列，便于不同项目按同一口径合并统计。
每个字段填什么：字段说明
字段的含义决定填写质量。下表逐项说明每个字段的填写口径和常见写法，模板、说明与后文示例使用同一套字段。
| 字段 | 填写口径 | 常见写法与注意事项 |
|---|---|---|
| 风险编号 | 清单内唯一标识，便于引用和追踪 | 采用“R-序号”格式，如 R-001；跨项目汇总时可加项目前缀 |
| 风险描述 | 写清不确定事件及其可能造成的后果 | “因某原因，可能导致某结果”，避免只写“进度风险”这类笼统词 |
| 触发条件 | 风险可能发生的前置条件或预警信号 | 写成可观察的事实，如“关键接口联调延期超过3个工作日” |
| 发生概率 | 在当前信息下风险发生的可能性 | 用高/中/低三档，团队内统一判定标准 |
| 影响程度 | 风险发生后对范围、进度、成本或质量的影响 | 同样用高/中/低，说明主要影响维度 |
| 风险等级 | 由概率与影响共同得出的优先级 | 可用“概率×影响”矩阵判定，高概率高影响为高等级 |
| 应对策略 | 处理风险的总体思路 | 规避、减轻、转移、接受四类，选其一 |
| 应对措施 | 落实策略的具体动作 | 写动作和完成标志，如“提前锁定备用供应商并完成资质审核” |
| 责任人 | 负责推动应对和复查的人 | 填具体姓名或明确角色，避免填“项目组” |
| 复查日期 | 下一次检查该风险状态的日期 | 填具体日期，高风险复查间隔更短 |
| 当前状态 | 风险在生命周期中的位置 | 待评估、跟踪中、已缓解、已关闭 |
触发条件与预警信号容易混淆。触发条件描述“什么情况下风险会真的发生”，预警信号描述“哪些早期迹象说明它正在逼近”。填写时可以把两者合并写在同一格，前半句写触发条件，后半句写可观察的预警信号，例如“若第三方组件停止维护（触发条件），则出现安全补丁缺失和升级受阻（预警信号）”。
概率、影响与等级的判定需要团队事先约定口径。常见做法是把概率分为高（大于60%）、中（30%—60%）、低（小于30%），影响按对里程碑或预算的偏离幅度分档，再用矩阵把两者映射为高、中、低等级。口径一旦确定，同一项目内保持一致，便于比较和排序。
应对策略分四类：规避是改变计划消除风险来源；减轻是降低概率或影响；转移是通过合同、保险或外包把后果转给第三方；接受是不主动干预，但保留应急储备并持续观察。责任人应具备推动措施所需的权限，复查日期要与风险等级匹配，高等级风险的复查间隔通常更短。
必填与选填：哪些字段不能空
必填项的作用是保证每条风险可追溯、可判断、有人负责。以下字段建议设为必填，留空会直接造成追踪缺口。
| 字段 | 必填/选填 | 留空的影响 |
|---|---|---|
| 风险编号 | 必填 | 无法在会议、文档和任务中准确引用该风险 |
| 风险描述 | 必填 | 无法判断风险性质，后续评估失去对象 |
| 发生概率 | 必填 | 无法排序优先级 |
| 影响程度 | 必填 | 无法判断需要投入多少应对资源 |
| 风险等级 | 必填 | 清单无法按优先级筛选，评审效率下降 |
| 应对策略 | 必填 | 风险被登记却无人处理，清单沦为记录本 |
| 责任人 | 必填 | 措施无人推动，复查无人发起 |
| 复查日期 | 必填 | 风险长期停留在初始状态，错过应对窗口 |
| 当前状态 | 必填 | 无法区分活跃风险与已关闭风险 |
| 触发条件 | 建议必填 | 缺少预警信号，风险只能被动发现 |
| 应对措施 | 建议必填 | 策略停留在方向层面，无法执行和验收 |
| 备注 | 选填 | 不影响追踪，可用于记录背景或关联链接 |
选填字段的适用场景主要是信息补充。备注可以记录风险来源、相关会议结论或关联文档位置；在风险数量少、团队规模小的项目中，触发条件和应对措施也可以先简写，待风险升级为高等级时再补全。项目规模较大、涉及多方协作时，建议把触发条件和应对措施一并设为必填，因为跨团队交接更依赖书面信息。
字段取舍的原则是：影响“能否判断优先级”和“能否找到负责人”的字段必须保留；只影响阅读便利的字段可以选填。即便精简，风险编号、风险描述、风险等级、责任人、复查日期和当前状态这六项也不宜省略。
填写示例：一条完整风险记录
以下示例为演示情景，用于说明各字段如何配合，非真实客户案例。
| 字段 | 示例取值 |
|---|---|
| 风险编号 | R-007 |
| 风险描述 | 核心支付接口依赖的第三方服务若在促销期出现限流，可能导致下单失败率上升，影响大促期间的成交和用户信任 |
| 触发条件 | 第三方服务调用错误率连续两天超过1%，或对方发布限流公告 |
| 发生概率 | 中 |
| 影响程度 | 高 |
| 风险等级 | 高 |
| 应对策略 | 减轻 |
| 应对措施 | 提前与第三方确认促销期限流额度；准备降级支付通道并完成一次切换演练，演练通过作为完成标志 |
| 责任人 | 支付模块负责人（填写具体姓名） |
| 复查日期 | 促销开始前两周 |
| 当前状态 | 跟踪中 |
| 备注 | 关联接口监控看板和降级方案文档 |
逐项看这条记录：风险描述写明了“第三方限流”这一不确定事件和“下单失败率上升”这一后果，读者不看上下文也能理解；触发条件给出了可量化的错误率阈值和对方公告两种信号，便于监控发现；概率定为中，是因为促销期限流有历史先例但并非必然发生；影响定为高，是因为支付失败直接冲击成交；按高概率高影响对应高等级的矩阵口径，等级为高。
应对策略选“减轻”，因为无法消除对第三方的依赖，但可以通过额度确认和降级通道降低发生时的损失；应对措施写成了可验收的动作，而不是“关注第三方服务”这类无法判断完成与否的表述；责任人落到具体角色，复查日期设在促销前两周，留出演练和调整时间；状态为“跟踪中”，表示风险已识别并已有应对安排，尚未缓解。
模板的调整与维护方法
风险清单的价值在持续更新。首次填写完成后，需要把复查、状态更新、关闭判定和字段调整纳入项目例行节奏。
- 复查周期：高等级风险按周复查，中等级风险每两周复查，低等级风险按月复查；临近里程碑或关键决策点时，对所有活跃风险做一次集中复查。复查时更新概率、影响和等级，并顺延下一次复查日期。
- 状态更新规则：风险被识别但尚未评估时记为“待评估”；已有应对措施并进入观察时记为“跟踪中”；触发条件不再具备或影响已降到可接受范围时记为“已缓解”；风险不再存在或已处理完毕时记为“已关闭”。每次状态变化都应在备注中写明依据和日期。
- 关闭与转为问题的边界：风险指尚未发生的不确定性，一旦触发条件成立、影响已经实际产生，就应转为问题登记和处置，原风险行标记为已关闭并注明转为哪条问题记录。已发生的阻塞、缺陷和事故不进入风险清单，避免清单混杂两类对象。
- 字段增删原则：新增字段应能回答一个明确的追踪问题，例如增加“关联里程碑”以便按阶段汇总；删除字段前确认没有评审或汇报依赖该列。字段调整后同步更新填写说明，保持模板、说明和示例一致。
- 评审参与角色：清单评审通常由项目经理组织，模块负责人提供技术与执行判断，业务或产品负责人确认影响口径，必要时邀请采购、法务等参与转移类风险的评估。评审输出是更新后的清单和明确的责任分工。
当清单需要多人协作维护时，可以把模板放入团队文档空间统一版本，并按角色分配读写权限，避免多人同时修改造成覆盖。ONES Wiki 支持使用模板库一键创建制式化文档，页面版本可随时查看与回滚，文档还能关联项目任务并嵌入任务进度和报表，适合把风险清单与项目执行信息放在同一处对照。对于使用项目计划和里程碑基线的团队，ONES 瀑布项目管理解决方案支持实时对比计划与执行的偏差，可把偏差信号回填到风险清单的触发条件中，帮助更早识别风险。具体模板形态和字段配置以实际使用环境为准。
常见问题
风险清单里的“触发条件”和“预警信号”要分开两列吗？
不必强制拆成两列。触发条件回答“什么情况下风险会真的发生”，预警信号回答“哪些早期迹象说明它正在逼近”，两者可以合写在同一格：前半句写触发条件，后半句写可观察的预警信号。例如“若第三方组件停止维护，则出现安全补丁缺失和升级受阻”。如果项目需要监控多个指标，也可以拆成两列，但拆开后要保证每列都有明确的判定阈值，否则容易变成描述性文字。
风险等级用高/中/低三档够用吗，需要更细的分级吗？
多数项目用三档足够，前提是团队事先约定概率和影响的判定口径，并用同一张矩阵映射等级。风险数量多、需要跨项目汇总排序时，可以扩展到五档或改用数值评分，但档位越多，判定分歧越大，需要更详细的评分说明。无论几档，同一项目内应保持一致，并在模板说明中写清每档对应的概率区间和影响幅度，避免不同人按各自理解打分。
风险已经发生并造成延期，这条记录应该怎么处理？
风险指尚未发生的不确定性。一旦触发条件成立、影响已经实际产生，就应转为问题登记和处置，原风险行标记为“已关闭”，并在备注中注明转为哪条问题记录，保留追溯关系。已发生的阻塞、缺陷和事故直接进入问题管理，不新增风险行，避免清单里同时混着“可能发生”和“已经发生”两类对象，导致评审时判断标准不一致。
小团队风险不多，能不能只保留几列？
可以精简，但影响“能否判断优先级”和“能否找到负责人”的字段应保留。风险编号、风险描述、风险等级、责任人、复查日期和当前状态这六项不宜省略；备注可以删除，触发条件和应对措施可以先简写，待风险升级为高等级时再补全。团队规模变大或需要跨团队交接时，建议恢复完整字段，因为书面信息越少，交接时越依赖口头补充。
把风险清单放进协作工具维护，需要注意什么？
重点是版本和权限。多人同时编辑同一份表格容易互相覆盖，可以放入团队文档空间统一版本，按角色分配读写权限，并保留页面历史以便回滚。ONES Wiki 支持使用模板库一键创建制式化文档，页面版本可随时查看与回滚，文档还能关联项目任务并嵌入任务进度和报表，适合把风险清单与执行信息放在同一处对照。使用项目计划和里程碑基线的团队，还可以把计划与执行的偏差信号回填到触发条件中。具体模板形态和字段配置以实际使用环境为准。
