Bug跟踪管理系统的工作流怎么配：状态、字段、通知三件事

配一套 Bug 处理流程，返工通常不是因为状态设得太少。状态、字段、通知这三件事，任何一件单改，另外两件都会跟着失效。状态加了，字段没跟上，解决时说不清影响范围；字段加了，通知没跟上，辛苦填的内容没人看；通知先配好，状态一调整，规则又要推翻重来。

所以这篇不按功能菜单讲，而是按配置顺序讲三件事：先把状态和流转定下来，再决定字段收哪些信息，最后配通知。顺序反了，前面配的东西大概率要重做。这些设置都在管理后台完成，需要管理员或流程配置权限；动手之前，先把现有的状态列表、字段和通知规则导出或截图存档，调整后不合适可以按原样退回去。配完之后，你应该能随口回答两个问题：某条 Bug 现在卡在谁那里，这个版本为什么还有这么多 Bug。

一、先看清工作流管的三件事

1. 状态、字段、通知的分工

把 Bug 跟踪管理系统里的工作流拆开看，它其实只回答三个问题：

• 状态回答这条 Bug 走到了哪一步，它是流程里的位置，决定谁该接手。

• 字段回答判断下一步需要哪些信息，它是决策依据，决定这条记录能不能被直接处理。

• 通知回答谁需要在什么时候知道，它是协作触发，决定下一个动作会不会被漏掉。

三者不是并列的功能，而是有先后的依赖关系。状态没定，你不知道哪一步会因为没有信息而卡住，必填字段就没有设立的理由；字段没定，通知里写不出严重程度、影响版本这类关键信息，接收人只能点开才知道要不要管；通知先配，状态一改，规则基本作废。

2. 配置前先定三句话

动手之前先把三句话写清楚，写不出来就先别动后台：

1. 谁来提——测试提单，还是客服与用户反馈渠道汇总。

2. 谁来解——直接指派开发，还是先由模块负责人分流。

3. 谁来关——测试验证后关闭，还是由质量负责人统一关。

这三句话对应的是角色边界。反复返工的工作流，问题几乎都不在配置技巧上，而在于团队对谁负责这件事没有共识。角色边界清楚之后，多数团队要做的不是从零设计流程，而是在禅道内置的 Bug 工作流上按自己的边界调整。禅道的测试管理默认已覆盖 Bug 从提交到关闭这一条链路，具体覆盖范围以官方帮助文档为准。

二、状态与流转：状态不是越多越好

1. 一条 Bug 走完需要哪些状态

最小可用的闭环是四个状态：待确认 → 待解决 → 待验证 → 已关闭。

每个状态都要能回答三件事：谁负责、从哪进来、往哪出去。答不出来的状态，过一段时间就会变成没人管的角落。

状态名在不同团队、不同工具里并不统一，这里给的是通用模型，配置时按自己工具里的命名落地。图里的回退路径属于分支情况，放在第 3 节说明。

2. 状态、动作、解决方案不是一回事

容易混淆的是这三个概念：

• 状态是位置，描述这条 Bug 现在停在流程的哪一步，比如待确认、待解决、待验证。

• 动作是按钮，负责把位置往前推，比如确认、解决、激活、关闭。

• 解决方案是解决时给出的结论，说明为什么这样处理。

常见错误是把解决方案当成状态来用：在状态列表里加上重复、设计如此、无法重现，结果状态越加越多，统计口径也越来越乱。这类结论应该留在解决方案字段里。

判断一个词属于哪一类，看它在流程里的职责：表示当前位置的是状态，表示一次操作的是动作，表示处理结论的是解决方案。三者名称有时很接近，判断依据是职责，不是字面。

禅道默认提供设计如此、重复、外部原因、已解决、无法重现、延期处理和不予解决等解决方案，团队可以按自己的口径在后台调整；具体默认项以官方帮助文档和当前版本的后台配置为准。

下面这张表把四个状态的待办角色和进出条件对齐，可以直接拿去和团队核对。

每个状态原则上只设一个待办角色，出口明确。这张表的作用在于：任何一条 Bug 卡住时，都能直接指出卡在谁那里。

3. 分支情况怎么处理

主链路之外，实际工作里一定会出现分支，处理方式要事先约定：

• 验证不通过：用激活把 Bug 退回待解决，不要为同一个问题新开一条记录。

• 判定不是 Bug：用解决方案说明原因后关闭，保留原始记录，避免同类问题反复讨论。

• 重复：关联到已有 Bug 上，两条并行会导致修复和统计重复计算。

• 确实要改但当前不做：选延期处理，并写清什么条件下重新评估。

• 本质是需求：转需求继续走产品流程，Bug 侧留痕即可。

分支写清楚了，一套流程才算完整。禅道的工作流管理支持对流程、动作和相关选项做配置，分支多、口径不一的团队可以在这一层调整，不必靠人工在群里催。

4. 一个状态该不该存在的判断标准

分支处理完，回到更基础的问题：这些状态本身有没有必要存在。

判断只看两个条件：它有明确的待办角色，并有明确的进入条件。两条缺一条，就把它合并到相邻状态。

如果一个状态的作用只是等待，那它多半是在流程里人为加了一个等待区。等待不是状态，等待是时间，应该用超期提醒或统计口径去管。

三、字段：先定用途，再谈加不加

1. 字段的三种用途

一个字段该不该存在，先看它服务哪种用途：

• 给人看：重现步骤、运行环境、日志片段，修复的人要靠它复现问题。

• 给判断用：严重程度、优先级、影响版本，排期和决策的人要靠它排序。

• 给统计用：所属模块、发现阶段、Bug 来源，复盘的人要靠它定位问题集中的环节。

用途说不清的字段，过一段时间就会变成没人填的空白列。

2. 严重程度和优先级为什么要分开

这两个字段经常被合并，理由是填两个太麻烦，结果是 Bug 排序失去依据。

严重程度描述 Bug 本身造成的影响有多大，判断依据是功能受损范围、是否阻断测试、是否涉及数据安全，一般由测试或质量角色给出。优先级描述现在应该先处理哪一个，它会受发布时间、用户范围、临时规避方案和合规要求影响，一般由排期角色调整。

把两者分成高、中、低还是更多等级，各团队的做法并不统一。真正需要统一的是每个等级的判断条件，以及谁有权调整它。

两个字段组合起来是四种情况，处理方式并不对称：

四种组合里，高严重、低优先这一种比较容易被误判。它不是不重要，只是当前触发条件窄。把它排在后面时，要写清复查条件；用户范围或业务阶段一变，优先级就要重估。

3. 必填字段划到哪里为止

必填的判定标准只有一条：缺了它，下一步就无法判断。

按这个标准复盘，很多团队会发现必填设多了。提交环节强制填写位置、复现频率、外部客户信息，会让提单人为了绕过校验而随便填，反而污染数据。

真正需要在流程早期就锁住的通常是这几类：能复现的操作步骤、影响版本，以及描述不清就无法定位的标题。影响版本和解决版本这一对尤其重要，它们决定了能不能追溯一个问题最终修在了哪个版本。Bug 与需求、用例的关联字段也建议早配，这样需求管理侧的验收和 Bug 侧的修复才能对得上。

4. 什么时候才该加自定义字段

加字段的触发条件有三个，满足其一再动手：

1. 同一信息被不同角色反复口头确认。

2. 统计报表缺一个口径，导致结论说不清。

3. 流程某一步的判断明确依赖这条信息。

不该加的信号同样清楚：存量记录里没人填、与已有字段语义重叠、只是因为看起来更完整。加字段的代价不在创建那一刻，而在之后每个人都要多填一次、每张报表都要多维护一列。

确定要加之后，按这个顺序做：

1. 在后台新增字段，选好类型，一次把选项列全。下拉和复选框的选项值反复改，会让已经填过的记录对不上。

2. 指定它出现在哪些页面。列表页用于扫读，编辑页用于填写，两处不必同时打开。

3. 先设为选填，观察一段时间看填写率和取值分布，再决定要不要收紧成必填。

4. 需要参与流程判断时，把它绑定到真正需要它的那一步，不必做成全局必填。

5. 回看一次：如果它在统计里几乎没有被使用，就撤掉。

禅道支持在后台自定义字段，也支持在工作流中把字段挂到具体步骤上，具体入口与限制以官方帮助文档和当前版本为准。

四、通知：让该知道的人在恰当的时候知道

1. 通知泛滥的原因

通知失控，通常不是因为数量多，而是因为按事件全量推送、不区分角色。所有人收到所有变化，几次之后成员就开始屏蔽消息，真正需要处理的那条也跟着被忽略。

2. 配通知前先回答三个问题

每一条通知都应该能回答下面三个问题，答不上来就先不发：

• 谁需要知道：写角色，不写具体的人。人一换岗，按人配的规则就失效。

• 什么时候知道：状态变化、条件满足（严重程度达到某一级、超期未处理），还是被点名。

• 看完要做什么：这条通知对应哪个动作。没有动作的通知只是噪音。

按这个框架，一条 Bug 主链路上的通知大致是这样：

这张表里的每一行都能落到具体角色身上，也都能对应一个下一步动作。

3. 通知配置放在哪一层

同样是状态变了要通知，配置位置不同，效果差别很大。

• 个人订阅：管的是个人想收到哪些消息。接收人、渠道、合并规则和免打扰属于个人偏好与企业消息策略，通知失败不影响流程本身。

• 工作流步骤后置动作：管的是某个步骤完成后必须发生的事。它跟随流程配置一起生效和调整，无论用户从详情页、看板还是接口操作，结果一致。禅道的工作流支持为流程对象增加自定义动作，在其项目变更流程里，就有配置通知干系人动作的做法，这类与步骤绑定的通知属于这一层；具体可用范围以官方帮助文档和当前版本为准。

• 独立自动化规则：处理的是条件跨对象、动作不止一条、还要能单独停用的场景。比如只有来自外部客户的最高严重程度 Bug 在验证通过后，同时通知客户协作群并生成一条复盘任务。这类规则需要独立的触发条件和运行记录，一般由流程引擎或自动化工具承担，不在基础通知设置里。如果手上的工具没有这一层，就把它拆成两条简单规则，或者先用人工流程兜住。

选择逻辑可以压缩成一句话：个人偏好放订阅，步骤必备放工作流，跨对象且有独立条件放自动化。

落到操作上，按这个顺序配：

1. 先按事件列出上面那张通知表，把每行的接收角色和期望动作写清楚。

2. 判断每一行该放在哪一层，个人偏好、步骤必备、跨对象规则分开放。

3. 配完先让两个真实角色实际接收一遍，确认标题里有对象编号和状态变化，正文有关键字段。

4. 上线一段时间后收一次反馈，以删除为主，不要急着加，直到没有人抱怨消息太多。

4. 通知内容写什么

通知本身的信息量，决定了它是有用还是打扰：

• 标题带对象编号和状态变化，让接收人一眼知道是哪一条、变成了什么。

• 正文带关键字段：严重程度、影响版本、重现步骤要点、期望动作。

• 给合并和延迟留位置：同一人被连续指派多条时合并成摘要，非工作时间的通知延迟到下一个工作时段。

五、配置完怎么验收

1. 用一条真实 Bug 走完全链路

配置完成后，找一条真实 Bug，从提交开始手动推一遍：确认、解决、验证不通过、激活、再解决、验证通过、关闭。每一步记录三件事：是否卡住、谁在这里等待、有没有收到通知。

2. 三个验收信号

跑完之后，用三个信号判断这套配置能不能上线：

• 状态无死角：对照状态表逐条核对，每个状态都能指出当前的待办角色和下一个位置。

• 字段有实际用途：必填字段在后续环节确实被使用，比如排期时看严重程度、回归时看影响版本。

• 通知不遗漏也不轰炸：关键角色都收到了，同时没有人抱怨又多了一堆消息。

三个信号里，第二个容易被忽略。字段是否被真正使用，可以直接看效能与统计数据：分布集中在一两个取值、或者大面积为空的字段，就是闲置字段。

3. 上线后的调整节奏

前期按发现一个问题改一处的节奏走，一次改太多，会看不清究竟是哪一处改动起了作用。稳定之后，把口径写进团队规范，作为新人上手和工具配置的依据。

每次调整都留一条记录：谁改的、为什么改、影响哪些角色。留记录这件事，在多人共管的系统里比较重要——没有记录，过一段时间就没人说得清某个状态为什么存在。

六、不同团队怎么取舍

同一套方法，团队规模不同，落点不同。

1. 小团队：够用就好

单产品、十人以内的团队，配置做减法：状态控制在三到五个，必填字段只保留无法事后补的，通知只覆盖闭环上的关键节点。这个阶段的重点是把流程跑顺，不是把字段配全。

2. 多产品多团队：先统一口径

产品线一多，容易出的问题不是流程不一致，而是同一概念在不同产品里有不同定义。Bug 严重程度的取值、模块的划分方式、状态名称，这些基础口径建议统一维护一处，差异只体现在必填范围和通知范围上。

这一层也是工作流与项目管理的分工边界：状态流转管这件事怎么走，审批管谁能批准，两者职责不要混在一起。配置本身属于后台治理工作，需要有明确的责任人。

3. 交付与合规场景：多留可追溯记录

有审计或体系认证要求的团队，配置目标会多一条：任何一次改动都能回答谁改的、什么时候改的、关联了哪个需求和用例。做到这一点，靠的不是临时补材料，而是把关联关系在日常流转中就记录下来。

七、常见问题

1. Bug 提上来没人认领，配置上怎么兜住？

给每个状态指定默认的待办角色，不要依赖谁主动认领。指派后超过约定时间仍无人确认，就把提醒升级到该角色的负责人。责任落在角色上，人员变动时才不会断。

2. 改了状态和字段，历史上的 Bug 怎么办？

先确认历史 Bug 当前所处的状态，在新流程里是否还有出口。没有出口的，在切换前为它们指定一个迁移后的状态。字段一般允许留空，但统计口径要标注从哪一天起生效，避免新旧数据混在一起看。

3. 管理层要看质量趋势，配置时该提前留什么？

至少留三样：模块划分口径、Bug 来源、发现阶段。缺了它们，趋势分析只能停在总数上，看不出问题集中在哪个环节，也分不清是内部测试发现的还是上线后被用户发现的。

4. 开发认为不是 Bug、测试坚持要改，流程怎么收口？

用解决方案字段记录判定结论，而不是让讨论停在群里。如果双方都到不了结论，指定一个裁决角色，通常是产品负责人或质量负责人，并在流程里给这个角色留出可操作的入口。

如果现在这套 Bug 跟踪管理系统的工作流已经在跑，但你说不清某条 Bug 卡在谁那里，或者找不到这个版本为什么还有这么多 Bug 的答案，通常就是三件事里有一件没配到位。从状态开始重看一遍，往往比继续加新功能更有用。