项目风险识别中最常见的混淆，是把已经发生的问题继续写在风险清单里，或者把尚未发生的不确定性当成待处理问题。两者的分界在于发生状态：尚未发生、结果不确定的事项属于风险事件；已经出现并影响项目目标的事项属于已发生的问题。本文给出定义、判断边界、记录与流转机制，并用示例说明如何避免误记。
要点总览（TL;DR）
- 风险事件是尚未发生、结果不确定的事项，已发生的问题是已经出现并影响项目目标的事项，区分的第一标准是当前是否已经发生。
- 风险进入风险登记册，记录触发条件、概率、影响、应对策略和责任人；问题进入问题清单，记录发生时间、影响范围、处置措施和关闭标准。
- 同一事项触发条件满足后应从风险转为问题，保留原风险记录并与问题记录关联，避免两边重复登记或两边漏管。
- 假设是当前视为成立但未验证的条件，变更是已批准的基准调整，二者都不应直接记为风险事件。
- 判断时先自问该事项现在是否已经发生、是否已产生实际影响，答案为是则按问题管理，答案为否则按风险跟踪并设定触发条件。
风险事件和已发生的问题分别指什么
风险事件指尚未发生、发生与否以及发生后影响程度都不确定的事项。它描述的是“可能”：可能因供应商交付延迟导致联调推迟，可能因关键人员变动影响进度，可能因需求理解偏差造成返工。这些事项当前没有成为事实，但一旦触发，会对项目范围、进度、成本或质量产生影响。风险事件需要被识别、评估并安排应对策略，目的是降低发生概率或减轻影响。
已发生的问题指已经出现、已对或将对项目目标产生实际影响的事项。它描述的是“事实”：接口联调已经失败、关键设备已经到货延迟、某位核心开发人员已经离职。问题不需要再讨论“会不会发生”，需要的是确认影响范围、安排处置措施、明确责任人和关闭标准。问题管理的目标是尽快控制影响并恢复计划。
两者的共同点在于都与项目目标相关，都需要明确责任人跟进，也都需要记录和评审。区别可以用一句话概括：看该事项在当前时点是否已经发生，已经发生的按问题管理，尚未发生的按风险管理。严重程度、来源渠道、由谁提出，都不改变这一基本判断。
区分的边界：哪些事项归风险，哪些归问题
判断归属时，第一标准是发生状态，而非严重程度或来源。一个影响很大的事项，只要尚未发生，仍应作为风险跟踪；一个影响较小的事项，只要已经发生，就应进入问题管理。来源同样不决定归属：客户提出的、测试发现的、例会上讨论的，都先问“现在发生了吗”。
按发生状态划分，归属关系可以归纳如下：
| 事项状态 | 归属 | 典型描述 | 管理动作 |
|---|---|---|---|
| 尚未发生，发生概率和影响不确定 | 风险事件 | “如果第三方接口延期，联调可能推迟两周” | 登记风险，设定触发条件，安排应对策略并定期评审 |
| 已经发生，已造成或即将造成实际影响 | 已发生的问题 | “第三方接口已延期，联调已无法按计划开始” | 登记问题，确认影响范围，安排处置并跟踪关闭 |
| 已发生阻塞，阻碍当前工作推进 | 已发生的问题 | “测试环境当前不可用，测试无法执行” | 按问题管理，优先恢复可用状态 |
| 尚未发生，但触发条件已明确且临近 | 风险事件（重点跟踪） | “合同约定周五前未收到物料，将影响下周装配” | 保留风险记录，触发条件满足后转为问题 |
中间地带主要出现在“即将发生”的情形。触发条件已经明确、时间窗口很近，但事实尚未出现，此时仍应保留在风险侧，同时提高评审频率。一旦触发条件满足，例如约定日期已过且物料未到，就应转为问题并立即处置。已发生阻塞的具体排查与处置步骤、项目组合层面的风险平衡与资源调配，不在本文讨论范围。
同一事项状态变化时，归属处理原则是“转记并关联”，而非“两边各记一份”或“直接删掉原记录”。风险记录保留识别过程和原定应对策略，问题记录承接实际影响和处置动作，两者建立关联，便于回溯该事项从可能变为事实的完整过程。
从识别到跟踪：两类事项各自的处理机制
风险与问题在记录字段、责任人和处置节奏上存在机制差异。风险侧的重点是提前判断和预案准备，问题侧的重点是影响控制和关闭验证。字段设置应服务于这两种不同的管理目的。
| 维度 | 风险事件 | 已发生的问题 |
|---|---|---|
| 核心字段 | 触发条件、发生概率、影响程度、应对策略、责任人、评审日期 | 发生时间、影响范围、处置措施、责任人、关闭标准 |
| 描述方式 | 条件式描述，说明“如果……则……” | 事实式描述，说明“已经……导致……” |
| 责任人职责 | 监控触发条件，准备并执行应对策略 | 组织处置，控制影响，验证关闭标准 |
| 评审节奏 | 按固定周期评审，触发条件临近时提高频率 | 按处置进展跟踪，通常节奏更短，直至关闭 |
| 结束标志 | 风险已不会发生、已转为问题，或影响已消除 | 关闭标准满足，影响已控制或恢复 |
风险转为问题的衔接动作包括：确认触发条件已满足，记录实际发生时间和当前影响范围，将原风险记录标记为已转化并关联新建的问题记录，把原定应对策略转为具体处置措施，同时通知原风险责任人和受影响方。转化后，风险侧不再重复跟踪同一事实，问题侧承接后续处置，两边记录通过关联保持可追溯。
在工具承载上，团队可以用工作项类型区分风险与问题，用状态字段表达“待评估、跟踪中、已触发、处置中、已关闭”等阶段，用关联字段把转化前后的记录连起来。ONES 的项目管理能力支持团队按项目计划和工作分工推进事项，持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险；设置项目计划和里程碑基线后，可对比计划与执行的偏差，提早识别风险和问题。对于需要基于项目进展、工时投入、缺陷分布和资源配置做分析的场景，ONES Assistant 可生成进展分析、根因判断和资源合理性建议，帮助管理者在风险扩大前完成干预。具体字段和状态流转方式应结合团队现有流程配置，不宜把某一种记录结构当作统一要求。
与相邻概念的区别：风险、问题、假设与变更
风险与问题之外，项目中还有两类事项容易被误记：假设和变更。四者的区别可以从“是否已发生”和“是否已改变基准”两个角度理解。
| 概念 | 核心含义 | 判断要点 | 记录去向 |
|---|---|---|---|
| 风险事件 | 尚未发生、结果不确定，可能影响项目目标 | 现在没有发生，未来可能发生 | 风险登记册，持续跟踪 |
| 已发生的问题 | 已经出现，已对或将对项目目标产生实际影响 | 现在已经发生并产生或即将产生实际影响 | 问题清单，立即处置 |
| 假设 | 当前视为成立但尚未验证的条件 | 作为计划前提使用，尚未被证实或推翻 | 假设清单，安排验证 |
| 变更 | 已批准的基准调整 | 范围、进度或成本基准已被正式修改 | 变更记录，更新基准 |
假设是当前视为成立但未验证的条件，例如“假设测试环境在下周前可用”。它本身不是风险，但假设不成立时可能引出风险或问题，因此需要安排验证并记录验证结果。变更是已经批准的基准调整，例如范围增加或里程碑顺延，它改变的是计划基准，应进入变更记录并同步更新相关计划，不应作为风险事件登记。
概念混用会带来具体后果：把已发生问题写成风险，会导致处置延迟，影响持续扩大；把假设当作风险，会让风险清单混入大量待验证条件，稀释真正需要应对的不确定性；把变更当作风险，会造成基准与记录不一致，后续偏差分析失真。区分这些概念的目的，是让每类事项进入与其性质匹配的管理流程。
具体例子与常见误解
以下示例为演示情景，用于说明判断过程。某项目计划在第六周完成与第三方支付接口的联调。第二周识别到：第三方接口文档尚未提供，若对方在第四周前仍未提供，联调可能推迟。此时该事项尚未发生，登记为风险事件，触发条件设为“第四周结束仍未收到接口文档”，应对策略包括提前准备模拟接口、与对方约定交付时间，责任人为集成负责人，按周评审。
第四周结束，接口文档仍未提供，联调已无法按原计划启动。触发条件满足，该事项转为问题：记录实际发生时间、当前影响范围（联调推迟、后续测试压缩）、处置措施（启用模拟接口先行开发、升级对方对接层级）、关闭标准（真实接口联调完成并通过验证）。原风险记录标记为已转化并与问题记录关联，风险侧停止重复跟踪。
常见误解有三类。第一类是把已发生问题继续写成风险，例如联调已经失败，仍在风险清单里写“联调可能失败”。后果是处置动作被推迟到下一次评审，影响范围扩大，责任人也容易误以为还有缓冲时间。第二类是把风险当成必然发生的问题而过度反应，例如风险概率很低，却立即调动大量资源全面返工，造成浪费。合理的做法是按概率和影响安排应对力度，并设定触发条件。第三类是把假设或变更误记为风险，例如把“假设客户会按时确认”写成风险，或把已批准的范围调整写成风险，导致清单失真、基准与记录脱节。
判断时可自检三个问题：该事项现在是否已经发生？是否已对项目目标产生实际影响？如果发生，影响范围是否已经可以确认？前两个问题答案为“是”，应按问题管理；答案为“否”，按风险跟踪并设定触发条件。第三个问题帮助确定问题记录的处置范围。团队规模较小、流程较简单时，可以用同一张表加类型字段区分；流程成熟度较高的团队，可分别维护风险登记册和问题清单，并通过关联字段保持衔接。
常见问题
风险触发条件满足后，原风险记录应该删除还是保留？
建议保留原风险记录，并将其标记为已转化，同时关联新建的问题记录。原记录保留了识别过程、原定应对策略和触发条件，问题记录承接实际发生时间、影响范围和处置措施，两者关联后可以回溯该事项从可能变为事实的完整过程。直接删除原风险记录会让后续复盘缺少依据，也容易在风险清单和问题清单之间出现漏管。
影响很小的事项已经发生，也要按问题管理吗？
要。归属判断以发生状态为第一标准，影响大小不改变这一判断。已经发生的事项即使影响较小，也应进入问题管理，只是处置力度和跟踪频率可以相应降低。反过来，影响很大的事项只要尚未发生，仍应作为风险跟踪，按概率和影响安排应对资源，避免因为担心后果严重就提前当作问题处置。
团队规模小、没有独立的风险登记册，怎么区分这两类事项？
可以用同一张表加类型字段区分，风险类型记录触发条件、概率、影响和应对策略，问题类型记录发生时间、影响范围和关闭标准，状态字段表达跟踪中、已触发、处置中、已关闭等阶段。团队规模扩大或流程成熟度提高后，再考虑分别维护风险登记册和问题清单，并通过关联字段保持衔接。记录结构应结合团队现有流程配置，不宜把某一种方式当作统一要求。
假设一直没被验证，是否可以直接转成风险？
需要先判断假设不成立会带来什么。假设本身是当前视为成立但未验证的条件，应留在假设清单并安排验证；如果假设不成立会引出某个尚未发生的不确定事项，就把那个事项单独登记为风险事件，写明触发条件和应对策略。把假设直接当作风险登记，会让风险清单混入大量待验证条件，稀释真正需要应对的不确定性。
风险评审和问题跟踪的节奏应该怎么安排？
风险侧通常按固定周期评审，触发条件临近时提高频率，重点确认概率和影响是否变化、应对策略是否仍然可行。问题侧按处置进展跟踪，节奏更短，直至关闭标准满足。两者都需要明确责任人，但风险责任人的职责是监控触发条件并准备应对，问题责任人的职责是组织处置、控制影响并验证关闭。具体周期应结合项目阶段和事项紧迫程度确定。
