哪些事项应归入项目风险，哪些应归入项目问题

判断一条事项该归入项目风险还是项目问题，核心看它是否已经发生并正在影响项目：尚未发生、只是可能带来不确定影响的事项归入风险；已经发生、正在或已经造成实际影响的事项归入问题。本文围绕这一标准，说明两类记录的定义边界、转化衔接和常见误判，帮助团队在登记时做出可复用的一致判断。

要点总览（TL;DR）

• 判断标准是事项是否已经发生并产生影响：尚未发生、只是可能发生的事项归入风险；已经发生、正在或已经造成影响的事项归入问题。
• 风险记录要写清不确定事件、发生可能性、影响程度、触发条件、责任人和应对措施；已发生事项、日常待办和组合层面的风险平衡不登记为项目风险。
• 问题记录要写清实际影响、优先级、责任人和解决状态；仅有可能性的事项和没有事实依据的猜测不登记为项目问题。
• 风险触发后转为问题并保留来源关联，问题处置中暴露的新不确定性再登记为风险，转化动作嵌入周度或里程碑评审。
• 严重程度不改变归类，高影响风险在发生前仍是风险，已发生的小偏差仍是问题；归类后要同步更新字段与状态。

一句话区分：看事项是否已经发生

可以直接套用的归类判断句是：“这件事已经发生了吗？已经发生并产生影响，登记为问题；尚未发生、只是可能发生，登记为风险。”判断依据是事项的发生状态，影响大小和紧急程度不参与这一判断。

这条标准之所以可靠，是因为风险管理和问题管理处理的对象在时间位置上不同。风险面对的是未来的不确定性，管理动作是降低发生概率或减轻潜在影响；问题面对的是已经出现的事实，管理动作是控制影响、恢复计划。两者混用会导致两种后果：把已发生的事故挂在风险清单里，团队会误以为还有缓冲时间；把尚未发生的担忧登记成问题，问题清单会被猜测淹没，真正需要处置的事项反而被稀释。

需要强调的是，严重程度不改变归类。一个高概率、高影响的风险仍然是风险，直到它发生；一个影响很小的已发生偏差仍然是问题。同一事项在不同时点也可能先后属于两类：供应商延期交付在合同期内是风险，交付日已过而物料未到就转为问题。归类不是给事项贴永久标签，而是记录它当前处于哪个阶段。

项目风险的定义与边界

项目风险是指尚未发生、但一旦发生会对项目范围、进度、成本或质量产生不确定影响的事件或条件。一条可管理的风险通常由三个要素构成：不确定事件本身、发生可能性、影响程度。三者缺一，风险记录就难以支撑后续决策——只写“存在风险”而不写可能性和影响，无法排定应对优先级。

风险登记时应记录以下内容，使风险从一句担忧变成可跟踪的管理对象：

• 触发条件：什么信号出现说明风险正在逼近或已经发生，例如关键岗位人员离职意向、某供应商连续两周交付延迟。
• 责任人：负责监控触发条件并执行应对措施的人，通常不是项目经理本人包办全部风险。
• 应对措施：规避、转移、减轻或接受的具体动作，以及措施完成的时间点。
• 当前状态：开放、监控中、已触发、已关闭，便于定期评审时快速筛选。

以下情形不宜登记为项目风险：已经发生并产生影响的事项，应登记为问题；纯粹的日常待办任务，例如“提交周报”“安排评审会”，属于计划内工作，没有不确定性，不需要风险记录；项目组合层面的风险平衡，例如多个项目之间资源与风险的统筹取舍，属于组合管理职责，不在单个项目风险清单中处理。

项目问题的定义与边界

项目问题是指已经发生、并已对项目范围、进度、成本或质量造成实际影响的事项。它与风险的关键差异在于事实性：问题不需要讨论“会不会发生”，只需要确认“已经发生了什么、影响到什么程度、由谁在多长时间内解决”。

问题记录应包含影响描述、优先级、责任人与解决状态。影响描述要落到具体对象，例如“支付模块联调延迟三天，导致验收里程碑顺延”，而不是笼统的“进度受影响”。优先级依据影响范围和紧迫程度确定，决定处置顺序。解决状态通常经历待处理、处理中、待验证、已关闭，状态变化应留下时间记录，便于复盘时还原处置过程。

以下情形不宜登记为项目问题：仅存在发生可能性的事项，即使可能性很高，也应作为风险监控；尚未产生影响的猜测，例如“听说客户可能不满意”，在没有具体事实支撑前不构成问题；已经关闭且无后续影响的历史事项，保留记录即可，不需要继续占用问题清单的活跃位置。

风险管理和问题管理的对象差异可以归纳为下表：

对比维度	项目风险	项目问题
发生状态	尚未发生	已经发生
核心问题	会不会发生、影响多大	已经影响了什么、如何控制
关键字段	可能性、影响程度、触发条件、应对措施	实际影响、优先级、解决状态
管理动作	监控触发条件、执行预防或减轻措施	控制影响、恢复计划、验证关闭
关闭条件	风险已不会发生，或已触发转出	影响已消除并经确认

风险与问题如何衔接：触发、转化与回流

风险与问题是同一条不确定性在时间轴上的两个阶段，管理上需要一条清晰的流转路径，避免同一事项在两张清单里重复登记或两边都无人负责。

风险触发后转为问题。当风险登记中定义的触发条件出现，责任人应将该风险状态更新为“已触发”，并创建对应的问题记录，同时保留来源关联，注明由哪条风险转化而来。保留关联的价值在于：复盘时能看出哪些风险预警准确、哪些应对措施失效，也能避免原风险记录被直接删除而丢失历史。

问题处置中发现的新不确定性回流为风险。处理问题的过程中常会暴露新的未知，例如故障修复时发现同类模块可能存在相同缺陷。这类信息应登记为新风险，写明可能性和影响，进入正常的风险监控流程，而不是附在问题记录里当作备注。

在固定节点完成交接。风险与问题的转化不应依赖个人记忆，而应嵌入例行评审：在周度或里程碑评审中，逐条检查开放风险的触发条件是否出现，出现即转问题；同时检查处理中的问题是否衍生新的不确定性，衍生即登记风险。状态更新和关联建立应在同一次评审中完成，保证两张清单始终反映项目当前的真实状态。

在工具承载层面，ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，用于提早识别风险和问题；团队也可以按项目计划和工作分工持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险。对于需要从进展、工时、缺陷分布和资源配置中判断风险信号的项目，ONES Assistant 可生成进展分析、根因判断和资源合理性建议，帮助管理者在风险扩大前完成干预。这些能力服务于识别与跟踪环节，风险与问题的分类规则和转化节点仍需团队在管理约定中明确。

容易混淆的相邻概念

归类出错，很多时候不是风险与问题本身难分，而是把相邻概念混了进来。下表对照几组常见概念：

概念	核心特征	与风险、问题的关系
普通待办任务	计划内必须完成的工作，结果基本确定	既不是风险也不是问题；只有当任务执行出现不确定影响时才可能衍生风险，已经延误并造成影响时成为问题
假设条件	规划时默认成立、但未验证的前提，例如“接口文档在开发启动前冻结”	假设不成立时可能引发风险；假设已被证伪并造成影响，则成为问题
项目组合风险	多个项目之间资源、进度与风险的统筹平衡	属于组合层面的取舍决策，不在单个项目风险清单中逐条登记
依赖	本项目的推进需要外部团队或系统先完成某事	依赖本身是计划结构；依赖方可能延迟属于风险，已经延迟并影响本项目则成为问题

区分这些概念时，可以连续问三个问题：这件事是否属于计划内必须完成的工作？如果是，它是任务。它是否是一个尚未验证的前提？如果是，它是假设，需要跟踪验证结果。它是否已经发生并产生影响？按这一问回到风险与问题的基本判断。

归类示例与常见误解

以下示例演示归类判断的实际应用，情景为演示性质，用于说明判断逻辑：

事项描述	归类	理由
核心开发人员可能在项目高峰期请假两周	风险	尚未发生，影响取决于是否发生及发生时段，需记录可能性与应对措施
核心开发人员已请假，迭代交付预计延迟三天	问题	已经发生并造成进度影响，需明确责任人和恢复计划
第三方支付接口存在限流，高峰期可能影响下单	风险	限流是已知条件，是否在项目高峰期触发尚不确定
压测中支付接口触发限流，下单成功率下降	问题	影响已经实际出现，需要立即处置并验证恢复
需求评审会安排在周四下午	待办任务	计划内工作，结果确定，不属于风险或问题
假设客户在验收前完成 UAT 环境准备	假设	是规划前提；若到期未准备并阻塞验收，则转为问题

常见误解主要有三类。第一类是把严重风险当问题。“这个风险影响太大，直接当问题处理吧”——影响大不改变它尚未发生的事实，正确做法是提高风险等级、加密监控频率、准备应急预案，而不是改变记录类型。第二类是把已发生故障当风险。线上故障已经造成用户受影响，仍挂在风险清单里写“可能存在稳定性风险”，会掩盖处置紧迫性，应转为问题并记录实际影响。第三类是把猜测当事实。没有触发条件、没有事实依据的担忧，既不适合作为问题，作为风险也应先补充可能性和影响判断，否则无法安排应对。

完成归类后，应同步更新记录字段与状态：登记为风险时，补齐可能性、影响程度、触发条件、责任人和应对措施，状态设为开放或监控中；风险触发转为问题时，原风险状态改为已触发并建立来源关联，新问题记录实际影响、优先级和解决状态；问题处置中衍生新不确定性时，新建风险记录并注明来源问题。每次评审后核对两张清单的状态是否与项目实际一致，归类规则才能真正落地。

常见问题

风险已经很高但还没发生，可以直接登记为问题优先处理吗？

不建议改变记录类型。风险等级高说明需要提高关注度和应对强度，处理方式可以是加密监控频率、提前准备应急预案、明确触发条件与责任人，但记录仍应保留在风险清单中。一旦触发条件出现，再转为问题并记录实际影响。这样做的目的是让团队清楚这件事还处在“可能发生”的阶段，避免把尚未发生的事项当作既成事实来消耗处置资源。

同一个事项在风险清单和问题清单里都出现了，应该怎么处理？

先确认事项当前的真实状态。如果已经发生并产生影响，保留问题记录，将原风险状态改为已触发并注明来源关联，不再把原风险当作开放项继续跟踪；如果尚未发生，保留风险记录，问题清单中的条目应关闭或撤回。两张清单同时保留同一条开放事项，容易造成责任重叠和状态失真，评审时应把这类重复项作为核对重点。

问题处理完了，还需要回头更新风险清单吗？

需要。问题处置过程常常暴露新的不确定性，例如修复一个缺陷时发现同类模块可能存在相同隐患。这类信息应登记为新风险，写明可能性和影响，进入正常监控流程，而不是只写在问题记录的备注里。问题关闭时同步检查是否衍生新风险，可以让风险清单持续反映项目当前的真实状态。

团队规模小、没有专职风险负责人，转化交接怎么做？

可以把交接动作压缩到已有的例行会议中，不必另设流程。在周会或里程碑评审上增加两个固定检查项：逐条查看开放风险的触发条件是否出现，出现即转问题；查看处理中的问题是否衍生新的不确定性，衍生即登记风险。责任人按事项就近指定，由最了解该事项的人负责监控和更新状态。团队规模较小时，关键是让检查动作固定下来，而不是增加记录数量。

用工具管理时，风险转问题需要保留哪些信息？

至少保留三项：原风险的标识或链接、触发条件出现的事实依据、转化时间。保留来源关联的价值在于复盘时能判断哪些风险预警准确、哪些应对措施没有起作用。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，用于提早识别风险和问题；团队也可以按项目计划和工作分工持续查看任务状态、阶段进展和待处理问题。风险与问题的分类规则和转化节点仍需团队在管理约定中明确。