项目问题台账要同时支撑责任落实、升级和关闭验证，字段设计应围绕这三条主线展开，而不是只记录问题描述。下面提供一份可直接复制到表格工具或文档中的空白台账，并逐项说明填写口径、必填规则，用一条演示问题示范字段如何联动。模板适用于项目推进中的障碍、风险和待决事项；产品Bug归缺陷管理，服务中断归服务事件流程，不在本模板范围内。
要点总览（TL;DR）
- 台账字段按“基本信息—责任落实—升级管理—关闭验证”四组排列，责任落实靠唯一责任人、责任角色、承诺完成日期和当前状态。
- 升级管理需要升级级别、触发条件、升级对象、升级时间和升级后决策五个字段，未升级时升级级别填L0，保证数据可统计。
- 关闭验证需要关闭类型、解决措施、验证人、验证日期、验证结论和遗留事项，验证人由非责任人担任。
- 最小必填集为问题编号、问题标题、唯一责任人、当前状态、升级级别和验证结论，其余字段按项目复杂度选填。
- 模板可直接复制到表格工具或文档使用，上线后按“必填不动、选填按需”裁剪，并与周会、周报共用同一份记录。
可复制空白项目问题台账模板
下表为空白模板，列顺序按“基本信息—责任落实—升级管理—关闭验证”排列。复制到Excel、在线表格或文档表格后，第一行保留为列名，从第二行开始逐条登记问题。示例行中的占位内容仅提示填写位置，正式使用时删除。
| 问题编号 | 问题标题 | 问题描述 | 发现日期 | 问题来源 | 影响范围 | 优先级 | 唯一责任人 | 责任角色 | 协同人 | 承诺完成日期 | 当前状态 | 升级级别 | 升级触发条件 | 升级对象 | 升级时间 | 升级后决策 | 关闭类型 | 解决措施 | 验证人 | 验证日期 | 验证结论 | 遗留事项 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ISSUE-001 | （一句话概括） | （现象、发生场景、期望结果） | YYYY-MM-DD | （会议/巡检/客户反馈等） | （受影响模块、交付物或干系人） | 高/中/低 | （姓名，仅一人） | （如开发负责人、采购负责人） | （姓名，可多人） | YYYY-MM-DD | 待处理/处理中/待验证/已关闭/挂起 | L0/L1/L2/L3 | （如超期3天未解决） | （升级接收人及角色） | YYYY-MM-DD HH:MM | （升级会议或决策结论） | 已解决/已规避/取消/转其他流程 | （实际采取的措施） | （验证人姓名） | YYYY-MM-DD | 通过/不通过/有条件通过 | （未完成事项及跟进人） |
复制时注意两点：一是“唯一责任人”每行只填一人，协同人放在单独列，避免责任分散；二是“升级级别”即使未升级也填L0，保持每行都有值，便于筛选和统计。
台账字段说明：每个字段记录什么、怎么填
同一份台账会被项目经理、责任人、验证人共同使用，字段口径必须统一。下表按四组字段说明含义、填写口径和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 问题编号 | 台账内唯一标识 | 项目前缀加流水号，如PRJ-ISSUE-012，登记后不再变更 | 重复编号、关闭后复用编号 |
| 问题标题 | 便于列表浏览的一句话概括 | 写清对象和障碍，如“支付接口联调环境缺失导致验收延期” | 只写“有问题”“待跟进” |
| 问题描述 | 现象、场景和期望结果 | 写清何时何地发生、影响什么、期望达到什么状态 | 把解决措施写进描述，混淆现状与方案 |
| 发现日期 | 问题被记录的时间 | 按实际发现日填写，补录时注明补录日期 | 填成计划解决日期 |
| 问题来源 | 问题被识别出的渠道 | 如周会、巡检、客户反馈、测试、审计 | 统一填“其他”，失去追溯价值 |
| 影响范围 | 受影响的模块、交付物或干系人 | 写具体对象，如“影响二期上线验收和财务对账” | 只写“影响很大” |
| 优先级 | 处理先后顺序 | 按影响程度和时间紧迫性定高/中/低，并在项目内统一标准 | 所有问题都标高 |
| 唯一责任人 | 对问题闭环负总责的人 | 填一人姓名，须具备协调资源的能力 | 填部门名、填多人、填“大家” |
| 责任角色 | 责任人在该问题中的职能身份 | 如开发负责人、采购负责人、业务接口人 | 与协同人角色混填 |
| 协同人 | 配合处理的相关人员 | 可多人，用逗号分隔，注明各自配合事项 | 把协同人当责任人使用 |
| 承诺完成日期 | 责任人承诺的解决时间 | 由责任人确认后填写，变更须留变更记录 | 由项目经理单方面指定 |
| 当前状态 | 问题所处阶段 | 从待处理、处理中、待验证、已关闭、挂起中选择 | 状态长期停在“处理中”不更新 |
| 升级级别 | 问题被升级到的层级 | L0未升级，L1项目内协调，L2跨部门，L3管理层决策 | 未升级留空，导致无法统计 |
| 升级触发条件 | 触发升级的具体情形 | 写可判断的条件，如“超过承诺日期3天未解决” | 写“情况严重时”，无法执行 |
| 升级对象 | 升级后接收并决策的人或角色 | 填具体姓名和角色，如“项目发起人张经理” | 只写“上级领导” |
| 升级时间 | 升级动作发生的时间 | 精确到日期和时刻，多次升级分行记录 | 升级后补填、时间倒挂 |
| 升级后决策 | 升级会议或沟通形成的结论 | 写决策内容、资源调整和新的完成时间 | 只写“已汇报”，无结论 |
| 关闭类型 | 问题结束的方式 | 已解决、已规避、取消、转其他流程，转出时注明去向 | 所有问题都填“已解决” |
| 解决措施 | 实际采取并生效的动作 | 写做了什么、由谁做、结果如何 | 抄写问题描述或计划而非实际措施 |
| 验证人 | 确认解决效果的人 | 由非责任人担任，通常为提出方或质量角色 | 责任人自己验证自己 |
| 验证日期 | 完成验证的时间 | 按实际验证日填写，须晚于或等于解决日期 | 提前填写计划验证日 |
| 验证结论 | 验证结果判断 | 通过、不通过、有条件通过；有条件通过须写清条件 | 只写“已处理” |
| 遗留事项 | 关闭时仍未完成的事项 | 写事项、跟进人和计划时间；无遗留填“无” | 留空，导致后续无人跟进 |
必填与选填：哪些字段不能空
台账字段并非越多越好。支撑责任、升级、关闭验证的最小必填集是：问题编号、问题标题、唯一责任人、当前状态、升级级别、验证结论。前四项保证问题有人负责且可追踪，升级级别保证升级情况可统计，验证结论保证关闭有依据。其余字段按项目复杂度和风险程度选填。
| 类别 | 字段 | 设置理由或适用场景 |
|---|---|---|
| 必填 | 问题编号、问题标题 | 保证每条问题可被唯一引用和检索 |
| 必填 | 唯一责任人 | 没有明确责任人，责任落实无从谈起 |
| 必填 | 当前状态 | 状态是流转和例会跟进的依据 |
| 必填 | 升级级别 | 未升级填L0，保证升级数据完整 |
| 必填 | 验证结论 | 关闭前必须由验证人给出结论 |
| 选填 | 问题描述、发现日期、问题来源、影响范围 | 小型项目可精简；跨部门或高风险项目建议填写 |
| 选填 | 优先级、责任角色、协同人、承诺完成日期 | 问题量大、需要排期时填写；简单事项可只留责任人 |
| 选填 | 升级触发条件、升级对象、升级时间、升级后决策 | 发生升级时必填，未升级可空 |
| 选填 | 关闭类型、解决措施、验证人、验证日期、遗留事项 | 进入关闭环节时填写；取消类问题可只填关闭类型和说明 |
必填字段缺失时应在登记或流转环节阻断，而不是事后补录。具体规则可以设为：新建问题时唯一责任人和标题为空则不允许保存；状态改为“待验证”前必须已有解决措施；状态改为“已关闭”前验证结论必须为通过或有条件通过，且验证人不能与责任人相同。升级级别在登记时默认L0，发生升级时由责任人更新并同步填写升级对象和升级时间。
填写示例：一条问题从登记到关闭验证
以下为演示情景，用于说明字段之间的联动，不代表真实项目案例。某系统集成项目在联调阶段发现第三方接口文档缺失，导致验收测试无法按计划开展。
| 字段 | 填写内容 |
|---|---|
| 问题编号 | PRJ-ISSUE-012 |
| 问题标题 | 第三方接口文档缺失导致验收测试延期 |
| 问题描述 | 联调阶段发现供应商未提供接口字段说明，测试团队无法构造用例，原定本周五的验收测试面临延期，期望供应商在三个工作日内补齐文档 |
| 发现日期 | 2025-03-10 |
| 问题来源 | 联调周会 |
| 影响范围 | 影响验收测试进度和二期上线时间 |
| 优先级 | 高 |
| 唯一责任人 | 李工（集成负责人） |
| 责任角色 | 集成负责人 |
| 协同人 | 王工（测试）、赵工（采购接口） |
| 承诺完成日期 | 2025-03-13 |
| 当前状态 | 处理中 |
| 升级级别 | L0 |
登记时李工确认承诺完成日期为3月13日，状态为处理中，升级级别先填L0。3月14日文档仍未到位，超过承诺日期一天，满足预设的“超期未解决即升级”条件。李工将升级级别改为L1，填写升级触发条件“超过承诺日期未解决”，升级对象为项目经理，升级时间为3月14日上午，升级后决策为“项目经理协调采购向供应商发正式催办函，新的完成日期定为3月17日”。
3月17日供应商补齐文档，李工填写解决措施“供应商补充接口字段说明，测试团队完成用例补充”，状态改为待验证。验证人由提出方王工担任，3月18日完成回归测试后填写验证结论“通过”，关闭类型“已解决”，验证日期3月18日。遗留事项填写“接口变更通知机制尚未建立，由赵工在下次供应商例会上提出”，跟进人明确后该问题关闭。整条记录中，责任人、承诺日期、升级记录和验证结论前后衔接，任何人都能据此还原处理过程。
台账调整与维护方法
台账上线后需要按项目规模裁剪字段，并建立固定的维护节奏，否则字段会逐渐空置或失真。裁剪时遵循“必填不动、选填按需”的原则：十人以内、周期短的项目可只保留必填字段加问题描述和承诺完成日期；跨部门、多供应商或高风险项目建议启用全部字段，尤其是影响范围、升级记录和遗留事项。
| 维护动作 | 节奏 | 责任人 | 完成标志 |
|---|---|---|---|
| 更新问题状态和承诺日期 | 每周例会前 | 各问题责任人 | 状态与实际进展一致，超期项已标注 |
| 检查升级记录完整性 | 每周例会中 | 项目经理 | 升级项均有升级对象、时间和决策 |
| 复核待验证和已关闭问题 | 每两周一次 | 验证人或质量角色 | 关闭项验证结论齐全，遗留事项有跟进人 |
| 裁剪或补充字段 | 项目阶段切换时 | 项目经理 | 字段与当前风险程度匹配，团队确认口径 |
台账应与会议和周报衔接：周会直接以台账中“处理中”和“超期”筛选结果作为议题，会上只更新状态、承诺日期和升级决策，不重复描述问题；周报中的问题数量和升级情况从台账统计生成，避免另建一套记录。关闭验证的复核可以由验证人在关闭后一周抽查，确认解决措施仍然有效、遗留事项有人跟进。
如果团队使用ONES承载问题台账，可以把上述字段配置为问题工作项的自定义属性，用状态流转对应待处理、处理中、待验证和已关闭，并在工作项中保留责任人和验证记录，使台账、会议跟进和关闭复核在同一处完成。具体字段配置方式以团队实际使用的产品版本为准。
常见问题
问题升级后，原来的承诺完成日期怎么处理？
升级后由升级对象给出新的完成时间，原承诺日期保留在记录中，不直接覆盖。可以在升级后决策字段里写清新日期和调整原因，例如“协调供应商后完成日期由3月13日调整为3月17日”。这样既能看到原承诺，也能追溯变更依据。如果台账列数有限，至少保证升级后决策中包含新日期，避免出现两个互相矛盾的完成时间。
验证结论为“有条件通过”时，问题能不能直接关闭？
可以关闭，但条件必须写清楚并落到遗留事项字段。建议在验证结论中写明通过的前提，例如“功能可用，但接口变更通知机制待建立”，同时在遗留事项中填写具体事项、跟进人和计划时间。若条件涉及上线安全或验收关键路径，状态先停在待验证，等条件满足后再改为已关闭。关闭后一周的抽查应优先检查这类问题。
小团队问题不多，能不能只保留必填字段？
可以。十人以内、周期短的项目保留问题编号、问题标题、唯一责任人、当前状态、升级级别和验证结论即可运转，再按需要加问题描述和承诺完成日期。需要注意两点：升级级别即使从未升级也要填L0，否则统计升级情况时会出现空值；验证结论在关闭前必须填写，不能因为字段少就跳过验证环节。项目进入跨部门协作阶段时，再补充影响范围、升级记录和遗留事项。
台账里的问题关闭后又被发现没解决，应该重新开一条还是改原记录？
建议在原记录上重新打开，把状态从已关闭改回处理中，并在解决措施中补充本次实际处理内容，验证结论改为不通过后重新验证。这样保留完整的处理历史，统计问题复发率时也有依据。如果问题性质已经变化、影响范围不同，可以新建一条并在问题描述中引用原编号。两种做法都要避免直接删除原记录，否则关闭验证的追溯链会断掉。
台账和缺陷管理、服务事件流程怎么划清边界？
本模板覆盖项目推进中的障碍、风险和待决事项，例如资源不到位、接口文档缺失、跨部门协调不畅。产品Bug进入缺陷管理流程，服务中断进入服务事件与问题管理流程，两者有各自的处理环节和验证标准。实际操作中，如果一条问题在处理过程中确认是产品缺陷，可以在关闭类型中选“转其他流程”，注明转入的缺陷编号，再在台账中关闭，避免同一件事在两处重复跟踪。
