项目问题台账模板至少应覆盖五组字段：问题标识与描述、分类与优先级、责任落实、升级管理、关闭验证。字段设计围绕三条主线展开——谁负责、何时升级、如何证明已关闭。下面先给出一张可直接复制到表格工具中的空白台账，再逐字段说明填写口径，划分必填与选填，并用一条完整记录示范字段联动，最后说明台账上线后的维护方法。
要点总览（TL;DR）
- 项目问题台账模板至少覆盖五组字段：问题标识与描述、分类与优先级、责任落实、升级管理、关闭验证，字段设计围绕谁负责、何时升级、如何证明已关闭三条主线。
- 责任落实靠责任人（只填一人）、协同人、期望解决日期、当前状态支撑；升级管理靠升级级别、触发条件、升级对象、升级时间支撑，未升级也需填写以表明已评估。
- 关闭验证靠解决方案、验证人、验证方式、验证结论、关闭日期、遗留事项支撑，验证结论、验证人、关闭日期三项齐全才算完成关闭。
- 小型项目可精简描述性与分析性字段，但责任落实、升级管理、关闭验证三类字段不宜省略；多团队或强交付节点项目建议启用全部字段。
- 台账上线后需指定维护人做周度核对，字段增删记录变更原因与生效日期，并明确与缺陷管理、服务事件管理的边界。
可复制空白项目问题台账模板
将下表复制到 Excel、在线表格或文档表格中即可使用。表头按五组字段排列，组与组之间用列名前缀区分；最后一列“自定义”留给项目按需扩展，新增列放在该位置之后，避免打乱既有字段顺序。
| 编号 | 问题标题 | 问题描述 | 影响范围 | 发现日期 | 提出人 | 问题类型 | 严重程度 | 优先级 | 影响里程碑 | 责任人 | 协同人 | 期望解决日期 | 当前状态 | 升级级别 | 升级触发条件 | 升级对象 | 升级时间 | 解决方案 | 验证人 | 验证方式 | 验证结论 | 关闭日期 | 遗留事项 | 自定义 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
列顺序对应五组字段：第1至6列为问题标识与描述，第7至10列为分类与优先级，第11至14列为责任落实，第15至18列为升级管理，第19至24列为关闭验证，第25列为自定义扩展位。若项目使用在线表格，建议冻结前两列与表头行，便于横向滚动时定位问题。
每个字段记录什么：字段说明与填写口径
字段说明按下表逐项给出含义、取值方式和填写提示。枚举型字段建议在表格工具中设置为下拉选项，减少同一状态出现多种写法的情况。
| 字段名 | 所属分组 | 含义 | 取值方式 | 填写提示 |
|---|---|---|---|---|
| 编号 | 问题标识与描述 | 台账内唯一标识 | 按规则生成，如 PRJ-001 | 项目前缀加流水号，关闭后不复用 |
| 问题标题 | 问题标识与描述 | 一句话概括问题 | 文本，建议不超过30字 | 写清对象与现象，避免只写“有问题” |
| 问题描述 | 问题标识与描述 | 现象、发生条件、已尝试的处理 | 文本 | 记录可复现的客观事实，不写推测结论 |
| 影响范围 | 问题标识与描述 | 受影响的功能、团队、客户或交付物 | 文本或标签 | 写具体对象，便于判断严重程度 |
| 发现日期 | 问题标识与描述 | 问题首次被记录的时间 | 日期，YYYY-MM-DD | 以登记日为准，补录时在描述中注明实际发现时间 |
| 提出人 | 问题标识与描述 | 登记该问题的人 | 姓名或工号 | 提出人负责补充背景，不默认承担解决责任 |
| 问题类型 | 分类与优先级 | 问题来源或性质分类 | 枚举，如需求变更、资源缺口、技术障碍、外部依赖、流程阻塞 | 按团队约定维护枚举值，新增类型需同步更新说明 |
| 严重程度 | 分类与优先级 | 问题对目标造成的客观影响大小 | 枚举，如致命、严重、一般、轻微 | 依据影响范围判定，登记后尽量不再随意调整 |
| 优先级 | 分类与优先级 | 在当前排期内处理的先后顺序 | 枚举，如P0、P1、P2、P3 | 结合严重程度与里程碑紧迫性确定，可与严重程度不一致 |
| 影响里程碑 | 分类与优先级 | 受该问题威胁的交付节点 | 文本，填写里程碑名称与日期 | 无明确关联时填“无”，便于筛选 |
| 责任人 | 责任落实 | 对推动问题解决负主责的人 | 单一姓名 | 只填一人，避免多人共担导致无人推进 |
| 协同人 | 责任落实 | 提供支持或配合执行的各方 | 姓名列表 | 写清协同事项，如“提供接口日志” |
| 期望解决日期 | 责任落实 | 计划完成解决的时间 | 日期，YYYY-MM-DD | 与里程碑对齐；延期需更新并记录原因 |
| 当前状态 | 责任落实 | 问题所处处理阶段 | 枚举，如待分派、处理中、待验证、已关闭、挂起 | 状态变更时同步更新日期，挂起需写明原因 |
| 升级级别 | 升级管理 | 问题被提升到的管理层级 | 枚举，如未升级、项目级、部门级、公司级 | 未触发升级时填“未升级”，不留空 |
| 升级触发条件 | 升级管理 | 触发升级的具体情形 | 文本，如“超期3天未解决”“影响上线” | 与升级级别对应，写可核验的条件 |
| 升级对象 | 升级管理 | 接收升级信息并做决策的人或角色 | 姓名或角色 | 填有决策权限的角色，如项目负责人、部门负责人 |
| 升级时间 | 升级管理 | 升级动作发生的时间 | 日期时间 | 每次升级追加记录，保留历史 |
| 解决方案 | 关闭验证 | 实际采取的处理措施与结果 | 文本 | 写做了什么、结果如何，不写“已处理”了事 |
| 验证人 | 关闭验证 | 确认问题已解决的人 | 姓名 | 建议由提出人或受影响方验证，责任人不自验 |
| 验证方式 | 关闭验证 | 验证所采用的手段 | 枚举或文本，如复测、评审、客户确认、数据核对 | 与验证结论配套，便于追溯 |
| 验证结论 | 关闭验证 | 验证是否通过 | 枚举，如通过、不通过、部分通过 | 不通过时状态回退到处理中 |
| 关闭日期 | 关闭验证 | 验证通过并正式关闭的时间 | 日期，YYYY-MM-DD | 以验证通过日为准，不以方案提交日为准 |
| 遗留事项 | 关闭验证 | 关闭时仍未处理完的关联事项 | 文本 | 写明后续承接人与计划时间，无则填“无” |
两组容易混淆的字段需要特别说明。严重程度描述问题本身的客观影响，登记后相对稳定；优先级描述在当前排期中的处理顺序，会随里程碑临近而调整，同一问题可能严重程度为“一般”但优先级为P1。责任人是对解决负主责的单一角色，协同人是提供输入或配合执行的辅助角色，二者在字段中分开填写，避免出现“共同负责”导致推进停滞。
日期字段统一采用YYYY-MM-DD格式，便于排序和筛选。发现日期、期望解决日期、升级时间、关闭日期分别对应问题生命周期的四个节点，填写时以实际发生时间为准，补录情况在问题描述中注明。责任人字段只填一人，需要多人参与时通过协同人字段表达。
必填与选填：按项目规模裁剪字段
字段裁剪的原则是：支撑责任落实、升级、关闭验证的字段保留，描述性和分析性字段按项目复杂度启用。下表给出必填与选填的划分及适用场景。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 编号、问题标题、问题描述、发现日期、提出人 | 必填 | 构成问题的最小识别信息，缺少任一项无法追溯 |
| 责任人、期望解决日期、当前状态 | 必填 | 责任落实主线的核心，缺少则无人推进、无法判断进度 |
| 升级级别、升级触发条件、升级对象、升级时间 | 必填 | 升级主线的核心，即使未升级也需填写“未升级”以表明已评估 |
| 解决方案、验证人、验证结论、关闭日期 | 必填 | 关闭验证主线的核心，是证明问题真正解决的依据 |
| 问题类型、严重程度、优先级 | 建议必填 | 用于排序和统计，小型项目可先只保留优先级 |
| 影响范围、影响里程碑 | 选填 | 多团队或强交付节点项目建议启用，用于评估影响面 |
| 协同人 | 选填 | 存在跨角色配合时填写，单人可闭环的问题可留空 |
| 验证方式 | 选填 | 需要留存证据或对外交付时启用 |
| 遗留事项 | 选填 | 关闭时仍有后续动作时填写 |
小型项目（单一团队、周期短、问题量少）可精简为：编号、标题、描述、发现日期、提出人、责任人、期望解决日期、当前状态、升级级别、解决方案、验证人、验证结论、关闭日期。这一组合保留了三条主线的关键字段，同时减少填表负担。
多团队项目或强交付节点项目建议启用全部字段，尤其是影响范围、影响里程碑、协同人和验证方式。跨团队问题的责任边界和影响面往往不清晰，这些字段能在升级评审时提供判断依据。无论项目规模如何，责任落实、升级管理、关闭验证三类字段不宜省略——它们分别回答谁负责、何时升级、如何证明已关闭，是台账区别于普通问题清单的关键。
填写示例：一条问题从登记到关闭的完整记录
以下为一条脱敏的通用示例，场景为某项目在联调阶段发现接口响应超时，影响上线节点。示例中各字段与空白模板一一对应。
| 字段 | 示例值 |
|---|---|
| 编号 | PRJ-012 |
| 问题标题 | 订单查询接口在高峰时段响应超时 |
| 问题描述 | 联调环境压测时，订单查询接口在并发200时平均响应超过3秒，已排查应用日志未见异常，怀疑与数据库连接池配置有关 |
| 影响范围 | 订单模块、联调进度、上线验收 |
| 发现日期 | 2025-03-10 |
| 提出人 | 测试负责人 |
| 问题类型 | 技术障碍 |
| 严重程度 | 严重 |
| 优先级 | P1 |
| 影响里程碑 | 3月20日上线验收 |
| 责任人 | 后端开发A |
| 协同人 | DBA（提供慢查询分析）、运维（提供连接池监控） |
| 期望解决日期 | 2025-03-14 |
| 当前状态 | 已关闭 |
| 升级级别 | 项目级 |
| 升级触发条件 | 3月13日仍未定位根因，距上线验收不足7天 |
| 升级对象 | 项目负责人 |
| 升级时间 | 2025-03-13 10:30 |
| 解决方案 | 调整数据库连接池上限并增加慢查询索引，压测并发200时平均响应降至800毫秒 |
| 验证人 | 测试负责人 |
| 验证方式 | 复测压测报告 |
| 验证结论 | 通过 |
| 关闭日期 | 2025-03-15 |
| 遗留事项 | 生产环境连接池参数需在上线前由运维复核，承接人：运维，计划3月18日完成 |
责任落实字段的填写依据是：责任人为实际承担排查与修复的后端开发，协同人按所需支持分别列出并注明事项，期望解决日期与上线验收节点保持缓冲。升级字段的依据是：问题在期望解决日期前一天仍未定位根因，触发“距上线验收不足7天”的条件，升级到项目负责人协调资源。关闭验证字段的依据是：由提出人复测压测报告确认响应时间达标，验证通过后才填写关闭日期；遗留事项写明承接人和计划时间，避免关闭后无人跟进。
当台账中的责任人、状态、升级与关闭验证需要与项目任务保持同步时，可以把台账文档与项目工作项关联起来。ONES Wiki 支持文档关联项目任务，页面树可组织项目文档与知识信息；其页面模板库支持一键创建制式化文档模板，便于把上述表头固化为统一格式；文档实时同步并记录页面版本，支持查看与回滚，适合在字段调整后保留变更痕迹。这样台账作为文档承载字段与证据，工作项承载任务推进，两者通过关联保持对应。
台账的调整与维护方法
台账上线后需要持续维护，否则容易退化为一次性文档。以下规则清单可作为日常维护的检查依据。
- 字段增删的触发条件：当出现现有字段无法表达的新问题类型、升级路径或验证要求时，才考虑新增字段；连续两个复盘周期无人使用的字段可评估删除。每次变更在台账文档的变更记录中写明变更内容、原因、生效日期和影响的历史数据处理方式。
- 状态更新节奏：责任人每次处理动作后更新当前状态与对应日期；项目周会前由台账维护人核对一次，确保状态与实际一致。阶段结束时做一次全量复盘，重点检查超期未关闭、升级后无结论、验证结论缺失的记录。
- 关闭验证的证据留存：验证方式为复测、评审或客户确认时，将报告、会议结论或确认记录与台账记录关联保存；验证结论、验证人和关闭日期三项齐全才算完成关闭，仅有解决方案不算关闭。
- 边界划分：产品功能缺陷的跟踪归入缺陷管理流程，服务中断等线上事件归入服务事件与问题管理流程；项目问题台账聚焦项目推进中的障碍，如资源缺口、外部依赖、流程阻塞和跨团队协调问题。同一事项若同时涉及缺陷与项目影响，在缺陷系统中跟踪修复，在台账中记录对项目节点的影响与协调动作，避免两处重复维护同一份处理细节。
维护台账时，建议指定一名台账维护人负责周度核对与变更记录，责任人负责本人问题的状态更新，验证人负责关闭前的确认。三者分工明确后，台账才能持续反映项目问题的真实进展，并在复盘时提供可追溯的依据。
常见问题
问题台账里的“严重程度”和“优先级”可以合并成一个字段吗？
不建议合并。严重程度描述问题对目标造成的客观影响，登记后相对稳定；优先级描述在当前排期中的处理顺序，会随里程碑临近而调整。同一问题可能严重程度为“一般”但优先级为P1。合并后，排期调整会连带改动影响判断，复盘时难以还原问题本身的严重性。小型项目若填表负担重，可先只保留优先级，但需在字段说明中注明严重程度暂缺。
问题一直没升级，升级相关字段怎么填？
升级级别填“未升级”，升级触发条件、升级对象、升级时间可留空，但建议在升级触发条件中写明评估过的条件，如“未超期、未影响上线”。这样能表明升级动作经过评估，而非遗漏。一旦触发升级，每次升级追加一条记录并保留历史，不要覆盖前一次的时间和对象。
验证不通过时，台账应该怎么记录？
验证结论填“不通过”或“部分通过”，当前状态回退到“处理中”，关闭日期留空。在解决方案字段补充本次处理结果与验证发现的问题，便于责任人继续推进。遗留事项可记录验证中发现的关联问题及承接人。待再次验证通过后，再填写验证结论、验证人和关闭日期完成关闭。
同一事项既影响项目节点又涉及产品缺陷，台账和缺陷系统要各记一遍吗？
不需要重复维护同一份处理细节。缺陷系统中跟踪修复过程与缺陷状态，台账中记录该缺陷对项目节点的影响、协调动作和升级情况。两处通过编号或链接关联，台账的关闭验证以项目影响消除为准，缺陷本身的修复结论以缺陷系统为准。这样既保留项目视角的推进记录，也避免两套记录不一致。
台账字段用了一段时间想调整，历史数据怎么处理？
先判断调整是否必要：现有字段无法表达新的问题类型、升级路径或验证要求时才新增，连续两个复盘周期无人使用的字段可评估删除。变更时在台账文档的变更记录中写明变更内容、原因、生效日期，以及历史数据的处理方式，例如新增字段对历史记录统一填“不适用”。调整后同步更新字段说明，避免填表人按旧口径填写。
