项目问题清单以“问题”为一行记录，围绕项目推进中遇到的障碍登记信息。一份可用的清单通常包含问题编号、问题描述、提出人与提出日期、所属项目与阶段、影响范围、严重程度与优先级、责任人、计划解决日期、当前状态、解决措施与结果、关闭确认。本文提供可直接复制的空白表格、逐字段填写口径、必填与选填划分，以及一条完整填写示例，并说明清单上线后的维护规则。产品缺陷与服务中断分别走缺陷管理和服务事件流程，不混入本清单。
要点总览（TL;DR）
- 项目问题清单以“问题”为一行记录，核心字段包括问题编号、问题描述、提出人与提出日期、所属项目与阶段、影响范围、严重程度、优先级、责任人、计划解决日期、当前状态、解决措施与结果、关闭确认。
- 小团队起步可用八个必填字段：编号、描述、提出人、提出日期、所属项目、严重程度、责任人、当前状态，先支撑登记、分派和跟进。
- 问题描述写清现象、场景和影响三要素；严重程度按后果定级，优先级按处理顺序排定，两列分开填写。
- 清单上线后按使用证据增删字段，状态沿待分派→处理中→待验证→已关闭流转，例会前检查异常，阶段结束或每月复盘归档。
- 产品缺陷进入缺陷管理流程，线上服务中断进入服务事件与问题管理流程，项目问题清单只记录项目推进中的障碍。
可复制空白项目问题清单模板
下表可直接复制到 Excel、在线表格或文档工具中使用。表头按记录顺序排列，前两行为空白行，复制后按行追加即可。列宽建议仅作参考，实际以团队屏幕和打印需要调整。
| 问题编号 | 问题描述 | 提出人 | 提出日期 | 所属项目 | 所属阶段 | 影响范围 | 严重程度 | 优先级 | 责任人 | 计划解决日期 | 当前状态 | 解决措施与结果 | 关闭确认 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
填写格式提示：问题编号建议采用“项目缩写-序号”形式，如 PRJ-001，保持唯一；日期统一为 YYYY-MM-DD；严重程度与优先级使用固定选项而非自由文本，便于筛选和统计；问题描述列宽建议不低于 40 个字符宽，其余列按内容长度设置。若在文档工具中维护，可将本表作为页面模板保存，后续新建页面时直接套用。
每个字段记录什么：字段说明与填写口径
字段设计的目的是让一条问题记录在无人口头补充的情况下也能被读懂、分派和追踪。下表逐字段说明含义与填写方式，模板、示例与维护规则均以此口径为准。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 问题编号 | 记录的唯一标识 | 项目缩写加流水号，创建时分配，不复用、不跳号 |
| 问题描述 | 问题本身 | 写清现象、发生场景和造成的影响，一句话说清“什么情况下发生了什么、导致什么后果” |
| 提出人 | 谁最先发现或提出 | 填写真实姓名，便于回溯和补充信息 |
| 提出日期 | 问题被记录的时间 | 统一日期格式，当天登记当天填写 |
| 所属项目 | 问题归属的项目 | 填写项目全称或团队统一的项目代号 |
| 所属阶段 | 问题暴露时项目所处的阶段 | 如需求、设计、开发、测试、上线、验收，按团队阶段划分填写 |
| 影响范围 | 问题波及的对象和程度 | 写明受影响的模块、交付物、干系人或时间节点，避免只写“影响较大” |
| 严重程度 | 问题客观造成的后果等级 | 按后果定级，如阻断、严重、一般、轻微；由问题本身决定，与处理先后无关 |
| 优先级 | 处理先后顺序 | 结合严重程度、时间窗口和资源情况排定，如高、中、低；同一严重程度的问题可以有不同的优先级 |
| 责任人 | 负责推动解决的人 | 填写单一负责人，协作人写入解决措施栏，避免多人并列导致无人推进 |
| 计划解决日期 | 承诺的解决时间 | 填写具体日期而非“尽快”，日期变更时同步更新并说明原因 |
| 当前状态 | 问题所处处理环节 | 使用固定选项，如待分派、处理中、待验证、已关闭、挂起 |
| 解决措施与结果 | 怎么解决、结果如何 | 记录实际采取的动作和验证结果，未解决时记录当前进展和下一步 |
| 关闭确认 | 谁确认问题可以关闭 | 填写确认人和确认日期，确认人通常为提出人或其指定的验收人 |
严重程度与优先级容易混填，区分口径是：严重程度回答“这个问题造成多大后果”，优先级回答“现在先处理哪一个”。一个影响范围有限的合规问题可能严重程度一般，但因临近检查节点而被排为高优先级；反过来，一个后果严重但已有临时绕行方案的问题，优先级可以适当靠后。两列分开填写，评审时才不会把资源排序和问题定级混为一谈。
问题描述是最容易被写空的字段。合格的描述包含三个要素：现象（看到了什么）、场景（在什么条件、哪个环节出现）、影响（导致哪个交付物或节点受阻）。例如“测试环境账号权限未开通，测试人员无法执行回归用例，原定本周的回归测试无法开始”，比“测试环境有问题”更能支撑后续分派和判断。
哪些必填、哪些选填：最小可用清单
字段越多，登记门槛越高，清单越容易空置。小团队起步时可以先启用最小字段集，等清单真正被使用后再补充扩展字段。
| 类别 | 字段 | 理由或适用场景 |
|---|---|---|
| 必填 | 问题编号 | 唯一标识是检索、引用和复盘的基础 |
| 必填 | 问题描述 | 没有描述就无法判断问题和分派处理 |
| 必填 | 提出人、提出日期 | 便于回溯信息来源和统计问题出现的时间分布 |
| 必填 | 所属项目 | 多项目并行时用于归集和筛选 |
| 必填 | 严重程度 | 决定是否需要升级处理，是定级的基本依据 |
| 必填 | 责任人 | 没有责任人的问题等于没有进入处理流程 |
| 必填 | 当前状态 | 支撑清单筛选和例会跟进 |
| 选填 | 所属阶段 | 阶段划分清晰、需要按阶段复盘问题分布时启用 |
| 选填 | 影响范围 | 问题涉及多方干系人或关键节点时建议填写，便于升级沟通 |
| 选填 | 优先级 | 问题数量较多、需要排处理顺序时启用；问题少时可先按严重程度处理 |
| 选填 | 计划解决日期 | 需要对外承诺时间或纳入里程碑跟踪时填写 |
| 选填 | 解决措施与结果 | 处理过程中逐步补充，关闭前应补齐 |
| 选填 | 关闭确认 | 需要验收留痕或问题影响较大时启用 |
最小可用版本包含编号、描述、提出人、提出日期、所属项目、严重程度、责任人、当前状态八个字段，足以支撑登记、分派和跟进三件事。完整版本在此基础上补齐阶段、影响范围、优先级、计划日期、解决措施和关闭确认，适合问题数量多、跨团队协作或需要定期向管理层汇报的项目。建议先按最小版本运行两到四周，统计哪些信息在例会上被反复口头追问，再把这些信息补成字段，而不是一开始就照搬完整表头。
填写示例：一条完整的问题记录
以下示例为演示情景，用于说明各字段如何配合形成从提出到关闭的完整信息链。
| 字段 | 示例取值 |
|---|---|
| 问题编号 | PRJ-012 |
| 问题描述 | 第三方支付接口的测试账号未开通，联调阶段无法验证支付回调，原定本周完成的支付模块联调无法开始 |
| 提出人 | 李敏 |
| 提出日期 | 2025-03-10 |
| 所属项目 | 订单系统升级 |
| 所属阶段 | 联调 |
| 影响范围 | 支付模块联调及后续的端到端测试，涉及前端、后端和测试三个小组 |
| 严重程度 | 严重 |
| 优先级 | 高 |
| 责任人 | 王磊 |
| 计划解决日期 | 2025-03-12 |
| 当前状态 | 已关闭 |
| 解决措施与结果 | 王磊联系支付服务商提交企业资质补充材料，3 月 11 日账号开通；测试组当天完成回调验证，联调恢复 |
| 关闭确认 | 李敏，2025-03-11 |
逐项看这条记录的信息链：编号 PRJ-012 让它在清单和会议纪要中可被准确引用；描述写明了现象（账号未开通）、场景（联调阶段验证支付回调）和影响（支付模块联调无法开始），任何人读到都能判断问题性质；提出信息交代了来源和时间；所属项目与阶段把问题定位到具体工作环节；影响范围说明了波及的三个小组，支撑了优先级判断；严重程度定为“严重”是因为它阻断了关键路径上的联调，优先级定为“高”是因为联调窗口临近；责任人只有王磊一人，协作动作写在解决措施里；计划日期给出了明确承诺；状态从处理中走到已关闭；解决措施记录了实际动作和验证结果；关闭确认由提出人完成，形成闭环。
对照前文的字段口径可以看到，示例中的每个取值都遵循了填写规范：日期格式统一，严重程度与优先级分开判断，描述包含三要素，责任人为单一负责人。团队照此填写，清单就能在无人解释的情况下被读懂。
清单的调整与维护方法
清单上线后最常见的失效方式是字段只增不减、状态长期不更新、问题关闭后无人归档。以下规则用于保持清单长期可用。
- 字段增删看使用证据。连续两次例会中有人口头追问同一类信息，就把该信息补成字段；某个字段连续一个月无人查看、也不影响筛选和汇报，可以考虑合并或删除。每次调整在清单说明中记录变更日期和原因，避免不同项目使用不同版本的表头。
- 状态流转固定路径。建议路径为待分派→处理中→待验证→已关闭，暂时无法推进的问题进入挂起并注明恢复条件。责任人变更、计划日期调整当天更新，状态变化由责任人本人修改，例会上只核对不代改。
- 更新频率与例会绑定。每周例会前由清单维护人检查一遍：新登记问题是否已分派、超期未关闭的问题是否升级、挂起问题是否仍有恢复条件。例会只讨论状态异常和需要协调的问题，逐条朗读已关闭记录没有意义。
- 定期复盘与归档。每个阶段结束或每月做一次复盘，按所属阶段和严重程度统计问题分布，找出反复出现的成因；已关闭且超过约定保留期的问题移入归档表，主清单只保留未关闭和近期关闭的记录，保证打开清单就能看到当前需要处理的事。
- 与缺陷、服务事件划清边界。产品功能不符合预期、需要研发修复的，进入缺陷管理流程；线上服务中断或可用性下降，进入服务事件与问题管理流程。项目问题清单只记录项目推进中的障碍，例如资源未到位、依赖方交付延迟、需求口径不一致、环境未就绪。登记时先判断问题性质，再决定进入哪张表，避免同一件事在两处重复跟踪。
清单落地到协作工具时，可以把空白模板、字段说明和维护规则放在文档页面中，用页面模板库固化为制式模板，新项目一键套用；问题记录本身则放在可筛选、可指派责任人的工作项或表格中，文档与项目工作保持关联，成员在页面上直接评论补充信息。ONES Wiki 支持文档关联项目任务、页面模板库和版本记录，适合承载模板说明与维护规则这类需要长期同步的内容；问题记录的具体载体以团队现有工具为准。无论使用哪种工具，判断清单是否健康的标志是一致的：打开清单能看清当前有哪些问题、谁在处理、卡在哪里，关闭的问题留有可追溯的措施和确认记录。
常见问题
问题数量很少的项目，还需要建项目问题清单吗？
问题数量少时，清单的价值主要在于留痕和交接，不在于统计。可以先只启用编号、描述、提出人、提出日期、所属项目、严重程度、责任人、当前状态八个字段，用一张简单表格登记。等出现跨人协作、问题需要升级或项目交接时，再补充影响范围、计划解决日期和关闭确认。清单的字段数量可以随使用情况调整，起步阶段保持轻量更有利于坚持登记。
同一个问题既影响项目进度，又涉及产品功能缺陷，应该记在哪张表？
先判断问题的主要性质。需要研发修改产品功能才能消除的，进入缺陷管理流程，在缺陷记录中关联受影响的项目和里程碑；项目问题清单只登记由此产生的推进障碍，例如修复排期未定导致联调延后，并注明关联的缺陷编号。这样两张表各自记录本职信息，通过编号互相引用，避免同一件事在两处重复跟踪、状态不一致。
责任人长期没有更新状态，清单怎么保持可信？
把状态更新绑定到固定节奏：责任人变更和计划日期调整当天修改，状态变化由责任人本人操作，例会上只核对不代改。清单维护人在每周例会前检查一遍，重点看新登记问题是否已分派、超期未关闭的问题是否需要升级、挂起问题是否仍有恢复条件。连续多次未更新的记录，在例会上明确处理意见，比反复提醒更能形成习惯。
清单里的历史问题越来越多，打开就看不清当前要处理什么，怎么办？
为主清单设定保留范围：只保留未关闭和近期关闭的记录，已关闭且超过约定保留期的问题移入归档表。归档表保留全部字段，便于复盘时按阶段和严重程度统计问题分布。主清单配合状态筛选，默认视图只看待分派、处理中和待验证的记录，打开就能看到当前需要处理的事。归档周期和保留期由团队在清单说明中写清楚，避免各项目自行其是。
用文档表格维护清单，和放到项目管理工具里有什么区别？
文档表格上手快，适合问题少、参与人固定的团队，字段说明和维护规则也可以和表格放在同一页面。问题数量增多、需要按责任人筛选、需要与任务和里程碑关联时，把问题记录放到可筛选、可指派责任人的工作项或表格中会更省力。ONES Wiki 支持文档关联项目任务、页面模板库和版本记录，适合承载模板说明与维护规则这类需要长期同步的内容；问题记录的具体载体以团队现有工具为准。
