问题状态改为已解决就算关闭吗：关闭判定标准与处理结果

把问题状态改为“已解决”并不等于关闭。它只代表处理人判断原因已消除，还需要补齐验证结论、影响处理确认和遗留事项登记，才能转为“已关闭”。本文给出四类关闭判定条件、从已解决到已关闭的操作步骤、角色分工和一个进度阻塞问题的完整示例，适用于项目推进障碍类问题的日常管理。

要点总览（TL;DR）

• “已解决”是处理人的单方声明，只说明原因已消除；“已关闭”需要验证、影响处理与遗留事项闭环三类结果同时具备。
• 关闭判定可对照四类条件：解决措施已实施、结果已验证、影响已处理、遗留事项已登记，每类都要有可查证据。
• 状态流转按“提交解决说明→验证人核对→确认影响→登记遗留事项后关闭”执行，验证不通过退回处理中。
• 处理人、验证人、提出人、问题负责人各产出对应记录，处理人与验证人应尽量分开。
• 关闭率统计只计入真正关闭的问题，把“已解决”计入会抬高指标、掩盖验证积压。

为什么“已解决”只是中间状态

“已解决”是处理人对自身工作的一个声明：我认为导致问题的原因已经消除。这个判断通常发生在处理动作完成的那一刻，此时结果还没有经过独立核对，受影响的一方也未必知道问题已经处理。把这一状态直接当作关闭，等于让处理人单方面决定问题是否结束，问题反复和记录失真的风险都由此产生。

“已关闭”则是一个经过多方确认的结论。它要求三类结果同时具备：结果经过验证，确认原因确实消除；影响已经处理，受影响的计划、交付物和相关方完成同步或调整；遗留事项完成闭环，预防措施、文档更新、观察期等后续工作已登记并有人负责。三类结果缺任何一类，问题都还停留在中间状态。

把两个状态分开设置，有三个直接好处。第一，问题在验证阶段重新出现时，可以直接退回处理中，不必先关闭再重开，状态历史保持清晰。第二，关闭判定有据可查，验证人、确认人和关闭时间都留在记录里，事后复盘或审计时能还原判断过程。第三，关闭率等统计口径不会被处理人的单方声明抬高，指标反映的是真正结束的问题数量。

需要说明的是，状态如何命名、分几级，应结合团队规模、问题类型和现有流程成熟度调整。小团队可以把验证与确认合并为一次核对，但“验证结果”和“影响确认”这两类信息仍应留下记录。

关闭判定标准：四类必须满足的处理结果

判断一个问题能否关闭，可以对照以下四类条件逐项检查。每类条件都对应具体的证据要求，证据缺失即视为未满足。

条件类别	判定要求	证据要求
解决措施已实施	针对原因采取的动作已经执行完毕	动作描述、责任人、实施时间可查；涉及外部协调的，附沟通或交付记录
结果已验证	由处理人以外的人核对，确认原因已消除	验证方式（复现测试、数据核对、现场确认等）、验证人、验证结论；结论需说明未复现或指标恢复的具体情况
影响已处理	受影响的计划、交付物、相关方已完成同步或调整	计划变更记录、交付物修订说明、相关方确认回复
遗留事项已登记	预防措施、文档更新、观察期等后续工作有明确归属	事项描述、跟进人、计划完成时间；观察期需写明观察指标和结束条件

四类条件之间是并列关系，不能互相替代。措施实施记录完整，不能代替验证结论；验证通过，也不能代替影响同步。实际执行中，影响已处理这一项最容易被忽略，因为处理人往往只关注原因本身，而受影响的计划调整可能涉及其他角色，需要单独确认。

验证结论的写法值得单独强调。“已验证”三个字信息量不足，应写明用什么方式验证、观察到什么结果。例如“按原触发条件连续执行三次，均未复现”“依赖方交付时间已恢复到计划节点，里程碑偏差归零”。这样的结论才能支撑关闭决定，也方便后续复查。

操作步骤：从已解决到已关闭怎么走

状态流转按以下五步执行，每步都明确输入、动作、输出和完成标志。步骤顺序可以按团队习惯微调，验证与影响确认也可以并行，但关闭动作必须放在最后。

第一步：提交解决说明并转为已解决

输入是问题记录，包括问题描述、原因分析和已采取的措施。处理人补充解决说明，写清原因、措施、实施时间和初步结果，附上实施证据，然后将状态改为“已解决”。完成标志是解决说明和证据已录入，状态已变更。此时问题进入待验证队列。

第二步：验证人核对结果

输入是解决说明与证据。验证人按说明中的触发条件复现或核对，判断原因是否确实消除，输出验证结论，写明验证方式、验证人和结论。完成标志是验证结论已记录，结论为通过或不通过。验证人应与处理人分离，至少不能由处理人自己确认。

第三步：确认影响已处理

输入是问题影响范围说明。提出人或问题负责人核对受影响的计划、交付物和相关方是否已同步或调整，输出确认记录。完成标志是确认记录已录入，影响范围内的调整有据可查。若影响涉及多个相关方，确认记录应体现各方反馈。

第四步：登记遗留事项并转为已关闭

输入是验证结论和影响确认记录。问题负责人登记预防措施、文档更新、观察期等遗留事项，明确跟进人和计划完成时间，然后将状态改为“已关闭”。完成标志是关闭记录生成，遗留事项进入跟踪列表。遗留事项可以独立于问题继续跟踪，不因问题关闭而消失。

第五步：验证不通过时退回处理中

验证结论为不通过时，问题退回“处理中”，验证人写明未通过的具体表现，处理人据此重新分析原因或补充措施。退回记录保留在原问题下，形成完整的处理历史。退回不是异常情况，而是验证环节发挥作用的正常结果。

角色与交付物分工

关闭判定涉及四个基本角色，各自产出不同的记录。分工清楚，验证与确认才不会落空。

角色	主要动作	交付物
处理人	分析原因、实施措施、提交解决说明	解决说明、实施证据（动作、时间、责任人）
验证人	按触发条件复现或核对结果	验证方式、验证结论、验证人署名
提出人	反馈问题是否解决、影响是否消除	结果确认、影响反馈
问题负责人	做关闭决定、登记并跟踪遗留事项	关闭记录、遗留事项清单与跟进状态
质量或项目管理人员（可选）	抽查关闭质量，核对证据完整性	抽查记录、不符合项及整改要求

角色可以由同一人兼任，但处理人与验证人应尽量分开。提出人确认这一步在问题影响范围较小时可以简化为一次书面回复，影响涉及交付节点或外部相关方时，应保留明确的确认记录。质量或项目管理人员的抽查适合问题数量较多、关闭频率较高的团队，抽查比例和频次按团队实际情况确定。

这些记录需要有一个统一的承载位置，否则验证结论散落在聊天记录里，关闭判定就难以复查。在 ONES 中，问题可以作为工作项管理，状态流转、解决说明、验证结论和关闭记录都留存在同一条工作项下，处理人、验证人和问题负责人的操作各有记录，遗留事项可以转为后续工作项继续跟踪。团队可以按自身流程配置状态与字段，把上述四类条件对应到具体字段上，使关闭前的核对有据可依。

示例：一个进度阻塞问题如何判定关闭

以下为演示情景，用于说明四类条件如何落地，不代表真实项目数据。

情景：某版本迭代中，一个关键模块依赖外部团队提供的接口，外部交付延迟两周，导致联调里程碑受阻。问题由联调负责人提出，状态为“处理中”。

已解决时的记录：处理人协调外部团队增加人力，接口于约定日期交付，本地联调环境完成对接。解决说明写明：原因是对外部交付节奏缺少提前确认；措施是与外部团队约定每周两次进度同步，并提前锁定交付日期；实施时间为某月某日；附外部团队的交付确认邮件。状态改为“已解决”。

验证与影响处理：验证人按原联调用例执行一轮完整联调，接口调用全部通过，结论为“原因已消除，未复现阻塞”。联调负责人确认里程碑计划已顺延并同步给项目组，受影响的测试排期完成调整，相关方在计划变更记录中回复确认。

遗留事项与关闭记录：问题负责人登记两项遗留事项：一是将外部依赖的交付确认纳入迭代启动检查，跟进人为项目经理，计划在下个迭代启动前完成；二是观察后续两个迭代的外部交付准时情况，观察期结束后由处理人反馈。随后状态改为“已关闭”，关闭记录中关联验证结论、影响确认和遗留事项清单。

若验证未通过：假设联调中仍有个别接口超时，验证人记录未通过的具体接口和现象，问题退回“处理中”。处理人重新分析原因，补充措施后再次提交解决说明，流程从验证环节重新走一遍。

完成检查：关闭前逐项核对

关闭操作前，按以下清单逐项核对。任何一项不满足，都应暂缓关闭。

• 解决说明完整：原因、措施、责任人、实施时间齐全，证据可查。
• 验证结论明确：写明验证方式、验证人和具体结果，结论为通过。
• 影响已确认：受影响的计划、交付物、相关方完成同步或调整，有确认记录。
• 遗留事项已登记：每项有描述、跟进人和计划完成时间。
• 记录完整：状态变更历史、各角色操作记录可追溯，无缺失环节。

阻断项包括：验证人缺失或由处理人自行验证；验证结论只有“已解决”字样而无具体结果；影响范围未确认即关闭；遗留事项无跟进人。出现任一阻断项，问题应保持“已解决”状态，待补齐后再关闭。

关闭后仍需保留复查机制。观察期内同类问题再次出现，或遗留事项到期未完成，应重新打开问题或新建关联问题，并在原记录中注明重开原因。重开条件建议提前约定，例如同一触发条件下再次发生、观察指标超出阈值。

使用关闭率统计时，口径应只计入真正关闭的问题。“已解决”状态的问题仍在处理链条中，计入关闭会抬高指标、掩盖验证环节的积压。统计页面或报表中应明确状态口径，并在团队内保持一致，避免不同项目各用一套算法导致数据不可比。

常见问题

小团队人手少，验证人必须由处理人以外的人担任吗？

建议尽量分开，但不要求一定由独立岗位承担。可以由同组另一位成员、提出人或问题负责人兼任验证人，关键是验证动作与处理动作由不同的人完成，并在记录中写明验证人和验证方式。如果确实只能由处理人自行核对，应在关闭记录中注明这一限制，并在后续抽查中优先检查此类问题。

问题关闭后观察期内又出现同类现象，应该重开原问题还是新建问题？

取决于现象与原问题的关系。若触发条件、影响对象与原问题一致，说明原解决措施未真正消除原因，应重开原问题并注明重开原因，保留完整处理历史。若现象出现在不同模块或由不同原因引起，新建问题并在记录中关联原问题更合适。团队可以提前约定重开条件，例如同一触发条件下再次发生、观察指标超出阈值。

影响已处理这一项，什么情况下可以简化确认？

影响范围仅限处理人自身工作、不涉及交付节点和其他相关方时，可以由提出人一次书面回复确认结果，不必走多方会签。影响涉及里程碑、对外交付或多个团队排期时，应保留计划变更记录和相关方确认回复。简化的只是确认形式，影响是否已同步这一判断本身不能省略。

遗留事项还没完成，问题能不能先关闭？

可以。遗留事项与问题本身是两条跟踪线，问题关闭的条件是四类处理结果已具备，遗留事项只需完成登记——有描述、有跟进人、有计划完成时间——即可随问题关闭转入后续跟踪。遗留事项到期未完成时，按约定重新打开问题或新建关联问题，并在原记录中说明。

用关闭率考核团队时要注意什么？

先统一状态口径，只把“已关闭”计入分子，“已解决”仍属于处理链条中的在办问题。其次要区分问题类型和提出时间，避免把不同复杂度的问题放在同一口径下比较。关闭率适合观察验证环节是否积压，不宜单独作为处理人的绩效指标，否则容易促使处理人跳过验证直接关闭。