先别急着上工具，先把“什么算 BUG”说清楚

外包团队最容易乱的地方，不是 BUG 多，是所有人对 BUG 的定义不一样。客户觉得按钮颜色不对是 BUG，开发觉得这是需求变更；测试提的“偶现白屏”没日志，开发只能猜。结果就是：群里每天在吵，迭代计划天天改。

先把边界写进项目规则：功能没按已确认需求工作，算 BUG；需求本身要改，走变更单；体验优化、新想法，进需求池。客户门户里让客户看到状态，比在微信里反复解释省事。

BUG 管理：一张表加每天 15 分钟

BUG 列表别做成聊天记录。至少要有这些字段：标题、环境、复现步骤、实际结果、期望结果、严重级别、负责人、状态、关联迭代、客户可见。缺复现步骤的，测试或提 bug 的人补，不补就退回，不然开发时间全耗在猜。

严重级别别拍脑袋，按影响定：

级别 例子 处理方式
P0 阻塞 生产环境登录不了、核心流程断 立即拉人，当天给结论
P1 严重 主要功能报错，有临时绕法 进当前迭代，优先修
P2 一般 非核心页面样式错、提示文案不对 排进下个迭代
P3 建议 体验优化、小改文案 进需求池，定期看

每天站会 15 分钟，只过三件事：昨天新增了哪些 P0/P1、谁手上卡住、今天要关掉哪几个 BUG。不要在会上逐条读 BUG，那是浪费时间。每周挑一次，把超过两周没动的 BUG 翻出来：要么排期，要么关掉，要么转需求。挂着不管最消耗信任。

迭代规划：给 BUG 留位置

很多团队做迭代，把功能排得满满当当，一有线上问题就全线崩。外包项目更明显，客户一个电话，计划全乱。

做法不复杂：每个迭代留 20% 左右容量给 BUG 和临时支持。不是固定死，是让计划有缓冲。迭代目标写清楚“这次上线什么”，不要写“修完所有 BUG”，那不可能。每个任务要有负责人和验收人，测试不通过不算完成。

需求变更别硬塞进当前迭代。让客户知道：塞进来可以，拿什么换？砍一个功能，还是延两天？这句话提前说，比最后吵架有用。Stepwise 里可以把 BUG 和迭代放同一个项目视图，需求、任务、BUG、工时串起来，客户门户只展示客户该看的状态，省掉大量截图和解释。私有化部署对金融、政企类外包项目也省心。

复盘只看两件事

迭代结束别开成批斗会。看两个数：延期任务卡在哪，重复 BUG 有没有变多。然后改一个流程点，下周验证。比如“提 BUG 必须带复现步骤”，执行两周，开发被打断的次数会下来。

工具不是救命药。先把规则定清楚，再用 Stepwise 这类平台把规则固化下来，跑两个迭代，乱的地方自己会冒出来。