周五下午四点半，客户在群里发了一句「登录好像有点问题」，后面跟两个问号。项目经理转给开发，开发问「哪个账号」，客户没回。周一早上，这句话变成了「你们系统不太稳定」。
外包团队大概都经历过这种时刻。不是谁不努力，是流程从第一步就没兜住：BUG 散在聊天记录里，迭代目标天天被「这个很急」冲掉，月底填工时靠回忆。下面这几条是踩过坑之后留下的，不复杂，但要真执行。
一、入口收成一个，别留第二条路
只要还有微信、电话、客户老板直接找开发这几条路，就一定有问题掉进缝里。
- 客户侧：走客户门户提单，他自己能看到提过什么、现在到哪一步了。项目经理每周写进度邮件的那两个小时，就这么省下来。
- 内部侧：测试、实施、开发发现问题，提进同一个池子。不许私聊解决——私聊解决的问题，下个月还会再来一次。
- 口头提的、会上说的：项目经理当天补录进系统，谁提的写清楚。
一个池子不只是为了「不丢」。它能让「这个月客户提了多少、我们修了多少、还剩多少」变成能算的数。
二、分级要能落到动作上
常见毛病是「紧急」两个字被用滥，最后所有单子都紧急，等于没分级。把定义写死，并且和响应动作绑在一起：
| 级别 | 判断标准 | 响应动作 |
|---|---|---|
| P0 | 生产不可用 / 客户收不了款 / 数据错乱 | 停下手上的活，当天必须有人处理 |
| P1 | 主流程能走但明显报错，客户天天碰到 | 本迭代内解决 |
| P2 | 局部功能有问题，有绕行办法 | 进 backlog，按周排 |
| P3 | 界面、文案、体验类 | 攒一批一起做 |
关键不在表格，在于有人能拍板。给项目经理一个权力：客户说「很急」但不符合 P0 的，可以往下压，并且把理由回给客户。这一步不做，迭代计划永远是废纸。
三、迭代别排满
外包团队的迭代，最大特点就是被打断。按 100% 容量排，第一周就崩。
两周的迭代，实际排 7~8 天的工作量，剩下的留给插单、P0 和客户对齐。另外两件小事：
- 迭代目标写一句话，别写清单。清单会被改，一句话不会。
- 中途插进来的单子，记一笔「插单」，哪怕是老板提的。月底看这个数字，才知道团队到底被消耗在哪。
四、单据写不清，沟通成本翻倍
返工大多不是因为技术难，是因为没写清楚。提单模板里这几项设成必填：
- 复现步骤（别人能照着走一遍）
- 期望结果 vs 实际结果
- 环境、账号、版本
- 截图或录屏
开发看完单子不用再问一轮，省下的就是纯时间。客户门户的提单表单可以按项目配字段，必填项不填就提交不了——这比事后催着补要有效得多。
五、工时和复盘：算得清才管得住
工时不用记到分钟，按天填就够。目的只有两个：算项目毛利，校准估算。
估算和实际差得离谱的单子，月底挑三五个出来看，比开十次会管用。
复盘不用长，每月半小时，看三个数：插单比例、返工率、P0 数量。三个数往下走，说明流程在起作用。只看其中一个，容易被自己骗。
最后
工具不是关键，能不能坚持「所有问题进同一个池子」才是。Stepwise 把需求、BUG、迭代、工时和客户门户放在一套系统里，也支持私有化部署，适合那种需要把交付过程摊开给客户看的团队。如果现在还是靠群消息管项目，不妨先从收敛入口这一件事开始，别的慢慢来。
