研发团队如何高效管理 BUG 和迭代 | 外包项目管理实践

外包团队管 BUG，难点从来不是「用哪款工具」。难的是 BUG 从哪来、谁定优先级、什么时候算真修完。

客户在群里丢一句「登录又不行了」，配一张糊掉的截图。这话在三个人脑子里过了一遍，没一条变成工单。三天后客户问进度，你翻聊天记录翻十分钟。

先把入口收掉。

一、BUG 只留一个入口，客户经理负责「翻译」

微信、电话、邮件、客户老板随口一句，都不能直接进研发。

留一个入口：客户门户提工单，或者客户经理代提。不管哪种，必须凑齐六样：

少一样就退回去问。听着麻烦，但它能砍掉一半「根本不是 BUG」的东西：缓存、客户自己改了配置、浏览器版本太老、以及「需求本来就长这样」。

外包最怕所有 BUG 都「很急」。客户急是正常的，你需要一把双方事先认过的尺子。

这张表最值钱的地方不是分得多准，是客户拿着它自己能判断「这个要不要现在打电话」。分级标准放进合同附件，验收时少扯一半的皮。

外包项目不存在「这个迭代没有新需求」。按 100% 排满，第一个插单就把计划打乱，然后整个迭代失控。

算法：可用人天 × 0.7。三个人两周，纸面上 30 人天，只排 21。剩下 9 天接 P0/P1，以及客户临时提、当天就要答复的小改动。

再加一个冻结点：sprint 开始后进来的需求，默认进下一个迭代。客户坚持要插，就说清楚砍掉哪一项，或者加钱。这句话在启动会上讲一遍，比事后吵十次都管用。

「完成订单模块联调并交付客户验收」是目标。「改 15 个页面、修 8 个 BUG、写 3 个接口」是清单。

清单的问题是，做完 80% 你也不知道这个迭代算成功还是失败。一句话目标能让你周三就发现要完，然后及时砍范围，而不是周五晚上加班。

半天粒度就够，不用精确到分钟。然后每周看 BUG 工时 ÷ 总工时。连着三周超过 30%，说明代码质量、需求理解或者测试环节有一个出问题了，停下来聊，别等客户投诉。

顺带的好处：报价时终于有依据，不用拍脑袋。

自测完就点关闭，是最常见的坑。客户下一轮再提一遍，你以为是新 BUG，其实是旧的没修好。

规矩很简单：谁提的谁验。客户提的客户验，测试提的测试验。关闭时写一句在哪个版本、怎么验的。

只问三件事：这周哪些 BUG 本来能避免？哪个估错得最离谱，为什么？哪个环节卡住了别人？

出 3 条 action，带进下个迭代。列 15 条改进项一条都不做的复盘，不如不开。

工具不是重点，但工具决定上面这些规矩能不能撑住。BUG、需求、迭代、工时散在四个地方，每一条都会慢慢走形。Stepwise 把它们放到一个平台里，客户门户让客户自己提单、自己看进度，能省掉大量「这个修好了没」的追问；需要甲方验收的项目，私有化部署也省事。

真要试，拿一个在跑的项目导进去跑两周，比看介绍有用。