先把 BUG 和需求分开放
外包团队最怕的不是 BUG 多，是 BUG 和需求混在一起。客户在群里丢一句「登录又报错了」，销售转给项目经理，项目经理再@开发，开发正赶迭代，最后谁都急。先把入口管住：所有问题进同一个池子，来源标清楚，是客户报的、测试提的，还是内部发现的。不要用微信群当 BUG 库，聊天记录翻不到，责任人也容易丢。
BUG 只分三级，别搞花活
| 级别 | 典型场景 | 处理方式 |
|---|---|---|
| P0 | 线上不可用、支付报错、数据错乱 | 立刻拉群，先止血，当天给方案 |
| P1 | 主流程卡住但有绕行 | 本迭代修，每天更新进度 |
| P2 | 文案、样式、低频问题 | 排到下个迭代，批量处理 |
不管客户怎么催，优先级不能按嗓门定。P0 要有人拍板，P1 要能说清影响范围，P2 别偷偷插队。BUG 单模板也别省：环境、账号、复现步骤、截图或日志、期望结果、实际结果。少一项，开发就得来回问，一天就没了。
迭代按两周跑，范围要冻住
外包项目最容易被「顺便改一下」拖死。建议两周一个迭代，迭代开始前把范围定死。插单可以，但拿等量任务换出来，项目经理签字。每日站会十分钟，只过三件事：昨天做完什么、今天做什么、哪个 BUG 卡住。别在站会上讨论方案，会后拉人。
迭代结束前留半天做回归测试，别等客户验收才发现主流程断了。验收放到客户门户里点确认，微信口头说「可以了」不算数。这一步能少很多扯皮。
工时和看板要连起来
BUG 修了多久、迭代里谁负载过高，工时表要能看见。不然复盘时只能凭感觉。看板上 BUG 和任务分开列，但同一个迭代里一起排，避免开发被两边拉扯。
这些动作靠自觉很难。我们用 Stepwise 管这类项目：BUG 单、需求单、迭代看板、工时表是连着的，客户门户只露出进度和待验收项，内部备注客户看不到。甲方要求数据不出内网，也可以私有化部署。
常见坑
- BUG 当需求做，做完没人验收，最后变成免费加需求。
- 客户直接找开发，绕过 PM，迭代范围天天变。
- 测试只在迭代最后一天进场，BUG 全堆到上线前。
- 工时随手填，复盘时不知道时间花在哪。
先把入口、分级、范围、验收这四件事跑顺，再谈工具。工具是帮你卡住流程的，不是替你定规则的。要是你们现在还在群里追 BUG，可以从下周的迭代开始，把 BUG 单和验收动作先固定下来。Stepwise 也能先拿一个小项目试试，不用一上来就全团队换。
