项目风险清单以“一行一个风险”的表格承载，核心信息分为四组：识别信息、风险描述、评估信息、应对与跟踪。本文提供一份可直接复制到表格工具或文档中的空白模板，逐字段说明填写口径，区分必填与选填，并用一条完整记录示范各字段如何互相呼应。清单用于记录尚未发生的不确定性；已经发生并造成阻塞的事项，转入问题管理处理。
要点总览（TL;DR）
- 项目风险清单按“一行一个风险”组织，核心字段分四组：识别信息、风险描述、评估信息、应对与跟踪。
- 最小可用清单只需风险编号、风险事件、概率、影响程度、风险等级、责任人、当前状态七项，其余字段随项目复杂度补充。
- 风险事件写“可能发生什么”，触发条件写“什么信号出现说明风险正在逼近”，两者分列才能让清单具备预警作用。
- 风险等级由概率与影响按团队约定的矩阵推导，等级决定复查频率：高等级每周、中等级每两周、低等级在里程碑节点复查。
- 风险已发生并造成阻塞时转为问题管理跟踪，在原记录标注转出，不在风险清单中继续挂账。
可复制的项目风险清单空白模板
下面的表头覆盖了风险从提出到关闭所需的全部核心信息。使用时把表头复制到 Excel、在线表格或文档表格中，每个风险占一行，编号保持唯一。示例行展示填写位置，正式使用时替换为真实内容。
| 风险编号 | 提出日期 | 提出人 | 风险事件 | 触发条件 | 影响环节 | 概率 | 影响程度 | 风险等级 | 评估日期 | 应对策略 | 责任人 | 截止日期 | 当前状态 | 复查记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | 2025-03-10 | （填写姓名） | （可能发生什么） | （什么信号出现说明风险正在逼近） | （受影响的阶段、交付物或系统） | 高/中/低 | 高/中/低 | 高/中/低 | 2025-03-10 | 规避/减轻/转移/接受 | （填写姓名） | （处理期限） | 待评估/监控中/应对中/已关闭 | （日期＋变化说明） |
字段的可选值建议在表格中做成下拉选项，减少填写随意性。概率与影响程度各分高、中、低三档即可起步；风险等级由两者组合得出，不必单独主观打分。当前状态限定为四个值：待评估表示刚提出尚未定级，监控中表示暂不采取动作但需定期查看，应对中表示已有措施在执行，已关闭表示风险已消除或已转为问题。复查记录每次更新写“日期＋一句话变化”，例如“2025-03-24 供应商仍未回复，概率上调为高”。
每个字段记录什么：字段说明与填写口径
字段填错最常见的原因是把不同性质的信息混在一列。下表逐字段说明含义、写法与易错点，其中风险事件与触发条件的区分是整张清单能否用于预警的关键。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 风险编号 | 清单内唯一标识 | 项目前缀加序号，如 R-001，关闭后不复用 | 多条风险共用一个编号，后续无法追溯 |
| 提出日期 | 风险被记录的时间 | 填写首次登记日期，不随更新改动 | 每次复查都改日期，丢失提出时间 |
| 提出人 | 识别该风险的人 | 填具体姓名，便于追问识别依据 | 填部门或“团队”，无人可追溯 |
| 风险事件 | 可能发生的不利情况 | 写“可能发生什么”，用“可能＋事件”句式，描述后果而非原因 | 写成已发生的问题，或只写“进度风险”这类笼统词 |
| 触发条件 | 风险正在逼近的可观察信号 | 写可观测的阈值或事件，如“关键接口联调延期超过 3 天” | 与风险事件重复，或写成“情况恶化”这类无法判断的表述 |
| 影响环节 | 受波及的阶段、交付物或系统 | 指向具体对象，如“验收测试”“支付模块” | 填“整个项目”，无法判断影响范围 |
| 概率 | 风险发生的可能性 | 按团队约定分高、中、低，评估时写明依据 | 凭感觉填写且从不更新 |
| 影响程度 | 一旦发生对目标的损害大小 | 从进度、成本、质量、范围中选最严重的一维定档 | 只考虑进度，忽略质量与合规影响 |
| 风险等级 | 概率与影响的组合结果 | 按团队约定的矩阵由两列推导，不单独主观打分 | 等级与概率、影响矛盾，如双高却定为低 |
| 评估日期 | 最近一次定级的时间 | 每次调整概率、影响或等级时同步更新 | 等级改了、日期未改，无法判断信息新旧 |
| 应对策略 | 计划采取的处理方式 | 从规避、减轻、转移、接受中选一，并写一句具体动作 | 只写“加强关注”，没有可执行动作 |
| 责任人 | 负责推动应对的人 | 填单一姓名，不用多人并列 | 写“项目组”，实际无人负责 |
| 截止日期 | 应对动作的完成期限 | 与复查节奏挂钩，到期必须给出结论 | 填项目结束日期，等于没有期限 |
| 当前状态 | 风险所处处理阶段 | 从四个约定值中选择，状态变化时更新 | 长期停留在“监控中”，无人推动 |
| 复查记录 | 历次复查的变化留痕 | 每次复查追加“日期＋变化说明”，不覆盖旧记录 | 只写“已复查”，没有信息量 |
概率、影响与等级的判定口径需要团队事先约定。常见做法是画一张三乘三矩阵：概率高且影响高为高等级，两者一高一中为中等级，其余为低等级。阈值由团队自定，重要的是同一项目内口径一致，并在评估日期栏留下定级时间，便于后续判断是否需要重新评估。风险事件与触发条件分列的价值在于：前者回答“怕什么”，后者回答“什么时候该行动”，只有触发条件可观测，清单才能从记录工具变成预警工具。
必填与选填：最小可用清单与扩展字段
字段过多是风险清单被弃用的主要原因。启动阶段只需保证每条风险能被理解、被定级、有人负责，其余字段随项目复杂度补充。
| 字段 | 最小可用清单 | 扩展建议 |
|---|---|---|
| 风险编号 | 必填 | — |
| 风险事件 | 必填 | — |
| 概率、影响程度、风险等级 | 必填 | — |
| 责任人 | 必填 | — |
| 当前状态 | 必填 | — |
| 提出日期、提出人 | 建议填写 | 跨团队协作、需要追溯识别来源时转为必填 |
| 触发条件 | 建议填写 | 高风险条目必填；作为预警依据时全部填写 |
| 影响环节 | 建议填写 | 多模块并行、影响范围需要区分时必填 |
| 应对策略、截止日期 | 建议填写 | 等级为高的风险必须写明策略与期限 |
| 评估日期、复查记录 | 建议填写 | 项目周期超过一个月时启用，用于判断信息时效 |
按项目规模取舍时，可以参考三条线：周期两周以内的小项目，用最小可用清单加触发条件即可；跨部门的中型项目，补齐提出人、影响环节、应对策略与截止日期；周期长、外部依赖多的项目，再启用评估日期与复查记录，并考虑增加“风险类别”“关联里程碑”“升级对象”等扩展字段。字段缺失时的处理原则是先留空并标注，不用猜测内容填充；空缺本身也是信息，复查时优先补齐高等级条目的空缺字段。若某个字段连续多个项目都无人填写，应删除而不是保留，保持模板精简。
填写示例：一条完整风险记录
下面是一条已填写的记录，演示各字段如何互相呼应。情景为演示用途，数值与名称均为示例。
| 字段 | 示例取值 | 取值理由 |
|---|---|---|
| 风险编号 | R-007 | 项目内顺序编号，便于在会议和文档中引用 |
| 提出日期 | 2025-03-10 | 首次登记时间，后续更新不改动 |
| 提出人 | 测试负责人李某 | 由最接近该环节的人提出，便于追问依据 |
| 风险事件 | 第三方支付接口可能无法在联调窗口内提供测试环境，导致支付模块验收延期 | 写“可能发生什么”及后果，未写成已发生问题 |
| 触发条件 | 联调开始前 5 个工作日仍未收到对方环境地址 | 可观测的时间阈值，到期即可判断是否启动应对 |
| 影响环节 | 支付模块联调、验收测试 | 指向具体阶段，便于评估影响范围 |
| 概率 | 中 | 对方此前有延迟记录，但尚未确认本次排期 |
| 影响程度 | 高 | 直接影响验收节点，属于进度维度的严重损害 |
| 风险等级 | 高 | 概率中、影响高，按团队矩阵定为高等级 |
| 评估日期 | 2025-03-10 | 与首次定级同步记录 |
| 应对策略 | 减轻：提前一周向对方确认排期，并准备模拟支付环境的备用方案 | 策略与等级匹配，高等级风险采取主动措施而非接受 |
| 责任人 | 开发负责人王某 | 单一责任人，负责对外沟通与备用方案落地 |
| 截止日期 | 2025-03-20 | 早于触发条件的时间点，留出应对余量 |
| 当前状态 | 应对中 | 已有措施在执行 |
| 复查记录 | 2025-03-17 对方确认排期，概率下调为低，等级调整为中；2025-03-24 环境已提供，风险关闭 | 每次复查追加日期与变化，保留完整轨迹 |
这条记录体现了等级与应对的对应关系：高等级风险配置了主动减轻措施和明确期限，并在两次复查中根据事实下调概率、最终关闭。复查节奏与等级挂钩，高等级风险每周复查一次，中等级每两周一次，低等级在里程碑节点复查即可。示例中的截止日期设在触发条件之前，是为了在信号出现前完成准备，而不是等到风险发生才行动。
当清单条目需要在多人之间流转时，可以把每条风险登记为可跟踪的工作项，指定责任人与状态，并在项目计划中持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险。ONES 在瀑布项目管理场景中提供这类围绕计划、分工与进度跟踪的协同能力；清单本身的字段与模板仍需团队按本文口径自行定义。若团队习惯在文档中维护清单，ONES Wiki 的页面模板库可用于创建制式化文档模板，版本记录支持随时查看与回滚，便于保留清单的历史形态。
模板的调整与维护方法
清单建立后需要一套轻量的维护规则，否则字段会逐渐失真、条目会长期挂账。以下规则可按项目实际情况裁剪。
- 字段增删看使用率与决策价值。连续两个复查周期无人填写、且不影响定级与应对决策的字段，删除；出现新的决策需求（如需要按供应商汇总风险）时增加对应字段，并在表头注明填写口径。
- 复查频率跟随等级。高等级每周复查，中等级每两周，低等级在里程碑节点复查。复查时至少更新评估日期与复查记录两列，概率或影响有变化时同步调整等级。
- 关闭要有依据。风险消除、触发条件已不可能出现，或已采取的措施使影响可接受，才可标记为已关闭，并在复查记录中写明关闭原因。
- 升级与转问题分开处理。风险逼近且需要更高层决策时，在复查记录中写明升级对象与时间；风险已经发生并造成阻塞，转为问题管理跟踪，在原记录中标注转出，不在风险清单中继续挂账。
- 归档与复盘。项目结束后将清单随项目文档归档，复盘时统计高等级风险的识别时间与关闭时间，检查触发条件是否真的起到了预警作用，据此调整下一项目的字段与阈值约定。
维护动作本身也应尽量少：一次复查只做“看信号、改状态、写一句记录”三件事，把精力留给高等级条目。清单的价值不在于字段齐全，而在于每条风险都有人负责、有期限、有可观察的触发信号，并且在项目推进中持续被查看和更新。
常见问题
小项目也要填满整张表吗？字段太多团队不愿意填怎么办？
不必填满。周期两周以内的小项目，用最小可用清单加触发条件即可：风险编号、风险事件、概率、影响程度、风险等级、责任人、当前状态，再加一列触发条件。字段过多是清单被弃用的主要原因，可以先按最小集合运行一两个周期，再根据实际决策需要补充字段。若某个字段连续多个项目都无人填写，直接删除比保留更有利于模板长期使用。
风险事件和触发条件总是写成一样的内容，怎么区分？
用两个问题分别检验：风险事件回答“怕什么”，写可能发生的不利情况和后果；触发条件回答“什么时候该行动”，写可观测的阈值或事件。例如风险事件是“第三方接口可能无法按时提供测试环境，导致验收延期”，触发条件则是“联调开始前 5 个工作日仍未收到环境地址”。如果触发条件写成“情况恶化”“进展不顺”这类无法判断的表述，说明还没有找到可观察的信号，需要回到具体环节重新识别。
风险等级应该由谁定，团队之间口径不一致怎么办？
等级由概率与影响按团队事先约定的矩阵推导，不由个人主观打分。常见做法是三乘三矩阵：概率高且影响高为高等级，一高一中为中等级，其余为低等级。口径不一致通常源于影响程度的判断维度不同，可以约定从进度、成本、质量、范围中选最严重的一维定档，并在评估日期栏留下定级时间。同一项目内保持口径一致，比追求精确的数值更重要。
风险已经发生并造成阻塞了，还留在风险清单里吗？
转为问题管理跟踪。风险清单只记录尚未发生的不确定性，事项已经发生并造成阻塞后，继续挂在清单里会让状态长期失真。处理方式是在原记录的复查记录中写明转出时间和原因，标注已转出，然后在问题管理中建立对应条目继续跟踪处置。若风险逼近但尚未发生、需要更高层决策，则在复查记录中写明升级对象与时间，仍保留在清单内。
清单条目需要在多人之间流转时，用什么方式承载比较合适？
可以把每条风险登记为可跟踪的工作项，指定责任人与状态，在项目计划中持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险。ONES 在瀑布项目管理场景中提供围绕计划、分工与进度跟踪的协同能力，清单本身的字段与模板仍需团队按本文口径自行定义。若团队习惯在文档中维护清单，ONES Wiki 提供页面模板库，可用于创建制式化文档模板，版本记录支持随时查看与回滚，便于保留清单的历史形态。
