项目问题台账、问题清单和风险登记册的边界，可以用事项所处的状态来判断：已经发生并阻碍项目推进的事项进入问题台账，需要按优先级排序跟进的问题形成清单视图，尚未发生的不确定性进入风险登记册。三者的用途不同，混用会让历史记录丢失或让风险跟踪失真。下面从定义、字段、转换规则和示例逐层说明。
要点总览（TL;DR）
- 项目问题台账是记录已发生、阻碍项目推进的障碍的底账，条目只增不删，跟踪到关闭并留下处理依据。
- 问题清单是台账的筛选视图或阶段性摘录，服务会议跟进和优先级排序，可随阶段重建。
- 风险登记册管理尚未发生的不确定性，记录概率、影响、应对策略与触发条件；是否已发生是风险与问题的分界。
- 风险一旦实际发生并造成障碍，应转为问题台账条目并保留来源关联，避免两处重复跟踪。
- 产品 Bug 归缺陷管理，服务中断归服务事件与问题管理，不纳入项目问题台账。
项目问题台账是什么：定义与核心字段
项目问题台账是记录项目推进过程中已经发生、对进度、成本、质量或协作造成实际影响的障碍的持续登记簿。它的关键特征是“跟踪到关闭”：每条问题从被发现到处理完毕，都要在台账中留下完整的状态变化和处理依据。临时在聊天群里提一句、会上口头过一遍，都不构成台账记录，因为缺少责任人和关闭结论，后续无法追溯。
一份可直接使用的台账，通常包含以下字段：
- 问题编号：唯一标识，便于在会议、文档和沟通中引用同一事项。
- 问题描述：说明发生了什么、在哪个环节发生，避免只写“接口有问题”这类无法判断的表述。
- 发现时间与发现人：确定问题的起点，也便于判断响应是否及时。
- 影响范围：涉及哪些模块、里程碑、团队或交付物，用于排定优先级。
- 责任人：对推进处理负责的单一角色，避免多人负责等于无人负责。
- 优先级：结合影响范围与时间紧迫度确定，作为清单排序的依据。
- 状态：如待处理、处理中、待验证、已关闭，状态流转需要留痕。
- 处理措施：实际采取的动作，而非仅写“已处理”。
- 关闭结论：说明问题如何解决、遗留影响是什么、是否需要后续观察。
台账的持续性体现在条目只增不删。问题关闭后保留在原位，通过状态标记区分，而不是从表中移除。这样在项目复盘、延期归因或同类问题再次出现时，可以查到当时的处理过程和结论。删除条目会让台账退化成一张待办列表，失去底账价值。
问题清单与问题台账：视图与底账的分工
问题清单是问题台账的筛选视图或阶段性摘录，服务于会议跟进和优先级排序。它回答的是“现在该先处理哪几件”，而台账回答的是“这件事从发生到关闭经历了什么”。两者管理的是同一批问题，差别在用途、粒度和生命周期。
从用途看，清单面向当下行动：站会、周会或专项推进会拿一份按优先级排序的未关闭问题清单，逐条确认进展和下一步动作。台账面向完整记录：审计、复盘、交接时需要看到全部条目及其历史状态。从粒度看，清单可以只保留编号、描述、责任人、状态和截止时间几个字段，台账则需要完整的处理措施与关闭结论。从生命周期看，清单可以随阶段重建，比如本周清单、本月清单、某个里程碑前的遗留问题清单；台账则持续累积，跨越整个项目周期。
实践中常见的做法是“一份台账、多份清单”：台账作为唯一数据源，清单按状态、责任人、优先级或时间窗口过滤生成。例如按责任人过滤出各小组的待办清单，按状态过滤出待验证清单，按里程碑过滤出上线前必须关闭的清单。这样既避免了同一问题在多处重复登记导致信息不一致，也让每份清单都有明确的筛选口径。
| 对比项 | 问题台账 | 问题清单 |
|---|---|---|
| 定位 | 底账，完整记录 | 视图或摘录，服务当下跟进 |
| 字段粒度 | 完整，含处理措施与关闭结论 | 精简，突出待办与优先级 |
| 生命周期 | 持续累积，条目只增不删 | 可随阶段重建 |
| 典型场景 | 复盘、审计、交接 | 站会、周会、专项推进 |
风险登记册管什么：与问题台账的状态分界
风险登记册记录尚未发生的不确定事件，关注的是“可能发生什么、发生的可能性多大、一旦发生影响多大、我们准备怎么应对”。它的核心字段包括：风险描述、发生概率、影响程度、应对策略（规避、减轻、转移或接受）、责任人、触发条件以及复查时间。触发条件是风险登记册特有的字段，它把模糊的担忧转化为可观察的信号，例如“关键供应商连续两周未回复确认邮件”可以作为供应延迟风险的触发条件。
风险与问题的分界标准是是否已经发生。尚未发生、只是存在可能性的不确定性，留在风险登记册；已经发生并造成推进障碍的，进入问题台账。这条标准看似简单，实际执行中最容易出错的是“风险已经发生却仍留在登记册里”。一旦触发条件被满足、影响已经显现，继续把它当风险跟踪，会导致问题台账缺项，处理责任和关闭结论都无处落实。
风险转为问题时，应保留来源关联：在问题条目中注明由哪条风险转化而来，风险登记册中对应条目标记为已发生并指向问题编号。这样既避免同一事项在两处重复跟踪，也保留了从预警到应对的完整链条，便于后续评估风险应对策略是否有效。风险登记册中未触发的条目则按复查时间定期回顾，判断概率和影响是否变化，必要时调整应对策略或关闭已消除的风险。
三者边界对照：一张表看清归属
把三个对象放在同一组维度下对照，归属判断会更清晰。下表按管理对象、时间属性、核心字段、典型使用者和关闭条件五个维度展开。
| 维度 | 问题台账 | 问题清单 | 风险登记册 |
|---|---|---|---|
| 管理对象 | 已发生并阻碍推进的障碍 | 台账中需要当下跟进的问题子集 | 尚未发生的不确定事件 |
| 时间属性 | 过去已发生，跟踪至关闭 | 当下待办 | 未来可能发生 |
| 核心字段 | 编号、描述、影响、责任人、状态、处理措施、关闭结论 | 编号、描述、责任人、优先级、截止时间 | 概率、影响、应对策略、触发条件、复查时间 |
| 典型使用者 | 项目经理、复盘与审计人员 | 例会主持者、各问题责任人 | 项目经理、风险责任人 |
| 关闭条件 | 问题解决并给出关闭结论 | 清单周期结束或问题状态更新后移出 | 风险已发生转为问题，或概率影响降至可接受并关闭 |
同一事项在三者间的流转路径通常是：风险登记册中的条目触发条件满足后，转为问题台账条目并保留来源关联；问题台账按状态或责任人过滤生成问题清单，用于会议跟进；问题关闭后在台账中记录结论，清单中相应条目移出。流转方向是单向的：风险可以转为问题，问题不会退回风险；清单是台账的投影，不反向修改台账数据。
几种易混情形需要单独说明。已发生但影响轻微的事项，仍应进入问题台账，只是优先级较低，不能因为“不重要”就留在风险登记册或干脆不记，否则同类事项累积后无法归因。重复出现的问题，应在台账中新建条目并关联历史条目，而不是合并成一条，否则出现频次和每次的处理差异都会丢失。已消除的风险，在登记册中标记关闭并写明消除原因，保留记录供后续同类风险参考。
具体例子与常见误解
以一个关键接口交付延迟为例，可以完整看到同一事项在三个对象间的归属变化。项目初期，团队识别到外部接口提供方排期紧张，存在延迟交付的可能，此时在风险登记册中登记：概率中等、影响为阻塞联调、应对策略为提前对齐排期并准备模拟接口、触发条件为对方超过约定日期未提供接口文档、复查时间为每周五。两周后触发条件满足，接口文档仍未到位，联调已经开始受阻，此时该事项转为问题台账条目：描述联调阻塞情况、影响范围为本迭代三个模块、指定责任人跟进、状态为处理中，并在条目中注明来源风险编号。问题处理期间，周会使用按状态过滤的未关闭问题清单逐条跟进。最终接口交付并完成联调后，在台账中填写处理措施和关闭结论，风险登记册中对应条目标记为已发生并指向该问题编号。
常见误解有两个。第一个是把问题清单当成台账：会上用一张清单跟进，会后清单被下一期覆盖，问题关闭时没有留下处理措施和结论，复盘时查不到当时为什么这样处理。纠正方式是明确清单只是视图，所有条目必须回写台账。第二个是风险已发生仍留在登记册：团队习惯了在风险表里更新状态，事项已经造成实际阻塞却还在填概率和影响，导致问题台账缺项、责任落不到人。纠正方式是在风险复查时增加一条判断：触发条件是否已满足，满足即转问题。
还有一类事项不属于这三类记录的范围。产品 Bug 归缺陷管理，按缺陷的严重程度、复现步骤和修复版本跟踪；服务中断归服务事件与问题管理，按事件响应和根因分析流程处理。这些事项有各自的管理流程和字段体系，强行放进项目问题台账会造成口径混乱。项目问题台账关注的是项目推进层面的障碍，与产品缺陷、服务事件的边界应在团队内提前约定。
落地时的记录与协作衔接
三类记录要在同一协作工具中分工承载，关键是让字段和状态各自独立，同时保留关联。可以用不同的工作项类型区分问题与风险：问题类型配置描述、影响范围、责任人、优先级、状态、处理措施、关闭结论等字段；风险类型配置概率、影响、应对策略、触发条件、复查时间等字段。问题清单则通过筛选视图实现，按状态、责任人或里程碑过滤问题类型的工作项，不单独维护一份数据。
问题条目与来源风险之间需要关联字段，风险转为问题时填写来源风险编号，风险条目同步标记已发生并指向问题。这样在查看任一方向时都能追溯完整链条。台账的定期复查可以固定节奏：每周例会上过一遍未关闭问题清单，确认责任人和下一步动作；每月或每个里程碑前复查风险登记册，判断触发条件是否满足、概率影响是否变化。关闭评审则针对拟关闭的问题，确认处理措施已落实、关闭结论已写明，再更新状态。
在 ONES 中，项目、缺陷与资源数据可以支撑进展分析和风险识别，ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成分析，帮助管理者在风险扩大前完成干预；ONES Project 承载项目管理工作项，ONES Wiki 可用于沉淀问题处理经验和复盘结论。问题与风险的具体工作项类型和字段配置，可按团队实际流程在项目管理模块中设置，使台账、清单视图与风险登记在同一套数据上衔接，减少重复登记和信息割裂。
常见问题
风险已经发生，但影响还不明显，应该先留在风险登记册观察吗？
不建议继续留在风险登记册。判断标准是是否已经发生并造成推进障碍，影响大小只决定优先级，不决定归属。已经发生的事项应进入问题台账，把优先级设低一些，同时写明当前影响有限、需要观察的条件。这样处理责任和关闭结论有落点，后续影响扩大时也有完整的起点记录可查。
问题清单和问题台账能不能只维护一份？
可以只维护一份数据，但要把角色分清：台账是唯一数据源，清单是按状态、责任人或里程碑过滤出来的视图。会议跟进时用清单，关闭和复盘时回写台账。如果只保留清单、每期覆盖，问题关闭时的处理措施和结论会丢失，复盘和交接时查不到当时的判断依据。
同一个问题反复出现，台账里应该合并成一条还是新建？
建议新建条目并关联历史条目。合并成一条会丢失出现频次和每次处理的差异，而这些信息正是判断根因是否解决的依据。新建条目时在描述中注明关联的历史问题编号，复盘时可以按关联关系统计复发次数，评估之前的处理措施是否有效。
风险转为问题后，风险登记册里的原条目怎么处理？
原条目保留，标记为已发生并指向对应的问题编号，不删除。保留原条目可以追溯从预警到应对的完整链条，也便于事后评估当时的概率判断和应对策略是否合理。风险登记册中未触发的条目则按复查时间定期回顾，概率和影响降到可接受范围或风险已消除时，标记关闭并写明原因。
在协作工具里落地时，问题和风险应该建成两类工作项还是放在同一张表里？
建议建成两类工作项，各自配置字段和状态。问题类型需要影响范围、处理措施、关闭结论等字段，风险类型需要概率、影响、应对策略、触发条件、复查时间等字段，混在一张表里会让大量字段长期为空，状态流转也难以统一。两类工作项之间用关联字段连接，风险转问题时填写来源风险编号即可保持可追溯。在 ONES 中，项目管理工作项由 ONES Project 承载，问题处理经验和复盘结论可沉淀在 ONES Wiki，具体的工作项类型与字段配置可按团队流程在项目管理模块中设置。
