缺陷分派规则要回答四个判定：这条缺陷多急、该派给谁、多久必须响应、派错了怎么纠正。把这四项写成有字段、有角色、有完成标志的判定表，分诊人就能按同一口径处理缺陷，减少口头协调。本文覆盖缺陷受理环节的分派决策，缺陷状态流转和根因分析分别由生命周期管理与缺陷分析机制承担。
要点总览（TL;DR）
- 缺陷分派规则要写成判定表，回答四个问题：优先级、责任人、响应时限、转派与升级，每一项都落到字段和完成标志上。
- 优先级用严重度与影响范围两个字段组合判定，取值固定、结论唯一；涉及数据错误或资金异常的缺陷可设少量覆盖规则并留痕。
- 责任人以模块归属表为主、当班轮值为辅；跨模块缺陷写死牵头人判定标准，归属不明的先派临时受理人并设确认时限。
- 时限分响应与处理两段，按优先级设定；超时升级和转派都要写明触发条件、确认权限和记录要求，避免退化为口头协调。
- 规则落地后用分派准确率、超时升级次数、转派率三项指标观察，并按季度或组织变化定期评审更新。
缺陷分派规则要解决哪几个判定问题
分派规则是一组受理决策，输入是缺陷单上的字段和团队的组织信息，输出是明确的负责人、优先级和时限。它处理的是缺陷进入团队后的第一段路径，不负责缺陷从新建到关闭的完整状态设计，也不负责从重复缺陷中归纳根因。
具体来说，分派规则要回答四个问题。第一，优先级：这条缺陷在当下应排到什么处理顺序。第二，责任人：由哪个角色、哪个人受理。第三，时限：受理后多久必须给出响应和处理结论。第四，转派：发现派错人或归属判断有误时，按什么条件、经谁确认、如何记录地改派。
规则依赖三类输入。缺陷单字段提供严重度、影响范围、复现环境、发现阶段等信息；模块归属信息说明缺陷落在哪个功能或服务范围；当班信息说明当前值班的测试、开发和分诊角色是谁。三类输入缺一类，判定就会退回到个人经验。
边界需要提前说清。缺陷状态如何从待确认流转到修复中、已验证、关闭，属于缺陷生命周期规则；缺陷集中在哪些模块、由什么原因反复出现，属于缺陷分析与预防。分派规则只保证缺陷在正确的时间落到正确的人手上，后续处理质量由其他机制保障。
第一步：用严重度与影响范围确定受理优先级
优先级不宜只按严重度一个维度判定。严重度高但影响面小的缺陷，与严重度中等但阻塞大量用户的缺陷，处理顺序可能不同。建议用严重度与影响范围两个字段组合成判定表，每个组合对应唯一优先级，分诊人查表即可得出结论。
严重度描述缺陷本身对系统功能的破坏程度，可按四级设定：致命指核心功能不可用或数据损坏；严重指主要功能失效且有临时绕行方案；一般指次要功能异常；轻微指界面、文案或体验问题。影响范围描述受影响的用户与场景，可分为全部用户、部分用户或特定环境、内部测试发现三类。
| 严重度 | 影响范围：全部用户 | 影响范围：部分用户或特定环境 | 影响范围：内部测试发现 |
|---|---|---|---|
| 致命 | P0 | P0 | P1 |
| 严重 | P0 | P1 | P2 |
| 一般 | P1 | P2 | P3 |
| 轻微 | P2 | P3 | P3 |
判定表的字段取值要固定下来，写进缺陷单模板：严重度用四级枚举，影响范围用三类枚举，优先级用P0至P3四级。分诊人填写优先级后，完成标志是三个字段均已填写且组合与判定表一致；若组合在表中无对应项，说明字段取值有误，应先修正字段再提交。
影响范围涉及数据安全或资金损失时，可在判定表之外增加一条覆盖规则：无论严重度如何，涉及数据错误或资金异常的缺陷直接定为P0，并在缺陷单中注明触发覆盖规则的原因。覆盖规则数量要少，且每次使用都留痕，便于后续评审。
第二步：按模块归属与当班角色确定责任人
责任人确定以模块归属为主、当班轮值为辅。模块归属表把产品功能或服务范围映射到具体负责人，是分派的主要依据；当班角色负责在负责人不在线时承接首次响应，避免缺陷停留在无人受理状态。
模块归属表需要有人维护。建议按功能域或代码仓库划分模块，每个模块指定一名主负责人和一名备份负责人，并记录模块的适用范围描述。组织调整、人员变动或系统拆分时同步更新映射表，更新动作纳入团队例行事项，避免映射表与实际分工脱节。
| 判定情形 | 责任人确定方式 | 记录要求 |
|---|---|---|
| 缺陷明确落在单一模块 | 派给该模块主负责人 | 缺陷单填写模块字段与负责人 |
| 主负责人不在线或休假 | 派给该模块备份负责人 | 注明转由备份受理的原因 |
| 缺陷跨两个及以上模块 | 派给涉及模块中优先级最高的模块负责人牵头 | 列出涉及模块，注明牵头人 |
| 归属不明或新模块尚无映射 | 先派给当班分诊人指定的临时受理人 | 标注“待确认归属”，设定确认时限 |
当班轮值角色承担三项职责：接收新提交的缺陷并完成首次分诊；对归属不明的缺陷指定临时受理人；在负责人未响应时按升级规则推动。轮值表按周或按迭代排定，值班人姓名与联系方式在团队内可见。
跨模块缺陷容易在几个负责人之间来回推诿。规则要明确牵头人判定标准，例如以缺陷主要表现所在的模块为准，或以修复改动量最大的模块为准，二者选其一写死，避免每次临时协商。临时受理人的确认时限建议设为半个工作日，超时未确认归属则进入升级流程。
第三步：响应时限、超时升级与转派规则
时限按优先级设定，分响应时限和处理时限两段。响应时限指负责人确认受理并给出初步判断的时间，处理时限指给出修复方案或修复完成的时间。两段时限分开设定，可以区分“没人看”和“看了但没修完”两类问题。
| 优先级 | 响应时限 | 处理时限 | 超时升级层级 |
|---|---|---|---|
| P0 | 30分钟内 | 当班内给出修复或止损方案 | 模块负责人→技术负责人→项目负责人 |
| P1 | 2小时内 | 1个工作日内 | 模块负责人→技术负责人 |
| P2 | 1个工作日内 | 当前迭代内 | 模块负责人→当班分诊人 |
| P3 | 2个工作日内 | 排入后续迭代 | 模块负责人 |
表中时限为示例口径，团队应结合自身发布节奏调整，调整后保持各级别之间的相对关系。升级触发条件要写成可判断的事实：响应时限到期仍未确认受理、处理时限到期仍无进展记录、临时受理人超过确认时限未落实归属。触发后由当班角色通知上一层级，并在缺陷单中记录升级时间与接收人。
转派处理派错人的情况。发起条件包括：负责人判断缺陷不属于本模块、缺陷实际影响范围与分诊结论不符、负责人长期不在岗。转派需要原负责人填写转派原因并指定接收方，接收方确认后生效；P0和P1缺陷的转派需经技术负责人确认，P2和P3可由双方直接确认。每次转派在缺陷单中留下记录，包括转出人、接收人、原因和时间，供后续统计转派率。
规则落到工具上时，需要工作项字段承载优先级、模块和影响范围，需要负责人指派动作完成分派，需要状态变化记录响应与处理进展。ONES Project 适配缺陷管理等场景，支持自定义属性与分配负责人，可用于承载上述字段和指派动作；ONES TestCase 支持未通过用例快速创建缺陷任务，使测试发现的问题进入同一分派流程。时限提醒与升级通知的具体配置方式，需结合团队实际项目设置在试用中确认。
角色分工与各环节交付物
分派链条上有五类角色。分诊人负责首次判定，模块负责人负责承接与修复判断，当班角色负责兜底推动，测试人员负责提交信息完整的缺陷单，开发负责人负责升级裁决。每个环节都要有明确的输入、动作和输出，交接时字段不全的缺陷单应退回补充。
| 角色 | 职责与决策权限 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 提交人（测试或用户支持） | 如实描述缺陷，不判定优先级 | 复现步骤、环境、实际与预期结果 | 按模板填写缺陷单 | 字段完整的待分诊缺陷 |
| 分诊人 | 有权确定优先级与初步责任人 | 缺陷单字段、模块归属表、判定表 | 查表定级，按映射指派 | 带优先级、模块、负责人的缺陷单 |
| 模块负责人 | 有权确认或质疑归属，发起转派 | 被指派的缺陷单 | 在响应时限内确认受理并给出初步判断 | 受理确认与处理计划 |
| 当班角色 | 有权指定临时受理人、发起升级 | 轮值表、超时缺陷清单 | 处理归属不明缺陷，推动超时项 | 临时归属结论、升级记录 |
| 技术负责人 | 有权裁决跨模块归属与P0/P1转派 | 升级请求与争议记录 | 作出归属或转派决定 | 裁决结论与责任人变更记录 |
交接时的必填字段包括：严重度、影响范围、优先级、所属模块、负责人、响应时限。转派时额外填写转派原因与接收方确认；升级时额外填写升级时间、升级层级与接收人。这些字段既是分派动作的产物，也是后续统计分派准确率和超时率的原始数据。
示例：一条支付失败缺陷如何走完分派
以下为演示情景，用于说明规则如何运行，不代表任何真实系统的事故记录。
测试人员在回归测试中发现：部分用户在提交订单后支付页面报错，订单状态停留在待支付。缺陷单初始字段填写为：严重度“严重”，影响范围“部分用户”，复现环境为生产环境，涉及模块暂填“订单”。
分诊人查优先级判定表，“严重”与“部分用户”组合对应P1。由于缺陷涉及资金相关流程，分诊人按覆盖规则复核后维持P1，并在缺陷单注明复核依据。随后查模块归属表，“订单”模块主负责人为A，但缺陷表现涉及支付回调，分诊人将缺陷派给A，同时把支付模块负责人B列为协同人，响应时限按P1设为2小时。
A在40分钟内确认受理，判断问题出在支付回调处理逻辑，不属于订单模块，发起转派并指定B接收。因该缺陷为P1，转派提交技术负责人确认，确认后责任人变更为B，转派记录写入缺陷单。若A未在2小时内确认受理，当班角色将按升级路径通知技术负责人，并在缺陷单记录升级时间。
这个例子展示了规则的三段运行：查表定级、按映射指派、按条件转派或升级。每一步都有字段留痕，事后可以复盘判定是否准确。
规则落地后的完成检查
规则是否真正运行，可以用一份清单逐项核对。检查的对象是判定表、映射表和时限表是否齐备、是否有人维护，以及分派过程是否产生了可观察的数据。
- 优先级判定表已写入缺陷单模板，字段取值为固定枚举，组合结论唯一。
- 模块归属表覆盖当前全部在维护的模块，每个模块有主负责人和备份负责人，最近一次更新在约定周期内。
- 当班轮值表已排定并可见，值班人清楚自己的分诊与升级职责。
- 时限表按优先级设定响应与处理两段时限，升级层级与触发条件写明。
- 转派规则包含发起条件、确认权限和记录要求，P0/P1转派有审批人。
- 缺陷单的必填字段在提交、分派、转派、升级各环节均有校验。
观察指标建议包括三项：分派准确率，即首次指派后未发生转派的缺陷占比；超时升级次数，按优先级分别统计；转派率，按模块统计以发现归属表与实际分工的偏差。指标按月或按迭代查看，异常值回到对应表格中找原因。
规则本身需要定期评审。建议每个季度或在组织分工、系统架构发生较大变化时评审一次，评审内容包括判定表是否仍匹配业务风险、映射表是否与实际负责人一致、时限是否仍符合发布节奏。评审结论形成更新记录，规则版本与缺陷单模板同步调整，避免规则文件与实际执行脱节。
常见问题
团队规模很小，还需要维护模块归属表和当班轮值表吗？
可以简化，但两类信息仍要有人负责。小团队可以按功能域合并模块，一名负责人覆盖多个模块，备份负责人由相邻模块负责人兼任；当班轮值可以按周轮换，值班人同时承担分诊和临时受理职责。
需要保留的核心是：缺陷单上的模块字段有明确对应的人，归属不明时有指定承接者。缺少这两点，分派会退回临时询问，规则难以持续运行。
分诊人判断的优先级与模块负责人判断不一致时，以谁为准？
建议按缺陷级别区分。P0和P1缺陷由技术负责人裁决，裁决结论写入缺陷单；P2和P3缺陷由分诊人与模块负责人协商，协商不成时由当班角色指定临时结论并记录，留待规则评审时回看。
无论哪种情况，优先级变更都要留下变更前后取值、变更人和原因，否则后续统计分派准确率时缺少依据。
缺陷转派后，原负责人的响应时限怎么计算？
响应时限从缺陷首次分派时开始计算，转派不重置时限。这样处理可以避免缺陷在多次转派中反复获得新的响应窗口。接收方确认转派后，剩余时限继续有效；若转派发生在时限到期之后，按超时升级处理，同时记录转派原因。
如果团队希望转派后重新计时，需要在时限表中写明适用条件，并单独统计这类缺陷，防止时限被反复重置。
规则运行一段时间后，怎么判断判定表需要调整？
看两类信号。一是数据信号：某优先级缺陷的转派率持续偏高，说明模块归属或优先级判定与实际分工有偏差；超时升级集中在某一级别，说明该级别时限与团队节奏不匹配。二是事件信号：组织调整、系统拆分、发布节奏变化后，原映射表和时限表可能失效。
出现上述信号时回到对应表格修改，并同步更新缺陷单模板中的字段取值，保持规则文件与实际执行一致。
用工具承载分派规则时，哪些字段和动作是必须的？
至少需要四类承载：缺陷工作项上的严重度、影响范围、优先级、所属模块等字段；负责人指派动作；状态变化记录响应与处理进展；超时与升级的通知或提醒。ONES Project 适配缺陷管理等场景，支持自定义属性与分配负责人，可用于承载上述字段和指派动作；ONES TestCase 支持未通过用例快速创建缺陷任务，使测试发现的问题进入同一分派流程。时限提醒与升级通知的具体配置方式，需结合团队实际项目设置在试用中确认。
