项目风险识别的依据主要来自六类输入：项目目标与范围基线、WBS与进度计划、历史项目与经验教训、干系人与组织环境、合同与外部约束、假设与制约条件。把这些材料按“收集输入—分类扫描—逐条记录—评审确认”走一遍，每条风险落到触发条件、可能影响、责任人和下一步动作，才算形成可跟踪的识别结果。本文只覆盖识别阶段，已发生的阻塞按问题管理处理。
要点总览（TL;DR）
- 风险识别的依据可归为六类：项目目标与范围基线、WBS与进度计划、历史项目与经验教训、干系人与组织环境、合同与外部约束、假设与制约条件；每类材料对应一组具体的识别问题。
- 操作上按“收集输入—分类扫描—逐条记录—评审确认”四步推进，每步明确输入、动作、输出和完成标志，避免识别会开成漫谈会。
- 识别结果统一记入风险登记册，每条风险写清描述、依据来源、触发条件、可能影响、具体责任人和下一步动作，识别阶段只负责找出来、写清楚、指到人。
- 判断识别是否合格，看六类依据是否都扫描过、四个维度是否都有记录、条目能否回溯到具体材料、责任人是否认领，以及已发生事项是否已转入问题管理。
- 材料缺失时可用访谈、商务邮件、粗粒度WBS等替代做法先启动，但需标注来源和不确定性，待材料补齐后补充一轮识别。
风险识别要准备哪些依据
风险识别不是凭经验拍脑袋列清单，而是从已有项目材料中找“尚未发生但可能影响目标”的不确定性。准备依据时，按六类材料对照收集，每类材料回答一组特定的识别问题。下表可直接作为收集清单使用，责任人一栏按项目实际分工填写。
| 依据类别 | 具体材料 | 对应的识别问题 | 责任人 |
|---|---|---|---|
| 项目目标与范围基线 | 项目章程、范围说明书、验收标准、WBS顶层交付物 | 哪些目标一旦偏离就构成风险？范围边界哪里模糊、容易蔓延？ | 项目经理 |
| WBS与进度计划 | 工作分解结构、任务依赖关系、里程碑、关键路径、资源投入计划 | 哪些任务依赖外部交付？关键路径上哪些环节缓冲不足？里程碑是否集中在同一时段？ | 项目经理、计划负责人 |
| 历史项目与经验教训 | 过往项目复盘记录、问题台账、经验教训库、同类项目风险清单 | 同类项目曾在哪里出过问题？哪些风险反复出现但未被前置管理？ | 项目管理办公室或资深成员 |
| 干系人与组织环境 | 干系人清单、职责矩阵、审批流程、组织架构与资源池情况 | 哪些干系人决策慢或诉求不一致？关键角色是否单点依赖？跨部门协作有哪些接口？ | 项目经理 |
| 合同与外部约束 | 合同条款、验收与付款节点、供应商协议、法规与合规要求 | 哪些交付节点带违约后果？供应商履约能力是否有不确定性？合规要求是否可能变化？ | 商务负责人、法务 |
| 假设与制约条件 | 项目计划中列明的假设、预算与人力上限、技术选型约束、环境限制 | 哪些假设一旦不成立会直接冲击计划？制约条件被突破时影响多大？ | 项目经理、技术负责人 |
每类依据解决不同层面的问题：目标与范围基线用来发现“做错方向”的风险，WBS与进度计划用来发现“做不完、接不上”的风险，历史经验用来避免重复踩坑，干系人与组织环境用来发现协作与决策风险，合同与外部约束用来发现履约与合规风险，假设与制约条件用来发现前提失效风险。六类合起来，覆盖面才比较完整。
某类材料缺失时，不必等齐再启动，可以用替代做法先补位：没有历史复盘记录，就访谈参与过同类项目的成员，把口述经验整理成临时清单；没有正式合同文本，就用已确认的商务邮件和报价单代替；WBS尚未细化，就先按阶段和主要交付物做粗粒度扫描，待计划细化后补充一轮识别。替代做法的共同要求是标注材料来源和不确定性，避免把推测当成确定依据。
按四步完成一次风险识别
依据收集齐后，按四步推进。每一步都明确输入、动作、输出和完成标志，避免识别会开成漫谈会。
第一步：收集输入
输入是上表中的六类材料。动作是按清单逐项确认材料是否到手、版本是否为当前有效版本，缺失项记录替代来源。输出是一份“识别输入包”，包含材料清单、版本和缺口说明。完成标志是六类依据中每一类都有可用材料或明确的替代说明，项目经理确认输入包可用。
第二步：分类扫描
输入是识别输入包。动作是按范围、进度、资源、外部四个维度分别扫描：范围维度对照范围基线和WBS顶层交付物，找边界模糊和验收标准不清之处；进度维度沿关键路径和里程碑检查依赖与缓冲；资源维度对照资源投入计划和职责矩阵，找单点依赖和负荷集中；外部维度对照合同条款、供应商协议和合规要求，找履约与合规不确定性。输出是四个维度下的候选风险点，先不追求措辞完整。完成标志是四个维度都完成一轮扫描，每个维度至少产出一条候选风险或明确记录“本维度未发现”，并注明判断依据。
第三步：逐条记录
输入是候选风险点。动作是把每条候选风险整理成结构化条目，写清触发条件、可能影响、影响对象、责任人和下一步动作，合并重复项，剔除已经发生的事项。输出是风险登记册初稿。完成标志是每条风险都有触发条件和责任人，且能对应回至少一类依据材料。
第四步：评审确认与归档
输入是风险登记册初稿。动作是组织项目经理、职能负责人和关键干系人评审，确认条目描述是否准确、影响判断是否合理、责任人是否认领，补充遗漏项，并把登记册归档到项目统一位置。输出是评审通过的风险登记册和评审记录。完成标志是责任人对各自条目确认无异议，评审中新增或修改的条目已回填，登记册版本和归档位置明确。
风险登记册怎么填：字段与角色分工
识别结果统一记录到风险登记册，字段设计的目标是让条目可交接、可跟踪，而不是只写一句“存在延期风险”。建议至少包含以下字段。
| 字段 | 填写要求 | 填写人 |
|---|---|---|
| 风险编号 | 项目内唯一，便于引用和跟踪 | 项目经理或风险负责人 |
| 风险描述 | 用“由于……可能导致……”的结构写清不确定性与后果 | 提出人 |
| 依据来源 | 对应六类依据中的哪一类、哪份材料 | 提出人 |
| 触发条件 | 出现什么信号说明风险正在发生 | 提出人、责任人共同确认 |
| 可能影响 | 影响的目标维度（范围、进度、成本、质量）及大致程度 | 提出人 |
| 责任人 | 负责跟进该风险的具体个人，而非部门 | 项目经理指派、责任人认领 |
| 下一步动作 | 进入评估、制定应对或继续观察 | 责任人 |
| 状态与更新日期 | 记录当前处理状态和最近一次更新 | 责任人 |
角色分工上，项目经理负责组织识别、维护登记册整体质量和指派责任人；职能负责人对本领域条目的影响判断和应对资源负责，确认本部门相关风险描述是否准确；关键干系人参与评审，补充其视角下的外部与协作风险，并对涉及自身职责的条目认领或提出异议。提出人不限于项目组内部，任何掌握依据材料的人都可以提交候选条目。
识别与后续环节要有清晰交接边界：识别阶段只负责把风险“找出来、写清楚、指到人”，影响程度的具体量化、优先级排序属于风险评估环节，应对措施的选择属于风险应对环节。登记册中“下一步动作”字段就是交接点，写明该条目进入评估还是直接制定应对，避免识别会上就开始争论解决方案而拖慢进度。
在工具承载上，风险条目需要稳定的编号、责任人、状态和更新记录，才能支撑后续跟踪。ONES 的项目计划支持按目标、交付物或项目阶段分解WBS并设置任务依赖与里程碑，计划和里程碑基线可用于对比执行偏差，这些材料本身就是识别阶段的重要输入；识别出的条目可以在项目工作项或文档中统一登记，按责任人和状态持续更新。若团队已使用 ONES Assistant，还可围绕项目进展、工时投入和资源配置生成分析，辅助发现偏差信号，具体可用范围以实际开通情况为准。
一个示例：从WBS和进度计划识别风险
以下为演示情景，用于说明依据如何转成风险条目，不代表真实项目数据。
示例背景：某系统交付项目处于计划阶段，WBS已分解到三级任务，进度计划标注了关键路径和两个里程碑。输入材料包括WBS、带依赖关系的进度计划、资源投入表，以及上一同类项目的复盘记录。
扫描进度维度时发现：关键路径上的“接口联调”任务依赖外部供应商交付的接口文档，而该文档的交付时间在合同中只写了“联调开始前”，没有具体日期；同时资源投入表显示联调阶段只有一名工程师承担全部联调任务。对照历史复盘记录，上一项目曾因接口文档延迟导致联调整体后移。由此推导出两条候选风险：一是接口文档交付时间不确定导致联调启动延迟，二是联调阶段单点人力导致问题集中时无法并行处理。
按字段填写第一条风险，示例如下：
| 字段 | 填写内容 |
|---|---|
| 风险编号 | R-001 |
| 风险描述 | 由于供应商接口文档交付时间在合同中未约定具体日期，可能导致联调启动晚于计划，压缩后续测试窗口 |
| 依据来源 | 合同与外部约束（供应商协议条款）、WBS与进度计划（关键路径任务依赖） |
| 触发条件 | 联调计划开始前两周仍未收到接口文档，或供应商未给出明确交付日期 |
| 可能影响 | 进度：关键路径后移，影响联调里程碑；质量：测试窗口压缩可能增加上线缺陷 |
| 责任人 | 商务接口人（负责催交与条款澄清），联调负责人配合确认技术影响 |
| 下一步动作 | 进入风险评估，量化延迟天数对里程碑的影响，再决定应对方式 |
| 状态与更新日期 | 待评估，填写当日日期 |
这条示例体现了推导路径：从进度计划的依赖关系找到外部输入，从合同条款找到时间约定的模糊点，从历史复盘确认该情形曾实际发生，三者交叉后才形成一条有依据的风险条目，而不是笼统写“供应商可能延期”。
识别完成后的检查项
识别是否做完、做得是否合格，可以按以下清单逐项判断。任一项不满足，回到对应步骤补充。
| 检查类别 | 检查项 | 判断标准 |
|---|---|---|
| 依据覆盖 | 六类依据是否都完成扫描 | 每类依据有对应材料或替代说明，且能指出扫描结论 |
| 依据覆盖 | 范围、进度、资源、外部四个维度是否都有记录 | 每个维度有候选条目或明确的“未发现”记录及理由 |
| 条目质量 | 每条风险是否写清不确定性与后果 | 描述中包含触发情形和影响对象，不停留在“有风险”层面 |
| 条目质量 | 每条风险是否可回溯到依据 | 依据来源字段填写到具体材料，而非笼统写“经验” |
| 条目质量 | 是否混入已发生事项 | 已发生的阻塞已转入问题管理，登记册中不重复记录 |
| 责任人与时点 | 每条风险是否有具体责任人 | 责任人为个人且已确认认领，不写部门或“项目组” |
| 责任人与时点 | 触发条件是否可观察 | 触发条件对应可检查的信号或时间点，便于后续跟踪 |
| 责任人与时点 | 登记册是否完成评审并归档 | 有评审记录，版本和归档位置明确，更新日期为最近一次 |
| 与问题管理的边界 | 风险与问题是否分开管理 | 尚未发生的不确定性在风险登记册，已发生的阻塞在问题流程，两者不混用同一状态口径 |
检查通过后，识别阶段的交付物即为评审通过的风险登记册和输入包记录。后续评估、应对和监控按项目既定流程推进，识别阶段不提前展开。
常见问题
项目刚启动、WBS还没细化，能不能先做风险识别？
可以。WBS尚未细化时，先按项目阶段和主要交付物做粗粒度扫描，重点看范围边界、关键里程碑和外部依赖，形成第一版候选风险清单。等WBS细化到可执行层级后，再补充一轮针对具体任务依赖和资源投入的识别。两轮之间要保留版本记录，注明哪些条目来自粗粒度扫描，便于后续核对和更新。
风险识别和问题管理怎么划清界限，避免同一件事记两遍？
判断标准是事情是否已经发生。尚未发生、只是存在可能性的不确定性，进入风险登记册；已经发生并造成阻塞的事项，转入问题管理流程处理。识别会上如果发现某条候选风险其实已经发生，直接移出风险清单，按问题流程登记，不在两处重复记录，也不混用同一套状态口径。
识别会上大家争论应对方案，拖慢了进度，怎么处理？
在流程上把识别和应对分开：识别阶段只完成“找出来、写清楚、指到人”，影响程度的量化和优先级排序留给风险评估，应对措施的选择留给风险应对。登记册里的“下一步动作”字段就是交接点，写明该条目进入评估还是直接制定应对。主持人可以在会上明确这一边界，把方案讨论记录为待办，会后按流程推进。
历史项目没有留下复盘记录，经验教训这一类依据怎么补？
可以访谈参与过同类项目的成员，把口述经验整理成临时风险清单，并标注来源为访谈、尚未经过复盘验证。同时收集过往项目的问题台账、变更记录和延期说明，从中反推当时的不确定性。临时清单在后续项目中逐步校正，条件允许时再补做正式复盘，把经验沉淀下来。
风险条目登记后，用什么方式承载才能支撑后续跟踪？
条目需要稳定的编号、具体责任人、状态和更新记录，才能支撑后续跟踪。ONES 的项目计划支持按目标、交付物或项目阶段分解WBS，设置任务依赖与里程碑，计划和里程碑基线可用于对比执行偏差，这些材料本身就是识别阶段的重要输入；识别出的条目可以在项目工作项或文档中统一登记，按责任人和状态持续更新。若团队已使用 ONES Assistant，还可围绕项目进展、工时投入和资源配置生成分析，辅助发现偏差信号，具体可用范围以实际开通情况为准。
