项目问题台账和风险登记册的核心区别在于记录对象的时态：问题台账记录已经发生、正在阻碍项目推进的具体障碍，风险登记册记录尚未发生、可能影响项目目标的不确定事件。两者按“已发生还是未发生”划分，并在风险触发时完成从登记册到台账的转化。本文用同一组维度对照两个载体，说明各自的字段、边界与衔接方式，帮助项目团队确定先建哪个、如何合并维护。
要点总览（TL;DR）
- 问题台账记录已经发生、正在阻碍项目推进的障碍；风险登记册记录尚未发生、可能影响项目目标的不确定事件，两者按“已发生还是未发生”分流。
- 字段重心不同：问题台账围绕责任人、处置动作、计划完成时间和关闭结论；风险登记册围绕概率、影响、应对策略、触发条件和风险责任人。
- 管理节奏不同：问题在日常例会上逐条推进到关闭，风险按周或按阶段集中评审等级与应对进展。
- 风险触发条件成立后，在登记册标记转化，同时在问题台账新建问题并迁移描述、影响和已有应对动作。
- 小项目可先建问题台账，复杂长周期项目两个载体同时建立；合并维护时须保留两类关闭标准，事项增多后尽早拆分。
一张表看清问题台账与风险登记册的差异
把两个载体放在同一组维度下对照，差异会集中在记录对象、字段重心和管理节奏三处。问题台账回答“这件事现在卡在哪里、谁在处理、什么时候能关闭”；风险登记册回答“这件事如果发生，影响多大、我们准备怎么应对、什么信号说明它正在逼近”。
| 对照维度 | 项目问题台账 | 风险登记册 |
|---|---|---|
| 记录对象与时态 | 已经发生、正在影响项目推进的障碍，如关键资源迟迟不到位、跨部门接口迟迟未确认 | 尚未发生、可能影响项目目标的不确定事件，如关键供应商延期交付的可能性 |
| 核心字段 | 问题描述、影响范围、提出人、责任人、处置动作、计划完成时间、当前状态、关闭结论 | 风险描述、发生概率、影响程度、风险等级、应对策略、触发条件、风险责任人、复盘记录 |
| 管理动作重心 | 处置与闭环：推动具体动作落地，直到障碍消除并确认关闭 | 预防与应对：降低概率、减轻影响，或准备应急方案 |
| 责任人与评审节奏 | 单一责任人牵头处置，按问题紧急程度在日常例会上逐条跟进 | 风险责任人负责监控，按周或按阶段在风险评审会上集中复盘 |
| 关闭与转化条件 | 障碍消除、影响解除并经确认后关闭 | 风险不再存在时关闭；触发条件成立、转化为现实障碍时转入问题台账 |
| 适用项目类型 | 所有需要跨角色协调解决障碍的项目 | 周期较长、外部依赖多、不确定性高的项目收益更明显 |
这张表给出的结论是：两个载体服务于同一条管理链条的前后两段。风险登记册偏向前瞻，问题台账偏向执行。把两者混为一谈，常见后果是风险被当成问题追着要“关闭时间”，或者已经发生的问题仍挂在风险清单里等待“观察”，导致处置动作迟迟不落地。
项目问题台账的定义与边界
项目问题台账是记录已经发生、影响项目推进、需要跨角色协调解决的障碍的跟踪载体。它至少承担三项职责：让问题被看见、让责任落到人、让处置过程有状态可查。判断一条记录是否应进入问题台账，可以问三个问题：它是否已经发生？它是否正在阻碍或即将阻碍项目目标？它是否需要两个以上角色协调才能解决？三个答案都为“是”，就应登记。
问题台账与问题清单的关系
问题清单是入口，台账是带责任人和状态的跟踪载体。团队在例会、评审或日常沟通中先把发现的问题记入清单，避免遗漏；经过初步判断后，把需要跟踪的问题转入台账，补齐责任人、处置动作、计划完成时间和状态。清单解决“有没有记下来”，台账解决“有没有人管、管到哪一步”。小团队可以只用一张表同时承担两个角色，但字段中必须包含责任人与状态，否则跟踪会落空。
与缺陷管理、服务事件管理的界线
产品 Bug 归缺陷管理，按缺陷的严重程度、复现步骤、修复版本和验证结果跟踪，其生命周期与项目问题台账不同。服务中断归服务事件与问题管理，前者关注服务恢复，后者关注根因消除。项目问题台账收的是影响项目交付节奏的协调性障碍，例如需求确认反复、关键人员缺口、外部依赖未按期到位。三类记录可以在同一协作平台上并存，但字段和关闭标准应各自独立，避免用项目问题的关闭标准去要求一个尚未修复的缺陷。
典型字段与关闭标准
- 基础信息：问题标题、问题描述、提出人、提出日期、所属项目或阶段。
- 影响判断：影响范围、紧急程度、是否影响里程碑。
- 处置信息：责任人、处置动作、协作方、计划完成时间。
- 状态流转：待分派、处理中、待验证、已关闭、挂起。
- 关闭结论：障碍如何解除、影响是否消除、是否需要沉淀为经验。
关闭标准应写清楚“什么算解决”。例如“接口联调阻塞”的关闭条件可以是双方接口文档确认并完成一次联调通过，而不是“已联系对方”。标准越具体，台账越不容易变成只更新状态、不推动动作的摆设。
风险登记册的定义与边界
风险登记册记录尚未发生、可能影响项目目标的不确定事件，并为每条风险明确概率、影响、应对策略和监控方式。它与问题台账的分工在于：问题台账管理已经发生的障碍，风险登记册管理可能发生的事件。风险登记册的价值不在于列得多，而在于每条风险都有责任人、有应对动作、有可观察的触发信号。
核心字段
- 风险描述：用“原因—事件—影响”的结构写清楚，例如“关键模块依赖外部团队，若其排期后移，将导致联调延期”。
- 概率与影响：按团队约定的等级评估，两者共同决定风险等级和关注优先级。
- 应对策略：规避、转移、减轻或接受，并写明具体动作和责任人。
- 触发条件：可观察的信号，例如“外部团队排期确认晚于某日期”或“某指标连续两周未达标”。
- 风险责任人：负责监控信号并推动应对动作的人，通常不是项目经理一人包揽。
- 复盘记录：风险状态变化、应对效果和关闭原因。
维护方式
风险登记册需要固定的评审节奏，通常按周或按阶段在项目例会上集中过一遍：新增了哪些风险、等级是否变化、应对动作是否执行、触发条件是否逼近。评审之外，风险责任人负责日常监控，发现信号变化及时更新。只登记不评审的登记册，几周后就会变成一份无人维护的静态文档。
风险触发后的处理路径
当触发条件成立、风险转化为现实障碍时，应在风险登记册中把该条目标记为已转化，同时在问题台账中新建对应问题，迁移风险描述、影响判断和已有应对动作，指定处置责任人并设定计划完成时间。原风险条目保留转化记录，便于后续复盘“哪类风险最容易变成问题”。
两个载体如何衔接使用
衔接的关键是在识别阶段就完成分流，而不是先记下来再反复搬运。团队可以在同一张收集表上先记录所有事项，再按“是否已经发生”分流：已经发生且影响推进的进入问题台账，尚未发生的进入风险登记册。分流动作由项目经理或指定的协调人完成，避免同一事项在两个载体中重复登记。
从识别到关闭的连续流程
- 识别：在例会、评审、日常沟通中收集事项，记录原始描述和提出人。
- 分流：判断是否已发生。已发生且构成障碍的进问题台账；尚未发生的进风险登记册。
- 指派：问题指定处置责任人，风险指定监控责任人，两者都需明确下一步动作和时间。
- 跟踪：问题在日常例会上逐条推进状态；风险在风险评审会上集中复盘等级和应对进展。
- 转化：风险触发后，在登记册标记转化，在台账新建问题并迁移相关字段。
- 关闭：问题按关闭标准确认后关闭；风险在不再存在或已转化后关闭，并记录原因。
联合检查与避免重复登记
建议在每周例会上用固定顺序检查：先过问题台账中逾期或停滞的条目，再评估风险登记册中等级上升或触发条件逼近的条目，最后核对是否存在同一事项两边都登记的情况。发现重复时保留一个主记录，另一处只做引用说明。两边都无人跟踪的常见原因是责任人不明确，因此每条记录都必须有具名责任人，而不是挂在某个部门名下。
当团队在协作平台上管理这些记录时，问题与风险可以作为两类工作项分别设置字段和状态，责任人和评审节奏通过视图与通知落实。ONES 的研发管理方案描述了围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与根因判断，帮助管理者在风险扩大前完成干预；这类数据联动可以作为风险评审的输入，具体的问题台账与风险登记册字段配置仍需按团队流程在平台中设定。
适配场景与选择建议
两个载体并非所有项目都必须同时建立。选择取决于项目周期、不确定性和协调复杂度，起步阶段可以先建一个，再按需要补齐另一个。
按项目类型取舍
| 项目情形 | 建议做法 |
|---|---|
| 小型、短周期、参与角色少的项目 | 先建问题台账，保证障碍有人管、能关闭；风险以简表或例会口头跟踪为主 |
| 复杂、长周期、外部依赖多的项目 | 两个载体同时建立，风险登记册按周评审，问题台账按日或按周推进 |
| 处于启动或规划阶段的项目 | 先建风险登记册，把不确定性和应对策略前置；执行阶段再启用问题台账 |
| 交付压力大、障碍频发的执行阶段 | 以问题台账为主，风险登记册保留高等级条目，避免维护负担过重 |
合并维护的适用条件与风险
当团队规模小、事项数量有限时，可以用一张表通过“类型”字段区分问题与风险，减少维护成本。合并维护的前提是字段中同时保留处置动作、关闭状态和概率、影响、触发条件，并且评审时按类型分别过。风险在于两类记录的关闭标准不同，合并后容易被统一成“填完即关闭”，导致风险缺少持续监控。一旦事项数量增加或项目周期拉长，应尽早拆分为两个载体。
起步顺序建议
- 先明确分流规则：用一页纸写清“已发生进台账、未发生进登记册”的判断标准和责任人。
- 建立最小字段集：问题台账先保证描述、责任人、处置动作、计划时间、状态五项；风险登记册先保证描述、概率、影响、应对策略、触发条件五项。
- 固定评审节奏：问题在日常例会跟进，风险按周或按阶段复盘，并把复盘结论写回记录。
- 按项目复杂度扩展：复杂项目再补充影响范围、风险等级、关联里程碑等字段。
最后需要提醒边界：产品 Bug 的修复跟踪放在缺陷管理中，服务中断的恢复与根因处理放在服务事件与问题管理中，项目问题台账聚焦影响项目推进的协调性障碍。三类记录可以在同一平台协同，但各自的字段、责任人和关闭标准应保持独立，这样问题台账和风险登记册才能真正各司其职。
常见问题
风险触发后，原风险条目应该删除还是保留？
建议保留，并在风险登记册中把该条目标记为已转化，注明转入问题台账的对应记录。保留原条目有两个用处：一是复盘时可以追溯这条风险从识别、监控到触发的完整过程；二是积累一段时间后，能看出哪类风险最容易转化为现实障碍，为后续的风险识别和应对策略提供依据。删除原条目会让风险评审失去历史参照。
一个问题在台账里挂起很久，是否应该退回风险登记册？
通常不需要。挂起表示问题已经发生，只是当前暂不处置或等待外部条件，它仍然属于问题台账的管理范围。此时应写清挂起原因、复查时间和挂起期间的临时应对，而不是转回风险登记册。只有当该事项的影响尚未发生、团队实际是在观察某种可能性时，才属于风险登记册的记录对象。判断依据仍是“是否已经发生”，而不是“是否正在处理”。
团队规模很小，只维护一张表可行吗？
可行，前提是这张表同时保留两类字段：处置动作、关闭状态，以及概率、影响、触发条件，并用“类型”字段区分问题与风险。评审时按类型分别过，问题看处置进展，风险看等级变化和触发信号。需要留意的是，两类记录的关闭标准不同，合并后容易被统一成“填完即关闭”，导致风险缺少持续监控。事项数量增加或项目周期拉长后，应尽早拆成两个载体。
问题台账和缺陷管理、服务事件管理如何避免重复登记？
按记录对象的性质分工：产品 Bug 进入缺陷管理，按严重程度、复现步骤、修复版本和验证结果跟踪；服务中断进入服务事件与问题管理，前者关注恢复，后者关注根因消除；项目问题台账只收影响项目交付节奏的协调性障碍，例如需求确认反复、关键人员缺口、外部依赖未到位。三类记录可以在同一平台并存，但字段、责任人和关闭标准各自独立。出现交叉时保留一个主记录，另一处只做引用说明。
风险评审会上应该重点看哪些条目？
优先看三类：等级上升或触发条件正在逼近的条目、应对动作逾期未执行的条目、以及新识别但尚未指派风险责任人的条目。对已转化的风险，核对问题台账中是否已建立对应问题并指定处置责任人。评审结论要写回记录，包括等级调整、应对动作变更和关闭原因，否则登记册会逐渐变成无人维护的静态文档。
