[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-contact":3,"article:zh:managing-bugs-and-sprints-in-a-software-outsourcing-team-a":21},{"phone":4,"wechatId":5,"wechatQr":6,"wecomQr":7,"emails":8},"17744963663","","\u002Fqr\u002Fwechat.png","\u002Fqr\u002Fwecom.png",[9,13,17],{"labelZh":10,"labelEn":11,"email":12},"商务咨询","Sales","hi@dhthub.com",{"labelZh":14,"labelEn":15,"email":16},"客户服务","Support","service@dhthub.com",{"labelZh":18,"labelEn":19,"email":20},"联系 Peter","Peter","peter@dhthub.com",{"slug":22,"category":23,"title":24,"summary":25,"cover":26,"tags":27,"publishAt":33,"content":34,"seoTitle":35,"seoDesc":36,"seoKeywords":37,"updatedAt":33,"related":38},"managing-bugs-and-sprints-in-a-software-outsourcing-team-a","practice","研发团队如何高效管理 BUG 和迭代：外包团队踩过的坑","外包团队的 BUG 往往散在微信、电话和截图里，迭代排期又总被插单打乱。这篇讲清楚入口统一、分级、七成排期、BUG 占比和验收留痕这几件具体的事。",null,[28,29,30,31,32],"BUG管理","迭代规划","外包研发管理","工时统计","客户门户","2026-11-06T15:00:46","## 先说一个常见场面\n\n上周一个做外包的朋友打电话过来。客户在微信群里发了十几条语音，他回了句「收到，我让开发都看一下」。两周后客户问进度，他把聊天记录翻到底，也没搞清楚哪条改了、哪条没改。\n\n这不是态度问题，是流程问题。BUG 进来的时候没有形状，出去的时候自然说不清。\n\n## 一、所有问题只能有一个入口\n\n外包团队最典型的场景：客户不走工单，走微信。语音、截图、电话、当面说。开发顺手改掉，没留记录。过几天客户说「上次那个还没改」，两边就开始扯皮。\n\n规矩就一条：所有问题只从一个地方进。客户群里说了什么，对接人负责转成一条记录——哪个客户、什么现象、原始截图、谁转的，都带上。开发别在群里直接回「好的我看下」，这句话约等于没说过。\n\n能让客户自己提最好。开个客户门户，甲方登录进去提单、看状态、看处理记录。听上去是给自己找麻烦，实际能省掉一半「这个改了吗」的电话。Stepwise 的客户门户就是这个用法：客户看到的是干净的进度，你看到的是背后连着的工单和工时。\n\n## 二、别用 P0 到 P3 分级\n\nP0 到 P3 这套，有专职 QA 的团队撑着还行。十来个人的外包团队，谁来定级？定完谁认？\n\n换成三个问题：\n\n- 影响这次上线吗？\n- 影响多少用户，是不是那个正在催的客户？\n- 有没有临时绕过去的办法？\n\n答案一出来，级别自己就定了。\n\n| 情况 | 怎么处理 |\n| --- | --- |\n| 卡上线、影响全部客户、绕不过去 | 当天修，算插单 |\n| 影响部分客户、有临时方案 | 排进当前迭代 |\n| 不影响使用，体验问题 | 下个迭代，或按合同优先级排 |\n| 其实是需求变更 | 拉回需求池，走变更和报价 |\n\n最后一行值得多说一句：客户嘴里的「BUG」，有不少其实是改需求。改需求要算工时、要谈排期，不能和 BUG 一起被顺手做掉，不然做完才发现这个迭代白干。\n\n## 三、迭代容量只排七成\n\n这条是血泪换来的。外包团队永远有插单：客户临时改文案、老板新接了个活、线上挂了。\n\n按 100% 排满，插单一来就延期；延期几次，客户就不信你的排期了，开始天天问。\n\n按七成排。五个人、十天，50 人天，排 35，剩下 15 明明白白写进「缓冲」。提前交付客户觉得你靠谱，插单进来也不至于全盘崩。\n\n### 迭代开始前那半小时\n\n- 需求池和 BUG 池一起过，别只看需求\n- 每个条目估点，估不出来说明还没想清楚\n- 把缓冲写进计划里，不是留在心里\n- 排完问一句：这个迭代里 BUG 占多少？\n\n## 四、BUG 占比是个信号\n\n一个迭代里 BUG 工单超过四成，基本不是排期问题，是质量问题。这时候别急着开下一个迭代，停下来看看：需求写清楚了吗？测试覆盖到了吗？是不是上个迭代赶工赶出来的？\n\n外包还有个隐形成本叫返工。客户验收说不合格，改一遍，这段时间往往没记进工时，等项目结算才发现没赚钱。工时统计不是为了考核谁，是让你知道哪个项目在偷偷亏。\n\n## 五、状态机别搞太复杂\n\n见过一个团队，BUG 状态十一个：新建、待确认、已确认、已分配、修复中、待测试、测试中、待验收、已关闭、重新打开、挂起。结果没一个人更新，全停在「修复中」。\n\n五六个够了：待处理 → 处理中 → 待验证 → 已关闭，再加一个「挂起」。多一个状态，就多一次没人维护的机会。\n\n## 六、关闭一条 BUG 要有证据\n\n「已修复」这三个字最不值钱。\n\n关一条至少要写清楚：哪个版本修的、谁验的、什么时候验的、验的哪个环境。外包项目尤其要紧——最后要交付、要验收、要收尾款。客户在门户上能看到每条问题的处理轨迹，比你说十遍「都改好了」管用。\n\n## 最后\n\n工具不是万能的。但没有一个统一的池子，上面这些全是空话。\n\nStepwise 里需求、BUG、迭代、工时、客户门户是一套东西，好处很实在：排期的时候能直接看到这个迭代 BUG 占了多少、工时够不够、客户那边看到的是什么样。要私有化部署，放甲方机房也行。\n\n先把入口统一了，别的再慢慢来。","研发团队如何高效管理 BUG 和迭代｜外包项目管理实践","外包团队如何统一 BUG 入口、简化分级、按七成排迭代、用 BUG 占比发现问题，并在验收时留下证据。来自一线交付经验的具体做法。","BUG管理,迭代规划,外包团队研发管理,BUG跟踪工具,客户门户,工时统计",[39,49,57],{"slug":40,"category":23,"title":41,"summary":42,"cover":26,"tags":43,"publishAt":48},"tracking-developer-hours-and-team-capacity-a-practical-2","项目工时统计与产能管理：外包团队怎么把账算清楚","工时统计不是填表交差，产能管理也不是数人头。这篇聊几个外包团队能直接上手的方法：怎么记工时、怎么算真实产能、怎么在排期时留缓冲，以及常见的坑。",[31,44,45,46,47],"产能管理","外包团队","项目排期","研发管理","2026-11-06T18:00:34",{"slug":50,"category":23,"title":51,"summary":52,"cover":26,"tags":53,"publishAt":56},"how-software-teams-manage-bugs-and-sprints-a-practical-4","研发团队如何高效管理 BUG 和迭代：外包项目实操打法","这篇讲外包研发团队怎么把 BUG 入口、分诊、迭代缓冲、验收复盘串起来，少靠群聊救火，多让流程可追踪。",[28,29,47,54,55],"外包交付","项目复盘","2026-11-06T12:00:45",{"slug":58,"category":23,"title":59,"summary":60,"cover":26,"tags":61,"publishAt":63},"how-software-teams-can-actually-manage-bugs-and-sprints-an","研发团队如何高效管理 BUG 和迭代：外包团队的落地做法","外包项目很少死在技术难题上，多半死在 BUG 说不清、迭代排不明白。这篇文章讲清一个入口、BUG 与变更的边界、定级规则，以及怎么给 BUG 留出产能。",[28,29,54,62,32],"需求变更","2026-11-06T09:00:40"]