缺陷分配真正难的地方，是“分给谁”和“交付什么”要同时落地：只写处理人，缺陷容易反复退回；只写要求，又常常无人跟进。本文给出一套可直接照做的分诊规则、唯一责任人判定方法、缺陷单交付字段和流转留痕规则，并附一个跨模块缺陷的完整走查与运行检查清单。
要点总览（TL;DR）
- 分诊先于分配：由值班分诊人和模块责任人按影响范围、复现条件、所属模块、是否受理的顺序判定，结论只有直接指派、退回补充信息、转交其他团队三种去向。
- 责任分配坚持唯一责任人原则：缺陷单处理人字段只填一人，协作人字段记录配合人员；跨模块缺陷按根因所在模块、用户可见异常模块、分诊人指定并记录理由的顺序确定主责。
- 交付要求写进缺陷单才可验证：修复范围、影响版本、复现步骤、验收标准、期望完成时间、证据要求六类字段，验收标准与复现步骤逐条对应。
- 指派、转派、退回都要在缺陷单上更新字段并写明原因，新处理人确认接手后才视为责任转移完成，责任空窗当日清零。
- 按周核对分诊时限达标率、无责任人缺陷数量、交付字段完整率和退回转派原因分布，用检查结果反过来调整规则。
分诊规则：谁受理、按什么判定、结论如何落地
分诊环节解决的是“这个缺陷是否受理、由哪条线接手”，它发生在确定具体处理人之前。建议设置两个固定角色：值班分诊人负责每日新缺陷的首次判定，模块责任人负责确认本模块缺陷的技术归属。两个角色都应是岗位而非个人，人员轮换时职责不变。
判定按固定顺序进行，前一步有结论就不再往下走，避免不同人得出不同结果：
| 顺序 | 判定项 | 判定内容 | 结论去向 |
|---|---|---|---|
| 1 | 影响范围 | 是否影响线上用户、核心流程或数据正确性 | 影响面大且信息充分，直接指派并提升优先级 |
| 2 | 复现条件 | 是否有版本、环境、操作步骤，能否稳定复现 | 信息不足，退回提交人补充，缺陷单保持待分诊状态 |
| 3 | 所属模块 | 根据报错位置、功能入口、代码归属判断模块 | 归属明确，进入责任分配；跨模块则按主责规则处理 |
| 4 | 是否受理 | 是否为重复缺陷、设计预期行为或非本产品问题 | 重复则关联原单；预期行为则说明依据后关闭；他方问题转交对应团队 |
受理结论只有三种去向：直接指派、退回补充信息、转交其他团队。每种去向都必须在缺陷单上留下结论和理由，不能只在群里说一声。退回时写明缺哪项信息，转交时写明接收团队和转交依据。
分诊时限建议按工作日设定，例如新缺陷在提交后一个工作日内完成首次判定，高优先级缺陷当日内判定。超过时限未判定的缺陷自动进入升级队列，由测试负责人或项目负责人接手处理。时限数值应结合团队缺陷量和值班安排确定，并在团队内公示。
责任分配：从模块归属到具体处理人的确定方法
责任分配的终点是缺陷单上只有一个处理人。多人共同负责等于无人负责，因此需要维护一份模块责任人清单，并坚持唯一责任人原则。
模块责任人清单至少包含以下字段：模块名称、模块责任人、备选责任人、所属团队、清单维护人、最近更新日期。清单由各团队负责人维护，架构调整或人员变动时同步更新，分诊人以此作为指派依据。备选责任人的作用是在主责任人请假、离职或负载饱和时承接，避免缺陷停在无人状态。
缺陷单上区分两个人员字段：处理人字段只填一人，代表对修复结果负责；协作人字段可填多人，记录需要配合排查、提供环境或参与评审的人员。协作人不承担交付责任，但应在缺陷单中被通知到。
跨模块缺陷的主责判定可按以下规则执行：以缺陷首次出现或根因所在的模块为主责模块；无法判断根因时，以用户可见异常所属模块为主责；仍无法区分时，由分诊人指定主责并记录理由，被指定方如有异议在当日内提出，由项目负责人裁定。主责人负责组织协作人完成修复，并对最终交付负责。
当模块责任人当前在办缺陷数量明显偏高时，分诊人先与模块责任人协商，可转派给备选责任人，或与团队负责人确认排期后保留在原责任人处并调整期望完成时间。转派和延期都要在缺陷单上记录原因，避免出现“已分配但长期不动”的隐性积压。
交付要求：缺陷单上必须写清的字段与验收标准
交付要求写在缺陷单里，才能被验证。建议缺陷单固定包含以下字段，并对关键字段设置必填：
| 字段名 | 填写要求 | 示例 |
|---|---|---|
| 修复范围 | 说明需要修改的功能点或模块，明确本次不处理的相关问题 | 修复订单列表分页参数丢失；导出功能同类问题另开单处理 |
| 影响版本 | 列出受影响的版本号或环境，注明是否已上线 | 影响 3.2.0 及以上版本，线上环境可复现 |
| 复现步骤 | 按操作顺序编号，包含前置数据和环境 | 1. 登录测试账号；2. 进入订单列表；3. 翻至第 2 页；4. 观察列表为空 |
| 验收标准 | 与复现步骤逐条对应，写成可观察的结果 | 第 2 页正常展示 20 条订单，翻页参数在请求中正确传递 |
| 期望完成时间 | 与优先级挂钩，高优先级当日或次日，普通优先级按迭代排期 | P1，期望次日 18:00 前提交修复 |
| 证据要求 | 修复说明、自测记录、回归范围 | 附修复提交说明；自测截图；回归订单列表与导出两个入口 |
验收标准与复现步骤要一一对应：复现步骤描述问题如何出现，验收标准描述修复后同样的操作应得到什么结果。只写“修复分页问题”无法验证，写成“第 2 页展示 20 条订单且请求参数正确”才能被测试人员直接核对。
期望完成时间由优先级决定，而不是由提交人随意填写。优先级判定依据影响范围和用户规模，分诊时一并确认。修复完成后，处理人需在缺陷单中填写修复说明和自测记录，测试人员按验收标准验证并记录回归范围，验证通过后才可关闭。
交接与留痕：指派、转派、退回的记录方式
责任流转的每一步都要在缺陷单上留下字段变化和说明，口头指派不作为分配依据。可以按以下规则执行：
- 指派时更新处理人、优先级、期望完成时间，并填写分诊结论。
- 转派时更新处理人，同时写明转派原因、原处理人已完成的排查工作和新处理人的接手事项。
- 退回补充信息时，缺陷单状态回到待分诊或待补充，必填说明缺少的信息项和提交人需补充的内容。
- 转交其他团队时，写明接收团队、转交依据和对接人。
交接的通知对象包括原处理人、新处理人、提交人和测试负责人。新处理人应在缺陷单上确认接手，确认动作可以是状态变更或评论回复，确认后才视为责任转移完成。
责任空窗指缺陷处于进行中状态却没有有效处理人，或处理人已转派但新处理人未确认。识别方式是按状态和人员字段定期筛查，发现后由分诊人在当日内重新指派。责任空窗的停留时长应作为团队复盘时的观察项。
在研发管理工具中承载这套规则时，缺陷单的字段、指派记录和状态变化可以成为留痕依据。ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；其多层级权限可按组织架构、项目角色分配，便于区分分诊人、模块责任人和测试人员的操作范围。ONES TestCase 支持未通过用例快速创建缺陷任务，使测试与研发之间的流转有据可查。具体字段是否必填、流转记录如何展示，需结合团队实际配置确定。
示例：一个跨模块缺陷从受理到交付的完整走查
以下为演示情景，用于说明规则如何串联执行。
缺陷描述：用户在订单详情页点击“申请退款”后页面无响应，影响 3.2.0 版本线上环境，可稳定复现。提交人附有操作录屏，但未说明浏览器版本。
初始分诊：值班分诊人按顺序判定：影响范围为线上核心交易流程，判定为高优先级；复现条件基本具备，但缺少浏览器版本，先退回补充信息，缺陷单保持待分诊。提交人补充浏览器版本后，分诊人确认可复现，进入模块判定。
主责与协作人确定：该缺陷涉及订单服务和支付网关两个模块。排查发现退款请求在订单服务侧未正确组装参数，判定订单服务为主责模块，处理人为订单服务模块责任人；支付网关开发人员加入协作人字段，配合确认接口返回。分诊人在缺陷单中记录主责判定理由。
交付要求填写：修复范围写为“修复退款申请参数组装逻辑，支付网关侧配置问题另开单”；影响版本写为“3.2.0 及以上，线上环境”；复现步骤按录屏整理为四步；验收标准写为“点击申请退款后 3 秒内进入退款确认页，请求参数包含订单号和退款金额”；期望完成时间按 P1 设为次日 18:00；证据要求为修复提交说明、自测截图和订单详情页回归记录。
验证与关闭：处理人提交修复并附自测记录，测试人员按验收标准验证通过，补充回归范围记录，缺陷单关闭。全过程的人员变化、状态变化和说明均保留在缺陷单中。
完成检查：分诊机制是否运转正常的核对项
机制是否落地，可以用以下清单按周核对。判定标准应结合团队历史数据设定基线，首次运行时可先观察两周再确定阈值。
| 检查项 | 核对方法 | 判定标准 |
|---|---|---|
| 分诊时限达标情况 | 统计新缺陷从提交到首次判定的时长 | 达标率不低于团队设定目标，超时缺陷有升级记录 |
| 无责任人缺陷 | 筛查进行中状态但处理人为空的缺陷 | 数量为零或当日清零，停留时长不超过一个工作日 |
| 交付要求字段完整率 | 抽查已关闭缺陷的修复范围、验收标准、证据字段 | 关键字段完整率达到目标，缺失项有补填记录 |
| 退回与转派频次 | 按原因分类统计退回和转派记录 | 退回原因集中在信息缺失时可推动提交模板改进；转派集中在某模块时检查责任人清单 |
检查结果用于调整规则本身：分诊时限长期不达标，说明值班安排或缺陷量需要重新评估；退回频次过高，说明提交入口的必填引导不足；转派集中在少数模块，说明模块责任人清单需要更新或补充备选人。把检查结果与规则调整对应起来，分诊机制才能持续运转。
常见问题
分诊人由谁担任，和模块责任人是什么关系？
分诊人负责每日新缺陷的首次判定，模块责任人负责确认本模块缺陷的技术归属。建议两个角色都设为岗位而非个人，人员轮换时职责不变。分诊人依据模块责任人清单指派，遇到归属不清时由模块责任人给出判断，两者配合完成从受理到分配的衔接。
跨模块缺陷的主责人判定有异议时怎么办？
先按规则判定：以根因所在模块为主责，无法判断根因时以用户可见异常所属模块为主责，仍无法区分时由分诊人指定并记录理由。被指定方如有异议，应在当日内提出，由项目负责人裁定。裁定结果和理由同样记录在缺陷单中，避免同一类争议反复出现。
模块责任人负载过高时，是转派还是延期？
两种方式都可用，取决于缺陷优先级和备选责任人的可用性。分诊人先与模块责任人协商，可转派给备选责任人；也可以与团队负责人确认排期后保留在原责任人处，同时调整期望完成时间。无论转派还是延期，都要在缺陷单上记录原因，防止出现已分配但长期不动的隐性积压。
退回补充信息的缺陷，责任算谁的？
退回后缺陷单回到待分诊或待补充状态，责任暂时回到分诊环节，由分诊人跟踪提交人补充进度。退回时必须写明缺少哪项信息、提交人需补充什么。补充完成后重新进入分诊判定，不能因为退回就长期搁置。
在工具中落地这套规则，需要关注哪些配置点？
重点是把分诊结论、处理人、协作人、交付要求字段和流转记录都放在缺陷单上。ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；多层级权限可按组织架构、项目角色分配，便于区分分诊人、模块责任人和测试人员的操作范围。ONES TestCase 支持未通过用例快速创建缺陷任务，使测试与研发之间的流转有据可查。字段是否必填、流转记录如何展示，需结合团队实际配置确定。
