先解决一件事：BUG 从哪儿进来
外包项目里 BUG 一般有五个来源：客户微信群里喊、客户打电话、测试同学记在 Excel、邮件、以及生产环境自己报警。三天后项目经理问「上周那个问题修了吗」，没人答得上来。
规矩只有一条：一个入口。客户走客户门户提，测试在平台里提，内部同事发现了也提单。微信群里喊的，PM 负责转成单，然后回一句「已转 #1234」。
提单字段别省：
- 哪个客户、哪个环境（生产/测试）、哪个版本
- 复现步骤，写成 1、2、3
- 期望结果和实际结果分别是什么
- 截图或录屏
- 影响范围：单个客户还是所有客户
最值钱的是复现步骤。只写「页面报错」的单，开发要来回问三轮，一天就没了。
定级：别让客户替你定 P0
外包最常吵的就是优先级，客户觉得件件都是 P0。办法是启动会上把规则定死，写进合同附件。
| 级别 | 判断标准 | 响应 | 处理 |
|---|---|---|---|
| P0 | 生产环境不可用、数据错乱、涉及资金 | 30 分钟内响应 | 停下手上的活立刻修，当天出方案 |
| P1 | 主流程走不通，有绕行办法 | 当天响应 | 排进当前迭代，3 个工作日内解决 |
| P2 | 功能有偏差，不影响主流程 | 1 个工作日内确认 | 排进下个迭代 |
| P3 | 体验、文案、建议类 | 排期时统一看 | 攒一批一起做 |
关键点：定级权在 PM 和技术负责人手上，不在客户手上。但要让客户看见 P0 会挤占什么——「这个 P0 进去，本周原定的两个需求要往后挪」。话说清楚，大部分客户自己会重新掂量。
迭代：给线上问题留位置
两周一个迭代，容量按人天算，别按感觉。三个人两周，粗算 60 人天，扣掉会议、代码评审、联调，按 70% 折算大概 42 人天。
然后是关键一步：从这 42 人天里先划 20% 出来，大约 8 人天，专门留给线上问题。剩下的才排需求。
不划这块，迭代第一周就会被客户问题打穿，计划表变成摆设，团队也习惯了「反正排了也没用」。划出来之后，只要线上问题没超，迭代基本能按时收。超了，那是信号——要么质量出了问题，要么需求范围本身就不现实。
多客户并行的团队，看板上按客户分泳道，谁的活在哪儿一眼能看见。
站会别开成汇报会
15 分钟，站着开，只说三件事：昨天做完什么、今天做什么、卡在哪。卡点当场指定人，当天解决。
不讨论方案，不追责，不汇报百分比进度。要细节的会后单独聊。
看板分列：待确认 / 待开发 / 开发中 / 待测试 / 测试中 / 待验收 / 已上线。每列设 WIP 上限。如果测试列堆了 20 个单没人验，那说明瓶颈在测试，加开发人手没用。
收尾和复盘
每次上线前准备四样东西：提测清单、回归范围、上线检查单、客户验收单。少一样，后期就扯皮。
复盘只看四个数：
- 本迭代新增 BUG 数、关闭数、遗留数
- 线上问题（P0 + P1）数量
- 返工工时占比
- 承诺交付 vs 实际交付
遗留 BUG 曲线是最诚实的指标。一路往上走，说明团队在赶新功能、顾不上质量，三个月后一定爆。
几个常见的坑
- 客户直接找开发。 绕过 PM，进度不可见，开发被打断。约定好：任何问题进单，开发只认单。
- 修 BUG 的工时不统计。 项目结束一算账，亏了，亏在哪不知道。BUG 工时单独记，下次报价能算进去。
- 迭代中途插需求不记录。 最后对不上账，客户说「这个不是早说过了」。插进去就记一笔，影响多少工期写清楚。
- 只修不防。 同一个模块一周出五个 P1，先别急着一单一单修，看看是不是测试覆盖不到，或者需求本身就写得模糊。
工具这件事
这些流程用 Excel 加微信群也能跑，但跑到三个客户以上就散了。我们做 Stepwise 的时候想的就是这个场景：客户在门户里自己提单，单子直接挂到对应的需求和迭代上，开发、测试在同一个看板里推进，工时按人和项目统。私有化部署的客户，数据不出自己的服务器。
不用一上来就全套。先把「一个入口提单 + 定级规则 + 迭代留 buffer」这三件事做掉，两周之内就能看出区别。
