项目风险识别要解决的是“哪些不确定性可能影响项目、由谁负责盯住”。核心做法是在项目启动和每个阶段关口，由项目经理组织各角色按统一来源清单逐项扫描，把结果写入风险登记册，再经评审进入跟踪。本文只讲识别环节：记录什么、按什么步骤做、谁来参与、如何判断做完。
要点总览（TL;DR）
- 风险识别的产出是一份可评审的风险登记册初版，每条记录包含条件句描述、来源、触发条件、可能影响、初判等级和具体责任人。
- 识别按来源清单逐项扫描：项目目标与假设、WBS与外部依赖、历史问题与复盘、干系人与合同约束，再经工作坊和干系人访谈补盲区。
- 识别由项目经理组织，技术或业务负责人、职能经理、干系人代表分别贡献本领域条目，质量或PMO角色检查覆盖度与记录规范。
- 单次识别做完的判断标准是来源清单全部覆盖、每条风险有触发条件和责任人、已发生事项已分流到问题管理。
- 识别结果在项目启动、阶段关口和重大变更后更新，登记册直接作为后续评估、应对与跟踪的输入。
风险识别先产出什么：字段与登记册
风险识别阶段的交付物是一份可评审、可跟踪的风险登记册初版。登记册不需要在识别时就写得面面俱到，但每条记录必须让人看得懂、找得到责任人、判断得了何时需要关注。字段设计围绕这三个要求展开。
最小字段与填写规则
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 编号 | 项目内唯一，便于评审和后续引用 | 重复编号或中途重排导致引用混乱 |
| 风险描述 | 写成“若……则……”的条件句，描述尚未发生的不确定性 | 写成“接口未就绪”这类已发生问题的陈述 |
| 来源 | 标注来自哪类扫描入口，如假设、WBS依赖、历史复盘、外部约束 | 只写“团队讨论”，无法回溯覆盖情况 |
| 触发条件 | 写明可观察的信号，如“供应商接口文档延迟超过两周未交付” | 写成“情况恶化”这类无法判断的表述 |
| 可能影响 | 说明影响的对象和大致范围，如进度节点、验收范围、人力投入 | 只写“影响项目”，无法支撑初判 |
| 初判等级 | 用发生概率与影响程度两维粗判为高、中、低 | 在识别阶段追求精确分值，拖慢进度 |
| 责任人 | 指定具体的人，负责观察触发条件并推动后续评估 | 填部门名称或“项目组” |
| 状态 | 识别阶段统一为“待评审”或“已确认”，后续再扩展 | 识别阶段就写入应对措施和完成时间 |
风险描述采用条件句，是为了把“尚未发生”和“已经发生”分开。比如“若第三方支付接口的联调环境延迟提供，则上线前的集成测试窗口将被压缩”，这条记录描述的是一个可能发生的未来情形；而“支付接口联调环境尚未提供”是当前已经存在的阻塞，应进入问题管理流程，由问题责任人推动解决。两类事项混在同一个登记册里，会导致风险评审被当成问题协调会，识别工作无法收敛。
初判等级在识别阶段只做粗判。概率和影响各分高、中、低三档，组合出等级即可，目的是让评审时能快速排序、决定哪些条目优先细化。精确的概率数值和影响金额留到风险评估环节，识别阶段不必为此反复讨论。
识别阶段的工作边界是记录与初判。应对策略、应对责任人、应对预算、残余风险评估属于后续环节，识别时只需保证条目本身清楚、可判断、有人认领。把应对方案提前塞进识别会议，往往会让讨论从“还有哪些不确定性”滑向“这个风险怎么解决”，覆盖度反而下降。
按来源逐项扫描：识别的操作步骤
识别不是开放式头脑风暴，而是按固定来源清单逐项过一遍，确保覆盖稳定、可重复。来源清单相当于一张检查表，每次识别都从同样的入口进入，避免这次想到技术风险、下次只谈进度风险。
输入准备
开始扫描前，需要把四类材料放在手边：项目目标与关键假设，包括范围、工期、验收标准以及立项时默认成立的前提；WBS与外部依赖，包括任务分解、前后置关系和对外部供应商、接口、审批的依赖；历史项目问题与复盘记录，尤其是同类项目中反复出现的延误、返工和资源缺口；干系人清单与合同约束，包括验收方、监管要求、付款与交付条款。这四类材料分别对应目标层、执行层、经验层和外部层的不确定性来源。
动作一：对照来源清单逐项提问
按来源逐项提问，每个来源准备两到三个固定问题。例如针对关键假设问“这个假设如果不成立，哪部分计划会失效”；针对WBS依赖问“哪些任务的前置条件不在项目组控制范围内”；针对历史复盘问“上个同类项目出现过的问题，这次的前置条件是否仍然存在”；针对合同约束问“哪些验收或合规要求存在解释空间”。提问的目的是引出不确定性，记录时只写风险条目，不展开解决方案。
动作二：工作坊与关键干系人访谈
团队工作坊适合覆盖执行层风险，参与者包括各模块负责人和一线执行人员，他们对任务依赖和资源紧张程度最敏感。关键干系人访谈用于补充工作坊的盲区，重点访谈外部依赖的对接人、验收方代表和职能资源负责人，这类角色掌握的信息往往不在项目组日常视野内。工作坊产出的条目和访谈补充的条目合并进入同一份候选清单。
动作三：评审去重与确认
候选清单需要一次评审，动作包括：合并表述同一不确定性的重复条目；把过于笼统的条目拆成可判断的具体情形；逐条确认责任人和触发条件；把已发生的事项移出风险登记册，转入问题管理。评审的输出是经确认的风险登记册初版，以及一份待观察清单，后者记录当前信息不足、暂不进入正式跟踪但需要持续留意的方向。
完成标志
单次识别可以结束的判断标准是：来源清单的每一类都有扫描记录，包括“该类未发现风险”的明确结论；每条正式条目都有条件句描述、触发条件和具体责任人；已发生事项已完成分流。三项同时满足，识别环节即可交付评审，进入后续的评估与应对环节。
谁来做：角色分工与交付物
识别如果只由项目经理完成，覆盖度会受限于个人视角，技术细节和外部约束容易漏掉。合理的做法是项目经理组织、各角色按领域贡献条目，每个角色都有明确的交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织识别活动，维护登记册，把关描述质量与字段完整性 | 风险登记册初版、识别会议记录、待观察清单 |
| 技术或业务负责人 | 提供本领域专业判断，识别技术方案、需求理解和实现路径上的不确定性 | 本领域风险条目及触发条件建议 |
| 职能经理或资源负责人 | 确认人员到位、技能匹配、供应商履约等资源约束类风险 | 资源与供应商相关风险条目及可用性判断 |
| 干系人代表 | 提出外部依赖、验收标准、合规要求方面的不确定性 | 外部约束类条目与验收相关风险说明 |
| 质量或PMO角色 | 检查来源覆盖度、字段规范性和风险与问题的分流情况 | 识别覆盖度检查结论与整改意见 |
分工的关键在于责任人的落点。每条风险的责任人应当是能够观察触发条件、并在触发时推动评估的人，通常落在具体模块负责人或职能接口人身上，项目经理负责整体登记册的完整性和评审组织。质量或PMO角色的检查不替代各角色的识别贡献，它解决的是“有没有漏掉整类来源”和“记录是否规范”的问题。
识别结果需要在团队可见的地方持续维护，而不是停留在个人表格里。以ONES为例，项目计划支持WBS分解和任务前后置依赖设置，里程碑可标记关键时间点与决策点，计划与基线偏差可以实时对比，这些信息本身就是识别依赖类和进度类风险的输入；识别出的条目可以在项目协作空间中登记、分配责任人并随阶段评审更新。ONES Wiki支持页面组关联项目、文档与需求互相对应，并保留页面版本记录，适合沉淀识别用的来源清单、历史复盘材料和登记册模板，使下一次识别有可复用的底稿。需要说明的是，风险登记册的具体字段与状态流转方式，应结合团队实际配置在工具中落地。
一个识别示例：从假设到登记条目
以下为一个演示情景，用于说明条目如何形成，不代表真实客户案例。背景是一个交付期固定的系统上线项目，立项时的一项关键假设是“核心交易接口由外部供应商按合同节点提供并完成联调”。
从假设到条件句
扫描关键假设时，针对“供应商按节点提供接口”这一前提提问：如果供应商交付延迟，哪部分计划会失效。由此写出条目：“若外部供应商的核心交易接口未能在联调开始前完成交付，则集成测试窗口被压缩，上线日期存在延后可能。”这条描述保留了不确定性，没有断言延迟已经发生。
补齐字段
触发条件写为“联调开始前两周，供应商仍未提供可用的接口文档与测试环境”。可能影响写为“集成测试时间不足，上线节点延后，验收范围可能需要分期”。初判等级按概率中、影响高，判为高等级。责任人指定为负责接口对接的技术负责人，由其持续跟踪供应商交付进度并在触发条件出现时发起评估。来源标注为“关键假设”。
评审中的合并与拆分
评审时发现另一条来自WBS依赖扫描的条目“供应商测试环境提供时间不确定”，与上述条目指向同一不确定性，予以合并，保留一条主条目，并在描述中补充测试环境这一具体对象。同时，原条目中“验收范围可能需要分期”被拆出为独立条目，因为它的触发条件和影响对象不同，责任人应落在验收对接的干系人代表身上。合并减少重复跟踪，拆分保证每条记录只有一个清晰的责任落点。
哪些内容不进入风险登记册
如果评审时供应商已经书面确认接口交付延期三周，这就不再是风险，而是已发生的问题，应转入问题管理流程，记录当前阻塞、影响范围和解决责任人。风险登记册中保留的是“若延期进一步扩大则……”这类仍然面向未来的判断，或者将该条目关闭并注明已转为问题跟踪。这个分流动作是识别评审的固定环节，不能省略。
识别完成检查与常见遗漏
识别做完不等于开过一次会。用一份检查清单逐项核对，可以判断本轮识别是否达到可交付状态。
完成检查清单
- 来源清单四类入口均有扫描记录，未发现风险的类别有明确结论。
- 每条风险描述为条件句，能区分“尚未发生”与“已经发生”。
- 每条风险都有具体责任人，没有以部门或项目组代替。
- 每条风险都有可观察的触发条件，评审人能判断何时需要升级。
- 初判等级已完成，高等级条目在评审中有明确记录。
- 已发生事项已移出登记册并转入问题管理，分流有记录。
- 待观察清单已建立，信息不足的方向有指定跟进人。
- 登记册版本和评审结论已归档，团队成员可查阅。
常见遗漏
第一类是来源偏科，只识别技术和进度风险，忽略组织调整、关键人员变动、验收口径变化和合规要求这类组织与外部风险。第二类是一次性识别，项目启动时做一遍就不再更新，导致阶段推进后新增的依赖和约束没有进入登记册。第三类是把问题当风险记录，登记册里堆满已经发生的阻塞，评审时间被问题协调占满。第四类是把风险写成笼统判断，如“需求可能变化”，缺少触发条件和影响对象，后续无法跟踪。
更新时点与后续衔接
识别结果需要在三个时点更新：项目启动时完成首轮全面识别；每个阶段关口对照来源清单做增量扫描，重点检查新出现的依赖和假设变化；重大变更发生后，如范围调整、供应商更换、关键人员离岗，针对变更影响范围补充识别。更新时沿用同一套字段和来源清单，保证前后可比。
识别产出的登记册直接进入后续环节：高等级条目优先做细化评估，明确概率与影响的具体判断；评估结论支撑应对策略的制定，应对责任人与风险责任人可以是同一人，也可以分开设置；跟踪阶段以触发条件为观察信号，条件出现时启动应对或重新评估。识别环节把条目写清楚、责任落到位，后续的评估、应对和跟踪才有稳定的输入。
常见问题
风险识别和问题管理怎么划清界限？
判断标准是这件事是否已经发生。尚未发生、只是存在可能性的不确定性进入风险登记册，写成“若……则……”的条件句；已经发生的阻塞，比如供应商已书面确认延期、接口环境迟迟未提供，应转入问题管理，记录当前影响和解决责任人。评审时如果发现某条风险已经变成事实，就关闭该条目并注明转为问题跟踪，这个分流动作要固定下来，否则风险评审会被问题协调占满。
小项目也需要走完整的来源清单扫描吗？
来源清单的作用是防止漏掉整类不确定性，项目规模小可以压缩每个来源的提问数量，但四类入口仍建议各过一遍，尤其是外部依赖和合同约束这两类，小项目往往由少数人对接，更容易遗漏。工作坊可以简化为一次短会，干系人访谈也可以合并到同一次沟通中。判断标准不变：每条风险有触发条件和具体责任人，已发生事项已分流。
识别出的风险很多，评审时怎么排序？
识别阶段只做概率与影响两维粗判，各分高、中、低三档组合出等级，评审时按等级排序即可。高等级条目优先进入细化评估，明确概率和影响的具体判断；低等级但触发条件临近的条目，可以先指定跟进人放入待观察清单。识别阶段不必追求精确分值，把讨论时间留给覆盖度和描述质量更划算。
阶段关口做增量识别时，上一轮的登记册怎么处理？
沿用同一套字段和来源清单，在原有登记册上更新，不另起一份。动作包括：核对上轮条目的触发条件是否出现、状态是否需要调整；对照来源清单扫描本阶段新增的依赖和假设变化；把已发生的事项分流出去。保留版本记录，便于回溯某条风险是何时识别、何时升级的。重大变更后，如范围调整或供应商更换，针对变更影响范围补充一轮识别。
识别结果怎么在协作工具里持续维护？
关键是让登记册在团队可见的地方更新，而不是停在个人表格里。以ONES为例，项目计划支持WBS分解和任务前后置依赖设置，里程碑可标记关键时间点与决策点，计划与基线偏差可实时对比，这些信息可以作为依赖类和进度类风险的识别输入；ONES Wiki支持页面组关联项目、文档与需求互相对应，并保留页面版本记录，适合沉淀来源清单、复盘材料和登记册模板。风险登记册的具体字段和状态流转方式，需要结合团队实际在工具中配置。
