项目问题台账记录已经发生、正在阻碍项目推进的具体问题，逐条跟踪责任人、处置动作和关闭状态；风险登记册记录尚未发生、可能影响项目目标的不确定事件，跟踪概率、影响、应对策略和触发条件。两者的核心分野在于时间性质和管理动作：问题台账管“已发生、要解决”，风险登记册管“未发生、要预防或准备”。同一个事项可以从风险登记册转入问题台账，转入后保留来源关联，避免两处重复跟踪。
要点总览（TL;DR）
- 项目问题台账记录已经发生、正在阻碍项目推进的障碍，跟踪责任人、处置动作和关闭依据；风险登记册记录尚未发生、可能影响项目目标的不确定事件，跟踪概率、影响、应对策略和触发条件。
- 判断归属用一条规则：问“它已经发生了吗”。已发生并产生实际影响的进问题台账，尚未发生、只是存在可能的进风险登记册。
- 两者在记录对象、触发时点、关键字段、责任人角色、更新频率和关闭标准六个维度上都有差异，其中关闭标准最容易被忽视：问题需要验证后关闭，风险可以消除、转入问题或标注已接受。
- 风险触发后转入问题台账时，要保留来源关联并更新原风险条目状态，避免同一事项在两处重复跟踪。
- 两本账并行是常规做法，投入程度随项目不确定性调整；常见误用是把已发生问题记入风险登记册，或把尚未发生的风险直接派活。
两者记录的对象和时间性质有何不同
项目问题台账是一份持续更新的清单，记录的是已经发生、并且正在影响项目推进的障碍。它关心的是“这件事已经挡路了，谁来解决、什么时候解决、解决到什么程度算完”。典型条目包括：关键依赖方延迟交付接口、核心成员被临时抽调、需求评审迟迟无法拍板、外部审批卡在某个环节。这些问题在记录时已经产生实际影响，台账的作用是让处置过程可见、可催、可验证。
风险登记册记录的是尚未发生、但一旦发生就可能影响项目目标的不确定事件。它关心的是“这件事有可能发生，概率多大、影响多大、我们准备怎么应对、什么信号出现时启动应对”。典型条目包括：关键供应商可能延期、核心技术方案可能存在性能瓶颈、关键人员可能流失、政策口径可能调整。风险在记录时还没有造成实际损失，登记册的作用是提前识别、评估并准备预案。
判断一个事项该进哪本账，可以用一条简单规则：问“它已经发生了吗”。已经发生并产生实际影响，进问题台账；尚未发生、只是存在发生可能，进风险登记册。如果一件事既有一部分已经发生、又有一部分可能继续恶化，通常把已发生的部分作为问题登记，把后续可能的连锁影响作为关联风险另行记录，并在两条记录之间标注关联关系。
需要留意的是，时间性质会变化。今天登记的风险，明天可能触发成为问题；今天关闭的问题，也可能暴露出一类尚未消除的隐患。台账和登记册都需要定期复核，而不是建好之后只在出事后才翻看。
同口径对照：字段、责任人与关闭标准
把两个载体放在同一组维度下对照，差异会更清楚。下表按记录对象、触发时点、关键字段、责任人角色、更新频率和关闭标准六个维度展开。
| 对照维度 | 项目问题台账 | 风险登记册 |
|---|---|---|
| 记录对象 | 已发生、正在影响项目推进的具体障碍 | 尚未发生、可能影响项目目标的不确定事件 |
| 触发时点 | 问题实际出现、被识别并确认影响时 | 风险被识别、评估后即登记，早于实际发生 |
| 关键字段 | 问题描述、影响范围、优先级、责任人、处置动作、当前状态、关闭依据 | 风险描述、发生概率、影响程度、风险等级、应对策略、触发条件、责任人、当前状态 |
| 责任人角色 | 问题 owner，对处置动作和关闭结果负责，通常是能调动资源解决问题的人 | 风险 owner，对监控信号和应对预案负责，通常是熟悉该风险领域的人 |
| 更新频率 | 按处置节奏高频更新，状态随动作推进而变化 | 按评审周期定期复核，概率、影响和应对策略随信息变化调整 |
| 关闭标准 | 问题已解决并经影响方验证，关闭依据可查 | 风险已消除、已发生并转入问题台账、或经评估后明确接受并保留观察 |
字段差异反映的是管理动作差异。问题台账的字段围绕“怎么解决”设计，所以处置动作和关闭依据是核心；风险登记册的字段围绕“怎么准备”设计，所以概率、影响和触发条件是核心。责任人的角色也随之不同：问题 owner 要推动事情落地，风险 owner 要盯住信号、维护预案。
关闭标准的差异最容易被忽视。问题关闭需要验证，不能由处置人自己宣布完成就算结束，通常要有受影响方的确认或可观察的结果。风险关闭则有多种合法路径：风险源消失可以关闭，风险已发生应转入问题台账，风险经评估在可接受范围内可以标注“已接受”并保留观察。把“已接受”当成“已解决”是常见误区，接受意味着团队知情并愿意承担剩余暴露，不等于风险不存在。
问题台账与问题清单、缺陷、服务事件的边界
问题台账和问题清单经常被混用。清单是一种记录形式，把事项列出来即可；台账强调持续跟踪与状态管理，每条记录都有责任人、处置动作、状态和关闭依据，并且会被定期复盘。可以说台账是“带管理动作的清单”，但只有清单没有跟踪机制，就起不到台账的作用。
项目问题台账的边界还需要和另外两类记录区分开。产品 Bug 归缺陷管理，由缺陷跟踪流程处理复现、修复、验证和回归，不进入项目问题台账；服务中断归服务事件与问题管理流程，按事件响应和根因治理处理，也不进入项目问题台账。项目问题台账聚焦的是项目推进层面的障碍：依赖未到位、资源不足、决策延迟、外部条件未满足等。
| 事项类型 | 典型例子 | 归属载体 |
|---|---|---|
| 项目推进障碍 | 接口依赖方延期、关键决策未拍板、外部审批卡点 | 项目问题台账 |
| 产品缺陷 | 功能报错、页面显示异常、数据计算错误 | 缺陷管理 |
| 服务中断 | 线上服务不可用、接口大面积超时 | 服务事件与问题管理 |
| 尚未发生的不确定事件 | 供应商可能延期、关键人员可能流失 | 风险登记册 |
边界判断的关键是看这件事影响的是“项目交付节奏”还是“产品/服务质量”。影响交付节奏的障碍进问题台账；影响产品质量的进缺陷管理；影响服务可用性的进服务事件流程。三类记录可以互相关联，但不宜混在同一本账里跟踪，否则责任人和关闭标准会互相干扰。
风险转为问题后如何交接
风险触发后转为问题，是两个载体之间最主要的流转。判断是否转入，看触发条件是否已经出现、影响是否已经实际产生。如果风险登记册里写明的触发信号已经发生，并且已经开始影响项目推进，就应当转入问题台账，按问题的节奏处置。
交接时建议按以下流程执行：
- 确认触发。由风险 owner 对照登记册中的触发条件，判断风险是否已经实际发生，记录触发时间和已观察到的影响。
- 在问题台账新建条目。把风险描述改写为已发生的问题描述，补充实际影响范围、优先级和处置动作，指定问题 owner。
- 保留来源关联。在问题条目中标注来源风险编号，在风险条目中标注已转出的问题编号，形成双向可查的关联。
- 处理原风险条目。将风险状态更新为“已发生并转问题”，不再作为独立风险重复跟踪；如果该风险还有残余影响或后续连锁可能，另建一条观察项，避免把已发生的事实继续挂在风险清单里。
- 评审确认。在项目例会上由项目经理或风险评审人确认交接完成，检查问题 owner 是否明确、处置动作是否可执行、原风险条目状态是否已更新。
交接环节最容易出问题的是“两处都留着”。风险条目没有关闭，问题条目又新建一条，同一件事被两个人分别跟踪，状态不一致时没人说得清哪个为准。保留来源关联、明确原条目状态，是避免重复跟踪的关键动作。
在项目管理工具中如何分账管理
两本账要在工具里落地，核心是用不同类型的工作项区分问题与风险，再用字段和状态流转承载各自的管理动作。ONES Project 支持自定义需求状态与多种属性，也支持组件化设计、按业务需求灵活定义项目类型与相关组件，这为分账管理提供了配置基础；具体字段模板是否内置，建议在选型时实际核验。
一套可执行的落地做法如下：
- 用工作项类型分账。在项目中设置“问题”和“风险”两类工作项，分别对应问题台账和风险登记册，避免混在同一类型里靠标签区分。
- 用字段承载管理动作。问题类型配置影响范围、优先级、处置动作、关闭依据；风险类型配置发生概率、影响程度、风险等级、应对策略、触发条件。责任人字段两类都保留，但角色含义按上文区分。
- 用状态流转体现关闭标准。问题状态可设为待处理、处置中、待验证、已关闭；风险状态可设为已识别、监控中、已发生转问题、已接受、已关闭。状态名称直接对应关闭路径，减少口头解释。
- 建立风险转问题的关联。风险触发时，在问题条目中关联来源风险，并同步更新风险状态。ONES Project 支持任务筛选器，提供全局筛选与项目内筛选，可按状态、责任人等条件快速拉出待处置问题和监控中风险，供例会使用。
- 在例会上按台账推进。项目例会固定查看两类视图：待处置问题按优先级排序，逐条确认处置进展和关闭依据；监控中风险逐条复核概率、影响和触发条件是否变化。ONES Project 提供看板、燃尽图等工具用于实时掌控当前进度，可作为例会推进的辅助视图。
如果团队希望进一步利用数据做判断，ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析、根因判断和资源合理性建议，帮助管理者在风险扩大前完成干预。这类分析适合作为例会的输入参考，具体的风险登记册数据联动方式仍以实际配置为准。
适配场景与选择建议
常规做法是两本账并行使用，只是投入程度随项目情况调整。问题台账几乎每个项目都需要，因为推进障碍总会发生；风险登记册的必要性取决于项目的不确定性和影响面。
项目周期短、不确定性低时，可以简化风险登记册：只保留高影响风险的少量条目，合并到项目例会议题中复核，不单独维护复杂字段；问题台账保持完整，因为短周期项目里问题处置速度直接决定交付。简化不等于取消，至少保留一张风险清单，避免完全失去提前准备的能力。
高风险项目或跨团队项目，建议强化两本账：风险登记册增加评审节奏，明确每条风险的触发条件和应对预案，指定风险 owner 定期复核；问题台账提高更新频率，跨团队障碍要标注依赖方和升级路径。跨团队场景下，问题 owner 需要具备跨团队协调权限，否则台账会停留在“已记录、无人推”的状态。
两类常见误用值得提醒。一是把已经发生的问题记入风险登记册，用“可能影响”的描述掩盖已经造成的阻碍，结果是问题得不到及时处置，风险清单也越来越长。二是把风险当问题直接派活，风险还没发生就安排具体处置任务，容易造成资源空耗；正确做法是先明确应对策略和触发条件，等信号出现再启动动作。
选择建议可以归纳为一句话：按事项的时间性质分账，按影响程度决定投入。已经发生的进问题台账并跟踪到验证关闭，尚未发生的进风险登记册并维护好触发条件；两本账通过来源关联衔接，在例会上同步复核，就能既不让问题积压，也不让风险失控。
常见问题
项目问题台账和风险登记册可以合并成一张表吗？
技术上可以放在同一个工具视图里，但建议保留两类独立记录。合并成一张表后，概率、影响、触发条件这些风险字段对问题条目没有意义，处置动作、关闭依据这些问题字段对风险条目也用不上，字段会大量留空，责任人和关闭标准也容易混淆。
更稳妥的做法是两类记录分开维护，通过来源关联衔接。如果团队规模很小、项目不确定性低，可以在同一张表里用类型字段区分，但仍要保证两类记录各自有对应的状态和关闭路径。
风险登记册里的风险一直没发生，需要定期处理吗？
需要。风险登记册的价值在于提前准备，长期不复核会让概率、影响和应对策略停留在登记时的判断。建议按项目评审周期逐条复核：触发条件是否出现、概率和影响是否变化、应对策略是否仍然可行、责任人是否还在岗。
如果某条风险经评估影响很小或已经失去发生条件，可以标注关闭或已接受并保留观察，不必一直挂在监控中。复核记录本身也是项目复盘的材料。
同一个事项既有已经发生的部分，又有后续可能的连锁影响，怎么记？
把已经发生并产生实际影响的部分作为问题登记，进入问题台账跟踪处置；把后续可能的连锁影响作为关联风险另行记录，在两条记录之间标注关联关系。这样处置动作和预防准备各有归属，不会因为混在一条记录里导致责任不清。
如果连锁影响随着处置推进逐渐明确，可以再评估是否需要调整两条记录的边界，并在例会上同步状态。
问题台账里的问题关闭后，还需要回头看吗？
单条问题关闭后不必持续跟踪，但建议在项目例会和阶段复盘中回看已关闭问题的分布。如果同类问题反复出现，说明背后可能存在尚未消除的隐患，可以把这类隐患作为风险登记，或者推动流程层面的改进。
关闭依据要可查，包括验证结果和确认人，这样复盘时才能判断问题是真正解决还是暂时缓解。
在项目管理工具里分账管理，最少需要配置哪些内容？
至少需要三样：用不同类型的工作项区分问题与风险；为两类工作项分别配置关键字段，问题侧重影响、优先级、处置动作和关闭依据，风险侧重概率、影响、应对策略和触发条件；用状态流转对应各自的关闭路径。
ONES Project 支持自定义需求状态与多种属性，也支持按业务需求灵活定义项目类型与相关组件，可作为配置基础；是否内置风险登记册模板和字段，建议在选型时实际核验。任务筛选器可以按状态、责任人等条件拉出待处置问题和监控中风险，供例会使用。
