先别急着买工具，先把入口收成一个
外包项目的 bug 管理，十有八九乱在入口。客户在微信群甩截图，测试在 Excel 记一行，开发在口头说「这个我改」。三天后问进度，谁也说不清。不是团队不努力，是信息散在四个地方。
做法很简单：所有 bug 只留一个入口。客户走客户门户，测试走缺陷池，开发自测发现的问题也进同一个池子。字段别贪多，六个够用：标题、复现步骤、截图/录屏、影响版本、紧急程度、提出人。少一个复现步骤，开发就得来回问半小时。
Stepwise 的客户门户可以按项目隔离，客户只看到自己的问题；提完自动进 bug 池，PM 再分流。私有化部署的客户也不用把数据放到外面。
Bug 要分「修不修」和「什么时候修」
很多团队把所有 bug 都塞进迭代，结果迭代目标天天变。建议两条线：缺陷池放所有问题，迭代里只放本迭代承诺修的。先分级，再排期。
| 级别 | 典型场景 | 处理方式 |
|---|---|---|
| P0 | 线上支付失败、系统打不开 | 2 小时内响应，当天给方案 |
| P1 | 主流程走不通，有替代路径 | 1 个工作日内修，进当前迭代 |
| P2 | 页面错位、非核心功能异常 | 排进下个迭代，批量修 |
| P3 | 文案、建议、体验优化 | 进需求池，不占 bug 工时 |
常见坑：所有人都标 P0，最后没有 P0。客户提的 bug 要给回执，哪怕只是一句「已收到，今天下午给结论」。
迭代别排满，留出插单空间
外包项目变更多，这是常态。迭代排 80% 的需求，留 20% 给 bug、客户插单和联调。别按人头把每天排满，排满就是给加班挖坑。
每周固定一次 bug 评审，PM、测试、开发一起过 P0/P1，决定哪些插单、哪些延后。每日站会 10 分钟，只说三件事：昨天干了什么、今天干什么、卡在哪。迭代结束做一次评审，给客户演示能跑的东西，再花 20 分钟回顾：这次返工最多的是哪块？下次能不能少做？
Stepwise 里迭代规划和工时统计是连着的。bug 修复也记工时，月底一看就知道维护成本占了多少。客户门户能看状态，少很多「在修了」的拉扯。
状态别设太多，三个会就够
Bug 状态用五个就够：新建、处理中、待验证、关闭、重新打开。状态越多，大家越懒得改。
会也不用多：
- 每日站会：10 分钟，看阻塞。
- 每周 bug 评审：过 P0/P1，定插单。
- 迭代评审+回顾：给客户看结果，内部聊返工。
几个容易踩的坑
- 截图当 bug：没有复现步骤，开发只能猜。
- 开发和测试互相甩锅：bug 必须写环境、版本、账号。
- 客户一直催：客户门户公开状态，比群里回「在修了」管用。
- 迭代目标写成任务列表：目标要一句话，比如「支付流程跑通」，不是「做 20 个任务」。
工具不是万能，但入口和状态先统一，能省很多扯皮。Stepwise 把这些放在一个项目里，想试的话可以拿一个真实项目跑两周看看。
