[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-contact":3,"article:zh:managing-bugs-and-sprints-for-software-teams-seven-rules":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":34,"content":35,"seoTitle":36,"seoDesc":37,"seoKeywords":38,"updatedAt":34,"related":39},"managing-bugs-and-sprints-for-software-teams-seven-rules","practice","研发团队如何高效管理 BUG 和迭代：外包项目里能落地的七条规矩","BUG 从哪来、谁定优先级、什么时候算真修完——外包团队的交付失控，多半卡在这三件事上。这篇讲七个能直接落地的做法，配一张可写进合同的分级表和几个常见的坑。",null,[28,29,30,31,32,33],"BUG管理","迭代规划","外包项目管理","需求变更控制","工时统计","客户门户","2026-11-03T18:00:45","外包团队管 BUG，难点从来不是「用哪款工具」。难的是 BUG 从哪来、谁定优先级、什么时候算真修完。\n\n客户在群里丢一句「登录又不行了」，配一张糊掉的截图。这话在三个人脑子里过了一遍，没一条变成工单。三天后客户问进度，你翻聊天记录翻十分钟。\n\n先把入口收掉。\n\n## 一、BUG 只留一个入口，客户经理负责「翻译」\n\n微信、电话、邮件、客户老板随口一句，都不能直接进研发。\n\n留一个入口：客户门户提工单，或者客户经理代提。不管哪种，必须凑齐六样：\n\n- 环境（哪个客户的哪套部署，测试还是生产）\n- 账号和角色\n- 操作步骤，一步一步写\n- 期望结果\n- 实际结果\n- 截图或录屏，加发生时间\n\n少一样就退回去问。听着麻烦，但它能砍掉一半「根本不是 BUG」的东西：缓存、客户自己改了配置、浏览器版本太老、以及「需求本来就长这样」。\n\n## 二、分级写进合同，别在群里吵\n\n外包最怕所有 BUG 都「很急」。客户急是正常的，你需要一把双方事先认过的尺子。\n\n| 等级 | 判断标准 | 响应 | 处理 |\n|---|---|---|---|\n| P0 | 生产不可用、数据错乱、资损 | 2 小时内响应 | 当天出方案，必要时热修 |\n| P1 | 主流程走不通，有临时绕行 | 24 小时内响应 | 进当前迭代 |\n| P2 | 局部异常，不影响主流程 | 3 个工作日 | 排进下个迭代 |\n| P3 | 体验、文案、样式 | 批量收集 | 攒够一批统一做 |\n\n这张表最值钱的地方不是分得多准，是客户拿着它自己能判断「这个要不要现在打电话」。分级标准放进合同附件，验收时少扯一半的皮。\n\n## 三、迭代容量按 70% 排\n\n外包项目不存在「这个迭代没有新需求」。按 100% 排满，第一个插单就把计划打乱，然后整个迭代失控。\n\n算法：可用人天 × 0.7。三个人两周，纸面上 30 人天，只排 21。剩下 9 天接 P0\u002FP1，以及客户临时提、当天就要答复的小改动。\n\n再加一个冻结点：sprint 开始后进来的需求，默认进下一个迭代。客户坚持要插，就说清楚砍掉哪一项，或者加钱。这句话在启动会上讲一遍，比事后吵十次都管用。\n\n## 四、Sprint 目标写一句话，不写任务清单\n\n「完成订单模块联调并交付客户验收」是目标。「改 15 个页面、修 8 个 BUG、写 3 个接口」是清单。\n\n清单的问题是，做完 80% 你也不知道这个迭代算成功还是失败。一句话目标能让你周三就发现要完，然后及时砍范围，而不是周五晚上加班。\n\n## 五、工时按任务记，每周只看一个数\n\n半天粒度就够，不用精确到分钟。然后每周看 BUG 工时 ÷ 总工时。连着三周超过 30%，说明代码质量、需求理解或者测试环节有一个出问题了，停下来聊，别等客户投诉。\n\n顺带的好处：报价时终于有依据，不用拍脑袋。\n\n## 六、关闭 BUG 必须有验证人\n\n自测完就点关闭，是最常见的坑。客户下一轮再提一遍，你以为是新 BUG，其实是旧的没修好。\n\n规矩很简单：谁提的谁验。客户提的客户验，测试提的测试验。关闭时写一句在哪个版本、怎么验的。\n\n## 七、复盘 30 分钟，产出不超过 3 条\n\n只问三件事：这周哪些 BUG 本来能避免？哪个估错得最离谱，为什么？哪个环节卡住了别人？\n\n出 3 条 action，带进下个迭代。列 15 条改进项一条都不做的复盘，不如不开。\n\n## 最后一句\n\n工具不是重点，但工具决定上面这些规矩能不能撑住。BUG、需求、迭代、工时散在四个地方，每一条都会慢慢走形。Stepwise 把它们放到一个平台里，客户门户让客户自己提单、自己看进度，能省掉大量「这个修好了没」的追问；需要甲方验收的项目，私有化部署也省事。\n\n真要试，拿一个在跑的项目导进去跑两周，比看介绍有用。","研发团队如何高效管理 BUG 和迭代 | 外包项目管理实践","外包团队管 BUG 和迭代的七条落地做法：统一入口、分级写进合同、70% 容量排期、工时看板与复盘。含可复用的 BUG 分级表和常见坑。","BUG管理,迭代规划,外包项目管理,需求变更,工时统计,研发管理平台,客户门户",[40,49,60],{"slug":41,"category":23,"title":42,"summary":43,"cover":26,"tags":44,"publishAt":48},"managing-bugs-and-sprints-for-software-teams-a-practical-2","研发团队如何高效管理 BUG 和迭代：外包项目实战做法","外包团队管 BUG 和迭代，关键不是工具多，而是入口、分级、范围、验收四件事跑顺。本文给出一套能落地的小团队做法，也说明 Stepwise 怎么把这些动作连起来。",[28,29,30,45,46,47],"研发管理","客户验收","Stepwise","2026-11-03T15:00:43",{"slug":50,"category":23,"title":51,"summary":52,"cover":26,"tags":53,"publishAt":59},"managing-bugs-and-sprints-in-outsourcing-teams-a-practical","研发团队如何高效管理 BUG 和迭代：外包团队能落地的做法","外包团队的 BUG 和迭代一旦各管各的，就会互相挤占。这篇讲清楚三个具体做法：BUG 只设一个入口、五个状态，由提单人负责关闭；迭代按 80% 容量排期，并固定留出 20%~30% 给 BUG 和技术债；该盯的四个数字分别是哪些。",[28,54,55,56,57,58],"迭代管理","外包研发","研发流程","项目管理","客户交付","2026-11-03T12:00:41",{"slug":61,"category":23,"title":62,"summary":63,"cover":26,"tags":64,"publishAt":66},"managing-bugs-and-sprints-in-software-outsourcing-teams-a","研发团队如何管理 BUG 和迭代：外包项目的落地做法","BUG 管理乱，通常不是工具少，而是入口散、迭代塞太满、修复不跟版本。把入口、容量、验收和客户可见性四件事管住，外包团队的 BUG 和迭代就能跑顺。",[28,29,65,45,33],"外包交付","2026-11-03T09:00:48"]