BUG 和迭代打架，几乎所有外包团队都踩过这个坑。迭代计划排得漂漂亮亮，第三天客户一个电话，线上付款页面白屏，两个后端去救火，原本要交付的三个需求全顺延。一周后复盘，谁也说不清这个迭代到底做了什么。
问题通常不在人不够，而在于 BUG 和需求是两套流程在跑。
一、BUG 和需求，用同一把尺子量优先级
很多团队的做法是：需求走迭代，BUG 走「随时插」。结果 BUG 永远是最高优先级，迭代目标形同虚设。
稳妥的做法是给两类单据定同一套分级：
| 级别 | 定义 | 响应与处理 |
|---|---|---|
| P0 | 客户业务中断，线上不可用 | 2 小时内响应，当天出方案，走紧急通道 |
| P1 | 主流程能走，但结果错了 | 当前迭代内必须修完 |
| P2 | 体验问题、边缘场景 | 排进下个迭代，占固定比例 |
| P3 | 记录，暂不修 | 攒着，重构或下个大版本一起清 |
关键是 P2、P3 要有明确去处，不能「先记着」。没人处理的后台积压，三个月后就变成没人敢碰的坟场。
二、迭代别排满，留出缓冲
外包团队尤其要认这件事：你控制不了客户插单。一个 10 人天的迭代，排 8 人天需求，留 2 人天给 BUG 和临时变更。这不是浪费，这是让承诺能兑现的唯一办法。
排满了再被插单，延期就是必然；留了 20%，偶尔还能提前交付，客户的感受完全不一样。
三、BUG 单的填写模板，比工具更重要
最常见的浪费是来回问：在哪个页面？用的什么账号？能截图吗？一个 BUG 在复现上耗三天，比修复本身贵得多。
强制几个字段就够：
- 环境和版本号（测试 / 预发 / 生产 + 具体版本）
- 账号和角色
- 复现步骤，从第几步开始不对
- 期望结果 / 实际结果
- 截图或录屏
- 影响谁：哪个客户、多大范围、是否卡验收
一条 BUG 只记一个问题。一个单里塞五件事，最后谁也不知道修没修完。
四、迭代节奏：短周期，明确出口
两周一个迭代，对外包项目比较合适：够做完一件事，又不会让客户等太久。
每个迭代固定三个动作：计划会上把范围写死，顺便写清楚本次不做什么；中途只看 P0 和 P1；结束时做一次演示加半小时回顾。回顾别开成批斗会，只回答两个问题：这个迭代插了多少单，为什么插。
插单率连续两个迭代超过 30%，说明要么客户预期没管好，要么前期需求评审太草率。这两个都是 PM 的问题，不是研发的问题。
五、工时记下来，报价才有底气
外包最容易亏的地方是估算。BUG 修了多久、需求做了多久，如果只有「感觉」，下次报价还是拍脑袋。
要求工程师在单据上记实际工时，粒度到 0.5 小时就够。三个月后你会有自己的基线：这类需求平均多少小时，这类 BUG 平均多少小时。报价、排期、跟客户谈变更，全靠这份数据。
几个常见的坑
- 拿 BUG 数当考核指标。工程师会开始藏 BUG，或者把一个问题拆成三个「完成」。
- 迭代目标写成「修完所有 BUG」。这个目标永远不成立，团队很快就懒得看目标了。
- 不做回归。一迭代修了 20 个 BUG，又开出来 15 个。
- 客户看不到进度，所有沟通都压在 PM 一个人身上。PM 变成传话筒，每天在这件事上耗掉半天。
这些事的共同点是：流程上省掉一个环节，就会在别的地方多花三倍时间。
Stepwise 里需求、BUG、迭代、工时本来就是同一套数据：BUG 单可以直接挂到某个迭代或某个需求上，工时记在单子上，客户在门户里自己提单、自己看状态，PM 不用再挨个转述。需要私有化部署的团队，直接装到自己内网就行。
先把 BUG 的入口和出口管住，再谈迭代。顺序反了，工具再好也白搭。
