项目风险管理与项目问题管理的区别和衔接

项目风险管理与项目问题管理的区别，可以用一个判断标准说清：事件尚未发生、只是可能影响项目目标的，归风险；事件已经发生并造成或即将造成影响的，归问题。两者并非两套互不相干的清单，风险触发后要转为问题跟进处置，问题处置中暴露的新不确定性也要回流为风险。本文围绕定义边界、管理机制、双向衔接和易混概念展开。

要点总览（TL;DR）

• 判断归属看两个问题：事件是否已经发生、是否已对项目目标产生实际影响；两者都成立归问题，仍停留在可能性层面归风险。
• 风险由不确定性、发生概率、潜在影响和应对预案构成；问题由已发生事实、影响对象、处置责任和关闭条件构成，字段设计各有侧重。
• 风险转为问题的触发点是事先约定的触发条件成立，转出后保留原风险记录并关联新问题，便于追溯。
• 问题处置中发现的新不确定性应回流为风险单独登记，问题关闭后若根因仍可能复发，也应回流一条风险用于长期监控。
• 变更请求走变更流程，缺陷和阻碍属于问题的具体形态，假设性担忧归风险，组合层面的风险平衡不在本文范围。

一句话说清两者的区别

面对一个具体事项，先问两个问题：它已经发生了吗？它已经对项目目标产生实际影响了吗？两个答案都是“是”，就应进入问题管理；只要事件尚未发生、影响还停留在可能性层面，就应进入风险管理。

风险管理的对象是尚未发生的不确定性。团队记录的是“可能发生什么、发生概率多大、一旦发生影响多大、提前做什么准备”。问题管理的对象是已经发生并产生影响的事项。团队记录的是“发生了什么、影响了谁、由谁负责、何时解决、怎样验证关闭”。

这条标准可以直接用于日常归类。例如“核心开发人员可能在下个迭代离职”是风险，因为离职尚未发生；“核心开发人员已提交离职申请，下月离开”是问题，因为事实已经成立，需要立即安排交接、补位和知识转移。判断时不必纠结事项的严重程度，严重的问题依然是问题，轻微的风险依然是风险，归属取决于发生状态而非影响大小。

定义与边界：什么算风险，什么算问题

风险由四个要素构成：不确定性、发生概率、潜在影响和应对预案。缺少其中任何一项，风险管理都会退化为模糊的担忧。不确定性说明事件尚未发生；发生概率让团队能够排序；潜在影响把风险和项目目标挂钩；应对预案则回答“如果发生，我们准备怎么做”。四要素齐全，一条风险记录才具备被监控和触发的基础。

问题由另外四个要素构成：已发生的事实、影响对象、处置责任和关闭条件。已发生的事实是问题成立的前提；影响对象说明它波及范围、进度、成本还是质量；处置责任明确谁负责推进；关闭条件则给出“什么情况下可以认为这件事结束了”的验收口径。四个要素缺失，问题就容易长期挂起、无人收口。

对比项	风险	问题
核心对象	尚未发生的不确定性	已经发生并产生影响的事项
关键要素	不确定性、发生概率、潜在影响、应对预案	已发生事实、影响对象、处置责任、关闭条件
时间指向	面向未来	面向当下
典型动作	识别、评估、制定预案、监控触发	登记、定级、分派、处置、验证关闭
不包括	已经发生的阻塞、已经出现的延期	尚未发生的假设性担忧、纯假设情景

边界之外还有两类内容需要说明。已经发生的阻塞事项属于问题，不应继续挂在风险清单里等待“观察”；尚未发生的假设性担忧属于风险，不应提前登记为问题制造虚假的紧迫感。项目组合层面的风险平衡与资源调配涉及多项目之间的取舍，属于组合管理范畴，本文不展开。

机制与组成：两套管理各自管什么

风险管理是一条面向未来的闭环：识别、分析评估、制定应对计划、持续监控并在触发条件成立时采取行动。识别阶段尽量把不确定性找全；分析评估阶段判断概率与影响，排出优先级；应对计划阶段确定规避、减轻、转移或接受等策略，并明确预案；监控阶段跟踪触发条件是否出现。风险负责人通常由最了解该风险领域的人担任，职责是持续观察、更新评估并在条件变化时推动响应。

问题管理是一条面向当下的处置闭环：登记、定级、分派、处置、验证、关闭。登记要写清事实和影响；定级依据紧急度和影响范围确定处理顺序；分派明确问题责任人；处置阶段推进解决方案；验证确认影响已消除；关闭需要满足事先约定的关闭条件。问题责任人对处置结果负责，需要在过程中同步进展，避免问题被登记后长期沉默。

维度	风险管理	问题管理
流程环节	识别、分析评估、应对计划、监控与触发	登记、定级、分派、处置、验证、关闭
关键字段	发生概率、潜在影响、触发条件、应对策略、风险负责人	影响范围、紧急度、问题责任人、处置措施、关闭条件
角色职责	风险负责人观察变化、维护评估、推动预案生效	问题责任人组织处置、同步进展、完成验证关闭
状态特征	开放监控中、已触发、已关闭（不再构成威胁）	待分派、处理中、待验证、已关闭

两类记录在字段设计上各有侧重。风险记录围绕“概率与影响”组织信息，便于排序和判断是否需要提前投入；问题记录围绕“影响与紧急度”组织信息，便于确定处置顺序和资源投入。把两者的字段混用，常见结果是风险清单里堆满已发生事项，或者问题清单里写着“可能”“也许”，导致团队无法据此安排工作。

当风险与问题需要在同一套工作项体系中登记和关联时，工具承载的是记录、状态和关联关系。以 ONES 为例，团队可以按项目计划和工作分工推进事项，持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险；设置项目计划和里程碑基线后，还能实时对比计划与执行的偏差，提早识别风险和问题。这些能力支撑的是识别与跟踪动作，风险与问题如何分类、如何流转，仍取决于团队事先约定的管理规则。

衔接机制：风险如何转为问题，问题如何回流风险

风险转为问题的触发点，是风险记录中约定的触发条件成立。触发条件应当在制定应对计划时就写清楚，例如“供应商交付日期晚于某日”“关键岗位空缺超过两周”“某项测试连续两轮未通过”。条件一旦成立，风险负责人应将该风险标记为已触发，并在问题清单中登记一条对应的问题记录，写清已发生的事实、影响对象、问题责任人和关闭条件，同时在两条记录之间保留关联，便于追溯来龙去脉。

问题回流风险的方向同样重要。问题处置过程中，团队常会发现新的不确定性，例如临时补位人员的能力尚待验证、替代供应商的产能存在上限、修复方案可能影响其他模块。这些内容尚未发生，不应塞进原问题记录里当作处置进展，而应作为新风险登记，注明来源问题，并指定风险负责人持续观察。这样问题记录保持聚焦于当下处置，风险清单则承接由此衍生的未来不确定性。

两个台账之间的状态与关联需要持续维护。风险触发并转为问题后，原风险记录不宜直接删除，应保留并标注已触发及关联的问题编号；问题关闭后，若其根因仍可能再次引发同类事件，应回流一条风险记录用于长期监控。复盘时还要检查误分类：把已发生事项错记为风险的，应补登为问题并追溯处置；把假设性担忧错记为问题的，应转为风险并补充概率与影响评估。纠正动作本身也应留下记录，避免同类错误反复出现。

相邻概念区别：与变更、缺陷、阻碍的界线

变更请求处理的是对已批准基准的修改诉求，例如范围增加、进度调整、预算追加。它既不是风险也不是问题，而是一个需要评审和审批的决策事项。变更请求可能由风险应对或问题处置引发，例如为规避风险而调整计划，但变更本身应走变更流程，不应直接记入风险或问题清单。

缺陷是产品、交付物或流程中已经存在的偏差，具有明确的判定标准和修复路径。缺陷属于问题的一种具体形态，可以纳入问题管理跟踪，但缺陷管理通常还有独立的严重等级、复现步骤和修复验证要求。阻碍是已经发生、正在阻塞工作推进的事项，属于问题范畴，特点是直接影响当前任务的进行，需要优先解除。

事项类型	归属判断	说明
变更请求	走变更流程	对已批准基准的修改诉求，需评审审批
缺陷	问题的一种	已存在的交付物偏差，按缺陷流程跟踪修复
阻碍	问题的一种	已发生且正在阻塞推进，需优先解除
假设性担忧	风险	尚未发生，需补充概率、影响与预案
组合层面风险平衡	组合管理范畴	多项目间资源与风险取舍，不在本文范围

区分这些概念的价值在于让每类事项进入匹配的处理通道。把变更请求当问题处置，容易绕过审批直接改动基准；把缺陷当普通风险观察，会延误修复；把阻碍写成风险，则会让本应立即处理的事情停留在“持续关注”。归属清楚，处理路径才清楚。

具体例子与常见误解

以下三个情景可以检验归类标准是否好用。情景一：供应商可能延期交付关键部件。事件尚未发生，属于风险，应记录发生概率、对进度的影响、触发条件（如约定交期前若干天仍未发货）以及备选供应商或替代方案。情景二：供应商已经延期，关键部件未按约定日期到货。事件已经发生并影响进度，属于问题，应登记影响范围、问题责任人、补救措施和关闭条件，同时可回流一条“后续批次是否还会延期”的风险。情景三：关键人员已经离职。事实成立，属于问题，需要立即安排工作交接、权限回收和补位；若补位人员能力尚待验证，则另记一条风险持续观察。

常见误解之一，是把已经发生的问题写成风险以回避上报。例如把“测试环境已连续三天不可用”写成“测试环境可能存在不稳定风险”，看似语气缓和，实际掩盖了已经发生的阻塞，导致处置被推迟。纠正方式是回到两个判断问题：是否已发生、是否已产生影响，两者成立就登记为问题。

常见误解之二，是把风险清单当成问题清单使用。风险清单里出现大量“某功能未完成”“某评审未通过”这类已发生事项，会让风险监控失去意义，因为风险负责人无法对已发生事实制定预案，只能转交处置。纠正方式是定期清理风险清单，把已触发事项移入问题跟踪，并保留关联。

常见误解之三，是认为风险关闭就等于问题解决。风险关闭只表示该不确定性不再构成威胁，可能因为触发条件已不可能出现，也可能因为风险已转为问题。若属于后者，真正的处置在问题清单中继续进行，风险关闭不代表影响已经消除。团队在复盘时应核对每条已关闭风险的去向，确认没有事项在流转中丢失。

把上述规则落到日常协作中，风险与问题需要在同一处可查、可关联、可追踪。ONES Project 支持按项目计划推进任务并持续查看任务状态、阶段进展和待处理问题，配合全局筛选与项目内筛选，团队可以按类型、责任人等条件快速定位待处理事项；缺陷可一键提交至对应项目或迭代并跟踪修复情况。风险与问题如何分设记录类型、如何建立触发关联，仍需团队结合自身流程约定，工具提供的是记录与流转的承载基础。

常见问题

风险触发后，原风险记录应该删除还是保留？

建议保留。风险触发并转为问题后，原风险记录应标注为已触发，并关联对应的问题编号，这样团队能追溯这条问题从哪条风险演变而来，复盘时也能核对触发条件是否设置得合理。直接删除会让流转链条断裂，后续很难判断同类风险是否被反复遗漏。

保留记录还有一个实际作用：如果问题处置完成后根因仍然存在，可以基于原风险记录快速重建监控项，不必从头再做一次识别和评估。

一个事项既已部分发生、又存在后续不确定性，该怎么记？

拆成两条记录分别管理。已经发生并产生影响的部分登记为问题，写清事实、影响对象、责任人和关闭条件；尚未发生的后续不确定性登记为风险，写清概率、潜在影响、触发条件和预案，并注明来源问题。

例如供应商首批货物已延期，延期本身是问题；后续批次是否还会延期是风险。两条记录关联但不混写，问题记录保持聚焦当下处置，风险记录承接未来观察，各自的负责人和状态也清晰。

团队规模较小、没有专职风险负责人时，这套区分还有必要吗？

有必要，但可以简化执行。区分风险与问题的核心价值是让已发生的事项进入处置通道、未发生的事项进入观察通道，这个判断与团队规模无关。小团队可以由项目经理兼任风险负责人，把风险评审并入例行项目例会，用一页清单维护概率、影响和触发条件即可。

需要简化的是流程形式，例如减少审批层级、合并评审会议；不宜简化的是触发条件和关闭条件这两项，缺少它们，风险无法判断何时转问题，问题也无法判断何时算结束。

风险清单和问题清单应该多久清理一次？

清理频率取决于项目节奏，常见做法是随例行项目例会同步检查，迭代型项目在每个迭代结束时清理一次，周期较长的项目按月检查。清理时重点核对三类情况：已触发但尚未转为问题的风险、长期挂起没有进展的问题、以及已经不可能发生的风险。

清理动作本身要留下记录，尤其是误分类的纠正，例如把已发生事项从风险清单移入问题清单，应注明原因，避免同类错误在后续反复出现。

在工具中登记时，风险和问题需要分成两种记录类型吗？

这取决于团队的管理精细度要求。分成两种记录类型的好处是字段可以分别设计，风险侧重概率、影响和触发条件，问题侧重紧急度、责任人和关闭条件，筛选和统计也更清晰；如果团队规模小、事项量不大，也可以在同一类记录中用标签或状态区分，降低维护成本。

无论采用哪种方式，建议保留两类记录之间的关联能力，让风险转问题和问题回流风险都有据可查。以 ONES Project 为例，团队可以按项目计划推进任务并持续查看任务状态、阶段进展和待处理问题，配合全局筛选与项目内筛选快速定位待处理事项；具体的记录类型划分与关联方式，仍需团队结合自身流程约定。