判断一条事项该进风险台账还是问题清单，先看它是否已经发生：尚未发生、结果不确定、可能影响项目目标的归入项目风险；已经发生、正在或已经造成影响、需要处置的归入项目问题。同一事项在发生前后会转换身份，风险触发后应转为问题承接处置。本文给出两类对象的定义要素、排除清单和转换约定，并用示例演示归类判断；涉及风险与问题记录在同一套工作项中流转时，会简要说明ONES可承载的环节。
要点总览（TL;DR）
- 判断归属的主判据是事项是否已经发生：尚未发生、结果不确定的归入项目风险；已经发生、正在或已经造成影响、需要处置的归入项目问题。
- 风险条目应写清不确定事件、发生可能性、影响程度、应对措施，并给出可核验的触发条件；缺少触发条件的风险往往在事后才被发现。
- 问题条目应包含现象、影响范围、责任人和处置状态；问题与变更请求分开记录，变更针对基准调整，问题针对已发生的偏差。
- 风险触发后转为问题：确认触发、新建问题记录、关闭或标记原风险为已发生、交接责任与信息，处置完成后回写风险库与经验记录。
- 常见误判有三类：把已延期写成风险、把担忧写成问题、在风险和问题两边重复登记同一事项。
一句话区分：看事项是否已经发生
归类的主判据只有一条：事项是否已经发生。尚未发生、是否出现以及出现后影响多大都不确定的事项，归入项目风险；已经发生、正在造成或已经造成影响、需要有人处置的事项，归入项目问题。这条规则可以直接复述给团队：没发生的进风险，发生了的进问题。
判断时同时看两个维度，避免只凭字面归类。第一个维度是发生状态：风险是“可能发生”，问题是“已经发生”。第二个维度是实际影响：问题通常已经对范围、进度、成本或质量产生可描述的偏差，或者偏差即将显现；风险的影响仍是预估区间，需要标注可能性和影响程度。两个维度结合，可以处理“已经出现苗头但尚未造成影响”的边界情况——若触发条件已经成立、影响开始显现，按问题登记更利于及时处置；若只是概率上升，仍留在风险台账并更新可能性评估。
需要强调的是，这条规则判断的是事项当前的状态，不判断事项的严重程度。严重但尚未发生的威胁仍是风险，轻微但已经发生的阻塞仍是问题。严重程度影响优先级排序，不影响归属类别。
项目风险的定义与边界
项目风险是指尚未发生、结果不确定、一旦发生可能对项目目标产生正面或负面影响的事项。纳入风险台账的条目，通常需要具备四个构成要素，缺一项都会让后续跟踪失去抓手。
- 不确定事件：用一句话描述“可能发生什么”，例如“核心接口联调可能因第三方排期推迟而延后”。
- 发生可能性：给出高、中、低或概率区间，并说明判断依据，如历史项目数据、当前依赖方反馈。
- 影响程度：说明一旦发生，对哪个目标产生多大影响，包括受影响的里程碑、交付范围或资源投入。
- 应对措施：明确规避、减轻、转移或接受中的一种策略，指定责任人和复查时间。
风险描述应写清触发条件与受影响目标。触发条件是风险转为问题的判断依据，例如“第三方在6月10日前未提供接口文档”就是一个可核验的触发条件；受影响目标则让团队理解为什么要投入精力管理这条风险。缺少触发条件的风险条目，往往在事后才被发现已经发生，失去提前干预的机会。
以下情形不纳入风险台账：已经发生的阻塞和故障，应进问题清单；日常待办任务，属于执行计划的一部分；纯信息记录，如会议纪要中的背景说明，没有不确定性和目标影响。项目组合层面的风险平衡与资源调配属于组合管理范畴，不在本文讨论范围，单项目风险台账不必承担这一职责。
项目问题的定义与边界
项目问题是指已经发生、正在造成或即将造成项目目标偏差、需要处置和恢复的事项。问题条目的价值在于让影响可见、责任到人、处置有状态，因此登记时应包含四类信息。
- 现象：客观描述发生了什么，例如“支付模块回归测试连续两天失败，阻塞提测”。
- 影响范围：说明波及的模块、里程碑、干系人或交付承诺，能量化则量化。
- 责任人：指定单一负责人协调处置，避免多人负责等于无人负责。
- 处置状态：至少区分待处理、处理中、已解决、已关闭，并记录解决方式和验证结果。
问题与变更请求需要分开。变更请求是对已批准的范围、进度、成本或质量基准提出调整，走变更评审流程，评审通过后更新基准；问题描述的是实际发生的偏差或障碍，处置目标是恢复或减小影响。一个问题可能引发变更请求，例如延期导致需要调整里程碑，但两者是不同记录：问题记录“发生了什么、影响多大、谁在处理”，变更记录“申请改什么、评审结论是什么”。已批准的变更本身也不属于问题，它已成为新的基准。
以下情形不纳入问题清单：尚未发生的担忧，应回到风险台账评估；常规执行任务，按计划推进即可；已经走完审批的变更，按新基准执行。问题清单聚焦需要额外协调和恢复动作的事项，避免变成第二个任务列表。
从风险到问题的转换机制
风险与问题是同一事项在不同阶段的状态，转换动作要保证记录连续、责任不落空。当风险条目设定的触发条件成立，或风险实际发生并开始产生影响时，按以下步骤完成转换。
- 确认触发：由风险责任人核对触发条件是否成立，记录触发时间和判断依据，必要时同步项目经理。
- 建立问题记录：在问题清单中新建条目，承接原风险描述中的事件、受影响目标和已有应对信息，补充实际现象与当前影响范围。
- 关闭或标记原风险：将原风险条目标记为“已发生”并关闭，注明转入的问题记录编号，避免同一事项在两边重复跟踪。
- 交接责任与信息：明确问题处置负责人，移交已有的应对方案、相关干系人联系方式和历史沟通记录；若责任人不变，也要在问题记录中确认。
- 处置完成后回写：问题解决后，评估是否需要更新风险库——原风险已关闭，但同类风险可能在其他模块或后续阶段仍存在，应补充新的风险条目或更新经验记录，供后续项目参考。
转换时的常见失误是只建新记录、不关旧记录，导致风险台账长期挂着已经发生的事项，统计口径失真；或者只在风险条目下追加评论，问题清单中没有独立记录，处置状态无法跟踪。状态约定应写进团队的风险与问题管理规则：风险条目只有“开放、已关闭、已发生转问题”等有限状态，问题条目独立维护处置状态。
当风险与问题记录在同一套工作项体系中流转时，转换动作可以借助工作项类型切换、状态字段和关联关系完成。ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，提早识别风险和问题（适用于设置计划和里程碑基线的瀑布项目场景）；团队也可以按项目计划和工作分工推进事项，持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险。这些能力帮助团队在偏差扩大前发现需要登记的对象，具体的风险与问题记录类型及状态流转配置，需结合团队自身的流程设置确定。
容易混淆的相邻概念
风险与问题之外，项目中还有几类常见对象容易混入同一张清单。用同一口径横向对照，可以快速判断归属。
| 对象 | 核心特征 | 判断问题 | 归属 |
|---|---|---|---|
| 风险 | 尚未发生，结果不确定，可能影响目标 | 触发条件是什么？可能性和影响多大？ | 风险台账 |
| 问题 | 已经发生，正在或已经造成偏差，需要处置 | 影响了什么？谁负责恢复？ | 问题清单 |
| 待办任务 | 计划内要完成的工作，结果基本确定 | 是否属于既定执行计划？ | 任务列表 |
| 变更请求 | 申请调整已批准的基准，需评审 | 是否要改范围、进度、成本或质量基准？ | 变更流程 |
| 假设条件 | 为规划而设定为真的前提，尚未验证 | 前提若不成立会带来什么影响？ | 假设日志，必要时转化为风险 |
风险与待办任务的区别在于确定性：待办是团队计划要做且结果基本可控的工作，风险是不确定是否发生的外部或内部事件。问题与变更请求的区别在于对象：问题针对已发生的偏差，变更针对基准的调整申请。风险与假设条件的区别在于性质：假设是规划时主动设定为真的前提，风险是可能发生的负面事件；当假设被验证不成立并产生威胁时，应将其登记为风险，触发后再转为问题。项目组合层面的风险平衡涉及多项目资源取舍，归组合管理主题，不在单项目风险与问题归类的讨论范围内。
归类示例与常见误解
下面用几条典型事项演示判断过程，读者可以按同样方式处理手上的待登记清单。
| 事项描述 | 判定 | 理由 |
|---|---|---|
| 关键供应商可能在月底前无法交付硬件样品 | 风险 | 尚未发生，结果不确定，影响样机测试里程碑；需写明触发条件和应对措施 |
| 供应商已确认硬件样品延迟两周交付 | 问题 | 已经发生并造成测试计划偏差，需要调整排期并跟踪恢复 |
| 核心开发人员可能在下月离职 | 风险 | 尚未发生，影响进度和知识交接；应评估可能性和应对方案 |
| 核心开发人员已提交离职申请，交接期两周 | 问题 | 已经发生，需要安排交接、调整任务分配并评估交付影响 |
| 下周安排需求评审会 | 待办任务 | 计划内工作，结果基本确定，不属于风险或问题 |
| 客户要求将上线日期提前一个月 | 变更请求 | 涉及进度基准调整，应走变更评审；评审通过后按新基准执行 |
| 假设测试环境在开发完成后一周内可用 | 假设条件 | 规划前提，需验证；若验证不成立并威胁测试计划，转为风险登记 |
同一事项会随时间推移改变归属。以“供应商交付延迟”为例：最初只是可能延迟，登记为风险并设定触发条件；供应商正式确认延迟后，触发条件成立，原风险标记为已发生并关闭，新建问题记录承接处置；问题解决后，回写经验记录，并在后续采购中登记新的供应商履约风险。整个过程记录连续，统计口径清晰。
高频误判有三类。第一类是把已经延期写成风险，例如“项目可能延期”实际已经延期两周，应作为问题登记并说明影响和恢复计划。第二类是把担忧写成问题，例如“担心测试人力不够”，人力尚未短缺、影响未发生，应作为风险评估可能性和影响。第三类是在风险和问题两边重复登记同一事项，导致状态不同步、责任不清；正确做法是任一时刻只在一个清单中保持开放状态，转换时关闭旧记录并注明关联。
归类规则确定后，团队还需要在工具中落实记录类型、必填字段和状态约定。ONES 的 AI 研发管理方案围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析、根因判断和资源合理性建议，帮助管理者在风险扩大前完成干预（依赖项目、工时、缺陷与资源等数据）；其价值描述也提出从汇报驱动升级为风险驱动，帮助项目经理提前识别延期、资源不足和质量风险。这些能力服务于发现和判断环节，风险与问题如何分列、字段如何设置，仍应结合团队流程成熟度确定，不宜把某一种登记方式当作统一要求。
常见问题
风险条目已经登记，但触发条件一直没成立，应该怎么处理？
触发条件未成立说明事项仍处于不确定状态，应继续留在风险台账，并按复查周期更新可能性与影响评估。若复查发现触发条件本身写得不可核验，例如只写“供应商可能出问题”，应改写为可判断的条件，如“供应商在约定日期前未提交样品检测报告”。若外部环境变化使该风险已不可能发生，或影响已可忽略，可以关闭条目并记录关闭理由，避免台账长期堆积失效条目。
一个问题处置完成后，还需要回到风险台账做什么？
问题关闭后建议做两件事。第一，确认原风险条目已标记为已发生并关闭，注明关联的问题记录，保证统计口径不重复。第二，评估同类风险是否仍存在于其他模块、其他阶段或后续项目中，若有则补充新的风险条目并更新经验记录。这一步把单次处置转化为可复用的判断依据，避免同类问题在下一个项目重复出现。
团队规模较小、没有专职风险管理员时，风险和问题还需要分开记录吗？
建议分开记录，但可以简化字段。分开记录的核心价值是让“尚未发生”和“已经发生”两类事项的状态流转互不干扰：风险需要复查可能性和触发条件，问题需要跟踪处置进度。小团队可以只保留必要字段，例如风险保留事件描述、触发条件、责任人和复查时间，问题保留现象、影响、责任人和状态。登记方式应结合团队流程成熟度确定，不宜把某一种字段设置当作统一要求。
已经提出但尚未批准的变更申请，算风险还是算问题？
两者都不算，应作为变更请求走评审流程。变更申请针对的是对已批准基准的调整，评审结论出来之前，它既不是已发生的偏差，也不是不确定的外部事件。如果变更申请被驳回，而原基准下的偏差已经实际出现，则按问题登记；如果变更申请尚在评审、结果不确定且可能影响交付承诺，可以在风险台账中登记一条与评审结果相关的风险，并注明关联的变更申请编号。
风险转为问题后，原风险条目的历史沟通记录怎么处理？
转换时应把已有的应对方案、相关干系人联系方式和关键沟通记录移交到问题记录中，或在问题记录中注明原风险条目的编号以便追溯。原风险条目关闭后保留只读状态，不再追加新的处置进展，避免同一事项在两处更新导致信息不一致。若团队使用同一套工作项体系承载两类记录，可以通过关联关系把问题记录与已关闭的风险条目连接起来，查阅时能还原完整过程。
