研发团队如何高效管理 BUG 和迭代｜外包团队实操

先说个场景

周一早会还没开始，客户群里三条 @ 你：上周提的两个 bug 说"还在看"，第三个没人接。转头问开发，开发说"我以为那个是需求"。

不是能力问题，是流程没接上。外包团队尤其容易踩——客户多、需求碎、交付节点硬，bug 和迭代各管各的，就变成互相挤占。

入口只能有一个。 微信、电话、邮件、客户老板直接找开发——bug 能从五个地方进来，就一定会有漏的。定死一条：全部进同一个列表，谁收到谁录，录完群里回一句"已记录 #123"。五分钟的事，省掉后面半小时扯皮。

状态别超过五个。 十几个状态的看板没人维护得动。够用的是：新建 → 已确认 → 修复中 → 待验证 → 关闭，另加一个"非缺陷/暂缓"，装"这不是 bug"和"客户说不急"的东西。别删，删了下次又提一遍。

谁来关？提单的人。 开发自己关 bug 是最常见的坑。他本地跑通了就关，客户环境没更新，第二天又炸。规定：只有提单人验证通过才能关，开发最多推到"待验证"。

必填字段四个： 环境（哪个客户、哪套部署）、复现步骤、影响版本、期望 vs 实际。少一个就打回去。这一步做扎实，"你用的哪个浏览器"能少问一半。

分个级：

关键是 P0 的定义写死，别让客户觉得什么都是 P0。

产品团队可以排到 100%，外包不行。客户中途插需求、要演示、要临时导数据，一定会发生。排满了就只能靠加班补，补两次团队就散了。

两周一个迭代，容量按 80% 排。 剩下 20% 接插单和 bug。插单不是不能接，接了就得从迭代里换出一个同等大小的任务，让客户看见代价。这步很多人不好意思做，但不做的结果是延期永远算团队的锅。

需求进迭代前，验收标准写清楚。 "导出报表要快一点"——多快？一万行几秒？谁说了算？写不出验收标准的别进迭代，先去澄清。

站会十分钟，只问三件事： 昨天做完什么、今天做什么、卡在哪。第三件最重要，卡住的事当场指人跟进。

迭代末复盘半小时。 不写文档，就问：承诺的做完了吗？没做完什么原因？下个迭代改一件什么事。改一件就够，改多了等于没改。

最大的脱节是：迭代计划里没给 bug 留位置，bug 全成了"额外工作"。

做法很简单——每个迭代固定留 20%~30% 容量给 bug 和历史债，写进计划，不是偷偷做。这样"这个迭代做了 8 个需求、修了 15 个 bug"是能解释的，不用每次汇报都说不清人力去哪了。

版本发布也和迭代对齐。别随到随发，攒到迭代末一起发，客户那边也少几次"又更新了"的打扰。

不用天天看，迭代结束扫一眼。

流程写在文档里没人执行，等于没有。真正起作用的是：客户从门户提单，自动进列表；需求、任务、bug 挂在同一个迭代下；工时记在具体条目上，月底不用靠回忆。

Stepwise 就是照这个思路做的——需求、BUG、迭代、工时在一条线上，客户门户让客户自己提单、自己看进度，省掉群里刷屏。支持私有化部署，客户要求数据不出内网时不用另外折腾。

如果你们现在还是靠群和 Excel，别一次改太多。先把 bug 入口收敛成一个、状态收到五个，跑两周看看。跑顺了再加迭代规则。