项目风险与项目问题的核心区别在于事件是否已经发生：风险是尚未发生、可能影响项目目标的不确定性，问题则是已经发生并正在造成偏差、阻塞或冲突的事项。判断时先问两个问题——这件事发生了吗？已经产生实际影响了吗？答案决定它应进入风险台账还是问题清单，也决定后续动作是预防应对还是处置解决。
要点总览（TL;DR）
- 判断口径只有两个问题：事件是否已经发生、是否已经产生实际影响。尚未发生的不确定性归风险，已经发生的偏差、阻塞或冲突归问题。
- 管理动作随判断而变：风险对应预防、规避、减轻、转移和应急准备；问题对应登记、定级、分派责任人、限期处置和复盘。
- 风险触发条件被满足后，应转为问题登记，保留原风险编号作为追溯线索，同时更新责任人与处理时限，避免同一事项在两处重复跟踪。
- 假设是当前认为成立的前提，被证伪后可能转化为风险；变更是经批准的基线调整，批准后按新基线执行，不再按问题跟踪。
- 常见误解包括把风险写成确定会发生的事件、把已发生的问题长期挂在风险清单里观察，以及登记时缺少发生状态和责任人字段。
一句话区分：风险看未来，问题看当下
可以直接复述的判断口径是：风险是“可能发生”，问题是“已经发生”。风险描述的是未来时点上的不确定性，例如关键供应商可能延期交付、核心开发人员可能在下个迭代请假；问题描述的是当下已经存在的事实，例如接口联调已经阻塞三天、需求评审已经因分歧延期两次。
落到具体事项上，用两个问题完成初判：
- 是否已经发生？尚未发生、只是存在发生可能性的，归入风险；已经发生、可以指出发生时间和具体表现的，归入问题。
- 是否已经产生影响？影响尚未出现、只是可能波及进度、成本、质量或范围的，按风险管理；已经造成偏差、阻塞或冲突的，按问题管理。
这两个问题也决定了管理动作的方向。风险对应预防、规避、减轻、转移和应急准备，关注的是降低发生概率或缩小影响范围；问题对应登记、定级、分派责任人、限期处置和复盘，关注的是尽快消除已经存在的偏差。把已发生的问题挂在风险清单里，团队会持续“观察”而不动手解决；把尚未发生的风险当成问题处理，则容易在无实际影响时消耗处置资源。
定义与边界：哪些算风险，哪些算问题
项目风险是指尚未发生、但一旦发生会对项目目标产生不利影响的不确定性。它有三个典型特征：结果不确定，可能发生也可能不发生；时点在未来，当前尚未成为事实；影响指向项目目标，如进度、成本、质量、范围或交付成果。风险登记时通常需要记录可能性、影响程度、触发条件和应对策略。
项目问题是指已经发生并已造成或正在造成影响的事项，表现为进度偏差、任务阻塞、资源冲突、质量缺陷或干系人分歧。它的典型特征是事实性：能够说明何时发生、当前状态如何、影响了哪些工作。问题登记的重点是严重程度、责任人、处理时限和当前处置进展。
| 对比维度 | 项目风险 | 项目问题 |
|---|---|---|
| 发生状态 | 尚未发生，存在发生可能 | 已经发生，是既成事实 |
| 时间指向 | 未来 | 当下 |
| 影响状态 | 可能影响项目目标 | 已造成或正在造成影响 |
| 核心管理动作 | 预防、规避、减轻、转移、应急准备 | 登记、定级、分派、限期处置、复盘 |
| 关键记录字段 | 可能性、影响程度、触发条件、应对策略 | 严重程度、责任人、处理时限、处置进展 |
边界可以这样划：尚未发生的不确定性归风险管理，已经发生的阻塞和偏差归问题管理。需要说明的是，项目组合层面的风险平衡与资源调配属于更高层级的决策议题，本文不展开；本文聚焦单个项目内的事项归类与流转。
从风险到问题的转化机制
风险不会永远停留在“可能”状态。当触发条件被满足，风险就从潜在威胁变成现实问题，管理记录也应随之转换，而不是在原条目上继续标注“观察中”。
转化通常经历四个动作：
- 设定触发条件与预警信号。风险登记时就应写明什么情况意味着风险正在逼近，例如“供应商交付日期晚于某日”“缺陷密度连续两个迭代上升”。触发条件越具体，越容易在早期被识别。
- 确认风险已发生。当预警信号出现且影响已经实际产生，由风险责任人确认状态变化，说明发生时间、当前影响范围和已造成的偏差。
- 转为问题登记。在问题清单中新建条目，保留原风险编号作为关联线索，便于回溯该问题由哪项风险演化而来。原风险条目关闭或标记为已转化，避免同一事项在两处重复跟踪。
- 调整责任人与时限。风险阶段的责任人侧重监控和预防，转为问题后需要明确处置责任人，并设定处理时限和升级路径。若问题超出项目组权限，还应触发向管理层升级的动作。
这套衔接依赖风险台账与问题清单之间的状态联动。以 ONES 为例，团队可以基于项目计划和里程碑基线对比计划与执行的偏差，提早识别风险和问题；在日常推进中持续查看任务状态、阶段进展和待处理问题，及时识别影响交付的风险。当风险确认发生后，将其转为问题工作项继续跟踪，责任人和期限随状态更新，原风险编号保留为关联记录，形成从识别到处置的完整链条。
容易混淆的相邻概念：风险、问题、假设与变更
除了风险与问题，项目中还有几个常被混用的概念。登记口径不统一，会导致同一类事项分散在不同清单里，跟踪时难以汇总。
- 假设与风险。假设是当前认为成立、并据此制定计划的前提，例如“测试环境在下个迭代前可用”。假设本身不是风险，但当假设被证伪或出现动摇迹象时，可能转化为风险，进而演化为问题。管理假设的重点是验证时点和验证方式。
- 变更与问题。变更是经批准的基线调整，例如范围增加、里程碑顺延，它经过评估和审批后成为新的计划基准。问题则是未经计划的偏差。一个变更请求可能由问题引发，但批准后的变更不再按问题跟踪，而应按新基线执行。
- 问题与缺陷、阻塞。缺陷是问题的一种具体形态，指交付物未满足质量要求；阻塞是问题在任务层面的表现，指某项工作因依赖未满足而无法推进。二者都可以登记为问题，用类型字段区分，便于统计质量类问题与协作类问题的分布。
概念混用的实际影响体现在跟踪效率上：风险清单里混入已发生事项，会让风险评审变成问题汇报会；问题清单里混入假设，会让处置动作失去对象。统一字段和判定口径，比增加清单数量更能减少混乱。
具体例子与常见误解
示例一：从风险识别到转为问题。某项目在计划阶段识别出一项风险——“第三方支付接口可能因对方版本升级而延迟联调”，记录可能性为中、影响为高，应对策略是提前两周预约联调窗口，触发条件定为“对方未在约定日期前提供测试账号”。两周后测试账号仍未到位，触发条件满足，联调任务已实际阻塞。此时风险责任人确认风险发生，在问题清单登记“支付接口联调阻塞”，关联原风险编号，指定联调负责人，设定三个工作日内完成升级并给出替代方案，同时向项目负责人升级。原风险条目关闭并注明已转化。
示例二：容易误判为风险的已发生问题。团队在周会上说“数据库性能可能有问题，查询越来越慢”。进一步追问后发现，慢查询已经连续一周影响报表产出，属于已经发生并造成影响的事项，应直接登记为问题并安排排查，而不是作为风险继续观察。判断依据仍然是那两个问题：已经发生了吗？已经产生影响了吗？两个答案都是“是”，就按问题处理。
常见误解主要有三类：
- 把风险写成确定会发生的事件。“下个迭代会延期”是判断而非风险。风险应描述不确定性与条件，例如“若关键模块返工超过两次，下个迭代可能延期”。
- 把问题当成风险长期挂账。已经阻塞的事项留在风险清单里反复“监控”，会延误处置时机。风险一旦触发，应及时转为问题并设定时限。
- 只记事项不记状态。缺少发生状态、影响目标和责任人字段，事后无法判断某条目该按风险还是问题跟踪。
为减少判断分歧，登记字段建议至少包含：事项描述、类型（风险或问题）、发生状态、影响的目标、可能性或严重程度、责任人、应对或处置动作、期限、关联事项编号。类型字段与发生状态字段配合使用，可以让团队在评审时快速筛出需要预防的事项和需要处置的事项，也让风险转问题的过程留下可追溯的记录。
常见问题
风险触发条件已经出现，但影响还不明显，应该先转成问题吗？
可以先判断影响是否已经实际产生。触发条件出现但尚未造成偏差时，风险仍处于发生概率上升的阶段，适合更新风险等级、加强监控并准备应急方案。一旦出现可指认的进度延误、任务阻塞或质量下降，就应转为问题登记，因为此时管理动作要从预防切换到处置。
实际操作中，把触发条件写具体能减少这类犹豫。例如把“供应商可能延期”细化为“供应商交付日期晚于某日”，条件满足与否一目了然，团队不必反复讨论是否已经发生。
同一个事项既像风险又像问题，能否在两个清单里各登记一条？
不建议同时保留两条独立条目。两处登记会让责任人、期限和状态各自更新，评审时难以判断哪条是最新进展。更清晰的做法是确定一个主归属：已经发生并造成影响的按问题跟踪，原风险条目关闭或标记为已转化，并在问题条目中保留原风险编号作为关联。
如果事项包含多个层面，可以拆成两条分别描述。例如“接口联调阻塞”登记为问题，而“后续模块可能因联调延迟而压缩测试时间”登记为风险，两者指向不同的管理动作，关联编号保持可追溯。
问题处置完成后，还需要回到风险清单做记录吗？
问题关闭后，建议在复盘环节回看它由哪项风险演化而来，以及当初的触发条件和应对策略是否有效。这些结论可以更新到风险登记的经验记录中，用于后续同类项目的识别和预警。原风险条目保持已转化状态，不再重新打开。
如果处置过程中发现新的不确定性，例如临时方案带来后续维护压力，应作为新风险单独登记，而不是把已关闭的问题重新挂回风险清单。
团队规模较小、没有专职风险负责人时，这套区分还有必要吗？
有必要，但可以简化。小团队不必设置复杂的风险评审流程，只需在任务跟踪中保留类型字段和发生状态字段，让每个事项能看出是待预防还是待处置。责任人可以由任务负责人兼任，期限跟随迭代节奏设定。
简化的重点是字段口径统一，而不是清单数量。类型、发生状态、影响目标、责任人、期限这几个字段保留下来，团队在周会或迭代评审时就能快速筛出需要干预的事项。
风险转为问题后，原来的应对策略还需要保留吗？
建议保留为背景信息。原应对策略记录了团队当初打算如何降低概率或缩小影响，转为问题后可以对照检查哪些措施已执行、哪些未执行，帮助判断问题成因。这部分内容不必出现在问题条目的显眼位置，作为关联记录或备注即可。
问题处置的重点转向当前影响范围、处置责任人和完成时限。若原应对策略中的应急方案仍然适用，可以直接转为处置动作，减少重新制定方案的时间。
