项目问题台账以“问题”为记录单位，最小可用字段包括问题编号、问题描述、提出人、提出日期、责任人、目标解决日期、优先级、状态、影响范围、解决措施与关闭确认。它只记录影响项目推进的障碍；产品缺陷归缺陷管理，服务中断归服务事件与问题管理，三类记录分表管理，台账才能保持清晰可用。
要点总览（TL;DR）
- 项目问题台账的最小可用字段为：问题编号、问题描述、提出人、提出日期、责任人、目标解决日期、优先级、状态、影响范围，关闭时补填解决措施与关闭确认。
- 问题描述写现象与影响，影响范围写波及的模块、里程碑与人力，优先级写处理顺序，三列分开填，排期才有依据。
- 台账只记录影响项目推进的障碍；可复现的软件错误归缺陷管理，线上服务中断归服务事件与问题管理，三类记录分表管理。
- 字段按需扩展：问题涉及多个任务时加关联任务，需要跨层级推动时加升级记录，同类问题反复出现时加根因分类，启用后同步更新字段说明。
- 维护重点是状态当天更新、目标日期变更留痕、每周例会只过新增高优先级、超期和待验证过久的记录，月度评审把持续威胁升级到风险清单。
可复制空白项目问题台账模板
下面这张表可以直接复制到 Excel、在线表格或协作工具中作为初始台账。表头顺序按“识别—分派—跟踪—关闭”的信息链排列，前七列用于快速定位和分派，后五列用于跟踪处理过程与关闭依据。字段命名在后续字段说明、填写示例中保持一致，复制后不需要再改名。
| 问题编号 | 问题描述 | 提出人 | 提出日期 | 责任人 | 目标解决日期 | 优先级 | 状态 | 影响范围 | 解决措施 | 关闭确认 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
使用时有两点约定：问题编号建议采用“项目缩写-序号”的格式，例如 PRJ-001，便于跨表引用；状态列先按“待分派、处理中、待验证、已关闭”四档起步，团队熟悉后再按需细分。表格保留两行空白填写行，实际使用时按行追加即可。
台账字段说明：每个字段记录什么、怎么填
字段的价值在于填写口径统一。同一列在不同人手里填出不同含义，台账就会退化成聊天记录汇总。下表逐字段说明含义、填写口径和常见错误，其中问题描述、影响范围、优先级三列最容易填偏，需要重点关注。
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 问题编号 | 台账内唯一标识 | 项目缩写加顺序号，创建时自动或手工分配，不复用 | 多条记录共用编号；关闭后编号被回收 |
| 问题描述 | 障碍的现象与影响 | 写“谁在什么场景下遇到什么阻碍、导致什么后果”，一句话说清现象 | 写成原因猜测或解决方案；只写“进度受阻”这类无信息量表述 |
| 提出人 | 记录该问题的人 | 填真实姓名，便于回溯原始信息 | 填部门名或“项目组” |
| 提出日期 | 问题被记录的时间 | 统一格式，如 2025-03-14 | 格式混用；补填时写成解决日期 |
| 责任人 | 负责推动解决的人 | 填单一责任人，可另在备注写协作方 | 填多个平级责任人，导致无人真正推进 |
| 目标解决日期 | 承诺解决的时限 | 与责任人确认后填写，变更时更新并留痕 | 填成“尽快”；长期不更新导致超期不可见 |
| 优先级 | 处理顺序的相对高低 | 按对项目目标的影响定档，如高、中、低三档，并写明定档依据 | 与影响范围混为一谈；所有问题都标高 |
| 状态 | 问题当前所处环节 | 从约定状态集中选择，变更时同步更新日期 | 长期停留在“处理中”；状态与关闭确认矛盾 |
| 影响范围 | 问题波及的对象与程度 | 写清受影响的模块、里程碑、团队或交付物，以及是否阻塞关键路径 | 只写“影响较大”；把影响范围当成优先级 |
| 解决措施 | 实际采取的处理动作 | 关闭前填写，写动作与结果，可附验证方式 | 提前填入设想方案；只写“已处理” |
| 关闭确认 | 关闭的依据与确认人 | 写确认人、确认方式和日期，遗留事项转入备注或新记录 | 责任人自行关闭且无验证；遗留事项直接删除 |
| 备注 | 补充信息 | 放协作方、关联记录、升级情况等不宜入主字段的信息 | 把关键结论只写在备注里 |
影响范围与优先级要分开填：影响范围回答“波及了什么”，优先级回答“先处理哪个”。一个只影响单个文档模板的问题可能影响范围小但优先级高，因为它是本周交付的前置条件；反过来，影响多个模块的问题也可能因有替代方案而排在后面。两列配合，才能让排期有依据。
边界判断同样影响填写质量。产品功能不符合预期、可复现的软件错误，应进入缺陷管理，由缺陷记录跟踪修复与验证；线上服务中断、可用性下降，应进入服务事件与问题管理流程，按事件响应机制处理。项目问题台账记录的是跨角色协作、资源、依赖、决策延迟等阻碍项目推进的事项。遇到一条记录拿不准归属时，先判断它的处理流程由谁主导：由测试与研发按缺陷流程走的进缺陷表，由运维按事件流程走的进服务事件表，其余影响项目计划执行的进问题台账。
必填与选填：最小可用台账与扩展字段
字段不是越多越好。必填字段的标准是：缺少它，这条记录就无法被分派、跟踪或关闭。按这个标准，最小可用台账保留九个字段即可运转；其余字段按项目复杂度和团队协作方式逐步启用。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 问题编号 | 必填 | 唯一标识，跨表引用和沟通定位的基础 |
| 问题描述 | 必填 | 没有描述就无法判断问题是什么 |
| 提出人 | 必填 | 回溯原始信息、补充细节的联系人 |
| 提出日期 | 必填 | 计算存续时长、识别积压的依据 |
| 责任人 | 必填 | 没有责任人就无人推进 |
| 目标解决日期 | 必填 | 超期识别和评审排序的基准 |
| 优先级 | 必填 | 多问题并存时决定处理顺序 |
| 状态 | 必填 | 反映当前环节，支撑例会同步 |
| 影响范围 | 必填 | 判断是否阻塞关键路径，支撑升级决策 |
| 解决措施 | 选填（关闭前必填） | 处理中可暂空，关闭时作为关闭依据 |
| 关闭确认 | 选填（关闭前必填） | 关闭环节填写确认人与方式 |
| 备注 | 选填 | 放协作方、关联记录等补充信息 |
最小可用组合即上表中的九个必填字段，加上关闭时补填的解决措施与关闭确认。这个组合适合问题数量少、参与角色单一的项目，一张表就能完成记录与跟踪。
扩展字段按条件启用：问题经常涉及多个任务或需求时，增加“关联任务/需求”列，写明编号即可建立引用；问题需要跨层级推动时，增加“升级记录”列，记录升级对象、时间和结论；同类问题反复出现时，增加“根因分类”列，用有限几个类别归因，便于季度复盘。扩展字段一旦启用，就要同步更新字段说明，避免只有创建者知道怎么填。
填写示例：一条完整的问题记录
下面用一条演示记录展示各字段如何配合。情景为虚构示例：某项目在联调阶段发现第三方接口文档缺失，导致联调排期后移。
| 字段 | 填写内容 |
|---|---|
| 问题编号 | PRJ-012 |
| 问题描述 | 联调阶段发现第三方支付接口文档缺失，前端无法按计划完成对接，联调里程碑存在延期风险 |
| 提出人 | 李敏 |
| 提出日期 | 2025-03-14 |
| 责任人 | 王磊 |
| 目标解决日期 | 2025-03-21 |
| 优先级 | 高（阻塞联调里程碑） |
| 状态 | 已关闭 |
| 影响范围 | 支付模块前端对接；联调里程碑；前端小组两人排期 |
| 解决措施 | 3月17日联系对方接口负责人取得文档初稿；3月19日完成字段核对并补充差异说明；3月20日前端按文档完成对接并通过联调验证 |
| 关闭确认 | 李敏于3月21日验证联调通过后确认关闭；遗留事项：文档正式版待对方发布后归档，已转备注跟踪 |
| 备注 | 协作方：第三方接口负责人；关联任务：联调计划 T-208 |
逐项看这条记录的信息链：问题描述只写现象和影响，把“对方流程慢”这类原因判断留给处理过程；影响范围写清了模块、里程碑和人力，优先级据此定为高，两列互相印证；解决措施按时间写动作和结果，关闭确认写明验证人和遗留事项去向。状态从“处理中”变为“已关闭”的过程，在解决措施和关闭确认的日期中留有痕迹，评审时能还原处理节奏。
关闭确认的写法值得单独说明：确认人要写具体姓名，确认方式写“验证联调通过”这类可核验的动作，遗留事项写清去向——转入备注跟踪、另开新记录或纳入风险清单，三种去向选其一并写明，避免关闭即失联。
台账的调整与维护方法
台账上线后的主要风险是字段膨胀和状态失真。维护的重点是让字段增删有依据、状态变更有时效、超期问题有出口。
字段增删遵循三条原则：新增字段前先确认现有字段无法承载该信息，能写进备注的先不新增列；删除字段前确认历史记录不再需要该信息，或先导出归档；字段含义变更时同步修订字段说明，并在台账首页注明生效日期。每次调整后抽查五条记录，确认填写口径一致。
状态与优先级规则按固定节奏维护：状态变更当天更新，不允许“处理中”长期挂起；优先级调整需写明依据，例如里程碑变更或出现替代方案；目标解决日期变更要留痕，连续两次延期的记录进入评审议程。建议每周例会上过一遍台账，只讨论三类记录：本周新增的高优先级问题、已超期问题、待验证超过约定天数的问题。
定期评审建议按月进行，检查项包括：超期未关闭记录的数量与原因、长期停留在同一状态的记录、关闭确认缺失的记录、备注中堆积未处理遗留事项的记录。评审结论要么推动关闭，要么升级为项目风险，进入风险清单单独跟踪，避免问题台账与风险清单重复记录同一件事。
台账与项目周会的衔接方式是：周会前由台账负责人整理上述三类记录形成简短清单，会上逐条确认责任人和新时限，会后当天更新台账。台账与风险清单的分工是：问题台账记录已发生、待解决的障碍；风险清单记录尚未发生、需要预防的不确定事件。一个问题若演变为对项目目标的持续威胁，就从台账升级到风险清单，台账中保留编号并注明升级去向。
当团队把台账从表格迁移到协作工具时，可以用工作项承载每条问题记录，把责任人、目标解决日期、优先级和状态设为字段，状态流转和筛选视图直接对应上述维护动作；填写规范和字段说明则放在项目文档中，与工作项互相引用。ONES Project 支持自定义状态与多种属性，并提供任务筛选器按多重条件筛选，适合承载问题记录的分派与跟踪；ONES Wiki 提供页面模板库，可把本文的空白模板和字段说明做成制式文档，并记录版本、支持查看与回滚，方便字段调整时留痕。具体字段配置以实际环境为准，团队仍应先确定自己的填写口径，再落到工具里。
常见问题
问题台账里的“问题”和缺陷管理里的“Bug”怎么划界？
按处理流程的主导方来判断。可复现的软件错误、功能不符合预期，由测试与研发按缺陷流程跟踪修复和验证，进缺陷表；跨角色协作、资源不足、依赖未就绪、决策延迟这类阻碍项目计划执行的事项，进问题台账。
拿不准时看这条记录关闭时需要谁验证：需要测试回归验证的走缺陷流程，其余进问题台账。团队最好在台账首页写明这条判断规则，减少同一条记录在两处重复出现。
项目刚开始、问题数量很少，能不能只用最简的几列？
可以。最小可用组合是九个必填字段，加上关闭时补填的解决措施与关闭确认。问题数量少、参与角色单一的项目，一张表就能完成记录与跟踪。
需要留意的是，问题描述、责任人、目标解决日期、状态这四列从一开始就要填完整，缺任何一项，记录就无法被分派和跟踪。等同类问题开始反复出现，再考虑增加根因分类等扩展字段。
目标解决日期经常延期，台账该怎么处理？
延期本身可以接受，不留痕才是问题。日期变更时更新字段并在备注写明变更原因和新旧日期，连续两次延期的记录进入周会议程，由责任人说明卡点和新的推进方案。
如果延期原因是外部依赖长期无法满足，这条记录已不只是待办事项，应考虑升级为项目风险，进入风险清单单独跟踪，台账中保留编号并注明升级去向。
问题关闭后，遗留事项应该写在哪里？
关闭确认里写明遗留事项的去向，三种选其一：转入备注继续跟踪、另开一条新记录、纳入风险清单。写清去向和跟进人，避免关闭即失联。
遗留事项不建议直接删除。它往往说明问题只解决了一部分，保留记录能让后续评审看到处理边界，也方便复盘时判断当时的关闭决定是否合理。
把台账从表格搬到协作工具，需要先做哪些准备？
先定填写口径，再配工具。字段含义、必填项、状态集和优先级定档依据应在团队内达成一致，否则工具只是把混乱搬到线上。
落地时可以用工作项承载每条问题记录，把责任人、目标解决日期、优先级和状态设为字段，用筛选视图对应周会要过的几类记录；空白模板和字段说明放在项目文档中，与工作项互相引用。ONES Project 支持自定义状态与多种属性，并提供任务筛选器按多重条件筛选；ONES Wiki 提供页面模板库，可把模板做成制式文档并记录版本、支持查看与回滚。具体字段配置以实际环境为准。
