项目问题解决可以按一条闭环流程执行：先把推进障碍登记为问题条目，写清现象、影响、期望结果和责任人；再做原因分析并确定处置方案；随后按方案执行、跟踪验证，确认障碍消除后关闭并沉淀经验。本文面向项目负责人和项目经理，覆盖项目推进障碍类问题；产品缺陷走缺陷管理，线上服务中断走服务事件与问题管理，不纳入本文流程。文中会以ONES作为承载问题记录与状态流转的协作工具举例说明。
要点总览（TL;DR）
- 项目问题解决按六步闭环执行：登记、分级与分派、原因分析、方案与计划、执行与跟踪、验证与关闭，每一步都有明确的输入、动作、输出和完成标志。
- 纳入范围是影响项目目标、进度、质量或交付的推进障碍；产品缺陷走缺陷管理，线上服务中断走服务事件与问题管理，混入事项只保留关联信息。
- 责任要落到具体角色：问题提出人负责描述，问题负责人统筹分析与推动，处置人执行，验证人独立确认，项目负责人确认分级并裁决升级事项。
- 关闭前由验证人用证据确认障碍消除，关闭记录写明处置结果和可复用经验，经验要具体到可操作的动作。
- 流程是否有效，按月或按里程碑检查字段完整性、状态准确性、超期升级、关闭证据、复盘沉淀和范围纪律六项。
先划清范围：哪些事项算项目问题
项目问题指影响项目目标、进度、质量或交付的推进障碍。判断一条事项是否纳入项目问题流程，可以问三个问题：它是否阻碍了当前项目某个交付物或里程碑？它是否需要项目层面协调资源、依赖或决策才能解决？它的解决结果是否需要向项目干系人交代？三个问题都答“是”，就应登记为项目问题。
边界划分的关键在于问题归属的管理流程不同。产品缺陷有独立的缺陷管理流程，关注复现步骤、严重程度、修复版本和回归验证；线上服务中断属于服务事件与问题管理，关注服务恢复、影响范围和根因消除。这两类事项即使由项目团队发现，也应转入对应流程处理，项目问题记录中只保留指向该流程的关联信息，避免同一事项在两套流程中重复跟踪、状态互相矛盾。
常见误纳入事项及处理去向如下：
| 事项 | 是否纳入项目问题 | 处理去向 |
|---|---|---|
| 关键接口联调因第三方排期推迟，影响集成测试开始时间 | 纳入 | 项目问题流程 |
| 某功能在测试环境出现崩溃，需修复后重新提测 | 不纳入 | 缺陷管理 |
| 生产环境服务中断，用户无法访问 | 不纳入 | 服务事件与问题管理 |
| 核心开发人员被临时抽调，迭代人力不足 | 纳入 | 项目问题流程 |
| 需求范围在评审后反复变更，影响排期 | 纳入 | 项目问题流程，涉及决策升级 |
| 文档中一处措辞不准确 | 不纳入 | 直接修改，无需立问题 |
判定口径确定后，应写入项目启动材料或团队工作约定，让提出人在登记前先做一次归属判断。口径本身也需要随项目阶段调整，例如进入上线保障期后，部分稳定性事项可能更适合走服务事件流程。
核心步骤：从登记到关闭的六步操作
六步流程的价值在于每一步都有明确的输入、动作、输出和完成标志，问题不会停在“已反馈”或“在处理”这类模糊状态。下表给出可直接对照执行的操作框架，表后对关键动作做补充说明。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 登记 | 发现人观察到的现象、影响信息 | 填写现象、影响范围、期望结果、提出人、时间要求 | 一条待分级的问题记录 | 字段完整，提出人确认描述准确 |
| 2. 分级与分派 | 问题记录 | 按影响和紧急度定级，指定问题负责人 | 带级别和负责人的问题条目 | 负责人接受分派，级别经项目负责人确认 |
| 3. 原因分析 | 问题现象与相关事实 | 区分技术、资源、依赖、决策等成因，找到可干预的根因 | 原因分析结论 | 结论能解释现象，并指向可执行的处置方向 |
| 4. 方案与计划 | 原因分析结论 | 确定处置动作、责任人、时间点，必要时准备备选方案 | 处置计划 | 动作、责任人、时间点三项齐全并经确认 |
| 5. 执行与跟踪 | 处置计划 | 按计划推进，更新状态，上报阻塞，协调跨团队事项 | 状态更新记录与协调结论 | 计划动作全部完成或已按变更流程调整 |
| 6. 验证与关闭 | 执行结果 | 确认障碍消除，记录结论与经验，关闭问题 | 关闭记录与经验条目 | 验证人确认影响消除，关闭结论有证据支撑 |
登记：把现象写清楚
登记质量决定后续效率。现象要写可观察的事实，例如“集成测试环境缺少第三方账号，联调用例无法执行”，避免写“联调不顺利”这类判断。影响范围写清受影响的交付物、里程碑和时间窗口；期望结果写清障碍消除后应达到的状态；时间要求说明最晚解决时点及其依据。提出人信息用于后续澄清，不能省略。
分级与分派：让责任落到一个人
分级通常综合影响面和紧急度：影响关键路径且临近里程碑的定为高优先级，影响非关键路径且有替代方案的定为常规优先级。级别决定跟踪频率和升级门槛。分派时指定一名问题负责人，由他统筹分析和协调，而不是把问题同时丢给多个团队。负责人接受分派是这一步的完成标志。
原因分析：区分四类成因
技术成因指方案或实现层面的障碍；资源成因指人力、环境、预算不足；依赖成因指外部团队或第三方的排期与交付；决策成因指需求、范围或优先级尚未拍板。四类成因的处置路径不同：技术问题靠方案调整，资源问题靠调配或缩减范围，依赖问题靠协调与备选安排，决策问题靠升级到有权限的人。分析结论要能解释现象，否则继续收集事实。
方案与计划：动作要可执行
处置计划至少包含做什么、谁来做、什么时候完成。涉及外部依赖的，补充备选方案和触发条件，例如“若第三方周五前未提供账号，改用模拟数据先行验证”。计划确定后同步给受影响的相关方，避免执行阶段才发现资源冲突。
执行与跟踪：状态要真实
执行期间按约定频率更新状态，状态变化对应实际进展而非主观意愿。遇到阻塞立即上报问题负责人，由其判断是调整计划还是升级。跨团队协调的结论要回写到问题记录中，让后来查看的人能还原决策过程。
验证与关闭：用证据说话
关闭前由验证人确认障碍确实消除，例如联调用例已执行通过、人力已补充到位、范围变更已获批准。关闭记录写明处置结果、验证方式和可复用经验。经验条目应具体到可操作，例如“外部账号类依赖在项目启动阶段统一申请”，而非“加强前期沟通”。
角色与交付物：谁负责哪一段
流程跑不动，常见原因是责任悬空：问题有人提、没人管，或者多人都在管、无人拍板。下表按角色列出职责、关键交付物和交接时点，项目可根据规模合并角色，但合并后仍需明确谁承担对应交付物。
| 角色 | 主要职责 | 关键交付物 | 交接时点 |
|---|---|---|---|
| 问题提出人 | 描述现象与影响，配合澄清 | 完整的问题登记信息 | 登记完成并确认描述准确后交接给问题负责人 |
| 问题负责人 | 统筹分析、制定计划、推动执行、组织验证 | 原因分析结论、处置计划、关闭记录 | 计划确定后交接给处置人执行；验证阶段交接给验证人 |
| 处置人 | 按计划完成具体处置动作 | 执行结果与状态更新 | 动作完成后交回问题负责人组织验证 |
| 验证人 | 独立确认障碍消除 | 验证结论与证据 | 验证通过后由问题负责人关闭 |
| 项目负责人 | 确认分级、裁决升级事项、调配资源 | 分级确认、升级决策 | 在高优先级问题定级和升级节点介入 |
升级路径应与分级挂钩：常规问题在约定跟踪周期内未推进，由问题负责人上报项目负责人；高优先级问题在影响里程碑前的规定时点仍未解决，直接进入项目例会议程，由项目负责人协调资源或调整计划。涉及范围、预算和优先级变更的决策，权限在项目负责人及其上级，问题负责人负责准备决策所需的事实和备选方案，不代替决策。
在协作工具中承载这套分工时，可以把问题登记为工作项，用负责人字段对应问题负责人，用状态字段反映从登记到关闭的流转，用关联字段挂接处置任务和验证记录。ONES的项目工作项与状态流转可以支持这种记录方式，让分级、分派和关闭留下可追溯的字段变化，周会检查时直接按状态和超期筛选即可。
示例：一个进度受阻问题如何走完流程
以下为演示情景，用于说明各步骤的填写方式，不代表真实项目数据。
背景与登记。某系统集成项目计划两周后开始端到端联调，负责提供测试账号的外部团队因内部排期调整，告知账号交付推迟三周。项目经理登记问题：现象为“第三方测试账号交付推迟三周，端到端联调无法按计划开始”；影响范围为联调阶段及后续验收里程碑；期望结果为“联调按原计划启动或确认可接受的替代方案”；时间要求为“一周内明确结论”；提出人为项目经理。
分级与分派。该事项影响关键路径且临近里程碑，定为高优先级，指定集成负责人为问题负责人。集成负责人接受分派，开始收集事实。
原因分析。与外部团队沟通后确认，成因属于依赖类：对方账号审批流程增加了一个环节，排期顺延。技术层面无替代账号可用，但部分联调用例可用模拟数据先行验证。结论指向两条处置方向：推动对方加急审批，同时准备模拟数据方案。
方案与计划。处置计划包含三项动作：集成负责人当日向对方接口人提交加急申请并约定反馈时点；测试负责人三天内完成模拟数据准备，覆盖可替代的用例范围；项目经理在周会上向项目负责人同步风险。每项动作明确责任人和完成时间，备选方案的触发条件为“对方三日内未给出明确交付日期”。
执行与跟踪。加急申请在第二天获得对方确认，交付日期提前至原计划前一周；模拟数据按期准备完成，作为兜底保留。执行期间问题状态从“分析中”更新为“处置中”，再更新为“待验证”，每次更新附上事实说明。
验证与关闭。账号按期交付，联调按原计划启动，验证人确认联调用例执行通过。问题负责人关闭问题，记录结论“依赖类问题通过加急协调加备选方案双线推进解决”，沉淀经验“外部账号类依赖在项目启动阶段统一申请并预留审批缓冲”。整个过程中，提出人、问题负责人、处置人和验证人之间的交接都记录在问题条目中，周会检查时可直接查看状态与超期情况。
完成检查：流程是否真正跑通
流程建立后，需要定期检查它是否在有效运行。以下清单可按月或按里程碑逐项核对，每项都给出可核验的判断依据。
- 字段完整性：抽查近期问题记录，现象、影响范围、期望结果、提出人、时间要求、负责人、级别是否齐全；缺失字段是否集中在某类提出人或某个阶段。
- 状态准确性：对比问题记录状态与实际进展，是否存在长期停留在“处置中”却无更新记录的问题；状态变更是否附有事实说明。
- 超期与升级：统计超过约定时点未解决的问题数量及占比，检查这些问题是按升级路径处理，还是被搁置；高优先级问题的升级是否在影响里程碑前发生。
- 关闭证据：抽查已关闭问题，验证结论是否有可核对的证据，例如测试通过记录、资源到位确认、决策批复；是否存在无验证人确认即关闭的情况。
- 复盘与沉淀：检查关闭记录中是否包含可复用经验，经验是否具体到可操作；同类问题是否重复出现，重复出现说明经验未转化为流程改进。
- 范围纪律：抽查问题记录中是否混入了缺陷或服务事件，混入事项是否已转入对应流程并保留关联信息。
检查结果应回到项目例会上讨论，对反复出现的字段缺失、超期搁置或重复问题，调整登记模板、跟踪频率或升级门槛。流程的有效性最终体现在：问题能被及时登记、责任清晰、按计划推进、关闭有据，并且同类障碍越来越少。
常见问题
问题登记后一直没人推进，通常卡在哪个环节？
最常见的原因是分级与分派没有真正完成：问题记录建了，但没有指定唯一的问题负责人，或者负责人没有明确接受分派。此时问题处于“已反馈”状态，却没有人对分析和协调负责。
处理办法是把“负责人接受分派”作为该步骤的完成标志，未接受就不算分派完成。同时约定跟踪周期，常规问题在周期内无进展由问题负责人上报项目负责人，高优先级问题在影响里程碑前的规定时点直接进入项目例会议程。
同一个事项既影响项目进度又涉及产品缺陷，应该走哪套流程？
以事项的主要管理对象判断归属。缺陷本身按缺陷管理流程跟踪复现、修复和回归；如果该缺陷同时造成项目里程碑受阻，可以在项目问题记录中登记“里程碑受阻”这一推进障碍，并关联对应的缺陷条目，由问题负责人推动协调，缺陷的修复状态仍在缺陷流程中维护。
关键是同一事实只在一套流程中作为主记录，另一套流程保留关联引用，避免两边状态互相矛盾。
小团队人手少，角色可以合并吗？
可以合并，但要保留对应交付物。例如问题提出人同时担任问题负责人，处置人也可能由同一人承担，此时仍需在记录中写清原因分析结论、处置计划和验证证据。
验证环节建议尽量由未直接执行处置的人确认，至少做到用可核对的事实判断障碍是否消除，例如测试执行记录、资源到位确认或决策批复，避免执行人自行判断“已解决”。
问题关闭后，经验沉淀怎么做才不会流于形式？
经验条目要写成可操作的动作，并说明适用条件。例如“外部账号类依赖在项目启动阶段统一申请并预留审批缓冲”，比“加强前期沟通”更容易被下一次项目直接采用。
沉淀之后还要看效果：在月度或里程碑检查中统计同类问题是否重复出现。重复出现说明经验没有转化为登记模板、检查项或流程节点的调整，应回到项目例会上讨论具体改哪一处。
流程运行一段时间后，检查发现大量问题长期停在“处置中”，该怎么调整？
先区分两类情况：一类是处置动作确实在推进但状态未更新，属于状态维护问题，应要求状态变更附事实说明并按约定频率更新；另一类是处置动作本身停滞，属于计划或资源问题，需要问题负责人判断是调整计划、补充资源还是升级。
如果停滞集中在某一类成因，例如外部依赖，可以针对性调整流程，例如在项目启动阶段统一梳理外部依赖并预留缓冲，或为这类问题设置更早的升级门槛。
