项目问题管理的关键，是把影响项目推进的障碍集中登记、指定负责人、设定解决期限，并在例会上持续跟踪，直到验证关闭。本文按“管什么—怎么做—谁负责—示例—工具承载—上线检查”的顺序，给出可直接落地的流程、角色表和检查清单；文中会提及ONES作为问题清单的承载工具，范围限于项目推进障碍，产品Bug和线上服务中断另按各自流程处理。
要点总览（TL;DR）
- 项目问题清单只收纳已经发生、影响项目目标或交付、需要跨角色协调的障碍；产品Bug走缺陷管理，线上服务中断走服务事件与问题管理。
- 五步流程为登记、分级、分派与承诺、跟踪与升级、关闭与复盘，每一步都要有输入、动作、输出和完成标志，避免问题停在登记环节。
- 问题提出人、问题负责人、项目经理和升级决策者各自承担明确职责；负责人缺位时由项目经理指定临时负责人并记录交接时点。
- 升级触发条件建议写清三类：超过承诺期限、影响里程碑或对外承诺、跨部门协调连续两次例会无进展。
- 机制上线前逐项核对字段与分级规则、角色落实、升级路径知晓、例会节奏和关闭标准，全部通过再宣布运行。
项目问题管理先定边界：哪些事项进入问题清单
项目问题清单只收纳一类事项：已经发生、正在阻碍项目目标、进度、范围或交付的事项。判断时问三个问题：它是否已经发生而非可能发生；它是否影响项目承诺的交付结果；它是否需要跨角色协调才能解决。三个问题都答“是”，就应登记为项目问题。
纳入与排除需要同时写清，否则清单很快会变成杂物箱。建议在团队内约定如下规则：
| 事项类型 | 是否进入项目问题清单 | 判定说明 |
|---|---|---|
| 需求方迟迟未确认验收口径，导致测试无法收尾 | 纳入 | 已发生，影响交付节点，需跨角色协调 |
| 关键供应商交付物质量不达标，需返工 | 纳入 | 已发生，影响进度与范围 |
| 产品功能不符合预期，需要修复 | 不纳入 | 归缺陷管理，按缺陷流程跟踪 |
| 线上服务中断或性能劣化 | 不纳入 | 归服务事件与问题管理，按事件流程处理 |
| 下季度可能出现的资源紧张 | 不纳入 | 属于风险，进入风险登记册 |
| 已排期的开发任务 | 不纳入 | 属于任务，按计划执行 |
| 范围调整申请 | 不纳入 | 属于变更，走变更评审 |
问题与风险的区别在于是否已经发生：风险是尚未发生的不确定事件，问题是已经发生并造成阻碍的事实。问题与任务的区别在于是否偏离计划：任务按计划执行即可，问题需要额外决策或协调才能消除。问题与变更的区别在于是否改变基线：变更改变范围、进度或成本基线，问题则是基线内需要清除的障碍。一个事项如果同时具备多重属性，按主要处理路径归口，并在记录中注明关联条目，避免重复跟踪。
问题清单的最小字段建议包含十项：问题描述、提出人、提出时间、影响范围、影响程度、问题负责人、承诺解决期限、当前状态、升级记录、关闭验证证据。字段少而稳定，才能保证登记成本低、后续可统计。影响程度可采用“高、中、低”三档，并写明每档的判定口径，例如“高”指影响里程碑或对外承诺，“中”指影响单个迭代内交付，“低”指影响局部效率但可通过调整消化。
从登记到关闭：项目问题管理的五步操作流程
五步流程的价值在于每一步都有明确的输入、动作、输出和完成标志，流程不会停在“已登记”就无人推进。
第一步：登记
输入是发现障碍的事实描述。任何项目成员都可以提出问题，提出人负责写清现象、发生时间、影响的对象和已尝试的动作。动作是填写最小字段并提交到统一问题清单。输出是一条状态为“待分级”的问题记录。完成标志是记录具备问题描述、提出人和影响范围三项信息，可以进入分级。
第二步：分级
输入是待分级的问题记录。项目经理或指定的分级责任人在一个工作日内按影响程度和紧急度确定优先级，并标注是否需要升级处理。输出是带有影响程度和优先级的问题记录。完成标志是每条问题都有明确档位，且高影响问题已通知相关干系人。
第三步：分派与承诺
输入是已分级的问题。动作是为每条问题指定一名问题负责人，由负责人给出解决思路和承诺解决期限；涉及跨部门的，由项目经理确认协调资源。输出是负责人、解决期限和下一步动作均已填写的问题记录。完成标志是负责人确认接受，期限落在项目可接受的范围内。
第四步：跟踪与升级
输入是处理中的问题清单。动作是在固定例会上逐条过问高影响和临近期限的问题，更新进展；触发升级条件时，按事先约定的路径提交给升级决策者。升级触发条件建议写清三类：超过承诺期限未解决、影响里程碑或对外承诺、跨部门协调连续两次例会无进展。输出是更新后的状态、进展说明和升级记录。完成标志是每条在办问题都有本周进展，触发条件的问题已完成升级并得到决策。
第五步：关闭与复盘
输入是声称已解决的问题。动作是由提出人或指定验证人确认解决结果，核对是否消除原有影响，并留存验证证据；随后在例会上确认关闭。输出是状态为“已关闭”且附有验证证据的记录。完成标志是验证人确认、证据可查、相关方知悉。仅把状态改为已关闭不构成闭环。复盘按季度或里程碑节点进行，统计问题数量、平均解决时长、升级比例和高频问题类型，用于调整流程而非追责。
角色与交付物：谁负责推动问题闭环
问题管理失效最常见的原因是责任悬空：有人提出问题，没有人认领解决。把角色和交付物固定下来，可以让每条问题在每一步都有明确的责任人。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 问题提出人 | 描述现象与影响，提供必要信息，参与关闭验证 | 问题记录初稿、验证结论 | 登记时提交；关闭前验证 |
| 问题负责人 | 制定解决方案，推动执行，按期更新进展 | 解决计划、进展更新、解决结果 | 接受分派时确认；每次例会前更新 |
| 项目经理 | 维护清单完整性，组织分级与例会，协调资源，指定兜底负责人 | 分级结论、例会纪要、升级提请 | 分级时；例会时；触发升级时 |
| 升级决策者 | 对超出项目组权限的问题作出决策或调配资源 | 决策结论、资源安排 | 收到升级提请后约定时限内 |
问题负责人缺位时，由项目经理在例会上指定临时负责人，并在记录中写明交接时点和原负责人回归后的交接安排。临时负责人承担推动职责，不改变问题的最终归属。若问题负责人连续两次例会未更新进展，项目经理应主动确认其是否仍适合承担该问题，必要时重新分派。
升级决策者通常是项目发起人或相关职能负责人，其职责是解决项目组权限之外的障碍，例如跨部门资源调配或优先级冲突裁决。升级不是告状，而是把决策权交给有权限的人，因此升级提请应附带问题影响、已尝试的动作和需要决策的具体事项。
一个跨部门延期问题的处理示例
以下为演示情景，用于说明字段填写与升级路径，不代表真实项目案例。
背景：某系统集成项目进入联调阶段，外部合作方负责的接口迟迟未按约定提供，导致联调窗口推迟，月度里程碑面临延期。
登记内容：问题描述为“合作方接口未按约定时间提供，联调无法启动，影响月度里程碑”；提出人为联调负责人；提出时间为联调计划启动当日；影响范围为联调阶段及后续验收；影响程度为“高”；初始状态为“待分级”。
分级与分派：项目经理当日判定为高影响，指定接口对接人为问题负责人，承诺解决期限为三个工作日，解决思路为“当日联系合作方确认交付时间，同步准备替代联调方案”。
升级过程：第一个例会时，合作方仅口头答复未给出明确时间，问题负责人更新进展并标记“协调无进展”。第二个例会仍无明确交付时间，触发“跨部门协调连续两次例会无进展”的升级条件，项目经理向项目发起人提请升级，附问题影响、已尝试动作和需要决策的事项。发起人协调后确定合作方交付日期，并批准在等待期间先执行替代联调方案。
关闭验证：合作方接口交付并完成联调后，由联调负责人验证接口功能与联调结果，附上联调记录和里程碑调整确认，问题负责人在例会上说明解决结果，项目经理确认后关闭。记录中保留升级记录、决策结论和验证证据，供后续复盘引用。
用工具承载问题闭环：清单、状态与例会视图
机制确定后，需要一个稳定的承载方式，让清单、状态和例会视图保持一致。工具配置的要点可以归纳为四项。
第一，把问题作为统一的工作项类型管理。问题与任务、缺陷分属不同类型，各自有独立字段和视图，避免混在一起统计。第二，状态流转与流程节点对应。建议设置“待分级—处理中—待验证—已关闭”四个状态，负责人字段在分派后必填，状态变更时记录变更时间，便于计算解决时长。第三，例会视图按分级和超期筛选。例会前生成高影响问题和超期问题的视图，会上逐条过问，升级记录作为字段保留在问题详情中。第四，记录留存与复盘取数。关闭验证证据、升级记录和决策结论随问题记录保存，复盘时按问题类型、影响程度和解决时长统计。
ONES可以承载上述组织方式：将问题配置为独立工作项类型，用状态字段对应流程节点，用负责人和期限字段支撑分派与跟踪，并通过视图按影响程度和超期条件筛选，供例会使用。具体字段配置和视图设置需结合团队现有项目空间调整，以实际产品能力为准。
上线前的完成检查：问题管理机制是否可运行
机制设计完成后，用以下清单逐项核对，全部通过再宣布上线运行。
- 字段与分级规则已明确：最小字段齐全，影响程度各档有书面判定口径，团队能举出例子说明如何分级。
- 角色已落实到人：问题负责人、分级责任人、升级决策者均有具体人员，兜底安排已写入规则。
- 升级路径已被团队知晓：升级触发条件、提请方式和决策时限在团队内公布，新成员入职时可获取。
- 例会节奏已固定：问题过问纳入固定例会，会议频率、时长和议程明确，例会前视图可自动生成。
- 关闭标准与记录可查：关闭需验证证据，记录可追溯，复盘取数方式已确定。
- 边界规则已沟通：团队清楚产品Bug和服务中断不进入项目问题清单，并知道应走哪条流程。
检查中发现缺项，优先补齐角色和升级路径，这两项决定问题能否被推动；字段和视图可以随运行逐步优化。机制上线后第一个月，建议每周检查一次清单中是否存在长期未更新的问题，及时纠正登记和跟踪习惯。
常见问题
项目问题清单和风险登记册需要分开维护吗？
建议分开维护，但保留关联。风险记录的是尚未发生的不确定事件，问题记录的是已经发生并造成阻碍的事实。一个风险一旦发生并影响项目推进，就应转为问题登记，并在问题记录中注明来源风险编号，便于复盘时看清风险应对是否有效。两套记录可以放在同一个协作空间里，用不同工作项类型区分，避免混在一起统计。
问题负责人不配合更新进展，项目经理可以怎么做？
先确认原因：是负责人对问题归属有异议，还是缺少解决资源。若归属有异议，在例会上重新确认责任边界并记录结论；若缺少资源，按升级路径提请决策者协调。若负责人连续两次例会未更新进展，项目经理应主动确认其是否仍适合承担该问题，必要时重新分派，并在记录中写明交接时点和原负责人的后续配合事项。
小团队也需要完整的五步流程和十项字段吗？
可以简化，但几个关键要素建议保留：问题描述、负责人、承诺期限、当前状态和关闭验证。分级可以只分高、低两档，例会可以并入现有的周会。简化的是字段数量和会议形式，保留的是“有人认领、有期限、有验证”这条闭环。团队规模扩大或问题数量上升后，再补充升级记录和复盘统计字段。
问题关闭后还需要做什么？
关闭后进入复盘取数环节。按季度或里程碑节点统计问题数量、平均解决时长、升级比例和高频问题类型，用于调整流程和资源配置。复盘关注的是流程改进，例如某类问题反复出现，说明前端环节需要加强；升级比例过高，说明授权或资源安排需要调整。复盘结论应形成具体动作，而不是停留在问题数量统计上。
问题管理机制上线后，怎么判断它真的在运行？
看三个可观察的信号：清单中的问题是否持续有新增和关闭，而不是长期积压；例会是否按固定节奏过问高影响和超期问题，并有进展更新记录；触发升级条件的问题是否在约定时限内得到决策。上线第一个月建议每周检查一次长期未更新的问题，及时纠正登记和跟踪习惯。若清单长期没有新增，需要确认是团队没有障碍，还是成员不敢或不愿提出问题。
