项目问题台账用来逐条记录项目推进中的障碍：谁提出的、影响了什么、由谁负责、什么时候要解决、现在处理到哪一步。它适合在项目启动时就建立，并在周会或每日站会中持续更新。本文提供一张可直接复制的空白台账表，配套字段说明、必填规则、一条完整填写示例和维护方法，拿到后可以粘贴到表格工具或项目文档中开始使用。
要点总览（TL;DR）
- 空白台账包含12个字段：问题编号、提出日期、提出人、问题描述、影响范围、关联任务/里程碑、责任人、优先级、目标解决日期、当前状态、解决措施、关闭验证结论。
- 登记时至少填齐七个必填字段：编号、提出日期、提出人、问题描述、责任人、优先级、当前状态；影响范围、关联任务、目标解决日期可随进展补齐。
- 状态只用待处理、处理中、待验证、已关闭四个固定值，关闭时必须填写验证结论，否则视为未关闭。
- 填写示例展示一条问题从登记到关闭的完整过程，状态变化与解决措施、验证结论逐项对应。
- 台账需按项目阶段增删字段，例会前更新状态，项目结束归档，人员变动时逐条移交未关闭问题。
可复制的项目问题台账空白模板
下面这张表可以直接复制到 Excel、在线表格或项目文档中。表头顺序固定，新增记录时在下方追加行即可。建议把第一行冻结，方便滚动查看。
| 问题编号 | 提出日期 | 提出人 | 问题描述 | 影响范围 | 关联任务/里程碑 | 责任人 | 优先级 | 目标解决日期 | 当前状态 | 解决措施 | 关闭验证结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|
填表前先约定三条规则，保证多人填写时口径一致：
- 日期格式：统一使用“YYYY-MM-DD”，例如 2025-03-14。提出日期和目标解决日期都按此格式填写，便于排序和筛选。
- 状态取值：只使用四个固定值——待处理、处理中、待验证、已关闭。需要说明阻塞原因时写进解决措施，不另造状态。
- 编号规则：建议“项目简称-序号”，如 PROJ-001、PROJ-002，按提出顺序递增，编号一经分配不再复用，即使该问题被撤销也保留编号并标注。
台账字段逐项说明：每个字段记录什么
十二个字段分为三组：识别问题（编号、日期、提出人、描述）、判断轻重与归属（影响范围、关联任务、责任人、优先级、目标日期）、跟踪处理（状态、措施、验证结论）。下表给出每个字段的含义和填写口径。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 问题编号 | 该条记录的唯一标识 | 按“项目简称-序号”生成，提出时即分配，不复用、不跳号 |
| 提出日期 | 问题被登记进台账的日期 | 填写登记当天日期，格式 YYYY-MM-DD；补录历史问题时填实际发现日期并在描述中注明 |
| 提出人 | 发现并提交该问题的人 | 填写真实姓名或团队内通用称呼，便于回溯沟通 |
| 问题描述 | 障碍的具体现象 | 写“什么环节、出现了什么情况”，一到两句话说清事实，避免只写“进度受阻”这类笼统表述 |
| 影响范围 | 问题波及的对象和程度 | 写明受影响的模块、交付物、团队或时间，例如“影响联调阶段，预计推迟 3 天” |
| 关联任务/里程碑 | 问题对应的任务或节点 | 填写任务名称、编号或里程碑名称，便于在项目计划中定位 |
| 责任人 | 负责推动解决的人 | 只填一个主责人，需要多人协作时在解决措施中列明配合方 |
| 优先级 | 处理的先后顺序 | 使用高、中、低三档；高对应阻塞关键路径或临近里程碑，中对应影响部分工作，低对应可延后处理 |
| 目标解决日期 | 计划完成解决的日期 | 格式 YYYY-MM-DD，与关联里程碑倒排；日期调整时更新本字段并在解决措施中记录调整原因 |
| 当前状态 | 问题所处的处理阶段 | 从待处理、处理中、待验证、已关闭中选一个，每次例会前更新 |
| 解决措施 | 为解决问题采取的动作 | 记录已做的处理和下一步计划，写明动作和产出，例如“已协调测试环境，等待部署验证” |
| 关闭验证结论 | 确认问题已解决的依据 | 状态改为已关闭时填写，写明验证人、验证方式和结果，例如“3 月 20 日回归通过，提出人确认” |
必填与选填：哪些字段不能空
台账最常见的失效方式是记录只剩一句描述，没人认领、没有期限，例会上无法推进。最小可用记录的标准是：一条问题登记时至少填齐七个必填字段，其余字段随处理进展补齐。
| 类别 | 字段 | 理由或适用时机 |
|---|---|---|
| 必填（登记时） | 问题编号 | 保证每条记录可被引用和检索 |
| 必填（登记时） | 提出日期 | 用于计算问题停留时长和判断是否超期 |
| 必填（登记时） | 提出人 | 关闭验证时需要提出人确认，也便于追问细节 |
| 必填（登记时） | 问题描述 | 没有具体现象，后续无法判断是否真正解决 |
| 必填（登记时） | 责任人 | 没有主责人的问题在例会上无人汇报进展 |
| 必填（登记时） | 优先级 | 决定例会讨论顺序和资源投入 |
| 必填（登记时） | 当前状态 | 状态是筛选和推进的基本依据，登记时填“待处理” |
| 选填（登记时） | 影响范围 | 问题刚发现、影响尚未评估时可暂空，在首次例会前补齐 |
| 选填（登记时） | 关联任务/里程碑 | 能对应到计划中的任务时填写；独立于计划的问题可留空 |
| 选填（登记时） | 目标解决日期 | 高优先级问题登记当天必须填写；低优先级可在评估后补 |
| 按阶段必填 | 解决措施 | 状态进入“处理中”后必须填写，记录已采取的动作 |
| 按阶段必填 | 关闭验证结论 | 状态改为“已关闭”时必须填写，否则不允许关闭 |
字段留空时按以下规则处理：选填字段留空要在例会上说明原因，并约定补齐时间；必填字段缺失的记录不进入正式台账，由提出人补全后再登记；状态为“已关闭”但验证结论为空的记录，视为未关闭，退回责任人补充。这样处理可以避免台账中出现大量无法推进的悬空条目。
填写示例：一条完整问题记录
以下是一条从提出到关闭的完整记录，覆盖全部必填字段，并展示状态变化与解决措施、验证结论的对应关系。示例为演示情景，项目名称和人员均为虚构。
| 字段 | 填写内容 |
|---|---|
| 问题编号 | PROJ-007 |
| 提出日期 | 2025-03-10 |
| 提出人 | 李敏（测试） |
| 问题描述 | 订单模块与支付模块联调时，测试环境支付回调地址未配置，回调请求全部失败，联调用例无法执行 |
| 影响范围 | 影响订单支付链路联调，涉及 12 条用例，预计推迟 2 天 |
| 关联任务/里程碑 | 订单模块联调 / 3 月版本提测里程碑 |
| 责任人 | 王磊（后端） |
| 优先级 | 高 |
| 目标解决日期 | 2025-03-12 |
| 当前状态 | 已关闭 |
| 解决措施 | 3 月 10 日：王磊联系运维确认测试环境配置缺失；3 月 11 日：补充回调地址配置并重新部署测试环境；3 月 12 日：通知测试重新执行用例 |
| 关闭验证结论 | 3 月 12 日测试回归，12 条用例全部通过，提出人李敏确认，问题关闭 |
这条记录的状态经历了“待处理→处理中→待验证→已关闭”四个阶段：登记当天填“待处理”；王磊开始排查配置后改为“处理中”，解决措施同步记录动作；配置部署完成、通知测试后改为“待验证”；测试回归通过并由提出人确认后改为“已关闭”，同时填写验证结论。每个状态变化都能在解决措施和验证结论中找到对应依据，字段之间保持一致。
对照字段说明可以看出：问题描述写的是具体现象而非“联调受阻”；影响范围给出了受影响用例数和延迟天数；责任人只有一个主责人；目标解决日期与实际关闭日期一致，若延期则应在解决措施中记录原因。按同样方式填写，台账中的每条记录都能在例会上直接用于汇报和决策。
台账的调整与维护方法
台账建好后需要随项目阶段调整字段、按固定节奏复核状态，并在人员变动时完成交接。以下规则可作为维护清单使用。
按项目阶段增删字段
- 启动与规划阶段：字段保持最小集，重点是问题描述、责任人和优先级，避免登记负担过重导致无人填写。
- 执行与联调阶段：问题密集出现，可增加“问题类别”字段（如需求、资源、技术、外部依赖），便于分类统计和定位高频障碍。
- 收尾阶段：增加“关闭日期”字段，用于统计问题平均停留时长；停止新增低优先级条目，集中清理存量。
- 增删字段时同步更新字段说明和填写约定，并在例会上向全体成员说明，避免新旧口径混用。
状态更新与例会复核节奏
- 责任人每周例会前更新自己名下问题的状态和解决措施，例会只讨论“处理中”“待验证”和超期条目。
- 例会按优先级从高到低过一遍未关闭问题，超期条目当场确认新的目标解决日期和下一步动作。
- “待验证”条目由提出人验证，验证通过后由责任人改为“已关闭”并填写结论；验证不通过则退回“处理中”。
- 每月统计一次问题数量和平均关闭时长，作为评估协作效率的参考，不单独作为个人考核依据。
归档、权限与责任人交接
- 项目结束后将台账标记为归档，保留只读版本，新项目另建台账，不混用历史记录。
- 台账对项目成员开放编辑权限，对项目外人员默认只读；涉及敏感信息的问题可在描述中做脱敏处理。
- 责任人离职或转岗时，在例会上逐条移交未关闭问题，更新责任人字段并在解决措施中注明交接日期。
如果团队把台账放在协作工具中维护，可以用 ONES Wiki 的页面模板库把上述空白表做成制式模板，新项目一键创建；台账页面可关联对应项目，通过页面树组织各项目的文档与知识信息。ONES Wiki 支持为不同角色配置读写权限，并记录页面版本、支持查看与回滚，便于在多人编辑和人员交接时追溯修改。具体功能以实际开通的版本和权限为准。
常见问题
问题登记时影响范围还没评估清楚，可以先留空吗？
可以。影响范围属于选填字段，问题刚发现、影响尚未评估时允许暂空，但要在首次例会上说明原因并约定补齐时间，最迟在首次例会前补齐。如果问题已被判定为高优先级，建议登记当天就给出初步影响判断，哪怕只是“影响某模块联调，延迟天数待评估”，也比完全留空更利于排期决策。
低优先级问题的目标解决日期可以一直不填吗？
不建议长期留空。目标解决日期对高优先级问题是登记当天必填，对低优先级问题允许在评估后补，但补的时点应明确，例如在下次例会前完成评估并填写。长期没有目标日期的问题容易在台账中沉淀为悬空条目，例会复核时也难以判断是否超期。若确实无法给出日期，可在解决措施中写明“待某条件满足后评估”，并设定复查时间。
问题关闭后又被发现没真正解决，应该新建一条记录还是重新打开？
建议重新打开原记录，把状态从“已关闭”退回“处理中”，在解决措施中补充复现情况和新的处理动作，并清空或标注原验证结论失效。这样能保留完整的问题历史，便于统计该问题的实际停留时长。只有当复现现象与原因和原问题明显不同、属于另一件事时，才新建记录并分配新编号。
团队规模变大后，一张台账还够用吗？
取决于问题的数量和交叉程度。单一项目、问题数量在几十条以内时，一张台账配合例会复核通常够用。当多个项目并行、问题需要按项目或模块分别统计时，可以按项目拆分台账，同时保留一个汇总视图用于跨项目查看高优先级和超期条目。拆分时保持编号规则和状态取值一致，避免各表口径不同导致汇总失真。
把台账放进 ONES Wiki 维护，模板和权限方面能做什么？
ONES Wiki 提供页面模板库，可以把本文的空白表做成制式模板，新项目创建页面时直接套用；页面组可关联项目，页面树用于组织各项目的文档与知识信息。权限方面支持为不同角色配置不同的读写权限，页面版本会被记录并支持查看与回滚，便于多人编辑和人员交接时追溯修改。具体可用范围以实际开通的版本和权限为准。
