• 文档
• 知识库

导读：本文以开源项目 tlroadmap 知识库中 Technical Lead 角色下"产品质量保障（Обеспечение качества продукта）"分支的 Bug 管理（Работа с багами） 文档为骨架，系统拆解一套从"发现 Bug → 登记 → 优先级排序 → 定期复盘"的完整工作流。读完你将掌握：如何搭建 Bug 工作流的四大构成（待办列表、填充规则、复盘流程、责任主体），如何根据团队结构（矩阵式组织、Bug 工厂模式）选择配置，以及 Zero Bug Policy（零 Bug 政策）的适用前提与三类代价，并学会把它与 Code Review、测试、事故管理等相邻能力分支协同落地。

什么是 Bug 管理：它在 tlroadmap 中的位置

在 tlroadmap 的能力树中，这条分支位于Роли（角色）→ Technical Lead → Обеспечение качества продукта（产品质量保障）→ Работа с багами，对应仓库路径 tlroadmap/roles/technical-lead/product-quality/bugs/ru.md。父级节点 product-quality/ru.md 与 technical-lead/ru.md 只保留 Frontmatter 元信息，起逻辑分组作用；真正的能力描述全部落在"叶子"文件上。

原文档对这条分支的定义非常精炼：它是"登记（наполнение）、优先级排序（приоритизация）与复盘（разбор）Bug"的完整流程。流程的产出不是某个工具，而是让团队对 Bug 这件事"看得懂、可透明"——任何人发现一个 Bug 后都知道接下来会发生什么。

值得注意的是，它与同目录下的其他能力分支共同构成质量闭环：Code Review 负责在合入前拦截缺陷、测试 负责验证行为是否符合预期、需求测试 负责在上游消灭错误、事故管理 负责生产环境突发问题的快速恢复。Bug 管理正是把"已确认的错误行为"纳入受控治理的入口。

为什么这条能力分支重要

原文档给出的核心理由是：系统中的 Bug 就是系统的错误行为，当关键 Bug 数量过多时，系统质量会急剧退化，最终传导到产品指标上。围绕这一点，流程为不同角色分别带来价值：

• 对 Tech Lead 而言：这是掌握系统状态的抓手。通过观察"Bug 登记速度"与"Bug 复盘速度"的动态对比，可以同时得到两个结论——产品本身存在哪些问题、以及开发团队的工作状态如何。动态数据比静态清单更有诊断价值。
• 对团队而言：发现 Bug 后有清晰的动作指引（往哪登记、谁来跟进），并且知道系统的错误行为将如何被消除，避免"发现了没人管"的恐慌与内耗。
• 对产品与用户而言：用户遇到错误行为的频率下降，关键场景下"几乎不会遇到"；同时，用户反馈本身成为 Bug 复盘流程的入口之一——这意味着客服、反馈渠道收集到的信息要能汇入同一个待办列表，而不是散落在聊天记录里。

从仓库视角看，这条分支与 需求测试分支 中引用的 McConnell 数据形成呼应：需求阶段引入的错误约占产品总错误量的 30%，且该阶段修复成本最低。Bug 管理解决的正是"已经漏到下游的错误行为"，而需求测试与 Code Review 负责让漏进来的 Bug 变少——两条分支一前一后，构成质量治理的完整拼图。

如果不做 Bug 管理，会发生什么

原文档列出了两个直接后果：

1. 职责不清：没人说得清"谁来复盘、什么时候复盘"。团队成员对同一件事的预期不一致，冲突由此产生。
2. 失控退化：系统开发过程中新 Bug 必然不断产生。没有流程约束，退化就是不可控的——直到关键 Bug 堆到影响产品指标。

这两点都指向同一个管理本质：Bug 治理不是"把问题记下来"，而是"对错误行为的生命周期建立确定性"。

这条分支可以委托给谁

原文档明确指出，Bug 管理流程可以整体或部分地委托出去，常见人选包括：

• 团队或公司中的资深 QA 工程师（熟悉缺陷生命周期、擅长与开发沟通）；
• Scrum Master（掌握迭代节奏，适合组织定期复盘）；
• 产品经理（Product Manager）（负责判断业务优先级）。

这与 tlroadmap 中 委托（Делегирование）分支 的核心思想一致：领导者的成长依赖于把已掌握的能力连同权限一起交付给团队。委托时需要注意配套控制手段——明确复盘频率、输出物与质量标准，而不是"甩出去就不管"。

好行为与坏行为对照

原文档用一组行为清单帮助团队自检现状，这里完整保留并归类：

坏行为（红灯信号）

• 发现的 Bug 不登记，结果永远得不到修复；
• 只有 QA 知道"怎么登记、往哪里登记"，知识集中在一小撮人手里；
• 要求"所有 Bug 必须立即修复"——没有优先级意识，等于没有策略；
• 待办列表的增长速度远超复盘速度；
• 上级塞来的任务自动获得最高优先级，与实际关键程度无关；
• 待办列表里堆满陈年旧 Bug。

好行为（绿灯信号）

• 团队每个成员都知道发现 Bug 后该做什么（去向、登记方式、后续路径）；
• 定期划出专门时间复盘 Bug，待办列表保持"不膨胀"的健康状态。

这两组行为的对照价值在于：坏行为的根因往往是"流程缺位"（没有登记规则、没有优先级规则、没有复盘节奏），而不是"人的态度问题"。因此改善手段也应落在流程设计上，而不是问责个人。

实践：如何搭建一套 Bug 工作流

四大构成要素

原文档强调，任何 Bug 管理系统都由四个部分组成，缺一不可：

配置没有唯一正确答案，取决于团队结构。原文档给出了两个典型形态：

• 矩阵式组织：Bug 收集与填充归 QA 部门统一负责；复盘则由开发人员以周期性"Bug 复盘会"的形式消化。职责在"收集"与"消化"之间自然切分。
• Bug 工厂（багодельня）：把复盘做成带游戏化元素的 Hackathon 式马拉松，集中时间"猎杀"积压的老 Bug。这类做法的价值在于把枯燥的积压清理变成有激励、有氛围的团队事件——Avito 的相关实践（一天内找到 200 个 Bug）就是这种模式的代表案例。

在 tlroadmap 的自我定位中（见 README.md 与 首页），技能地图被设计为"可适配任何公司与团队"的模型——这与原文档"配置因团队结构而异"的立场完全一致：流程是骨架，配置是血肉。

Zero Bug Policy（零 Bug 政策）

原文档用较大篇幅剖析了这一争议性方案，先看它要解决的问题：

传统"登记 + 定期复盘"模式最大的批评是：待办列表照样膨胀。原因很现实——对产品方而言，做新功能比清旧 Bug 看起来更有前景；对测试方而言，直接把 Bug 丢掉又违背职业本能。结果就是待办列表变成"夹层/阁楼（антресоль）"：Bug 进得去，出不来。

Zero Bug Policy 的核心理念是"不存储 Bug"，把 Bug 直接分成两组处理：

• 关键 Bug：拉下紧急制动阀（стоп-кран），在同一个 Sprint 内修完；
• 非关键 Bug：直接忘掉它——如果每个非关键 Bug 都堆进列表，待办列表只会永无止境地增长。

需要特别澄清的是，这不等于降低质量底线。原文档明确写道：这只是承认"产品里存在一定数量的 Bug 是正常的"，把有限精力集中在真正影响用户的错误行为上。

原文档同时给出了对这一方案的三类批评，需要落地前认真评估：

1. QA 团队可能退化：如果"我的 Bug 反正会被丢掉"，测试人员还有多少动力深挖缺陷？
2. 被丢弃的 Bug 有累积效应：单个 Bug 看似无关紧要，但多个被丢弃的 Bug 叠加后，可能在团队决定修复某个 Bug 时"连环引爆"。
3. 失去信息源：没有历史 Bug 记录，每次排查都像从零开始，无法从过去的问题中汲取经验。

因此，Zero Bug Policy 更适合信息能快速闭环、迭代节奏快的团队；而团队若依赖 Bug 库做知识沉淀，则宜采用"登记 + 定期复盘"的经典模式，或两者的混合体——关键 Bug 进 Sprint，非关键 Bug 进入低频复盘的长期队列。

与相邻能力分支的协同（仓库级佐证）

Bug 管理不是孤岛。tlroadmap 知识库中相邻分支的原文档提供了可交叉引用的落地线索：

• 上游预防：需求测试分支 提出用 CRUDL、决策表、使用场景等技法在开发前消灭需求错误（约占总量 30%）；Code Review 分支 则用"先问业务逻辑、再看架构、最后抠细节"的三步流程拦截合入前的缺陷。这两条分支做得越好，进入 Bug 工作流的流量就越小。
• 下游承接：事故管理分支 处理生产环境的突发中断；一次事故排障后暴露的缺陷，往往就该作为 Bug 进入本流程的待办列表——两个流程之间需要明确的转接约定。
• 优先级协同：待办列表优先级排序分支 讨论的是 PBI 的排序机制，而 Bug 列表同样需要一套"按实际关键程度排序、而非按喊声大小排序"的机制——这正好回应了坏行为清单中"上级任务自动最高优先级"的红灯。
• 迭代节奏：Scrum 分支 描述了 Sprint 与仪式结构；Zero Bug Policy 中"关键 Bug 在同一个 Sprint 内修复"的约束，天然依赖 Scrum（或其他固定节奏框架）提供的迭代容器。
• 入口规范：任务接收分支 强调"谁给团队派活、任务以什么形态进入团队"要透明——Bug 作为团队任务的形态之一，同样适用这套入口约定。

在 tlroadmap 中如何阅读与维护这类文档

理解这条分支的写法，有助于快速扫描知识库中其他能力描述。从仓库结构看，tlroadmap 的每条能力都是"目录即分支、%locale%.md即叶子"的约定（详见 贡献指南）：本分支文件位于tlroadmap/roles/technical-lead/product-quality/bugs/ru.md，采用统一的章节骨架——描述（Описание）→ 为什么重要（Почему ветка важна）→ 不做会怎样（Что будет, если её не делать）→ 委托对象（На кого может быть делегирована）→ 行为示例（Примеры поведения）→ 提升方法（Способы прокачки）→ 咨询与理论（Консультации / Теория）。

仓库还通过 tools/check_directory_tree.sh 做机械校验：目录名只能用小写字母、数字与连字符，文件名必须是ru.md/en.md/index.md等 locale 形式，且文件要么带 Frontmatter 的title字段、要么以 Markdown 一级标题开头。本分支文件正是"一级标题（# Работа с багами）"这一合法形态的实例——这种结构化的能力描述方式，使得每条分支都可以被单独评估、引用和移植到具体团队。

在使用层面，使用指南 给出了四种场景：制定个人发展计划、熟悉 Timlead 职责、界定公司内的责任范围、以及撰写 Timlead 招聘 JD 与面试提纲。对 Bug 管理分支而言，最直接的用法是拿"好行为/坏行为清单"对团队现状做差距分析，再按"四大构成"逐项补齐缺口。

咨询渠道与延伸阅读

原文档建议的咨询渠道是项目方维护的TL Bootcamp Telegram 社区（入口在文档"Консультации"一节），适合在实际落地时与其他 Timlead 交流配置取舍。

延伸阅读方面，原文档"Теория"一节收录了以下外部资料（此处仅保留标题与主题线索，便于按名检索）：

• 《Ещё один взгляд на разбор багов》——关于 Bug 复盘的另一种视角；
• 《Багодельня — марафон по убийству престарелых багов》——Avito 的 Bug 工厂：清除陈年 Bug 的马拉松实践；
• 《Багодельня: BUgHunting. Как найти 200 багов за день》——如何在一天内找到 200 个 Bug 的猎杀式复盘案例；
• 《Zero Bug Policy. Нет багов — нет проблем?》——对"没有 Bug 就没有问题吗"的专题讨论；
• 《Best engineering practices: how to fix a bug?》——从工程实践角度拆解"如何正确地修一个 Bug"；
• 《#zerobugpolicy или как мы баги чиним》——Dodo Pizza 工程团队落地 #zerobugpolicy 的真实记录。

小结

tlroadmap 的 Bug 管理分支给出了一个朴素但完整的治理框架：用待办列表收口、用规则约束填充、用流程保证消化、用责任主体兜底。在此基础上，Zero Bug Policy 提供了一种反直觉但值得权衡的激进选项——它的本质不是消灭 Bug，而是把注意力从"存储问题"转移到"修复关键问题"。结合仓库中 Code Review、需求测试、事故管理等相邻分支，一套"上游少漏、中游快修、下游沉淀"的缺陷治理闭环就能在团队中真正落地。

• 文档
• 知识库