项目问题台账、问题清单和风险登记册常被混用，核心区别在于事项是否已经发生、记录承担什么用途。已发生且需要有人推动解决的障碍进入问题台账；从台账中筛出当期要处理的部分，形成问题清单；尚未发生、可能影响项目的不确定性留在风险登记册。本文按这三条线索说明定义、判断规则和流转方式，并给出一个完整例子。
要点总览（TL;DR）
- 项目问题台账是持续维护的登记表，记录已发生、影响项目推进、需要指定人员推动解决的障碍，核心字段包括问题描述、责任人、优先级、状态和关闭结论。
- 三者的首要分界是事项是否已经发生：已发生的障碍进问题台账，尚未发生的不确定性留在风险登记册；问题清单是从台账中按条件筛出的当期处理视图，本身不产生新数据。
- 风险触发后应在问题台账中新建问题记录并关联原风险条目，保留原风险的概率评估和预案执行情况，直接改写风险条目会让追溯断链。
- 台账负责完整记录，清单负责当期聚焦，登记册负责提前准备；三者通过关联关系保持连续，定期复盘时分别检查长期未关闭项和风险变化。
- 常见误用包括把假设性风险直接写成问题、把台账当每日待办清单用、关闭后删除记录导致复盘无据可查。
项目问题台账是什么
项目问题台账是一份持续维护的登记表，记录项目推进过程中已经发生、对进度、成本、质量或协作造成实际影响、需要指定人员推动解决的事项。它的管理目的是让每一个障碍都有归属、有状态、有结论，避免问题在会议和聊天中被反复提起却无人收口。
台账与一次性问题记录的区别在于持续性。会议纪要里的一条待办、邮件里的一次求助，只说明问题被提到过；台账要求同一事项从提出到关闭保持同一条记录，状态随处理进展更新，关闭时留下结论。这样后续复盘、追责和经验沉淀才有依据。
一份可用的台账通常包含以下字段：
- 问题描述：发生了什么、影响哪个交付物或环节，写清事实而非情绪判断。
- 提出人与提出时间：保留发现问题的来源，便于回溯。
- 责任人：对推动解决负责的单一角色，避免多人共同负责导致无人推进。
- 优先级：按对项目目标的影响程度排序，为筛选当期处理项提供依据。
- 状态：如待处理、处理中、待验证、已关闭，状态定义应统一。
- 关闭结论：说明如何解决、遗留什么、是否需要转为其他记录。
台账的字段不必求多，关键是责任人和状态两项始终有效。责任人空缺或状态长期不更新的台账，会退化成问题堆放处，失去跟踪价值。
三者的边界：按发生状态和用途划分
区分三者的第一判断是事项是否已经发生。已经发生、正在造成影响、需要有人采取行动消除或缓解的，属于问题；尚未发生、只在特定条件下才可能影响项目的，属于风险。这一条时间与确定性分界优先于其他任何分类习惯。
第二条判断是记录承担的用途。问题台账是记录载体，同一批问题在台账中持续存在，直到关闭；问题清单是从台账中按条件筛出的视图或待办列表，回答“这一周、这个迭代、这个负责人当前要处理什么”。清单不产生新数据，它的内容来自台账，筛选条件变化时清单随之变化。
风险登记册管理的是另一类信息：不确定事件的发生概率、一旦发生的影响程度、应对策略与预案、风险责任人和复查时间。风险登记册不要求事项已经造成影响，它的价值在于提前准备，让团队在风险触发时有既定动作可执行。
| 对比项 | 项目问题台账 | 问题清单 | 风险登记册 |
|---|---|---|---|
| 记录对象 | 已发生、影响项目推进的障碍 | 台账中筛出的当期处理项 | 尚未发生的不确定事件 |
| 核心问题 | 这个问题由谁推到关闭 | 现在先处理哪几件 | 可能发生什么、如何应对 |
| 关键字段 | 描述、责任人、优先级、状态、关闭结论 | 筛选条件、处理顺序、截止时间 | 概率、影响、应对预案、复查时间 |
| 数据关系 | 持续登记的唯一数据源 | 台账的派生视图 | 独立登记，触发后与台账关联 |
| 结束方式 | 验证后关闭并留结论 | 随筛选周期更新 | 关闭、降级或转为问题 |
同一事项可以跨册迁移。风险触发、变成实际障碍后，应在问题台账中新建问题记录，同时保留原风险条目并注明触发依据和关联关系。直接改写风险条目会让此前的评估和预案失去追溯线索，复盘时说不清当初判断是否准确。
台账、清单与登记册如何联动运转
三者构成一条连续流程：识别不确定性、评估并登记风险、风险触发后转为问题、从台账筛出当期清单、责任人推进、评审关闭、定期复盘更新。每个环节都有明确的输入、动作和交接物。
风险触发后的转入时机，以“不确定性已经消失、影响开始实际发生”为标志。转入时保留原风险的概率评估、影响判断和预案执行情况，在新问题记录中关联原风险编号。这样处理动作有据可查，也能检验原有预案是否有效。
从台账筛出当期问题清单，常用规则包括按优先级、按责任人、按里程碑截止时间或按状态。筛选规则应事先约定并保持稳定，否则清单每周口径不同，团队无法据此安排工作。清单是工作视图，不替代台账的完整记录。
责任人推进问题后，状态按约定流转，处理结果需要经过验证再关闭。关闭结论写清解决方式、验证人和遗留事项；涉及流程或方案缺陷的，可另行提出改进项。评审环节的作用是确认问题确实消除，而非仅确认有人做过动作。
定期复盘同时更新两份记录：台账侧检查长期未关闭项、责任人空缺项和重复出现的问题；登记册侧复查风险概率与影响是否变化、预案是否仍可执行、已触发风险是否完成迁移。复盘频率可按项目节奏设定，例如每个迭代或每个里程碑一次。
在工具承载上，这类登记与流转需要记录可持续存在、状态可更新、关闭有结论。ONES 可用于承载问题与风险的登记和状态流转，把责任人和处理进展放在同一条记录上；风险与问题之间是否支持直接关联或迁移，属于选型时需要核验的具体能力，应结合团队实际流程确认。
容易混淆的相邻概念
项目问题容易与缺陷管理、服务事件与问题管理混在一起，区别在于对象和归属不同。
产品 Bug 归缺陷管理。缺陷针对的是产品功能与预期不符，通常在缺陷跟踪系统中按严重程度、复现步骤、修复版本来管理，归属研发或测试流程。项目问题台账关注的是项目推进中的障碍，例如关键人员长期缺位、供应商交付延迟、需求反复变更，这些事项不落在某个功能点上。
服务中断归服务事件与服务问题管理。服务事件指线上服务不可用或质量下降，按事件响应流程处理，强调恢复时限；服务问题管理则追查事件背后的根因。它们的对象是运行中的服务，与项目交付过程中的管理障碍属于不同体系。
项目问题与上述两类的差别可以概括为：缺陷管产品对不对，服务事件管线上通不通，项目问题管项目推不推得动。三者可能相互引发，例如供应商延迟导致上线缺陷增多，但记录仍应各归其位，通过关联关系体现因果，而不是合并成一张表。
一个具体例子与常见误解
假设一个系统集成项目，关键硬件由外部供应商提供。项目初期，团队在风险登记册中记录一条风险：供应商产能紧张，可能延迟交付，概率中等、影响为关键路径延误两周，预案是提前四周下单并准备备选供应商，责任人为采购负责人，每两周复查一次。
四周后供应商确认无法按期交付，风险触发。团队在问题台账中新建问题：某型号硬件交付延迟，影响集成测试开始时间，责任人为采购负责人，优先级为高，状态为处理中，并关联原风险条目。原风险条目保留，注明已触发及预案执行情况。
随后项目经理从台账中筛出本周问题清单，包含该交付延迟项和另外两项高优先级问题，按截止时间排序，在周会上逐项确认进展。采购负责人启动备选供应商比价，测试团队调整用例顺序先做不依赖该硬件的部分。两周后硬件到货，集成测试完成，问题经测试负责人验证后关闭，关闭结论记录实际延误五天、备选供应商比价结果和后续采购建议。
这个例子中，风险登记册负责提前准备，问题台账负责触发后的跟踪，问题清单负责当期聚焦，三者各司其职又通过关联保持连续。
常见误解有三类。第一类是把风险直接写成问题，风险尚未发生就进入台账，导致台账被假设性事项占满，真正需要处理的障碍被淹没；正确做法是留在登记册，触发后再迁移。第二类是把台账当清单用，每天在台账里勾选当天要做的几条，台账状态频繁变动却缺少完整跟踪；正确做法是台账保持完整记录，另设筛选视图。第三类是关闭后不再留痕，问题解决后直接删除记录，导致复盘时无据可查、同类问题重复发生；正确做法是保留记录和关闭结论，让台账成为项目的经验积累。
常见问题
风险触发后，原风险条目应该删除还是保留？
建议保留原风险条目，并在问题台账中新建问题记录，两者通过编号或关联字段建立对应关系。原条目注明已触发、触发依据和预案执行情况，问题记录承接后续的推进与关闭。
保留原条目的价值在于复盘时能对照当初的概率判断和应对预案，检验评估是否准确、预案是否有效。直接删除或改写风险条目，会让这段判断依据消失，后续说不清风险管理的实际效果。
问题清单需要单独维护一份数据吗？
通常不需要。问题清单是从问题台账中按条件筛出的视图，筛选条件可以是优先级、责任人、里程碑截止时间或状态。清单的内容随台账更新而更新，筛选条件变化时清单随之变化。
单独维护一份清单数据会带来两套记录不同步的问题：台账关闭了，清单还挂着；清单新增了，台账里找不到。把清单定位为工作视图，台账作为唯一数据源，可以避免这类重复录入和口径不一致。
一个事项既像风险又像问题，应该记在哪里？
按事项当前的实际状态判断：已经造成影响、需要有人采取行动消除或缓解的，记为问题；尚未发生、只在特定条件下才可能影响项目的，留在风险登记册。
如果影响已经开始显现但程度尚不确定，可以按问题登记，同时在描述中写清不确定部分和后续观察点。判断的关键是看是否已经有实际影响发生，而非看事项听起来严不严重。
问题台账的复盘频率应该怎么定？
复盘频率可按项目节奏设定，常见做法是每个迭代或每个里程碑一次。频率过高会增加管理负担，过低则长期未关闭项容易积压。
复盘时台账侧重点检查长期未关闭项、责任人空缺项和重复出现的问题；风险登记册侧复查概率与影响是否变化、预案是否仍可执行、已触发风险是否完成迁移。两项检查放在同一次复盘中完成，可以顺带核对风险与问题之间的关联是否完整。
项目问题台账能替代缺陷跟踪系统吗？
不能替代。缺陷针对产品功能与预期不符，按严重程度、复现步骤、修复版本管理，归属研发或测试流程；项目问题台账关注项目推进中的管理障碍，例如关键人员缺位、供应商交付延迟、需求反复变更。
两者可能相互引发，例如供应商延迟导致上线缺陷增多，但记录应各归其位，通过关联关系体现因果。把缺陷塞进项目问题台账，会让两类事项的处理节奏和责任人体系混在一起。
