研发团队如何高效管理 BUG 和迭代
外包项目很少死在技术难题上，多半死在两件事：BUG 说不清，迭代排不明白。
先看个常见场面。客户在微信群里发一句「登录又不行了」，PM 转给开发，开发回问：哪个环境？什么账号？点了哪几步？来回三轮，半小时没了。修完客户说「这不是我要的」，开发说「文档里就是这么写的」。然后开始扯皮，扯到最后往往是乙方免费改。
这件事能治。
一、所有 BUG 只留一个入口
微信群、电话、邮件、客户老板开会时口头提的——统统不算。这不是不尊重客户。没有记录的东西既没法排期，也没法结项。
统一走一个地方提，提的时候必填四样：
- 哪个页面、哪个功能
- 复现步骤，写「1、2、3」，不写「点一下就不行了」
- 期望结果，实际结果
- 截图或录屏，加上环境信息（账号、浏览器、版本号）
这四条不齐，单子直接退回。刚开始客户会烦，两周后就顺了，因为他们发现这样提的改得快。可以让客户自己在客户门户里提单，他能看状态，你少接三十条微信。
二、先分清是 BUG 还是需求变更
这是外包团队最容易漏钱的地方。
我们的判断标准很简单：按合同、需求文档、原型和验收标准做出来的东西，客户说「不好用」，那是变更；做出来跟文档不一致，那是 BUG。
变更走变更单，评估工时、报价、签了再排。BUG 直接进池子。这条规矩要写进合同附件，最好在项目启动会上当着客户的面过一遍。别指望事后解释。
三、定级：客户可以喊疼，级别由你定
让客户自己标级别，结果全是「紧急」。做法是把两件事分开：
- 客户提「影响」：影响多大、有没有绕行办法
- 开发负责人定「级别」和响应时间
| 级别 | 判断标准 | 响应 |
|---|---|---|
| P0 | 线上挂了、数据错了、客户正在演示 | 立刻，当天出结论 |
| P1 | 主流程走不通，没有绕行 | 24 小时内 |
| P2 | 有绕行方案 | 排进当周 |
| P3 | 文案、样式、体验 | 随版本 |
定完把理由写回给客户。他要是不认，就问他：这个能不能先这样用一周？多数时候能。
四、状态别超过五个
新建 → 确认 → 处理中 → 待验证 → 关闭。另外两个备用状态：挂起、不修复（要写原因，客户确认）。
状态一多就没人维护，看板就成了假的。每个单子必须有 owner，没有 owner 的单子三天就烂在那儿。
五、迭代：外包别硬套两周一个 sprint
一个开发同时挂三个客户的项目，你还按标准 Scrum 跑，那是自欺欺人。
我们按「交付批次」排，每周固定一次排期会：
- 先算容量：几个人、这周实际可用人天。请假、支持、开会都要扣。
- 只排 70%-80%。剩下 20%-30% 留给 BUG 和线上问题。排满 100% 的团队，来一个线上问题就全乱。
- 每个客户至少留一条「本周必交付」的线，让他感觉到进度，不然他天天来问。
- 批次结束必须有验收：客户签字或邮件确认，出一份简单的版本说明——改了什么、修了什么、还有什么没做。
没验收这一步，项目永远关不掉。
六、反复出现的 BUG，加用例，别加人
同一个地方修三次，问题不在人，在测试用例。把 BUG 的复现步骤直接抄成回归用例，下次改这块先跑一遍。花这点时间，比返工便宜得多。
七、每周就看三个数
- 新增 vs 关闭（看趋势，别看绝对值）
- 平均修复时长，按级别分开算
- 重开率：关掉又打开的占比。这个数高，说明修得快但没修对
给客户汇报别甩这些。就一句：「本周修复 23 个，剩余 11 个，P0/P1 已清零，版本 v1.4.2 已上线。」够了。
几个常踩的坑
- 复现步骤写成一段聊天记录截图，三个月后自己都看不懂
- 上线没打 tag，出问题不知道线上跑的是哪一版
- 迭代里没留测试时间，开发自测完就算完事
- BUG 单不关联需求和项目，月底算工时全靠回忆
我们在 Stepwise 里把这几个环节串在一起：需求和 BUG 挂在同一个项目下，BUG 能追溯回它来自哪条需求，工时按单子和人记，客户门户给甲方一个提单加看状态的入口。流程该有的都有，但不逼你改工作方式。私有化部署的话，直接装到客户内网也行。
最后
BUG 管理和迭代规划不是两件事，是一件事的两面：入口收得住，级别定得清，产能留得下，剩下的就是每周重复。做到这三条，团队不会突然变强，但交付会变得可预测。对外包公司来说，可预测比强更重要。
