线性团队实践立即修复bug的方法与经验

当我第一次看到 @artman 关于在 Linear 优先修复 bug 的帖子时，我先是点了点头，然后深表赞同。我很高兴 @thorstenball 和我在 @AmpCode 从第一天起就彻底贯彻了这一原则。以下是我的心得：

• 立即修复（而非优先修复）：提交问题、排优先级、分配问题、更新问题的开销往往大于修复本身所需的时间。遇到或听说 bug 时立即修复，不要费心去创建工单。报告者不一定是修复者，但在放手之前必须确认 bug 会立即被修复。

• 反压力：如果你真正做到了立即修复 bug，你永远不会被 bug 淹没，因为你没有时间构建可能引入新 bug 的新功能。如果你被 bug 淹没，说明你没有充分坚持立即修复，新功能偷偷溜了进来。解决这个问题。必要时立即缩减范围，无论多么痛苦。

• 直接沟通：修复 bug 时，开发者直接与客户对话，没有中间人。为你正在对话的真实的人立即修复 bug 是有成就感且高效的；其他任何方式都是苦力活，需要更多的激励和管理上的打气。而且，客户喜欢与开发者交流。

• 15分钟规则：从客户报告 bug 的那一刻起，你需要在15分钟内将修复推送给客户。当然有些修复需要更长时间，但假设是一个简单的一行修复：15分钟到达客户屏幕。如果时间更长，就会打断客户的工作流，所以他们不会费心报告大多数 bug（因为他们在当前任务中无法受益于修复）。同时，你会扼杀自己开发者的奖励循环，分散他们的注意力，因为他们在 bug 解决之前会一直在心里惦记。如果修复需要数天才能发布，那么你将需要一套追踪和沟通修复的流程，等等，这样一来，管理开销将远远超过编码修复的时间。

• 重复，重复，再重复：立即修复 bug 是如此反常规，以至于你的团队一开始不会相信你是认真的。即使你已经重复了10次。你需要每一条团队消息中都提到它才能深入人心。即使你知道需要重复比你想象的更多，你还是会重复得不够。

• 大棒：是的，表扬你的团队立即修复 bug。但对80%的开发者来说，现实是你需要（至少一次）在他们偏离（出于好意）立即修复 bug 时直接给出建设性反馈。你必须使用大棒才能让它深入骨髓：“我知道你构建 xyz 功能时忽略 bug 是出于好意，但这不是我们的工作方式，我需要你不要再这么做了。”

• 抱歉与感谢：Bug 是生活的一部分，但这并不意味着它们可以被容忍。你可以说我老派，但我认为当客户遇到 bug 时你应该道歉，并感谢他们提出。知道你感激他们，客户会给你更多反馈。

（注：我们为开发者构建产品，我们拥有让人信任的出色团队，并且我们从 @AmpCode 第一天就开始实施立即修复 bug。这可能不适用于已有 bug 列表的现有产品或非开发者产品。我想对我们有效的做法也会随时间而改变。）