先把 BUG 池和需求池分开
外包项目最常见的乱局：客户在群里丢一句「登录有问题」，PM 转给研发，研发一查是客户改了流程，或者根本没复现。三天过去，客户觉得你们慢，研发觉得天天被打断。
入口统一，但分三类：BUG、需求变更、使用咨询。每天固定 10 分钟做分诊，PM 加一个主程就够。分诊只回答三件事：是不是 BUG；影响哪个版本和客户；今天修还是排进迭代。别让 BUG 池变成垃圾桶。
BUG 单字段不用多，但这几项必须有：环境、版本、复现步骤、影响范围、期望时间、截图或日志。严重程度按业务影响分，别按研发手感分：
- P0：核心流程走不通，客户没法验收
- P1：主流程能走，但关键功能出错，有临时绕行
- P2：界面、文案、低频问题
P0/P1 当天给结论，P2 进迭代。规则写清楚，客户也认。
迭代留出 BUG 带宽
外包团队排迭代，最容易犯的错是「客户催什么就塞什么」。计划排到 100%，线上一个 BUG 就全乱。每期按人天算容量，留 20%-30% 给 BUG、联调和客户确认。不是浪费，是给不确定性留位置。
需求进迭代前，验收标准写出来。别写「优化登录体验」，写「手机号+验证码登录，验证码 60 秒倒计时，错误提示明确」。验收标准不清楚，开发完就是扯皮。
迭代长度建议 1-2 周。每日站会只问三件事：昨天做完什么，今天做什么，卡在哪。别开成汇报会。周五发一次简报给客户：本周完成、下周计划、风险、需要客户确认的事项。客户看得见，催得就少。
| 节点 | 动作 | 产出 |
|---|---|---|
| 计划 | 排容量，留 BUG 带宽 | 迭代目标、验收标准 |
| 开发 | 每日同步卡点 | 可演示的增量 |
| 测试 | 回归 + 客户验收 | 缺陷清单、发布说明 |
| 复盘 | 只看漏测和返工 | 1-2 个行动项 |
把客户拉进同一个节奏
很多 PM 的时间耗在传话：客户问进度，PM 去问研发，研发说早修了，PM 再回客户。让客户自己提交 BUG、看状态、看版本发布说明，沟通成本立刻下来。
每周固定发一次简报，比随时在群里解释有效。简报就四行：本周完成什么、下周做什么、有什么风险、需要客户确认什么。别写长文。
复盘只改一两个点
复盘别开成批斗会。只看两件事：漏测从哪来，返工为什么发生。常见原因就几类：需求没写清、环境不一致、回归漏了、代码质量。一次只改一个流程点，下次复盘看有没有效果。写一堆没人看的文档，不如把 BUG 单字段补全。
Stepwise 把需求、BUG、迭代、工时和客户门户放在一个项目空间里。客户在门户提问题，PM 分诊后直接进迭代，研发改完关联版本，发布说明更容易整理。私有化部署也适合有数据要求的团队。工具不解决规则问题，但规则定好后，它能让规则跑起来。
如果你们现在 BUG 靠群消息、迭代靠 Excel，先拿一个真实项目，把分诊和容量留白跑两周。跑顺了，再复制到下一个项目。
