研发团队如何高效管理 BUG 和迭代：外包项目实操指南

外包项目最怕两件事：BUG 在群里飞，迭代到周五才发现做不完

客户问“这个不是上周就改了吗”，项目经理翻聊天记录翻半天。开发说改了，测试说没收到，商务说客户又打电话了。问题不在人不努力，在入口太散、状态不透明。

不要让 BUG 散在微信群、邮件、电话、口头里。所有问题进一个池子。每条至少写清：环境、复现步骤、期望结果、实际结果、截图或录屏、提出人、客户是否可见。

常见坑是只写“页面报错”“样式不对”。开发追问三轮，半天没了。外包场景更麻烦：客户先反馈给商务，商务转项目经理，项目经理再转开发，链条一长就丢。最好让客户从门户或固定表单提，PM 先做初筛，再分给开发。

Stepwise 里需求、BUG、迭代在同一条线上，客户门户能收集反馈，BUG 带负责人和状态，少一层转述。

每周开一次 20 分钟 BUG 清理会，只过 P0/P1 和超过 7 天没动的。所有 BUG 都标“紧急”，最后等于没有紧急。

外包迭代最容易烂尾：需求没写清，开发做完，客户说不是这个意思。迭代计划会前，每个需求至少写一条验收标准。写不出，说明还没想清楚，别急着排。

迭代周期建议 1-2 周。不要为了显得快搞 3 天迭代，沟通成本就能吃掉一半。迭代里留 20% 缓冲给 BUG 和客户临时需求，不留缓冲，基本一定延期。

阶段	要做的事	常见坑
迭代前	需求有验收标准，BUG 池清一遍，确认客户优先级	需求只有一句话
迭代中	每天看看板，卡住的事当天说，新 BUG 先判断进不进当前迭代	客户临时加需求直接插队
迭代后	演示、验收、把没做完的放回池子	“做完了”但没有验收记录

站会不要逐人汇报。只看三件事：昨天有没有卡住、今天有没有依赖、有没有新 BUG 影响当前迭代。看板列可以设：待处理、进行中、待测试、待验收、已完成。进行中每人最多 2 个，多了就是排队。

常见坑是“开发说做完了，测试说没收到，PM 说客户没确认”。所以“待测试”和“待验收”要分开，责任才清楚。

外包要算成本。BUG 修了多久、哪个模块老返工、哪个客户老改需求，月底一看就知道。不要拿工时天天盯人，容易变成填表游戏。用来看趋势：某个模块 BUG 多，是需求没写清，还是测试漏了。Stepwise 的工时统计能跟迭代关联，看投入可以，别把它当考勤表。

客户门户让客户看到自己提的 BUG 状态、当前迭代范围、预计上线时间。每周固定一次同步：本周完成、下周计划、风险、需要客户确认的事。10 分钟邮件或门户更新就够。口头确认不算确认，验收单、邮件或门户点确认才算。

工具不是万能。先把 BUG 入口、优先级、验收标准、看板四件事定下来，再找工具。Stepwise 把这些放在一个平台里，需求、BUG、迭代、工时、客户门户不用来回切。如果团队现在还在群里捞 BUG，可以先拿一个项目试起来。