缺陷责任人并不是“接单的人”，而是缺陷受理决策的归口角色：判断缺陷是否成立、定级定责、指派处理人，并对受理结论负责。本文围绕这一职责，梳理缺陷责任人与提交人、测试、开发、产品、验收角色的分工，给出分诊会议与指派流程的操作步骤、一个端到端示例，以及机制上线后的检查清单。文中方法可按团队缺陷量与发布节奏调整，不构成统一强制要求。
要点总览（TL;DR）
- 缺陷责任人是缺陷受理决策的归口角色，负责成立判断、定级、定责、指派并记录受理结论；状态流转规则与根因分析分别归其他环节。
- 分工按“谁提供输入、谁做决策、谁执行、谁验收”划分：提交人补全复现信息，测试负责人参与定级，开发负责人承接修复，产品负责人裁定业务优先级，验收角色独立确认关闭。
- 分诊需要设定准入条件、执行步骤、争议处理与超时回收，每次分诊以受理结论和指派结果作为完成标志。
- 机制上线后按分诊时效、指派退回比例、争议升级记录、验收独立性等条目检查，出现退回比例上升或分诊时长超标时触发复盘调整。
缺陷责任人到底负责哪些决策
缺陷责任人的核心职责集中在“受理决策”这一环节：确认缺陷是否成立、给出严重程度与优先级定级、判断责任归属、指派处理人，并把受理结论记录到缺陷工作项上。这四项动作构成一个完整的受理闭环，缺任何一项，缺陷就会停留在“已提交但无人认领”的状态。
具体来说，缺陷责任人要做的事包括：
- 成立判断：核对复现步骤、环境、预期与实际结果，判断这是缺陷、需求变更、使用问题还是重复提交。
- 定级：依据影响范围、发生频率、是否有临时规避手段，给出严重程度；结合业务节奏给出优先级建议。
- 定责：根据缺陷现象与代码归属、模块边界，判断应由哪个模块负责人或开发负责人承接。
- 指派与记录：把缺陷指派给具体处理人，并在工作项上写明受理结论、定级依据与指派理由。
与状态流转规则的边界需要说清：状态流转规则回答“缺陷从新建到关闭要经过哪些状态、谁能改状态”，属于缺陷生命周期管理的范畴；缺陷责任人回答“这个缺陷该不该受理、由谁处理”。前者是流程骨架，后者是骨架上的决策动作。缺陷责任人按规则推进状态，但不负责设计状态机本身。
与根因分析的边界同样需要区分：根因分析发生在缺陷被受理、修复之后，回答“为什么会产生这类缺陷、如何预防”，属于缺陷分析与预防的范畴。缺陷责任人在受理阶段只做现象层面的判断，不承担根因定位与预防措施设计。
职责边界不清时，常见后果有三种：一是重复分诊，测试和开发各自判断一遍，结论不一致；二是责任推诿，缺陷在“不是我这模块”的判断中来回转派；三是缺陷积压，无人对受理结论负责，缺陷长期停留在待分诊状态。把“谁做决策、谁提供输入”写清楚，是避免这三种情况的前提。
各角色在缺陷受理中的分工与交接
分工的基本口径是“谁提供输入、谁做决策、谁执行、谁验收”。缺陷责任人处在决策位置，其他角色分别提供判断依据、承接修复或做关闭前确认。下表按输入物、动作、输出物三个维度对照各角色。
| 角色 | 输入物 | 动作 | 输出物 |
|---|---|---|---|
| 提交人（测试或用户） | 缺陷现象、复现步骤、环境信息、日志或截图 | 提交缺陷，补全复现信息，回答分诊追问 | 信息完整的缺陷单 |
| 测试负责人 | 测试用例执行结果、缺陷影响范围 | 参与定级，说明缺陷对测试进度与覆盖的影响 | 定级建议与影响说明 |
| 缺陷责任人 | 缺陷单、测试定级建议、模块归属信息 | 成立判断、定级定责、指派、记录受理结论 | 受理结论与指派结果 |
| 开发负责人 / 模块负责人 | 指派通知、缺陷单与受理结论 | 确认承接、评估修复工作量、安排处理人 | 承接确认与修复计划 |
| 产品负责人 | 缺陷定级、业务影响描述 | 在涉及业务优先级冲突时判断优先级 | 优先级结论 |
| 验收角色（测试或发布负责人） | 修复说明、验证环境 | 关闭前验证修复效果，确认是否可关闭 | 验收结论 |
缺陷责任人向开发负责人交接时，需要携带的信息应足以让承接方直接开始工作：缺陷单编号与标题、受理结论（成立/不成立/转需求）、定级与定级依据、复现步骤与环境、指派理由（为什么是这个模块）、期望的响应时间。缺少定级依据或复现信息，承接方往往需要回头再问一轮，交接就失去意义。
产品负责人参与优先级判断的时机，通常是在缺陷定级涉及业务取舍时：例如两个缺陷严重程度相近但只能先修一个，或缺陷修复会影响已排期的需求交付。日常的严重程度判断由缺陷责任人与测试负责人完成，产品负责人不必介入每一个缺陷。
验收角色在关闭前的确认职责是独立的一步：开发完成修复并提交验证后，由验收角色在约定环境复测，确认缺陷现象消失且未引入新问题，才能关闭缺陷。缺陷责任人负责受理，验收角色负责关闭前的最后确认，两者不宜由同一人兼任，否则受理结论与验收结论会失去相互校验的作用。
分诊会议与指派流程怎么跑起来
分诊可以按会议形式跑，也可以异步跑，选择取决于缺陷量与团队分布。无论哪种形式，都需要明确准入条件、执行步骤、争议处理和超时回收，才能保证每次分诊都有确定的输出。
分诊前的信息准备与准入条件
进入分诊的缺陷应满足基本准入条件：有可复现的步骤或明确的现象描述、标注了发现环境与版本、附有必要日志或截图、提交时已做过重复缺陷检索。不满足条件的缺陷退回提交人补充信息，不进入分诊队列。这一步把“信息不全”挡在分诊之前，避免分诊会议变成信息补录会。
分诊执行步骤
- 收集待分诊队列：缺陷责任人按约定频率（如每日一次或每个迭代固定时间）汇总新提交且未受理的缺陷。完成标志：队列清单确定，数量与提交记录一致。
- 逐条做成立判断：核对复现信息，判定为缺陷、重复、需求变更或使用问题。完成标志：每条缺陷有明确的成立结论。
- 定级定责：结合测试负责人的定级建议，给出严重程度与优先级；依据模块归属确定承接方。完成标志：定级字段与责任模块填写完整。
- 指派并记录受理结论：指派给具体处理人，在工作项上写明受理结论、定级依据与指派理由。完成标志：处理人字段非空，受理记录可追溯。
- 承接确认：开发负责人确认承接或提出异议。完成标志：承接方明确回复确认。
定级定责的判断依据与争议处理
定级依据应尽量落到可观察的事实：影响多少用户或哪些核心流程、是否阻断测试或发布、是否有临时规避手段、发生频率如何。定责依据模块边界与近期变更记录，避免凭印象指派。出现争议时，按“先定级、后定责”的顺序处理：定级争议由缺陷责任人与测试负责人协商，仍不一致时提交产品负责人裁定；定责争议由相关开发负责人各自说明模块归属，缺陷责任人依据代码归属与变更记录做最终判断，并把判断理由写入受理记录。
指派后的确认与超时回收机制
指派后应设定承接确认时限，例如一个工作日内未确认则自动回到缺陷责任人处重新分诊。修复过程中若处理人长期无进展，缺陷责任人按约定周期（如超过三个工作日无状态更新）回收缺陷，重新评估定责或升级处理。超时回收的目的在于让每个缺陷始终有明确的当前责任人，避免缺陷在“已指派”状态下静默积压。
在工具层面，缺陷受理涉及工作项指派、状态流转与受理记录留痕。ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；与 ONES TestCase 数据互通后，未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队之间流转。缺陷责任人可以在同一工作项上完成指派、填写受理结论并跟踪状态变化，分诊队列与受理记录由此保持在同一处可查。具体字段配置与权限设置需结合团队实际使用情况确认。
一个缺陷从提交到指派的完整示例
以下为演示情景，用于说明各角色在关键节点的动作，不代表真实项目数据。
提交阶段。测试人员在回归测试中发现“订单详情页在优惠券叠加场景下金额显示错误”，提交缺陷时填写了现象描述与截图，但缺少具体复现步骤和测试环境版本。缺陷责任人收到后，依据准入条件退回补充信息。测试人员补全了复现步骤（选择两张可叠加优惠券、提交订单、进入详情页）、环境版本与请求日志，缺陷重新进入分诊队列。
成立判断与定级。缺陷责任人核对复现步骤，确认现象可稳定复现，判定为缺陷，排除重复提交。测试负责人说明该场景属于本期重点回归范围，且金额错误会直接影响用户下单。缺陷责任人据此定为高严重程度，优先级建议为高，并记录定级依据：影响核心交易流程、可稳定复现、无临时规避手段。
交接动作。缺陷责任人依据模块归属判断问题出在优惠计算服务，指派给该模块开发负责人，交接信息包含缺陷单编号、受理结论、定级依据、复现步骤与环境、指派理由。开发负责人确认承接，评估修复工作量后安排具体处理人。由于该缺陷与本期已排期的促销需求存在资源冲突，缺陷责任人将优先级问题提交产品负责人，产品负责人确认优先修复缺陷、促销需求顺延。
指派结果与记录字段。最终缺陷单上记录：受理结论为“成立”、严重程度“高”、优先级“高”、责任模块“优惠计算服务”、处理人“该模块开发工程师”、指派理由“现象与优惠计算逻辑相关，近期该模块有变更”、承接确认时间、产品负责人优先级结论。验收角色在修复完成后按复现步骤复测，确认金额显示正确且未影响其他优惠场景，缺陷关闭。
分工机制上线后的完成检查
机制是否真正运转，不能只看文档是否发布，需要按可核验的条目逐项检查。以下清单可作为上线后一至两个迭代内的检查依据。
- 职责与权限已书面确认：缺陷责任人的决策范围（成立判断、定级、定责、指派）与其他角色的输入义务已形成书面说明，相关角色已知悉并确认。
- 分诊时效可观察：统计缺陷从提交到受理结论的平均时长，以及超时未受理的缺陷数量，判断分诊频率是否匹配缺陷产生速度。
- 指派准确率可观察：统计被承接方退回重派的缺陷比例，比例偏高说明定责依据不足或模块归属信息不清晰。
- 争议升级路径可用：抽查发生过定级或定责争议的缺陷，确认是否按约定路径升级并留下裁定记录。
- 验收环节独立执行：抽查已关闭缺陷，确认关闭前有独立于处理人的验收确认记录。
- 超时回收机制生效：确认存在长期无进展被回收重派的缺陷记录，机制处于实际运行状态。
机制复盘的触发条件可以设定为：指派退回比例连续两个统计周期上升、分诊平均时长明显超出约定、同一模块重复出现定责争议，或发布节奏发生较大变化。触发后由缺陷责任人牵头，联合测试与开发负责人调整准入条件、定级口径或分诊频率，调整结果同步到书面说明中，保持职责约定与实际执行一致。
常见问题
缺陷责任人与测试负责人在定级上意见不一致时怎么办？
按“先定级、后定责”的顺序处理。定级争议先由缺陷责任人与测试负责人协商，双方各自给出依据：缺陷责任人侧重影响范围与是否有规避手段，测试负责人侧重对测试进度与覆盖的影响。协商仍不一致时，提交产品负责人裁定，并把裁定结论与理由写入受理记录。这样处理的好处是争议有明确终点，缺陷不会停在待分诊状态。
缺陷量较小的团队也需要单独设缺陷责任人吗？
缺陷量小时可以由测试负责人或开发负责人兼任，但需要把受理决策的动作明确到人，避免“谁看到谁处理”。兼任时建议保留两条底线：一是受理结论要记录在工作项上，二是验收确认由处理人之外的角色完成。缺陷量增长或分诊时长明显拉长时，再考虑拆出专职角色。
指派后被开发负责人退回重派，说明机制哪里出了问题？
退回重派比例偏高，通常指向两个原因：定责依据不足，或模块归属信息不清晰。可以先检查指派时是否写明了指派理由与相关模块的近期变更记录，再检查模块边界文档是否与实际代码结构一致。若两者都具备仍频繁退回，说明定责权限需要上移，由开发负责人共同参与定责判断。
异步分诊和分诊会议如何选择？
缺陷产生频率高、需要多方当场对齐定级时，固定时间的短会效率更高；团队分布在不同时区或缺陷量较少时，异步分诊更合适。两种形式都要保留相同的准入条件、完成标志和超时回收规则，形式变化不影响受理结论的可追溯性。
用工具管理分诊队列时，需要关注哪些配置？
重点看三处：缺陷工作项的指派字段与受理结论记录是否可追溯，分诊队列能否按状态筛选出未受理缺陷，以及承接确认与超时是否有提醒或回收手段。ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；与 ONES TestCase 数据互通后，未通过的用例可快速创建缺陷任务。具体字段配置与权限设置需结合团队实际使用情况确认。
