BUG 不怕多，怕没人认领、没人排期、没人回访。外包项目最容易乱在这三件事：客户在群里甩截图，开发翻半天需求文档，项目经理在 Excel 里对状态。三天后，谁也说不清这个 BUG 修没修。

先把 BUG 入口收干净

  • 只留一个入口。客户群、邮件、电话里提到的问题，都转进 Stepwise 的 BUG 列表。群聊只做提醒，不做仓库。
  • 提单必填五项：环境、复现步骤、期望结果、实际结果、附件。缺了就打回。别让开发靠猜。
  • 角色分开：提单人、处理人、验收人。外包项目再加一个客户确认人。谁提的、谁修、谁点头，写清楚。
  • 定响应规则。比如 P0 线上不可用 2 小时内响应；P1 主流程卡住 1 个工作日；P2 一般问题进迭代；P3 建议不占迭代容量。规则可以改，但要写下来，别留在某个人脑子里。

迭代别做成许愿池

  • 每个迭代只放能验收的条目。需求、BUG、技术债分开打标签，别混成一锅。
  • 按容量排，不按人头拍。四个人不等于四乘五天全是功能开发。留 20% 给线上问题、客户沟通、部署和代码评审。外包团队尤其要留联调时间。
  • 迭代前开 30 分钟排期会。产品讲目标，开发估工作量，测试提风险。会议只产出两样东西：进迭代的清单，和明确不做的清单。
  • 每日站会只问三句：昨天完成什么，今天做什么，卡在哪。别开成汇报会。
  • 中期看一次燃尽图，也看 BUG 新增曲线。新增比关闭快，先停新功能，回头补质量。

BUG 和迭代要连起来

  • BUG 必须挂到迭代或版本。否则修了也不知道上没上线。
  • 流程简单点：新建 -> 确认 -> 修复中 -> 待验证 -> 客户验收 -> 关闭。每一步有负责人和时间戳。
  • 每周五做 20 分钟 BUG 复盘。只看三类：重复出现的、拖过响应时间的、客户升级的。产出动作：补测试用例、改代码规范、加监控。别开成批斗会。
  • 发布前看两个数：未关闭的 P0/P1 数量，回归通过率。没有数据就别拍板上线。

外包多一层：让客户看得见

  • 客户门户不是摆设。让客户自己提 BUG、看进度、确认验收。能少掉一半“修了吗”的重复询问。
  • 对外只暴露客户关心的状态，内部备注别外泄。
  • 发布说明写清楚：修了哪些 BUG、影响哪些模块、客户要验什么。

几个常见坑

常见坑 表现 处理
BUG 只留在聊天记录 客户问进度才翻群 统一进 Stepwise，聊天只做通知
迭代塞太满 每次延期，测试被压缩 按容量排，留 20% 缓冲
修复不关联版本 上线后说不清修没修 BUG 关联迭代/版本，发布单自动带出
客户验收缺失 修完又被打回 客户门户点确认，留痕

如果你们现在还在用 Excel 加群聊管 BUG，不用一次换全套。先把 BUG 入口和迭代列表搬到 Stepwise，跑两个迭代，再决定要不要接客户门户。工具是帮团队少扯皮，不是多一个填表的地方。