缺陷分派规则要解决的是缺陷进入待分派队列后“交给谁、先处理哪个”的判断问题。本文给出一份已填写的示例分派表，覆盖模块归属、影响范围、严重程度、复现条件到责任团队与处理人的完整路径，并逐项解释填写依据。示例为演示情景，团队结构、模块划分与角色设置均为假设，读者可据此改造出适配自身团队的规则。
要点总览（TL;DR）
- 缺陷分派规则的核心是把“交给谁、先处理哪个”拆成可判断的字段组合：模块归属定责任团队，影响范围与严重程度定优先级，复现条件定是否直接指派。
- 示例分派表用四条记录覆盖常规分派、高优先级分派、跨模块分派和复现条件不足四种路径，每条都写明分派结论与依据。
- 复现条件不足时采用回退路径：先由模块分诊人补充日志和复现环境，信息补齐后再指派处理人，减少反复转派。
- 改造为自身规则时，先确定判断字段，再维护模块与团队对应表，按优先级排列组合规则并编号，最后约定争议升级机制。
- 模块划分变化、跨团队缺陷增多、外部依赖缺陷出现或分派争议频繁时，需要重新审视规则并更新对应表。
示例要解决的分派问题
这份示例聚焦缺陷受理阶段的一个决策：缺陷提交后进入待分派队列，分诊人需要在信息有限的条件下，确定责任团队、具体处理人和处理优先级。它不涉及缺陷状态如何流转，也不讨论缺陷产生的原因和预防措施，只回答“这条缺陷该由谁接、按什么顺序接”。
为了让示例可参照，先交代假设前提。示例假设一个中等规模的研发组织，按业务模块划分为交易、账户、消息三个研发团队，每个团队设一名分诊人，负责接收本模块缺陷并确认最终处理人。缺陷由测试人员在测试过程中提交，提交时填写所属模块、影响范围、严重程度和复现条件四个判断字段。分派结果由分诊人确认后写入分派记录，包括责任团队、处理人和分派依据。
需要说明的是，以下记录均为演示情景，用于展示规则如何落地，不代表任何真实客户案例，也不附带实测效果数据。读者关注的重点应是字段之间的判断关系，而非表中的具体人名或编号。
完整示例：一张填好的缺陷分派表
下表给出四条已填写的缺陷记录，分别覆盖常规分派、高优先级分派、跨模块分派和复现条件不足四种判断路径。每条记录都写明了分派结论和依据，便于对照规则复核。
| 缺陷编号 | 所属模块 | 影响范围 | 严重程度 | 复现条件 | 责任团队 | 处理人 | 分派依据 |
|---|---|---|---|---|---|---|---|
| BUG-101 | 交易-下单 | 部分用户，特定优惠券 | 一般 | 可稳定复现，步骤完整 | 交易团队 | 交易团队分诊人指定后端开发A | 模块归属交易团队；影响范围限于特定优惠券场景，严重程度一般；复现步骤完整，直接指派模块内处理人 |
| BUG-102 | 账户-登录 | 全部用户，无法登录 | 严重 | 可稳定复现，步骤完整 | 账户团队 | 账户团队分诊人指定后端开发B，并同步测试负责人 | 模块归属账户团队；影响范围为全部用户且阻断登录，严重程度高；复现完整，按高优先级直接指派并同步相关角色 |
| BUG-103 | 交易-支付回调 | 部分用户，支付结果不同步 | 严重 | 可稳定复现，涉及消息通知 | 交易团队牵头，消息团队配合 | 交易团队分诊人指定后端开发C，消息团队分诊人指定开发D协同 | 主模块为交易，影响支付结果，严重程度高；复现路径涉及消息通知，按跨团队规则由主模块团队牵头、关联团队配合 |
| BUG-104 | 消息-推送 | 部分用户，推送延迟 | 一般 | 偶现，缺少稳定复现步骤 | 消息团队 | 消息团队分诊人暂接，补充信息后再指派 | 模块归属消息团队；影响范围与严重程度均为一般；复现条件不足，按回退规则先由分诊人补充日志与复现环境，再确定处理人 |
四条记录展示了同一套字段组合在不同取值下的分派结果：模块决定责任团队，影响范围与严重程度共同决定优先级和处理方式，复现条件决定是直接指派还是先补充信息。跨团队缺陷则增加一条主责与配合的约定。
逐项解释：每个字段为什么这样填
模块归属如何映射到责任团队
模块归属是确定责任团队的第一依据。示例中模块按“业务域-功能点”两级命名，交易、账户、消息三个业务域分别对应三个研发团队，功能点用于在团队内进一步定位处理人。填写时要求提交人选择到功能点层级，避免只写到业务域导致团队内二次分派。模块与团队的对应关系由各团队维护，新增模块时同步登记归属团队和分诊人。
影响范围与严重程度的分工
影响范围描述缺陷波及的用户或业务面，严重程度描述缺陷对业务造成的损害程度，两者分工不同，需要组合判断。影响范围回答“多少人受影响”，严重程度回答“受影响时后果多严重”。示例中，BUG-101影响范围有限、严重程度一般，按常规优先级处理；BUG-102影响全部用户且阻断登录，两项取值都指向高优先级，因此直接指派并同步测试负责人。只写严重程度而不写影响范围，容易把个别用户的严重问题与全量用户的轻微问题混在同一优先级。
复现条件不足时的处理方式
复现条件是决定能否直接指派到个人的关键。步骤完整、可稳定复现的缺陷，分诊人可以直接指定处理人；偶现或缺少步骤的缺陷，示例采用回退路径：先由模块分诊人接收，补充日志、复现环境和操作路径，信息补齐后再指派处理人。这样处理的原因是，直接指派到个人后若信息不足，处理人往往需要退回补充，造成反复转派。回退路径的责任人仍是模块分诊人，补充信息的时限和标准由团队约定。
分派依据栏的写法要求
分派依据栏用于复核和追溯，写法要求是“字段取值加对应规则条目”，而不是只写结论。例如“模块归属交易团队；影响范围限于特定优惠券场景，严重程度一般；复现步骤完整，直接指派模块内处理人”，读者可以据此还原判断过程。当分派结果被质疑时，依据栏也是升级复核的输入材料。
从示例到自己的规则：可迁移的写法
这张表可复用的部分是一套“条件组合到责任归属”的映射结构，而不是表中的具体取值。改造时先确定判断字段，再为字段组合定义分派结果，最后补上维护和争议处理机制。
第一步，确定判断字段。常见字段包括所属模块、影响范围、严重程度、复现条件，团队也可加入缺陷来源、客户等级等字段。字段数量控制在提交人能在几分钟内填完的范围，字段过多会降低提交质量。
第二步，建立模块与团队的对应表。这张表是分派规则的基础数据，需要明确每个模块的归属团队、分诊人和备份分诊人。模块划分调整时，先更新对应表，再调整分派规则，避免规则与组织实际脱节。
第三步，定义组合规则。可以按优先级从高到低排列规则条目，例如“影响全部用户且严重程度为严重”优先于“影响部分用户且严重程度一般”，命中即停止匹配。规则条目应编号，便于在分派依据栏引用。
第四步，约定争议处理。当提交人与分诊人对模块归属有分歧，或缺陷涉及多个团队时，示例采用主模块团队牵头、关联团队配合的方式，由双方分诊人确认分工；无法达成一致时，升级到测试负责人或研发负责人裁定，裁定结果回写分派记录。
规则落地需要工作项承载这些字段和分派记录。ONES Project 适配缺陷管理等研发场景，支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转。团队可以把模块、影响范围、严重程度、复现条件作为缺陷工作项的记录字段，把分派依据写入处理记录，让分派过程在工具中留痕，便于后续复核和规则调整。
适用边界：这套规则什么时候需要调整
示例规则建立在模块边界清晰、团队职责稳定、缺陷量适中的前提上。出现以下信号时，需要重新审视规则。
- 团队规模或模块划分变化：新增业务域、拆分团队或合并模块后，模块与团队的对应表需要同步更新，原有组合规则可能指向已不存在的团队。
- 跨团队缺陷增多：当涉及多个模块的缺陷占比上升，主责加配合的约定需要细化，明确各团队的处理顺序和交接标准。
- 外部依赖缺陷：缺陷根因位于第三方服务或外部系统时，责任团队的处理动作变为跟踪和推动外部方，分派规则应增加外部依赖标记和跟进责任人。
- 分派争议频繁：同一类缺陷反复出现归属分歧，说明模块边界或规则条目定义不清，需要补充判定口径。
- 提交信息质量下降：复现条件缺失比例上升，回退路径会积压分诊人工作量，需要回头检查提交模板和字段必填要求。
规则维护应指定明确的责任人，通常由测试负责人或质量负责人担任，负责收集分派争议、更新模块对应表和规则条目。更新节奏可跟随团队迭代周期，在每个迭代回顾时检查一次分派记录，发现规则未覆盖的情况及时补充。规则版本变更后，应通知提交人和分诊人，避免按旧规则填写。
常见问题
缺陷提交时信息不全，分派规则应该怎么处理？
示例采用回退路径：先由模块分诊人接收，补充日志、复现环境和操作路径，信息补齐后再指派处理人。这样做的原因是直接指派到个人后，处理人往往需要退回补充信息，造成反复转派。回退路径的责任人仍是模块分诊人，补充信息的时限和标准由团队约定，并建议在提交模板中把复现条件设为必填项，从源头减少信息缺失。
一条缺陷涉及多个团队时，责任团队怎么定？
示例按主模块团队牵头、关联团队配合的方式处理。先判断缺陷的主要影响落在哪个模块，由该模块团队承担主责并指定处理人，关联团队指定协同人。双方分诊人确认分工后写入分派记录；无法达成一致时，升级到测试负责人或研发负责人裁定，裁定结果回写记录。跨团队缺陷占比上升时，需要进一步细化各团队的处理顺序和交接标准。
分派规则应该由谁维护，多久更新一次？
规则维护通常指定一名明确的责任人，由测试负责人或质量负责人担任，负责收集分派争议、更新模块与团队对应表和规则条目。更新节奏可以跟随团队迭代周期，在每个迭代回顾时检查一次分派记录，发现规则未覆盖的情况及时补充。规则版本变更后应通知提交人和分诊人，避免继续按旧规则填写。
缺陷根因在第三方服务时，分派规则要改什么？
当缺陷根因位于第三方服务或外部系统时，责任团队的处理动作从修复变为跟踪和推动外部方。分派规则应增加外部依赖标记和跟进责任人，明确由谁对接外部方、跟进到什么程度算闭环。这类缺陷的优先级判断也要单独考虑，例如外部方响应周期较长时，是否需要先提供临时规避方案。
分派规则能否在工具里自动执行？
规则中的字段和分派记录需要有工作项承载才能留痕和复核。ONES Project 适配缺陷管理等研发场景，支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转。团队可以把模块、影响范围、严重程度、复现条件作为缺陷工作项的记录字段，把分派依据写入处理记录。自动指派的具体配置方式需结合团队实际使用的工具版本确认。
