项目风险管理与项目问题管理常被混用，但两者处理的对象不同：风险管理面向尚未发生、结果不确定的事件，提前评估概率与影响并准备应对；问题管理面向已经发生、正在造成阻碍的事项，记录、定级、指派责任人并推动关闭。判断一件事该记成风险还是问题，核心看它是否已经发生并产生实际影响；两者通过“风险触发”衔接，风险一旦发生即转为问题，并保留来源关联便于复盘。
要点总览（TL;DR）
- 项目风险管理处理尚未发生、结果不确定的事件，提前评估概率与影响并准备应对；项目问题管理处理已经发生、正在造成阻碍的事项，推动解决并验证关闭。
- 判断归属的核心标准是“是否已经发生并产生实际影响”：尚未发生的归风险，已经发生并需要处置的归问题。
- 两者通过“风险触发”衔接：触发条件成立后，风险转为问题，明确问题责任人并完成交接，同时保留来源关联。
- 假设被证伪、变更导致返工、已发生但影响尚未显现的事项，都需要按状态判断归属，避免把担心的事一律记成问题。
- 常见误解包括把担心的事记成问题、风险登记后不再跟踪、问题关闭后不回溯关联风险，三者都会让预警与处置脱节。
项目风险管理与项目问题管理的核心区别
项目风险管理是对未来不确定性的系统性处理。团队在项目早期识别可能影响范围、进度、成本或质量的事件，评估其发生概率与影响程度，为高优先级风险制定应对策略，并在项目推进中持续监控触发信号。它关心的问题是“什么可能发生，我们提前做什么”。
项目问题管理处理的是已经发生并正在影响项目目标的事项。这类事项已经造成或正在造成实际阻碍，例如交付延期、缺陷阻塞测试、关键资源无法到位。问题管理的动作包括登记、定级、指派责任人、跟踪解决进度、验证关闭。它关心的问题是“已经出了什么事，谁在什么时候解决”。
判断归属的核心标准可以归纳为一句话：尚未发生、结果不确定的归风险；已经发生、需要处置的归问题。这条标准同时适用于新识别的事项和已经在跟踪的事项。一个事项在登记时是风险，一旦触发条件成立，就应转为问题，而不是继续留在风险清单里。
| 比较维度 | 项目风险管理 | 项目问题管理 |
|---|---|---|
| 管理对象 | 尚未发生的不确定性事件 | 已发生并产生影响的阻碍 |
| 时间取向 | 前瞻，关注未来可能 | 回溯与当下，关注已发生事实 |
| 核心目标 | 降低威胁概率或减轻影响，抓住机会 | 尽快消除影响、恢复计划 |
| 责任人角色 | 风险责任人，负责监控与执行应对措施 | 问题责任人，负责推动解决并交付结果 |
| 典型动作 | 识别、评估、制定应对、监控触发 | 登记、定级、指派、解决、验证关闭 |
| 完成标志 | 风险关闭、降级或转为问题 | 影响消除并经确认关闭 |
两类管理在责任人设置上也有差别。风险责任人通常由最接近该不确定性的人担任，职责是持续观察信号并在触发时启动应对；问题责任人则需要对解决结果负责，往往拥有调动资源或协调跨团队的权限。把两者混为一谈，容易出现“风险没人盯、问题没人扛”的情况。
边界划分：哪些事项归入风险，哪些归入问题
归属判断可以从事件状态入手。以下情形属于尚未发生、结果不确定，应归入风险：供应商可能延期交付、需求可能发生变更、关键人员可能流失、第三方接口可能不稳定、验收标准可能收紧。这些事项的共同点是当前没有造成实际影响，但存在发生的可能性，需要提前准备应对方案和触发信号。
以下情形已经发生并产生实际影响，应归入问题：供应商已经延期且影响里程碑、需求已经变更导致已完成工作返工、关键人员已经离职造成模块无人负责、接口故障已经阻塞联调、验收未通过导致交付推迟。这些事项需要立即处置，记录的重点是影响范围、严重程度和解决时限。
| 判断情形 | 归属 | 记录重点 |
|---|---|---|
| 供应商可能延期，尚未收到延期通知 | 风险 | 概率、影响、触发信号、应对预案 |
| 供应商已发延期通知，交付节点受影响 | 问题 | 影响范围、责任人、解决时限 |
| 需求可能变更，正在评估可能性 | 风险 | 变更来源、影响评估、应对策略 |
| 需求已变更，已完成工作需返工 | 问题 | 返工范围、工时影响、责任人 |
| 关键人员有流失可能，尚未提出离职 | 风险 | 替代方案、知识备份计划 |
| 关键人员已离职，模块无人接手 | 问题 | 交接缺口、临时负责人、恢复计划 |
处于临界状态的事项需要额外判断。例如“供应商回复变慢，尚未确认是否延期”，此时影响尚未确认，可以继续作为风险跟踪，同时设置明确的触发条件，如“超过约定交付日前三天仍未确认排期即转为问题”。触发条件写清楚，临界状态就不会长期悬空。
同一事项在生命周期中从风险转为问题是正常流转。处理方式是：在风险登记中标记该风险已触发，生成对应问题记录，保留与原风险的关联，原风险状态改为“已转为问题”而非直接删除。这样既避免重复跟踪，也保留了从预判到实际发生的完整链条，便于后续复盘应对措施是否有效。
风险与问题如何衔接：从识别到关闭的流转机制
两套机制的衔接点在于“风险触发”。风险登记与问题登记在信息结构上有差异，也有可共用的字段。风险登记通常包含风险描述、发生概率、影响程度、风险等级、触发信号、应对策略、风险责任人、监控频率；问题登记通常包含问题描述、实际影响、严重等级、问题责任人、解决期限、当前状态、解决结果。两者可以共用项目、关联工作项、来源、标签、关联文档等字段，这些共用字段是建立关联的基础。
风险转为问题的触发条件应当事先写明，常见形式包括：概率评估变为确定发生、监控指标越过阈值、外部通知确认不利结果。触发后，风险责任人将事项提交为问题，明确问题责任人并完成交接，交接内容包括已执行的应对措施、当前影响范围、待决事项。风险记录保留并标注“已触发”，问题记录标注来源风险，形成双向可查的关联。
风险应对措施执行过程中也可能产生新问题。例如为规避供应商延期而启用备选供应商，备选供应商的资质审核未通过，这就是应对动作带来的新问题。这类问题应正常进入问题登记，同时在来源字段中标注对应的风险与应对措施，便于判断原应对策略是否需要调整。
关闭与复盘阶段，两类记录需要一起看。问题关闭时确认影响是否消除、是否需要更新相关风险的概率或影响评估；风险关闭时确认触发条件是否已失效、应对措施是否产生了遗留问题。复盘时按“风险—应对—触发—问题—解决”的链条回溯，可以判断哪些风险预判准确、哪些应对措施有效、哪些问题本可提前识别。
在工具承载上，这类流转需要工作项状态与关联记录的支持。ONES 的项目计划与里程碑基线可用于对比计划与执行偏差，帮助团队提早识别风险和问题；任务状态、阶段进展和待处理问题的持续查看，也有助于及时发现影响交付的风险。风险与问题是否分设独立登记对象、两者之间的关联与状态流转如何配置，属于具体产品的配置细节，选型时应结合实际版本核验。
容易混淆的相邻概念：风险、问题、假设与变更
假设与风险容易混淆。假设是团队已接受为真的前提，例如“测试环境在开发完成后两周内可用”。假设本身不是风险，但假设不成立时会转化为风险或问题。管理上应记录假设并定期验证，假设被证伪时，评估其影响：若影响尚未发生，作为风险处理；若已造成阻碍，作为问题处理。
变更与问题也不同。变更是经审批的范围、进度或基线调整，例如客户正式确认增加一个功能模块并相应延长工期。变更走变更控制流程，记录审批结论和新基线；问题则是需要处置的阻碍。需求变更导致返工，返工本身是问题，变更审批是另一条流程，两者应分别记录并相互关联。
组合层面的风险平衡不属于单个项目的风险或问题管理。在多项目之间调配资源、权衡整体风险敞口，属于项目组合管理的范畴，其决策对象是项目集合而非单个项目内的事件。单个项目的风险登记不应承担组合决策的职责，否则会让项目层面的跟踪失去焦点。
已发生但影响尚未显现的事项，判断上偏向问题。事件已经发生，只是后果还在传导，例如关键人员已提出离职但尚未离开、供应商已确认延期但缓冲期尚未耗尽。这类事项应按问题登记并设置观察期，因为处置窗口正在缩小，需要责任人主动干预，而非继续按概率监控。
具体例子与常见误解
以下示例为演示情景，用于说明归属判断与流转过程。某项目计划在第三季度末完成系统上线，项目经理在月度评审中识别到“核心支付模块的第三方接口文档可能延迟提供”。此时接口文档尚未延迟，属于风险：记录概率为中、影响为高，触发信号设为“约定提供日前五天未收到文档”，应对策略为提前联系对接人并准备简化版对接方案，风险责任人指定为技术负责人。
两周后约定提供日临近，对接方确认文档将推迟十天，触发条件成立。技术负责人将该风险转为问题：问题描述写明实际延迟天数与影响的上线节点，严重等级定为高，问题责任人改为集成负责人，交接已执行的应对动作和当前待决事项，问题记录关联原风险。集成负责人推动简化版对接方案落地，联调完成后验证影响消除，问题关闭。复盘时团队回看这条链条，确认触发信号设置及时，但应对方案准备偏晚，后续项目将简化版方案的准备提前到风险登记阶段。
常见误解一：把所有担心的事都记成问题。担心的事大多尚未发生，记成问题会让问题清单膨胀，真正需要立即处置的事项被淹没，团队也会逐渐忽视清单。正确做法是先按“是否已发生并产生实际影响”判断，未发生的进风险登记。
常见误解二：风险一旦登记就不再跟踪。风险登记不是归档动作，概率和影响会随项目推进变化，触发信号需要定期检查。长期不更新的风险清单会失去预警作用，等到事项发生时才被动应对。
常见误解三：问题解决后不回溯关联风险。问题关闭时若不回看来源风险，就无法判断原应对措施是否有效、同类风险是否仍存在。缺少回溯会让同样的风险在后续阶段重复触发，团队也难以积累可复用的应对经验。
这些误解带来的管理后果是共同的：风险与问题的边界模糊，责任归属不清，预警和处置脱节。把归属标准写进团队的工作约定，在风险登记时写明触发条件，在问题关闭时回看关联风险，两套机制才能真正衔接起来，形成从预判到处置再到复盘的闭环。
常见问题
一个事项已经发生，但影响还没显现，应该记成风险还是问题？
这类事项按问题登记更合适。事件已经发生，只是后果还在传导，例如关键人员已提出离职但尚未离开、供应商已确认延期但缓冲期尚未耗尽。处置窗口正在缩小，需要责任人主动干预，而不是继续按概率监控。登记时可以设置观察期，明确在多长时间内确认影响范围，并同步评估是否需要调整相关风险的评估结论。
风险转为问题后，原来的风险记录应该删除吗？
不建议删除。原风险记录应保留并标注“已触发”或“已转为问题”，问题记录标注来源风险，形成双向可查的关联。保留这条链条的价值在于复盘：可以判断触发信号设置是否及时、应对措施是否有效、同类风险是否还会在后续阶段出现。删除记录会让预判到实际发生的完整过程丢失，后续复盘缺少依据。
风险应对措施执行过程中产生了新问题，应该怎么记录？
新问题正常进入问题登记，同时在来源字段中标注对应的风险与应对措施。例如为规避供应商延期而启用备选供应商，备选供应商资质审核未通过，这就是应对动作带来的新问题。标注来源后，团队可以判断原应对策略是否需要调整，避免把应对措施本身变成新的隐患。
假设和风险是什么关系，假设不成立时怎么处理？
假设是团队已接受为真的前提，本身不是风险，但假设不成立时会转化为风险或问题。管理上应记录假设并定期验证。假设被证伪时评估影响：若影响尚未发生，作为风险处理，制定应对并设置触发信号；若已造成实际阻碍，作为问题处理，指派责任人推动解决。
在工具中落地时，风险与问题需要分设独立登记对象吗？
这取决于团队规模和跟踪复杂度，没有统一要求。规模较小、事项不多的项目，可以在同一工作项类型下用状态或标签区分风险与问题，重点是保留来源关联和触发条件字段。事项较多、需要分别统计预警与处置情况时，分设独立登记对象更便于管理。ONES 的项目计划与里程碑基线可用于对比计划与执行偏差，帮助团队提早识别风险和问题；任务状态、阶段进展和待处理问题的持续查看，也有助于及时发现影响交付的风险。风险与问题是否分设独立登记对象、两者之间的关联与状态流转如何配置，属于具体产品的配置细节，选型时应结合实际版本核验。
