风险登记册把项目中尚未发生、但可能影响目标的不确定性逐条记录下来，便于团队提前判断和跟踪。本文提供一张可直接复制到电子表格或文档中的空白风险登记册，逐字段说明填写口径，区分必填与选填，并用一条完整记录示范如何填写，最后给出复查、关闭和字段调整的维护规则。
要点总览（TL;DR）
- 空白风险登记册包含表级信息区（项目名称、版本、更新日期、维护人）和13个记录字段，可直接粘贴到电子表格或文档表格中使用。
- 必填字段为风险编号、风险描述、发生概率、影响程度、风险等级、应对策略、责任人、复查日期、当前状态；风险类别、触发条件、应对动作、备注按需启用。
- 风险等级由概率与影响按团队约定的矩阵组合得出，同一项目内所有风险须使用同一套档位口径。
- 填写示例演示一条外部依赖风险从识别、定级到复查、转为问题的完整过程，示例为演示情景。
- 维护重点是按等级设定复查间隔、区分关闭与转为问题、字段调整时递增版本号，并让复查日期、责任人、当前状态保持可筛选。
可复制空白风险登记册模板
下面这张表分为两部分：表级信息区记录登记册本身的身份，记录区逐条登记风险。复制时把表级信息放在表格上方或单独一个工作表，记录区保留表头与空白行即可开始使用。
表级信息区
| 项目名称 | 登记册版本 | 更新日期 | 维护人 |
|---|---|---|---|
| V1.0 |
表级信息的作用是让任何人拿到这份登记册时，能判断它属于哪个项目、处于哪一版、由谁负责更新。项目名称写全称或团队内部通用简称；登记册版本从 V1.0 起编，每次结构性调整递增；更新日期填最近一次实际修改的日期；维护人写具体姓名，不写岗位代称。
空白记录表
| 风险编号 | 风险类别 | 风险描述 | 触发条件 | 发生概率 | 影响程度 | 风险等级 | 应对策略 | 应对动作 | 责任人 | 复查日期 | 当前状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | ||||||||||||
| R-002 |
这张表可以直接粘贴到 Excel、在线表格或文档的表格中。粘贴后建议冻结表头行，并按风险等级设置条件格式，让高等级风险在视觉上先被看到。风险编号按 R-001、R-002 顺序编排，编号一经分配不再复用，即使该风险已关闭也保留原编号，便于追溯历史讨论。
每个字段填什么：字段说明
字段说明解决的是“同一条风险，两个人填出来不一样”的问题。下表给出每个字段的含义、填写口径和示例值，其中概率、影响与等级三项需要团队事先约定统一口径，否则等级判断会失去可比性。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 风险编号 | 登记册内唯一标识 | 前缀加顺序号，关闭后不复用 | R-007 |
| 风险类别 | 风险来源的分类 | 使用团队约定的固定选项，如进度、成本、质量、资源、外部依赖 | 外部依赖 |
| 风险描述 | 不确定性及其可能后果 | 写“某原因可能导致某后果”，一句话说清，不写解决方案 | 第三方接口交付延迟，可能导致联调阶段整体后移 |
| 触发条件 | 可观察到的预警信号 | 写成可判断的事实，避免“情况恶化”这类模糊表述 | 接口文档在约定日期前一周仍未提供 |
| 发生概率 | 风险发生的可能性 | 按团队约定的档位取值，如高／中／低，或 1–5 分 | 中 |
| 影响程度 | 一旦发生对目标的冲击 | 按同一维度评估，如对工期的影响天数或对成本的幅度 | 高 |
| 风险等级 | 概率与影响的组合结果 | 查团队约定的矩阵得出，不单独凭感觉填写 | 高 |
| 应对策略 | 处理风险的方向 | 从规避、转移、减轻、接受中选择一项 | 减轻 |
| 应对动作 | 落实策略的具体措施 | 写清做什么、谁做、何时完成 | 提前一周与供应商确认接口排期，准备本地模拟接口 |
| 责任人 | 对该风险跟踪与推动的人 | 写具体姓名，一人负责，可另设协助人 | 张明 |
| 复查日期 | 下次检查该风险的日期 | 按风险等级设定间隔，高等级更频繁 | 2025-06-20 |
| 当前状态 | 风险所处阶段 | 使用固定选项，如待评估、跟踪中、已缓解、已关闭、已转为问题 | 跟踪中 |
| 备注 | 补充信息 | 记录判断依据、相关链接或历史变更说明 | 供应商已口头确认排期，待书面回复 |
概率、影响与等级的判定口径
概率和影响需要先定档位，再用矩阵组合成等级。常见做法是各分三档：概率分为高、中、低，影响分为高、中、低，矩阵中“高×高”“高×中”“中×高”为高等级，“低×低”为低等级，其余为中等级。团队也可以改用 1–5 分打分，但打分标准要写进表级说明，例如影响 5 分对应工期延误超过两周。档位数量没有统一标准，关键是同一项目内所有风险使用同一套口径。
应对策略与应对动作的区别
应对策略回答“往哪个方向处理”，只有规避、转移、减轻、接受四类。规避是改变计划消除风险来源；转移是把后果转给第三方，如保险或合同条款；减轻是降低概率或影响；接受是不主动采取措施，但保留跟踪。应对动作回答“具体做什么”，必须落到可执行、可验收的动作上。只写策略不写动作，风险就会停留在纸面；只写动作不写策略，团队难以判断处理思路是否合理。
必填与选填：最小可用字段集
字段越多，登记册越难坚持维护。建议先保证必填字段完整，再根据项目复杂度增加选填字段。判断一个字段是否必填的标准是：缺少它，是否会导致这条风险无法被跟踪或无法被决策。
| 字段 | 必填／选填 | 理由或适用场景 |
|---|---|---|
| 风险编号 | 必填 | 用于引用、讨论和追溯，缺少则无法定位具体风险 |
| 风险描述 | 必填 | 登记册的核心内容 |
| 发生概率 | 必填 | 等级判断的输入之一 |
| 影响程度 | 必填 | 等级判断的输入之一 |
| 风险等级 | 必填 | 决定复查频率和上报层级 |
| 应对策略 | 必填 | 表明团队对风险的处理方向 |
| 责任人 | 必填 | 无人负责的风险不会被跟踪 |
| 复查日期 | 必填 | 保证风险被周期性检查 |
| 当前状态 | 必填 | 区分仍在跟踪与已结束的风险 |
| 风险类别 | 选填 | 风险数量较多、需要按来源汇总时启用 |
| 触发条件 | 选填 | 需要提前设置预警信号时填写，高等级风险建议必填 |
| 应对动作 | 选填 | 策略为减轻或规避时建议填写，接受类风险可暂缺 |
| 备注 | 选填 | 需要记录判断依据或变更历史时使用 |
精简版字段集
小团队或短周期项目可以使用精简版，只保留风险编号、风险描述、发生概率、影响程度、风险等级、应对策略、责任人、复查日期、当前状态九个字段。这套字段足以支撑“识别—判断—指派—复查”的闭环。当项目出现跨团队依赖、外部供应商或合规要求时，再补充风险类别和触发条件，便于分类汇总和提前预警。
字段增减的判断依据
增加字段前先问三个问题：这个字段是否会改变某条风险的等级或处理方式；是否有人会实际读取它；维护它需要多少额外时间。三个问题都答不上来的字段，先不加。反过来，如果某类信息反复出现在备注里，说明它已经具备独立成列的价值，可以提升为正式字段，并在版本记录中注明。
填写示例：一条完整风险记录
以下是一条演示情景中的完整记录，项目为某业务系统的版本升级，风险来自外部接口供应商。示例覆盖模板中的全部必填字段，并包含选填字段，便于对照填写。
| 字段 | 填写内容 |
|---|---|
| 风险编号 | R-003 |
| 风险类别 | 外部依赖 |
| 风险描述 | 第三方支付接口交付延迟，可能导致联调阶段整体后移，影响版本按期上线 |
| 触发条件 | 约定交付日前一周仍未收到接口文档与测试环境账号 |
| 发生概率 | 中 |
| 影响程度 | 高 |
| 风险等级 | 高 |
| 应对策略 | 减轻 |
| 应对动作 | 本周内与供应商确认书面排期；同步搭建本地模拟接口，保证联调不因外部延迟完全停滞 |
| 责任人 | 张明 |
| 复查日期 | 2025-06-20 |
| 当前状态 | 跟踪中 |
| 备注 | 供应商已口头确认排期，待书面回复后更新触发条件判断 |
取值理由与等级计算
概率定为“中”，依据是供应商过往合作中偶有延迟但未造成严重阻塞；影响定为“高”，依据是联调位于关键路径，延迟一周以上会直接压缩测试时间。按“高×中”查矩阵得出高等级，因此复查间隔设为两周一次，并在项目周会上作为重点风险通报。若供应商书面确认排期且交付正常，概率可下调为“低”，等级随之降为中，复查间隔可放宽到一个月。
复查与状态更新动作
到了复查日期，责任人需要做三件事：核对触发条件是否出现；确认应对动作是否完成；根据新信息更新概率、影响和等级。如果接口文档按期到位，状态改为“已缓解”并记录依据；如果交付已确定延迟且开始影响联调，状态改为“已转为问题”，转入项目问题跟踪流程，登记册中保留原编号并注明转出日期。这条记录在关闭前不删除，保证风险历史可查。
调整与维护：让登记册持续可用
登记册的价值来自持续更新，而不是建立当天的完整度。维护工作集中在复查节奏、状态流转、字段调整和版本记录四件事上，每件事都应有明确的触发条件和负责人。
复查节奏与复查日期设置
复查间隔按风险等级设定：高等级两周一次，中等级一个月一次，低等级可在阶段节点复查。复查日期填具体日期而非“下周”，并在每次复查后顺延到下一个周期。项目进入关键阶段，如上线前两周，可临时缩短全部高等级风险的复查间隔。复查时若无变化，也要更新复查日期，让登记册反映最近一次检查时间。
关闭、降级与转为问题
风险关闭的前提是触发条件不再可能出现，或应对动作已完成且后果已被消除，关闭时在备注中写明依据。降级适用于概率或影响下降但风险仍存在的情况，更新等级和复查间隔即可，不改变编号。当风险已经发生并造成实际阻塞，应转为项目问题，按问题管理流程指派处理，登记册中状态改为“已转为问题”并注明转出日期。把已发生的问题继续留在风险登记册里跟踪，会混淆两类事项的处理节奏。
字段随阶段调整与版本记录
项目早期风险以进度和资源为主，进入测试阶段后质量和外部依赖类风险增多，可以相应启用风险类别和触发条件字段。每次调整字段结构，在表级信息区递增版本号，并在备注或单独的变更说明中记录调整内容和原因，例如“V1.1 增加触发条件字段，用于上线前预警”。记录区内的单条风险变更不需要升版本，靠备注和复查日期体现即可。
与例会和评审的衔接
把登记册放进固定会议节奏，维护成本会明显下降。项目周会只过一遍高等级风险和本周到期复查项，避免逐条朗读；阶段评审前由维护人汇总等级分布和状态变化，作为评审输入。登记册的承载方式可以是一份共享表格，也可以放在项目协作工具中。以 ONES 为例，ONES Wiki 支持通过模板库创建制式化文档，并记录页面版本、支持查看与回滚，适合承载登记册正文和版本记录；ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，提早识别风险和问题，可作为登记册中进度类风险的判断依据。风险条目本身的状态流转和到期提醒如何配置，需按团队实际使用的版本和工具能力确认。无论使用哪种工具，复查日期、责任人和当前状态三个字段都应保持可筛选，让下一次复查时能直接筛出到期项。
常见问题
风险登记册和项目问题清单需要分开维护吗？
建议分开。风险登记册记录尚未发生的不确定性，项目问题清单记录已经发生并造成阻塞的事项，两者的处理节奏和责任人不同。当某条风险已经发生并开始影响交付时，把登记册中的状态改为“已转为问题”，注明转出日期，再按问题管理流程指派处理。登记册中保留原编号，便于回溯这条风险从识别到发生的完整过程。
团队对概率和影响的判断经常不一致，怎么统一？
把档位定义写进表级说明，例如影响“高”对应工期延误超过两周或成本超支超过约定比例，概率“高”对应已有明确迹象且短期内可能发生。定档时要求填写人对照定义取值，并在备注中写明判断依据。等级由矩阵查得，不由个人感觉直接填写。项目启动时用两三条历史风险做一次校准，能明显减少后续分歧。
小团队字段填不全，可以先只填一部分吗？
可以先用精简版字段集：风险编号、风险描述、发生概率、影响程度、风险等级、应对策略、责任人、复查日期、当前状态。这九个字段足以支撑识别、判断、指派、复查的闭环。风险类别和触发条件在出现跨团队依赖、外部供应商或需要提前预警时再补充。字段增减的判断标准是缺少它是否会导致风险无法被跟踪或无法决策。
风险登记册放在共享表格里，还是放进项目协作工具？
两种方式都能用，区别在于版本记录和与项目数据的关联程度。共享表格上手快，适合风险数量少、参与人固定的项目。项目协作工具的优势是文档版本可追溯、风险条目能与计划或任务关联。以 ONES 为例，ONES Wiki 支持通过模板库创建制式化文档，并记录页面版本、支持查看与回滚，适合承载登记册正文和版本记录；ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，可作为进度类风险的判断依据。风险条目本身的状态流转和到期提醒如何配置，需按团队实际使用的版本确认。
风险关闭后，记录要不要从登记册里删掉？
不删除。关闭时把状态改为“已关闭”，在备注中写明关闭依据，例如触发条件已不可能出现或应对动作已完成且后果已消除。保留记录的价值在于阶段复盘时能看清哪些风险被识别过、处理方式是否有效，也能避免后续重复登记同一风险。风险编号一经分配不再复用，关闭的记录继续占用原编号。
