先说一个常见场面
上周一个做外包的朋友打电话过来。客户在微信群里发了十几条语音，他回了句「收到，我让开发都看一下」。两周后客户问进度，他把聊天记录翻到底，也没搞清楚哪条改了、哪条没改。
这不是态度问题，是流程问题。BUG 进来的时候没有形状，出去的时候自然说不清。
一、所有问题只能有一个入口
外包团队最典型的场景：客户不走工单，走微信。语音、截图、电话、当面说。开发顺手改掉，没留记录。过几天客户说「上次那个还没改」，两边就开始扯皮。
规矩就一条：所有问题只从一个地方进。客户群里说了什么，对接人负责转成一条记录——哪个客户、什么现象、原始截图、谁转的，都带上。开发别在群里直接回「好的我看下」，这句话约等于没说过。
能让客户自己提最好。开个客户门户，甲方登录进去提单、看状态、看处理记录。听上去是给自己找麻烦，实际能省掉一半「这个改了吗」的电话。Stepwise 的客户门户就是这个用法：客户看到的是干净的进度，你看到的是背后连着的工单和工时。
二、别用 P0 到 P3 分级
P0 到 P3 这套，有专职 QA 的团队撑着还行。十来个人的外包团队，谁来定级？定完谁认？
换成三个问题：
- 影响这次上线吗？
- 影响多少用户，是不是那个正在催的客户？
- 有没有临时绕过去的办法？
答案一出来，级别自己就定了。
| 情况 | 怎么处理 |
|---|---|
| 卡上线、影响全部客户、绕不过去 | 当天修，算插单 |
| 影响部分客户、有临时方案 | 排进当前迭代 |
| 不影响使用，体验问题 | 下个迭代，或按合同优先级排 |
| 其实是需求变更 | 拉回需求池，走变更和报价 |
最后一行值得多说一句：客户嘴里的「BUG」，有不少其实是改需求。改需求要算工时、要谈排期，不能和 BUG 一起被顺手做掉，不然做完才发现这个迭代白干。
三、迭代容量只排七成
这条是血泪换来的。外包团队永远有插单：客户临时改文案、老板新接了个活、线上挂了。
按 100% 排满，插单一来就延期；延期几次，客户就不信你的排期了，开始天天问。
按七成排。五个人、十天，50 人天，排 35，剩下 15 明明白白写进「缓冲」。提前交付客户觉得你靠谱，插单进来也不至于全盘崩。
迭代开始前那半小时
- 需求池和 BUG 池一起过，别只看需求
- 每个条目估点，估不出来说明还没想清楚
- 把缓冲写进计划里，不是留在心里
- 排完问一句：这个迭代里 BUG 占多少？
四、BUG 占比是个信号
一个迭代里 BUG 工单超过四成，基本不是排期问题，是质量问题。这时候别急着开下一个迭代，停下来看看：需求写清楚了吗？测试覆盖到了吗？是不是上个迭代赶工赶出来的？
外包还有个隐形成本叫返工。客户验收说不合格，改一遍，这段时间往往没记进工时，等项目结算才发现没赚钱。工时统计不是为了考核谁，是让你知道哪个项目在偷偷亏。
五、状态机别搞太复杂
见过一个团队，BUG 状态十一个：新建、待确认、已确认、已分配、修复中、待测试、测试中、待验收、已关闭、重新打开、挂起。结果没一个人更新，全停在「修复中」。
五六个够了：待处理 → 处理中 → 待验证 → 已关闭，再加一个「挂起」。多一个状态，就多一次没人维护的机会。
六、关闭一条 BUG 要有证据
「已修复」这三个字最不值钱。
关一条至少要写清楚：哪个版本修的、谁验的、什么时候验的、验的哪个环境。外包项目尤其要紧——最后要交付、要验收、要收尾款。客户在门户上能看到每条问题的处理轨迹，比你说十遍「都改好了」管用。
最后
工具不是万能的。但没有一个统一的池子，上面这些全是空话。
Stepwise 里需求、BUG、迭代、工时、客户门户是一套东西，好处很实在：排期的时候能直接看到这个迭代 BUG 占了多少、工时够不够、客户那边看到的是什么样。要私有化部署，放甲方机房也行。
先把入口统一了，别的再慢慢来。
