项目问题清单要真正发挥作用，关键在四件事：划清收录范围、固定更新节奏、约束状态流转、落实责任人。本文面向负责项目推进的人，给出从登记到关闭的操作方法，包括范围判断、更新时点、关闭证据和检查表。清单的登记、状态流转与更新记录可以放在 ONES 的工作项与文档中承载，具体方式按团队现有体系选择。
要点总览（TL;DR）
- 清单只收影响项目推进的障碍类事项，产品 Bug 归缺陷管理、服务中断归服务事件与问题管理，登记时至少填齐编号、描述、责任人、目标解决日期和状态。
- 更新靠例行与触发式配合：例会和周报逐条检查字段新鲜度，状态变化、责任人变更、日期调整时即时修改并留下变更说明。
- 状态保持精简（待确认、处理中、挂起、已升级、已关闭），每个状态设准入条件，关闭必须有可核验证据并经提出人验收。
- 提出人、责任人、清单维护人、项目负责人各管一段，升级由责任人发起、项目负责人协调、维护人回写结论。
- 每周或双周按检查表核对字段完整性、超期条目、长期未更新条目和关闭证据，发现的问题落到具体改进动作。
先划清范围：哪些事项该进项目问题清单
项目问题清单只收录影响项目推进的障碍类事项。判断标准可以归纳为三条：该事项是否阻碍当前计划中的任务完成；是否需要项目层面协调资源或决策才能解决；如果不处理，是否会在近期影响里程碑或交付质量。三条中满足两条以上，就适合进入清单。
相邻事项按归属分流，避免清单变成杂事堆。产品功能缺陷进入缺陷管理流程，由测试与研发按缺陷优先级处理；线上服务中断、可用性下降进入服务事件与问题管理流程，按事件响应机制处理。项目问题清单关注的是“项目怎么往前走”受阻，例如关键依赖方交付延迟、需求范围未确认导致排期无法锁定、跨团队接口人对不齐、环境或权限申请长期未批。这些事项的共同点是：解决动作发生在项目协调层面，而非单个缺陷修复或服务恢复。
每条问题进入清单时，至少填齐以下字段，后续更新才有依据。
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 唯一编号 | 按项目前缀加序号，如 PRJ-012 | 便于引用、追踪和复盘 |
| 问题描述 | 写清现象、影响范围和已尝试的动作 | 让责任人无需追问即可判断 |
| 提出人 | 记录发现问题的具体人员 | 后续验收与补充信息 |
| 责任人 | 一名具体人员，而非一个团队 | 明确推进主体 |
| 提出日期 | 登记当天 | 计算存续时长 |
| 目标解决日期 | 与责任人确认后的日期 | 判断是否超期 |
| 当前状态 | 按统一状态集合填写 | 反映真实进展 |
| 下一步动作 | 一句话说明接下来做什么、谁做、何时做 | 防止条目挂起 |
| 关闭证据 | 关闭时填写，指向可核验的结果 | 保证关闭可信 |
字段不必一次填满所有细节，但编号、描述、责任人、目标解决日期和状态五项在登记时必须齐全，缺一项就不算完成登记。
更新节奏：例行更新与触发式更新怎么配合
清单失真的常见原因是只在出问题时才看它。可行的做法是把例行更新和触发式更新配合起来：例行更新保证字段定期被检查，触发式更新保证变化发生时记录跟得上。
例行更新放在固定的项目例会上，每次留出固定时间逐条过清单。检查项包括：状态是否与实际情况一致、目标解决日期是否仍然成立、下一步动作是否已执行、责任人是否发生变化。周报中同步清单摘要，列出本周新增、本周关闭、超期条目和需要升级的条目。例行更新的输出是更新后的清单和一份需要协调的事项列表。
触发式更新在以下时点即时完成，不等到下次例会：问题状态发生变化，例如从待确认进入处理中；责任人变更，需同时说明交接内容；目标解决日期调整，需写明调整原因和新日期；问题影响范围扩大，需要升级处理。触发式更新的输入是变化事实，动作是修改对应字段并留下变更说明，输出是字段与事实一致的条目。
| 时点 | 负责人 | 更新内容 | 完成标志 |
|---|---|---|---|
| 每周项目例会 | 清单维护人主持，责任人逐条确认 | 状态、目标日期、下一步动作、责任人 | 清单字段与例会结论一致，超期条目有处理意见 |
| 每周周报 | 清单维护人 | 新增、关闭、超期、待升级条目摘要 | 摘要发出，需协调事项进入项目负责人视野 |
| 状态变化时 | 责任人 | 状态字段与变更说明 | 状态与证据匹配，下一步动作已填写 |
| 责任人变更时 | 原责任人移交，清单维护人确认 | 责任人字段、交接说明 | 新责任人确认接手，提出人知悉 |
| 目标日期调整时 | 责任人提出，项目负责人确认 | 目标解决日期、调整原因 | 新日期有依据，调整记录可查 |
节奏确定后要写进项目约定，明确例会上清单检查占用的时间，避免被其他议题挤掉。连续两次例会未检查清单，就视为维护机制失效，需要在复盘时处理。
状态流转与关闭规则：让清单可信
状态集合建议保持精简：待确认、处理中、挂起、已升级、已关闭。状态少而含义清楚，比状态多但边界模糊更利于维护。
| 状态 | 含义 | 进入条件与所需证据 |
|---|---|---|
| 待确认 | 已登记，尚未确认责任人与处理方案 | 有编号、描述、提出人；责任人和目标日期待定 |
| 处理中 | 责任人已明确并开始推进 | 责任人确认接手，有下一步动作和目标解决日期 |
| 挂起 | 暂时无法推进，等待外部条件 | 写明挂起原因、解除条件和复查日期 |
| 已升级 | 超出责任人权限，需项目负责人或更高层协调 | 有升级说明，明确协调对象和期望结论 |
| 已关闭 | 问题已解决并经提出人确认 | 有可核验的关闭证据，提出人验收通过 |
进入处理中的准入条件是责任人和目标解决日期都已确定，仅有“有人在看”不算。挂起不是逃避推进的手段：挂起条目必须写明解除条件和复查日期，到期自动回到例会议程。升级适用于责任人权限不足、需要跨团队决策的情形，升级后原责任人仍负责跟进协调结论的落地。
关闭需要满足三个条件：问题描述中的影响已消除或有明确替代方案；关闭证据可核验，例如确认邮件、已上线的变更记录、对方团队的书面承诺；提出人验收确认。只写“已解决”而没有证据的条目不允许关闭。关闭检查项包括：证据是否指向具体结果、提出人是否确认、关联的下一步动作是否已全部完成、是否需要沉淀为经验记录。
角色与交付物：谁负责哪一段
清单维护涉及四类角色，各自负责一段，交接点清楚，条目才不会在中间停住。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 问题提出人 | 描述问题与影响，提供补充信息，关闭时验收 | 完整的问题描述、验收结论 |
| 责任人 | 推进解决，维护自己条目的状态、日期和下一步动作 | 状态更新记录、解决证据、关闭申请 |
| 清单维护人 | 组织例行更新，检查字段完整性，汇总周报 | 更新后的清单、周报摘要、超期与待升级列表 |
| 项目负责人 | 处理升级事项，协调跨团队资源，确认日期调整 | 升级处理结论、资源协调结果 |
升级与跨团队协调的责任归属要提前说清：责任人负责发起升级并说明需要什么支持，项目负责人负责对接协调对象并给出结论，清单维护人负责把结论回写到条目。跨团队问题在协调期间保持已升级状态，协调结论落地后由责任人更新为处理中或已关闭。
在 ONES 中承载这套分工时，可以把每条问题登记为工作项，责任人字段对应到人，状态流转按上述集合配置，更新记录留在工作项动态中；清单视图和例会检查可以基于工作项列表进行，周报摘要从列表筛选生成。这样提出人、责任人和维护人看到的是同一份数据，减少多头维护。
示例：一条问题从登记到关闭的完整更新过程
以下为演示情景，用于说明字段填写与更新动作，不对应真实项目。
初始登记：编号 PRJ-012，问题描述为“支付渠道对接方的接口文档延迟两周未提供，导致联调排期无法锁定，影响本月版本上线”，提出人为测试负责人，责任人为后端接口人，提出日期为 3 月 3 日，目标解决日期暂定 3 月 10 日，状态为待确认，下一步动作为“责任人联系对接方确认文档交付时间”。
第一次更新发生在 3 月 5 日：责任人确认对接方接口人已变更，原承诺失效，状态从待确认改为处理中，目标解决日期调整为 3 月 14 日，调整原因写明“对接方接口人变更，需重新对齐交付计划”，下一步动作改为“3 月 6 日前拿到新接口人的书面交付时间”。
第二次更新发生在 3 月 11 日：对接方仅口头答复，未给出书面时间，责任人判断超出自身协调能力，状态改为已升级，升级说明写明需要项目负责人与对接方项目经理沟通，期望结论为“3 月 13 日前提供文档并确认联调窗口”。项目负责人当天完成沟通，结论回写到条目，状态回到处理中。
关闭发生在 3 月 13 日：对接方提供接口文档，联调窗口确认为 3 月 17 日至 19 日，责任人上传文档接收记录和联调排期确认邮件作为关闭证据，提出人验收确认排期可执行，状态改为已关闭，关闭说明中记录证据位置和验收人。
这条示例的关键在于每次状态变化都有依据、日期调整都有原因、关闭有可核验证据。读者可以对照自己的清单，检查条目是否具备同样的记录习惯。
完成检查：清单维护是否到位的核对项
维护机制是否有效，可以用一张检查表逐项核对，建议每周或双周执行一次，由清单维护人完成，项目负责人抽查。
| 检查项 | 核对方法 | 合格标准 |
|---|---|---|
| 字段完整性 | 抽查全部在办条目 | 编号、描述、责任人、目标日期、状态、下一步动作齐全 |
| 字段时效性 | 对比最近一次例会记录 | 状态与例会结论一致，无过期信息 |
| 超期条目 | 筛选目标解决日期早于今天的条目 | 每条都有处理意见或已调整日期并注明原因 |
| 长期未更新条目 | 筛选两周内无任何变更的条目 | 每条都有说明，或已挂起并设定复查日期 |
| 关闭证据齐全度 | 抽查近期关闭条目 | 每条都有可核验证据和提出人验收记录 |
| 挂起条目复查 | 检查挂起条目的复查日期 | 到期条目已回到例会议程 |
检查发现的问题要落到改进动作：字段缺失集中的，在登记环节增加必填校验；超期条目多的，检查目标日期设定是否过于乐观；长期未更新条目多的，检查责任人是否明确、例会检查是否被挤占。复盘节奏建议与项目例会同步，每次复盘只处理一到两个最突出的问题，避免检查表本身变成负担。
清单维护做到位的标志是：例会上不需要逐条追问背景，条目状态可以直接支撑排期判断，关闭记录经得起事后追溯。达到这个状态，清单就从记录工具变成了项目推进的工作台账。
常见问题
问题挂起后一直没人跟进，怎么处理？
挂起条目必须写明挂起原因、解除条件和复查日期，到期自动回到例会议程。清单维护人在例行检查中筛选复查日期已到的条目，逐条确认解除条件是否满足：满足则回到处理中，不满足则重新设定复查日期并说明原因。连续多次到期仍无进展的条目，应提交项目负责人判断是否需要升级或调整方案。
责任人离职或转岗，清单里的条目怎么交接？
责任人变更属于触发式更新，由原责任人移交、清单维护人确认。交接时至少完成三件事：新责任人确认接手并了解问题背景与已尝试的动作；目标解决日期重新确认，原日期不再成立的要写明调整原因；提出人知悉新的责任人。交接说明留在条目记录中，避免后续追溯时找不到责任链条。
目标解决日期经常被推迟，说明什么？
日期频繁推迟通常指向两个问题：一是登记时日期由单方拍定，未与责任人确认可行性；二是问题本身依赖外部条件，登记时未识别。处理方式是要求日期调整必须写明原因并经项目负责人确认，同时在检查表中统计推迟次数，推迟集中的条目重新评估解决路径，必要时转为挂起或升级。
清单条目很多时，例会上逐条过会不会太耗时？
条目多时可以分层处理：状态为处理中且日期未到的条目只做快速确认，重点讨论超期、挂起到期、待升级和本周新增的条目。清单维护人提前筛选出需要讨论的条目，例会上按筛选结果过，其余条目由责任人自行维护字段。这样既保证关键条目被检查，也控制会议时间。
项目结束后，问题清单还需要保留吗？
建议保留并做一次收尾整理：未关闭条目逐条说明处理结果或转入后续项目；已关闭条目保留关闭证据和验收记录，供复盘和审计追溯。复盘时可以从清单中提取反复出现的问题类型，作为改进项目计划、依赖管理和沟通机制的输入。
