先说个常见场面

客户在微信里发一句「登录又不行了」，测试在群里 @ 开发，开发改完回一句「好了」。三天后客户说还是没好。你想翻记录，翻不到——因为从头到尾就没人把它当成一条记录。

这不是工具的问题，是「收口」的问题。BUG 必须有唯一入口，而且要能接住四个来源：客户、测试、开发自查、线上告警。少接一个，你就会在某个周五晚上补课。

一、字段别贪多，六个就够

严重程度（P0–P3）、影响模块、来源渠道、是否客户可见、复现步骤、期望结果。就这六个。多加一个字段，填的人就少一截。

复现步骤写不清的单子，直接退回提交人。这条规矩严格执行两周，提单质量会明显变好。

二、优先级矩阵：客户可见是单独一列

外包和自研最大的差别在这儿——团队内部觉得不疼的问题，客户下周就要验收。

级别 客户可见 客户不可见
P0 阻塞 当天修，其他活全停 当前迭代内修掉
P1 严重 24 小时内给方案和时间点 排进当前迭代
P2 一般 当前或下个迭代 进待办池，按容量取
P3 轻微 攒着批量处理 三个月没人提就关掉

重点是 P3 要敢关。待办池里躺着两百条三年前的 BUG，每次翻都要浪费半小时，还看不清真正该做什么。

三、迭代排 70%，剩下 30% 留给插单

外包团队被插单是常态，不是意外。你把两周迭代排到 100%，客户插一个紧急需求，计划当场崩掉，然后团队开始默认「计划是假的」。这个心态一旦形成，后面很难扭回来。

按 70% 排，留出 1–2 个机动位给插单、线上问题和联调延期。估算按人天，不要按「感觉能做完」。

四、BUG 和需求进同一个池子排序

需求走一套流程、BUG 走另一套，你就永远算不清这个迭代能不能交付。放到一个池子里，按价值和风险一起排，排完再看总量是不是超了容量。

五、让客户自己提，别让 PM 当传话筒

PM 一天花两小时截图、转述、解释进度，这活儿没产出。给客户一个门户：自己提单、自己看状态、自己看验收清单。客户提的单直接进池子，PM 只负责定优先级。

Stepwise 的客户门户就是处理这些事的——客户只看得到他关心的单子，看不到你内部的争论和排期拉扯。

六、每周盯三个数就够

  • 新增 vs 关闭：连续两周新增大于关闭，就是在超支，别自我安慰说「下周就好了」。
  • 平均修复时长：按优先级分开看。混在一起看没有意义，P0 和 P3 的影响因素完全不同。
  • 重开率：修完又被打回来的比例。这个数超过 10%，通常不是人手不够，是验收标准没写清楚。

七、几个反复踩的坑

  1. 让开发自己关单。关单权限给测试或者提单人。
  2. 测试环境和生产环境混着报。单子里必须写环境，不然复现全靠猜。
  3. 客户口头说的需求没落单，两周后变成「你们答应过的」。凡是口头提的，PM 十分钟内补一条记录，哪怕先只有标题。
  4. 站会开成进度汇报。站会只讲阻塞，进度看板上有，不用念。

工具不解决管理问题，但能把「收口」这件事的成本压得很低。Stepwise 里 BUG 池、迭代看板和客户门户是打通的，不用来回导表格——顺手试一下也行。