先把 BUG 从聊天记录里捞出来
外包项目最怕的不是 BUG 多，是 BUG 散。微信一条、电话一条、客户邮件一条，最后项目经理靠脑子记。三天后客户问“那个登录问题修了吗”，团队翻聊天记录翻半天。先把入口收口：所有 BUG 只进一个池子，来源可以是客户门户、测试、线上监控、内部同事，但字段必须统一。
至少要求这几项：项目/版本、环境（测试/预发/生产）、严重程度、优先级、复现步骤、预期结果、实际结果、截图或日志、报告人、负责人、截止时间。严重程度看影响，优先级看这周做不做，别混在一起。客户说“很急”不等于 P0，PM 要按影响面、是否有绕过方案、是否影响验收来定。
常见坑：
- 只写“页面报错”，没版本没环境，开发复现不了。
- BUG 和需求脱节，改完不知道影响哪个验收项。
- 客户在群里直接 @ 开发，PM 不知道，迭代计划被打穿。
- 关闭 BUG 没有验证人，开发说修了，测试说没修，来回拉扯。
迭代别排满，留出救火的口子
外包团队的迭代很容易被两件事打乱：客户临时加需求、线上问题插队。解决办法不是“让客户别提”，而是把口子提前留出来。两周一迭代，按可用工时排任务，别按“人头×天数”拍脑袋。把会议、联调、请假、支持都扣掉，再留 15%-20% 缓冲给 BUG 和临时问题。排满 100% 的迭代，第一周就会崩。
每次迭代只承诺“必须交付”的范围，其余进待定区。中途加需求可以，走变更：谁提的、为什么现在做、影响哪个任务、工期加几天，写清楚再决定。否则最后一定是测试时间被压缩，BUG 堆到上线前。
BUG 也要有预算。比如每个迭代固定留出 20% 左右工时处理历史 BUG 和线上问题；新 BUG 每天花 15 分钟过一遍：关掉重复的、补全信息的、定负责人和时间的。别开长会，站会式过一遍就行。
用工具把“说过”变成“可查”
Stepwise 这类研发管理平台的价值，不是多一个看板，而是把需求、BUG、迭代、工时和客户门户串起来。BUG 可以直接挂在需求或验收项下面，开发改完，测试验证，客户在门户里看到的是处理状态，不是群里一句“快了”。迭代规划时能看成员可用工时和历史 BUG 分布，避免拍脑袋排期。工时统计也能反过来校准：这类 BUG 平均修多久，下次排期就有数。私有化部署对外包团队也实用，客户数据不出自己环境。
落地别贪大。先做三件事：统一 BUG 字段、每天 15 分钟过 BUG、迭代留 20% 缓冲。跑两周再调。工具只是把规矩固定下来，规矩本身得先简单到大家愿意用。
