缺陷分派规则要解决的是受理阶段的两个判断：这条缺陷是否有效，以及它应该落到哪个团队、哪个人。规则写成可执行的决策流程，才能减少反复转派和口头协调。下面按“决策点—入口字段—责任定位—无效判定—角色分工—示例—校准”的顺序给出制定方法，并说明这类规则可以怎样在 ONES 的工作项与流程配置中承载。
要点总览（TL;DR）
- 分派规则先固定四个决策点：谁受理、依据什么判断、分给谁、分错如何纠正，每个决策点都要有输入、输出和责任人。
- 分诊入口把产品/模块、版本、环境、复现步骤、影响范围设为必填，字段缺失时写明退回补录或先行分派的处理动作。
- 责任定位以模块责任人表为主干，按主责人、备份人、严重程度、值班轮换的顺序分派，跨模块缺陷按根因归属并保留转派记录。
- 重复、无效、待确认三类结论各有判定依据和处置动作，无效判定需举证，争议由模块负责人复核、产品负责人裁定。
- 上线后用分派准确率、退回率、首次分派时长校准规则，分诊会议复盘结论转化为责任人表和判定条目的具体修订项。
先定分派规则的四个决策点
制定分派规则时，先不要急着写条款，而是把规则要回答的问题固定下来。一条缺陷从提交到有人接手，中间需要四次判断：谁负责受理、依据什么信息判断、判断结果分给谁、分错之后由谁纠正。四个问题各有输入和输出，缺一个，规则就会在执行时退化成“找熟悉的人问一下”。
| 决策点 | 要回答的问题 | 输入 | 输出 |
|---|---|---|---|
| 谁受理 | 缺陷提交后由哪个角色在什么时点接手判断 | 提交入口、受理值班安排 | 分诊人及其受理时限 |
| 依据什么判断 | 用哪些字段和标准判断缺陷的有效性与归属 | 产品/模块、版本、环境、复现步骤、影响范围 | 判定结论：有效、重复、无效、待确认 |
| 分给谁 | 有效缺陷落到哪个责任团队和具体处理人 | 模块责任人表、严重程度、值班安排 | 主责人、协办人、优先级 |
| 分错如何纠正 | 归属判断有误或信息不足时如何改派和升级 | 改派申请、争议记录 | 改派结果、仲裁结论、规则修订项 |
规则颗粒度需要在制定初期做取舍。按模块划分最贴近代码与业务边界，定位准确但责任人表维护成本高；按严重程度划分适合先保证高优先级缺陷快速响应，但无法回答“具体谁修”；按产品线划分适合多产品并行、团队边界清晰的场景，颗粒较粗，通常还需要在团队内部再落到模块。实践中常见做法是以模块为主干、以严重程度决定响应顺序、以产品线界定升级路径，三者叠加使用，而不是只选一种。
还要划清分派规则与缺陷生命周期状态规则的边界。分派规则管的是“进入受理后判给谁”，输出是责任人和判定结论；状态规则管的是“缺陷在修复过程中如何流转”，例如从待处理到修复中、待验证、关闭。两者在同一个工作项上衔接，但修订原因不同：分派规则因组织调整和模块变更而改，状态规则因研发流程变化而改。把两者混在一份文档里，后续维护时容易互相牵制。
分诊入口与必填字段怎么设
分派判断的质量取决于提交时采集到的信息。入口设计的目标是让分诊人仅凭工作项内容就能做出初步归属判断，而不必先找提交人补问一轮。缺陷提交入口应统一到项目的工作项入口，明确受理时点，例如“提交后进入待分诊状态，由当周分诊人在一个工作日内完成首次判断”。
支撑责任模块定位的字段应设为必填，其余字段按对判断的帮助程度设为选填。必填与选填的划分原则是：缺少该字段会导致无法判断归属或无法复现，就必填；只影响修复效率、不影响归属判断，可以选填但建议填写。
| 字段 | 填写要求 | 对分派的作用 |
|---|---|---|
| 产品/模块 | 必填，从预置选项中选择 | 直接映射责任团队，是分派的主依据 |
| 版本 | 必填 | 判断影响范围，区分回归缺陷与新引入缺陷 |
| 环境 | 必填，如测试、预发、生产 | 生产环境缺陷通常需要提高响应级别 |
| 复现步骤 | 必填，至少包含操作路径与预期、实际结果 | 判断是否为有效缺陷，也是开发接手的前提 |
| 影响范围 | 必填，描述受影响的功能与用户范围 | 支撑严重程度评定与优先级排序 |
| 附件与日志 | 选填，建议截图或日志 | 辅助判断，缺失不阻断分派 |
| 发现阶段 | 选填，如冒烟、系统测试、线上巡检 | 辅助判断缺陷来源与责任环节 |
字段缺失时需要明确的处理动作，而不是让缺陷停在原地。常见做法是：产品/模块、复现步骤等关键字段缺失时，分诊人将缺陷退回提交人补录，并在工作项中写明缺什么、补录时限；非关键字段缺失时，分诊人可先行分派，在备注中标注待补充项。退回动作本身要留痕，便于后续统计退回率，判断是入口设计问题还是提交质量问题。
责任模块定位与处理人分配规则
从缺陷特征映射到处理人，依赖一张持续维护的模块责任人表。这张表至少包含模块名称、主责团队、主责人、备份人、协办团队和生效日期。建立方式是从产品功能结构或代码仓库目录出发，逐个模块指定主责人，由团队负责人确认；维护方式是每次组织调整、模块拆分或人员变动时同步更新，并在分诊会议上核对一次。
分派优先级建议按以下顺序执行，前一条能确定结果时不再进入下一条：
- 按模块匹配主责人，这是默认路径，覆盖大多数缺陷。
- 主责人休假或不在岗时，分给备份人；无备份人时分给主责团队负责人。
- 按严重程度调整响应顺序：阻断类缺陷直接分给主责人并同步团队负责人，普通缺陷按常规队列处理。
- 按值班轮换处理无明确模块归属的缺陷，由当周值班人先接手初判。
主责与协办要分开记录。主责人对缺陷的修复结果负责，协办人提供接口、数据或联调支持。跨模块缺陷的归属判定通常看缺陷的根因所在模块，而不是表象出现的页面；无法当场判断根因时，由分诊人指定一个主责团队先行排查，排查结论确认根因后再转派，转派记录保留在原工作项中。涉及多个团队且影响面较大的缺陷，升级到产品负责人或研发负责人协调，升级路径和触发条件应写进规则。
这类规则落到工具上，需要工作项字段、责任人配置和流转记录共同承载。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代并记录跟踪缺陷修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队之间流转。模块责任人表、分派优先级和改派记录可以依托工作项字段与负责人配置来组织，具体字段必填校验与自动指派范围需按实际项目配置确认。
重复、无效与待确认缺陷的判定规则
受理阶段识别非有效缺陷，目的是避免无效工作占用开发资源，同时不误伤真实问题。三类结论对应不同处置动作，判定依据要写成可核对的条目。
| 判定结论 | 判定依据 | 处置动作 |
|---|---|---|
| 重复 | 同一模块、同一版本、同一现象已有未关闭缺陷；或复现步骤指向同一根因 | 关联到原缺陷并关闭新缺陷，在原缺陷中补充新信息 |
| 无效 | 按描述无法复现且提交人确认环境无误；或属于需求变更、使用方式问题而非缺陷 | 记录判定理由与举证材料后关闭，通知提交人 |
| 待确认 | 关键信息不足，暂时无法判断有效性或归属 | 转待确认状态，指定跟进人和跟进时限 |
重复缺陷的合并要保留追溯关系，新缺陷关闭时关联原缺陷编号，避免同一问题被反复提交后丢失上下文。无效缺陷的判定需要举证：分诊人应写明判定理由，附上复现尝试记录或与提交人的确认结论，仅凭“看起来不是缺陷”不足以关闭。待确认状态要设跟进时限，例如三个工作日内由提交人补录或由分诊人组织复现，超时未补齐的按无效处理并通知提交人。
判定争议需要预设仲裁角色。提交人对无效判定有异议时，由模块负责人复核；仍不能达成一致时，提交产品负责人裁定。仲裁结论要回写到工作项，并作为规则修订的输入：同类争议反复出现，说明判定标准写得不够具体，应在下一次规则评审中补充条目。
角色分工与各环节交付物
分派流程涉及四类角色，每类角色在固定环节产出固定交付物，交接时点明确，才能避免缺陷在角色之间悬空。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 提交人 | 按模板提交缺陷，补齐必填字段，响应补录请求 | 字段完整的缺陷工作项 | 提交即交接给分诊人 |
| 分诊人 | 判断有效性、定位责任模块、完成首次分派 | 判定结论、主责人与优先级 | 受理时限内交接给主责人 |
| 模块负责人 | 确认归属、处理争议、维护模块责任人表 | 归属确认意见、责任人表更新 | 争议发生时或被要求复核时 |
| 开发处理人 | 接手缺陷、确认可复现性、推进修复 | 接手确认或退回说明 | 接手后一个工作日内反馈 |
分诊会议是规则运转的协作机制。组织者由测试负责人或质量负责人担任，参与者包括各模块负责人和分诊人，频次可按迭代节奏安排，例如每两周一次，缺陷量大时可改为每周。会议议题聚焦三类事项：待确认缺陷的集中判定、归属争议的当场裁定、分派规则与责任人表的修订建议。会议产出是决议记录和规则修订项，而不是逐条复述缺陷内容。
权限设置要与职责对应：分诊人可改派和转待确认，模块负责人可确认归属和发起升级，产品负责人可裁定争议和关闭无效缺陷。关闭权限不宜下放给所有提交人，避免缺陷在未经验证的情况下被关闭。权限方案应在规则文档中列明，并与工具中的角色配置保持一致。
示例：一条缺陷从提交到分派完成
以下为演示情景，用于说明规则如何串联执行，不对应真实项目。
测试人员在订单模块执行回归测试时发现优惠券叠加后金额计算错误。提交时填写：产品/模块为“交易-优惠券”，版本为 3.2.0，环境为测试环境，复现步骤为“领取两张满减券后下单，预期按最优组合抵扣，实际只抵扣一张”，影响范围为“所有参与满减活动的订单”，并附上订单截图。字段齐全，缺陷进入待分诊状态。
分诊人当天受理，先查重：在“交易-优惠券”模块下检索到一条同版本、同现象的未关闭缺陷，但该缺陷描述的是单张券场景。对比复现步骤后判断根因不同，不构成重复，判定为有效缺陷。随后查模块责任人表，“交易-优惠券”主责人为交易团队开发人员，当前在岗，直接分派为主责人，优先级按影响范围定为高。
开发接手后发现计算逻辑涉及促销引擎，而促销引擎归属营销团队，属于跨模块缺陷。开发在主责人确认根因位于促销引擎后发起转派，分诊人将主责团队改为营销团队并保留原处理人为协办人，工作项中记录转派理由和排查结论。分派完成后系统通知新主责人和原提交人，工作项状态更新为已分派，首次分派时长和转派次数计入统计。
规则上线后的校准与完成检查
规则是否有效，要用指标验证而不是凭感觉判断。建议观察三类指标：分派准确率，即首次分派后未被转派的比例；退回率，即因字段缺失被退回提交人的比例；首次分派时长，即从提交到确定主责人的时间。指标按周或按迭代统计，连续偏高时回到规则本身找原因：准确率低说明模块责任人表过期或归属判定标准不清，退回率高说明入口字段设计或提交模板有问题。
分诊会议的复盘议题应围绕指标展开：本周期转派次数最多的模块是哪个、待确认缺陷超时未处理的有几条、无效判定是否出现争议。复盘结论转化为具体修订项，例如更新某模块责任人、补充某类缺陷的判定条目、调整必填字段清单。规则文档要有版本号和修订记录，责任人表标注生效日期，两者同步更新，避免执行时引用旧版本。
规则上线前用下面的清单做一次完整检查：
- 四个决策点是否都有明确的责任角色和输出物。
- 必填字段清单是否覆盖产品/模块、版本、环境、复现步骤、影响范围，缺失处理动作是否写明。
- 模块责任人表是否覆盖全部在用模块，是否包含备份人和生效日期。
- 分派优先级顺序是否明确，跨模块归属判定与升级路径是否可执行。
- 重复、无效、待确认三类判定是否各有依据和处置动作，争议仲裁角色是否指定。
- 各角色权限是否与职责对应，改派、关闭、升级权限是否列明。
- 观察指标、复盘频次和规则修订机制是否确定。
清单全部通过，规则即可进入试运行；试运行期间保留人工兜底，待指标稳定后再收紧判定标准。
常见问题
模块责任人表多久更新一次，由谁负责维护？
建议把更新触发条件写进规则，而不是只定一个固定周期。组织调整、模块拆分、人员变动发生时，由模块负责人在变更生效前完成责任人表更新，并标注生效日期；没有变更时，在分诊会议上按迭代或按月核对一次即可。维护责任落在模块负责人身上，分诊人负责发现过期条目并提交修订建议。责任人表长期不更新，分派准确率会先下降，转派次数随之上升。
提交人对无效判定有异议，流程上怎么处理？
先由模块负责人复核判定理由和举证材料，这是第一层仲裁；仍不能达成一致时，提交产品负责人裁定。仲裁结论要回写到工作项，保留判定理由、复核意见和最终结论。同类争议反复出现，说明判定标准写得不够具体，应在下一次规则评审中补充条目，而不是每次靠个案裁定。
待确认缺陷超过跟进时限还没补齐信息，应该关闭还是继续挂起？
规则里要预先写明超时处理动作。常见做法是三个工作日内由提交人补录或由分诊人组织复现，超时未补齐的按无效处理并通知提交人，同时保留重新提交的入口。继续无限期挂起会让待确认队列越积越多，也会让分派准确率和首次分派时长的统计失真。如果某类缺陷经常因同一字段缺失进入待确认，应回头调整入口必填字段或提交模板。
分派规则和缺陷状态流转规则可以写在同一份文档里吗？
可以放在同一份流程文档中，但建议分成两个章节并分别维护。分派规则管受理阶段的判断与责任归属，输出是判定结论和主责人；状态规则管修复过程中的流转，例如待处理、修复中、待验证、关闭。两者的修订原因不同：分派规则随组织调整和模块变更而改，状态规则随研发流程变化而改。混在一起写，后续修改时容易互相牵制。
规则试运行期间，自动分派和人工分诊怎么配合？
试运行阶段建议保留人工兜底：规则给出建议归属，分诊人确认后再正式分派，并记录人工调整的原因。等分派准确率稳定后，再逐步收紧判定标准、扩大规则覆盖范围。工具层面，ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并统计缺陷状态分布；模块责任人表、分派优先级和改派记录可依托工作项字段与负责人配置组织，具体字段必填校验与自动指派范围需按实际项目配置确认。
