项目风险识别清单要能直接用于核对，至少覆盖六个维度：来源与类别、触发条件与早期信号、影响对象与程度、概率与紧迫度、责任人与应对动作、证据与复查时点。清单按识别、评估、登记、复查四个阶段设置检查项，每项写明通过标准、证据要求和负责人，并标出未通过时不得进入下一阶段的阻断项。下文给出一套可逐项判断的清单结构，并说明谁在什么时点使用、如何避免照抄模板漏项。
要点总览（TL;DR）
- 风险识别清单至少覆盖六个维度：来源与类别、触发条件与早期信号、影响对象与程度、概率与紧迫度、责任人与应对动作、证据与复查时点。
- 清单按识别、评估、登记、复查四个阶段设置检查项，每项写明通过标准、证据要求和负责人，并标出未通过时不得进入下一阶段的阻断项。
- 通过标准要可观察、可核对，证据按项目名、检查项编号和日期命名留存，确认动作留下时间戳。
- 避免照抄的关键是把清单当提问工具：以 WBS、合同条款和干系人清单为线索逐条追问，并在阶段评审中固定留出补充新风险的时间。
- 已发生的问题转入问题管理流程，风险清单只保留尚未发生的事项，否则概率与影响判断会失真。
谁在什么时点使用这份风险识别清单
风险识别清单由项目经理维护版本，风险责任人、技术负责人、采购与商务接口人分别填写与自己职责相关的检查项。首次识别在计划阶段完成，此后每个阶段关口、里程碑前和重大变更评审后更新。清单本身要有版本号和修订记录，记录谁在何时增删了哪些检查项，避免多人修改后无法追溯。
不同角色负责的检查范围不同，按下表分工可以避免“大家都看一遍、没人真正核对”的情况。
| 角色 | 执行时点 | 负责的检查内容 |
|---|---|---|
| 项目经理 | 计划阶段首次识别；每个阶段关口 | 清单整体完整性、阻断项判定、复查时点是否到期、版本记录 |
| 技术负责人 | 计划阶段；技术方案变更评审 | 技术类风险的来源、触发信号与影响判断，技术应对动作的可行性 |
| 风险责任人 | 风险登记时；每次复查 | 本人负责条目的应对动作进展、状态更新、复查结论 |
| 采购与商务接口人 | 合同签订前；供应商变更时 | 供应商与合同类风险的识别、转移类应对（如保险、违约条款）的落实 |
| 质量与合规接口人 | 阶段评审；合规要求变化时 | 安全合规类风险是否识别、证据是否留存 |
里程碑前复查由项目经理发起，各风险责任人提交状态更新，项目经理汇总后判断清单是否满足完成条件。重大变更评审时，变更提出人需说明变更引入的新风险，并补录到清单中。
风险识别清单的六个核心维度
六个维度回答的是“风险从哪里来、怎么发现、影响什么、多大概率、谁来处理、凭什么说已处理”。每个维度下的检查项要能判断通过与否，不能只写“关注技术风险”这类无法核对的表述。
| 维度 | 检查内容 | 通过标准示例 | 证据要求 | 负责人 |
|---|---|---|---|---|
| 来源与类别 | 按技术、需求、资源、供应商、外部环境、组织与合规六类逐类追问，确认本项目在每类下是否有已识别条目或明确“无”的结论 | 六类均有结论，标“无”的类别写明判断理由 | 风险登记表条目；类别判断说明 | 项目经理 |
| 触发条件与早期信号 | 每个风险条目写明可观察的触发事件、指标阈值或前置条件 | 条目中的触发条件可被第三方观察或测量 | 指标定义、阈值来源、监控方式说明 | 风险责任人 |
| 影响对象与程度 | 标明影响落在进度、成本、范围、质量、安全合规、干系人关系中的哪些方面，并给出程度判断 | 影响对象明确，程度有估算依据（如工期天数、成本区间） | 估算过程记录、影响分析说明 | 技术负责人或对应领域接口人 |
| 概率与紧迫度 | 记录发生可能性的判断依据和时间窗口，区分“近期可能发生”与“长期存在” | 概率有依据来源，紧迫度对应到具体时间窗口 | 历史数据、专家判断记录、时间窗口说明 | 风险责任人 |
| 责任人与应对动作 | 每个风险指定一名责任人，明确应对策略属于规避、减轻、转移还是接受，并写出具体动作 | 责任人已确认，策略类型明确，动作可执行且有完成标志 | 责任人确认记录、应对计划条目 | 项目经理确认，责任人执行 |
| 证据与复查时点 | 登记依据可追溯，每条风险设定下次复查日期，复查后记录结论 | 依据可查，复查日期已设定，到期后有复查记录 | 登记依据附件、复查记录 | 风险责任人 |
来源与类别这一维度容易被简化成打勾。实际操作中，对每一类都要回答“本项目在这一类下具体可能出什么问题”，答不上来的类别要写明判断理由，而不是留空。概率与紧迫度的判断依据可以来自历史项目数据、供应商交付记录或专家判断，关键是写清依据来源，便于复查时复核。
分阶段检查项：从识别到复查的逐项核对
把六个维度落到阶段动作上，清单才具备可操作性。下表按识别、评估、登记、复查四个阶段列出检查项，可直接作为清单主体使用。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|---|
| 识别 | 按工作分解结构逐项追问：每个交付物在技术、资源、供应商上可能出什么问题 | WBS 中每个主要交付物均有对应追问记录 | 追问记录或会议纪要 | 项目经理、技术负责人 | 计划阶段 |
| 识别 | 按合同条款核对交付节点、验收标准、违约责任相关的风险 | 合同关键条款均有对应风险条目或“无风险”结论 | 合同条款对照表 | 采购与商务接口人 | 合同签订前、变更时 |
| 识别 | 按干系人清单核对关键干系人的期望与配合风险 | 关键干系人均有识别结论 | 干系人清单及结论 | 项目经理 | 计划阶段、阶段关口 |
| 评估 | 检查概率与影响判断是否有依据，是否区分已发生问题与未发生风险 | 每条风险有依据来源；已发生事项转入问题管理，不混入风险清单 | 判断依据记录；问题清单 | 风险责任人 | 识别完成后 |
| 登记 | 检查风险登记项字段是否完整：来源、触发条件、影响、概率、责任人、应对动作、复查日期 | 字段无空缺，责任人已确认 | 风险登记表条目 | 项目经理 | 登记时 |
| 复查 | 检查复查时点是否到期、状态是否更新、新增风险是否补录 | 到期条目均有复查结论；新增风险已登记 | 复查记录、更新日志 | 风险责任人、项目经理 | 阶段关口、里程碑前 |
识别阶段的三个检查项分别以 WBS、合同和干系人为线索，覆盖了项目内部交付、外部约束和人员配合三类来源。评估阶段的关键动作是把已经发生的问题从风险清单中分离出去，问题按问题管理流程处置，风险清单只保留尚未发生的事项，否则概率和影响判断会失真。
每项检查的通过标准与证据要求
通过标准的写法要满足两个条件：可观察、可核对。比如“每个高风险项均有指定责任人并记录确认”可以核对，“风险意识较强”无法核对。写标准时尽量落到具体对象和数量，例如“六类来源均有结论”“到期复查条目全部有结论”。
证据类型按检查项选择，常见的有风险登记表条目、评审会议记录、责任人确认记录、指标数据截图、合同条款对照表。证据要存放在团队约定的位置，命名规则建议包含项目名、检查项编号和日期，例如“项目A-R12-20250610-复查记录”，便于复查时按条目检索。
负责人确认方式要事先约定：评审类检查项由评审主持人在会议记录中签字确认；登记类检查项由风险责任人在系统中更新状态并注明日期；阻断项关闭由项目经理确认。确认动作要留下时间戳，避免事后补记无法判断先后顺序。
阻断项与清单完成条件
阻断项是未通过时不得进入下一阶段的检查项。典型例子包括：高风险条目没有指定责任人；关键供应商的交付风险未评估；合规类风险未识别或未留存判断依据；合同关键条款未做风险对照。阻断项数量不宜过多，集中在“缺了就无法判断后续影响”的环节。
阻断项的判定权归项目经理，升级路径为项目经理上报项目发起人或阶段评审组。处理流程是：记录未通过项、指定关闭责任人和期限、关闭后由项目经理复核并在清单中标注关闭日期。有条件接受的检查项要写明接受条件和后续跟踪方式，不能以“已知悉”代替结论。
整份清单的完成条件是：全部阻断项关闭；其余检查项均有明确结论，即通过或有条件接受；未通过项已登记并指定跟踪责任人。满足这三条，清单才算完成，可以随阶段评审材料一并归档。
如何避免机械照抄导致遗漏
照抄模板的典型表现是逐格打勾、每类都写“已识别”，但说不出本项目具体可能出什么问题。改进做法是把清单当提问工具：以 WBS 的每个主要交付物为起点，追问“这个交付物在技术实现、人员投入、外部依赖上分别可能出什么偏差”；以合同条款为线索，追问“这条约定如果对方做不到，影响落在哪里”；以干系人清单为线索，追问“谁的配合不到位会让哪个节点延期”。
对每个维度再追问一次“本项目有什么不同”，把行业特点、交付模式、客户环境的特殊风险补进清单。例如定制交付项目要重点核对需求变更的触发条件，多供应商项目要重点核对接口责任划分。这些补充条目应记录来源，说明是从哪次追问或哪个事件中发现的。
用已发生问题反推未发生风险也是有效方法：复盘时把每个已发生问题问一遍“同类问题在哪些环节还可能发生但尚未发生”，把答案补入风险清单。问题管理与风险识别要分开记录，问题有处置流程，风险有概率和复查时点，两者混在一起会让清单失去预警作用。
阶段评审中固定留出补充新风险的时间，例如在评审议程中设置十五分钟的“新增风险登记”环节，由参会角色各提一条，主持人记录来源和提出人。补充记录格式可以简化为：提出人、风险描述、来源维度、初步影响判断、待指定责任人。这样每次评审都会让清单随项目进展更新，而不是立项时填一次就束之高阁。
在协作工具中承载这套清单时，可以把风险条目作为工作项登记，关联到对应的 WBS 节点或合同条款文档，责任人更新状态和复查日期，项目经理在阶段关口按清单逐项核对。ONES 的项目计划支持创建工作分解结构，便于按交付物组织追问线索；ONES Wiki 支持文档关联项目任务并记录页面版本，适合存放清单模板、追问记录和复查结论，使每次修订可追溯。工具承载的是登记与复查动作，清单维度和通过标准仍需项目团队按本项目情况填写。
常见问题
项目刚立项、WBS 还没细化，风险识别清单怎么用？
计划阶段可以先按合同条款和干系人清单做第一轮识别，把交付节点、验收标准、违约责任和关键干系人的配合要求逐条对照，形成初始风险条目。WBS 细化后再补一轮按交付物的追问，重点看技术实现、人员投入和外部依赖。两轮结果合并登记，并在清单版本记录中注明每轮识别的依据，后续阶段关口再按同一结构复查。
风险条目已经发生，是留在风险清单里还是转走？
已经发生的事项应转入问题管理流程处置，风险清单只保留尚未发生的不确定性。混在一起会让概率判断失去意义：已发生事项的概率实际为 100%，继续按风险估算会干扰优先级排序。转出时在风险条目中记录转出日期和对应问题编号，便于复盘时追溯来源。
阻断项由谁判定，团队对判定有分歧怎么办？
阻断项的判定权归项目经理，升级路径为上报项目发起人或阶段评审组。出现分歧时，先把未通过的具体事实和可能影响写进清单记录，再由升级对象裁定是否放行。放行的检查项要写明接受条件和后续跟踪责任人，不能只写“已知悉”。
清单多久复查一次比较合适？
复查时点按风险的时间窗口设定，没有统一周期。紧迫度高的条目复查间隔短，长期存在的条目可以跟随阶段关口复查。每个阶段关口和里程碑前，项目经理需要核对到期条目是否都有复查结论、状态是否更新、新增风险是否补录。复查记录连同日期一并留存，便于判断清单是否处于有效状态。
用协作工具管理风险清单，需要关注哪些落地细节？
重点是把登记和复查动作落到具体条目上：风险条目关联到对应的 WBS 节点或合同文档，责任人更新状态和复查日期，项目经理在阶段关口按清单逐项核对。ONES 的项目计划支持创建工作分解结构，便于按交付物组织追问线索；ONES Wiki 支持文档关联项目任务并记录页面版本，适合存放清单模板、追问记录和复查结论。清单的维度和通过标准仍需团队按本项目情况填写，工具承载的是记录与追溯。
