BUG 和迭代乱，通常不是工具问题

外包项目最怕两种乱：BUG 堆成山，迭代像赶集。客户今天提个「小改动」，明天线上又炸一个。项目经理夹在中间，开发说在修，客户说没看到，最后谁都不信。问题往往不是团队不努力，而是 BUG 和迭代混在一起，没人能说清现在到底在交付什么。

先把两个池子分开。需求池放客户要的新东西，BUG 池放已交付功能出的问题。别把 BUG 当需求塞进下个迭代，否则迭代目标永远被冲掉。Stepwise 里需求、BUG、任务分类型管理，客户门户只让客户看到该看的进度和反馈，少掉微信群里的「好了吗」。

BUG 分级别只写高中低

高中低谁都会写，落到人身上就变成「我觉得这个不急」。外包团队按影响面和响应时限分级，再配修复窗口。

级别 典型场景 响应动作
P0 核心流程不可用，客户无法验收或已影响生产 立即拉群，负责人 30 分钟内响应，当天给方案
P1 主流程能走但结果错，客户会拒收 当天确认，进入当前迭代修复
P2 局部功能异常，有替代操作 排进下一迭代，先给客户说明
P3 文案、样式、体验优化 集中处理，不单独打断迭代

这张表是给开发和客户对齐预期用的。谁改级别必须写原因。别让销售一句「客户很急」就把 P3 升 P0，团队会被拖死。

迭代按可验收交付物切，不按人切

很多迭代计划列的是「张三修 BUG，李四写接口，王五改页面」。这不是迭代，是排班。迭代目标要能验收：比如「客户能完成订单退款并看到日志」，而不是「修 8 个 BUG」。

拆的时候做三件事：

  • 每个迭代最多一个主目标、两个次目标，写清楚验收人；
  • BUG 修复必须带复现步骤和影响范围，没写清楚的不进迭代；
  • 中途插需求走变更，不偷偷塞给开发。

Stepwise 的迭代看板把需求、BUG、任务放进同一个交付节奏，但状态分开看。客户门户更新验收状态，比项目经理每天截图发群靠谱。

站会只问三件事

每日站会别轮流念昨天做了什么。就问：今天卡在哪、今天谁验收、客户还在等哪个回复。超过 15 分钟，会后单聊。外包项目里，等回复和等验收最容易被忽略，最后变成延期理由。

工时也要记，但别记成考勤。按 BUG、需求、沟通支持分开记，月底复盘才知道时间花在哪。Stepwise 的工时统计和 BUG 跟踪连在一起，能看到一个迭代里返工吃掉多少时间。

复盘只看两个数

复盘别开成批斗会。看两个数：返工原因分布、延期原因分布。是需求没写清，还是测试环境不一致，还是客户验收标准变了。找出一个下个迭代能改的动作，写进计划，下次复盘检查。

BUG 和迭代管理没多玄乎，就是把池子分开、把标准写死、把验收摆到明面上。工具只是让这些动作少靠人肉记忆。如果还在用 Excel 追 BUG，可以拿一个迭代在 Stepwise 里跑一遍，至少客户问进度时不用翻聊天记录。