周五下午五点，客户在微信群里发来一张截图：「这个按钮点了没反应。」PM 转给开发，开发问：哪个账号？哪个版本？什么浏览器？客户回：「就那个啊。」来回三轮，下班时间过了。周一查出来，是客户自己电脑的浏览器缓存。
这种事一周来三次，迭代就废了。
做外包的都清楚，BUG 本身不可怕，可怕的是它没有形状——不知道谁提的、多严重、算谁的工时、这周能不能排进去。下面几条是我们踩过坑之后定下来的规矩。
一、BUG 只有一个入口
微信群、电话、邮件、客户老板顺口一句「顺便改一下」，统统不算提单。
规矩定死：所有问题走同一个入口。客户在客户门户提，测试按用例提，内部同事发现也提同一张单。谁在群里说「有个小问题」，回复永远一句：麻烦提个单，链接在这。
头两周客户会烦。第三周他们自己就习惯了，因为提完能看到状态：待确认、处理中、待验证、已关闭。光这一条，就省掉了 PM 每天二十次的「那个改好了吗」。
二、提单字段别手软
字段少一个就打回。听着不近人情，但比让开发猜半天便宜太多。
必填项：严重程度、环境（客户/版本号/设备）、复现步骤一二三、截图或录屏、期望结果与实际结果。
严重程度让提单人先选，最终由技术负责人改。客户眼里所有问题都是「紧急」，这个判断权不能交出去。
| 等级 | 什么情况 | 响应 | 排期 |
|---|---|---|---|
| P0 阻断 | 主流程走不通、数据出错、线上不可用 | 2 小时内 | 当天修，必要时热更 |
| P1 严重 | 核心功能异常，但有绕过办法 | 当天 | 当前迭代内 |
| P2 一般 | 非核心功能问题、体验瑕疵 | 2 个工作日 | 进下一个迭代池 |
| P3 建议 | 优化、文案、样式 | 批量处理 | 排期待定，季度清一次 |
这张表直接发给客户看，比解释一百遍管用。
三、排期必须留插单的位置
外包项目没有不插单的。按 100% 容量排两周，第一个插单进来整盘就乱。
我们现在的做法：两周一个迭代，按人天算容量，只排 70%–80%。剩下的明说是留给插单和线上问题的，并且跟客户讲清楚——这部分额度没用完也不会补做别的，它就是缓冲。
排之前先做一件事：把上个迭代没关的 BUG 数出来摆桌上。遗留超过 15 个，这个迭代就别接新需求，先还债。
四、BUG 和需求变更要分账
这是外包公司最容易亏钱的地方。
同一个「问题」可能是三种东西：我们代码写错了、客户当初没说清、客户现在想改了。第一种免费修，后两种走变更单，重新评估工时和费用。
所以 BUG 单里加一个必填字段：责任归属（我方缺陷 / 需求遗漏 / 需求变更 / 环境问题），关闭时必须填。
月底拉一次数据。某个模块「我方缺陷」占七成，说明这块该重构了，或者当初赶工太狠。某个客户变更单特别多，下次报价记得把这部分算进去。
五、发布前一周的标准动作
别等到验收会上才发现问题。
- 提前七天冻结新功能，只修 BUG
- 每天看收敛曲线：新增 vs 关闭，曲线压不下去就是有系统性问题
- 出一份「已知问题清单」，遗留的 P2/P3 一条条列清楚，让客户确认这版不修
- 验收单写明白：本次交付包含什么、已知问题有哪些、什么情况算通过
不写清楚，验收会就变成辩论会。
六、每周十分钟，只看两个数
第一，BUG 修复工时占迭代总工时的比例。超过 30%，说明质量在拖后腿，别再往里塞需求。
第二，P0/P1 的平均关闭时长。这个数往上走，客户满意度一定往下走。
会不用长，十分钟，两张图放出来，谁的问题谁认领。
工具上说一句：上面这些靠 Excel 加微信群也能跑，就是每天要花半小时对账。Stepwise 把需求、BUG、迭代、工时放在一条线上，客户在门户提单直接进对应的单子，状态变了客户自己看得到，工时到月底直接出结算表。省下来的时间，够你多盯两个项目。
