[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-contact":3,"article:zh:tracking-developer-hours-and-team-capacity-a-practical":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},"tracking-developer-hours-and-team-capacity-a-practical","practice","项目工时统计与产能管理的方法：外包团队实操指南","外包团队填了工时却用不上，多半是没把工时、产能和利用率分开。这篇讲清楚怎么记、怎么算产能、怎么用历史数据校准报价，以及每周二十分钟怎么跑起来。",null,[28,29,30,31,32],"工时统计","产能管理","外包交付","项目估算","Stepwise","2026-11-05T15:01:12","# 项目工时统计与产能管理的方法：外包团队实操指南\n\n很多外包团队都填工时，但填完没人看。月底导出一张表，发现项目又亏了。问题不在填不填，而在填了什么、怎么用。\n\n## 先把三个东西分开\n\n工时、产能、利用率，不是一回事。\n\n- 工时：一个人在某件事上花了多少小时。\n- 产能：未来两周团队能拿出多少可交付小时。\n- 利用率：可计费工时 ÷ 可用工时。\n\n外包公司最该盯的是“可交付小时”和“可计费工时”。前者决定能不能接活，后者决定赚不赚钱。\n\n## 工时怎么记才不招人烦\n\n别记到分钟。开发不是流水线，记太细只会逼人编数据。我们一般要求三条信息：项目、任务类型、小时数。任务类型固定五六种：需求开发、BUG 修复、联调、会议、售前支持、内部事务。每天下班前花两分钟填，或者每周五补一次，但别拖过下周。\n\n关键是一致性。同一个项目，上周把“改文案”算开发，这周算支持，数据就没法比。项目经理要在周会上花五分钟对一下异常：有人一周 60 小时，有人 20 小时，先问原因，别急着下结论。\n\n## 产能不是人头数\n\n三个人干两周，不是 3×10×8=240 小时。要扣年假、事假、例会、代码评审、线上支持。我们通常按可计费 6 小时\u002F人天估，新手项目再打八折。滚动看两周，别做半年预测，外包需求变得快。\n\n做产能表时，至少列这几项：\n\n| 项目 | 角色 | 可用人数 | 可计费天数 | 日均可计费小时 | 产能小时 |\n|------|------|----------|------------|----------------|----------|\n| A 项目 | 后端 | 2 | 8 | 6 | 96 |\n| A 项目 | 前端 | 1 | 8 | 6 | 48 |\n| B 项目 | 测试 | 1 | 5 | 5.5 | 27.5 |\n\n这张表比“大家都很忙”有用。排期时先看产能，再看需求。\n\n## 估算要用自己的历史数据\n\n别拍脑袋。每个任务记下预估小时和实际小时，两周复盘一次。看两类偏差：按任务类型看，比如“联调”总是超 50%；按人看，新人估得保守，老手估得乐观。下次报价把偏差加进去，用区间不用单点。比如“这个模块 80-110 小时”，比“95 小时”更接近现实。\n\n## 常见的坑\n\n- 把工时当监控工具。天天盯着谁填了多少小时，团队很快学会填你想看的数字。\n- 只记可计费工时。售前、支持、内部工具不记，产能永远算不准。\n- 产能按满负荷算。人不是机器，满负荷排期一定延期。\n- 工时和报价脱节。项目做完不复盘，下次还按老经验报，继续亏。\n- 没有任务类型。所有工时堆在项目上，看不出钱花在开发还是救火。\n\n## 每周二十分钟的节奏\n\n周一早上，项目经理拉一张本周产能表，标出谁在休假、谁被支持占用。周五下午，团队补工时，PM 只看三个数：可计费比例、预估偏差、超支任务。超过 20% 偏差的任务，下周例会上花五分钟聊原因。不用开长会，也不用做漂亮报表。\n\n工具上，Stepwise 把工时挂在任务和项目上，产能视图按人、按角色、按周看。工时填完直接进项目毛利，客户门户也能看到进度。省掉月底拿 Excel 对来对去的时间。\n\n工时统计不是为了管住谁，是为了下次报价更准、排期更稳。先坚持一个项目、一个月，数据有味道了再扩。","项目工时统计与产能管理方法 | Stepwise","面向软件外包团队的工时统计与产能管理实操：任务级工时、可计费产能、估算偏差复盘和每周节奏，少填无用表，把数据用在报价和排期上。","项目工时统计,产能管理,外包团队工时,研发工时,项目排期,工时估算",[39,51,61],{"slug":40,"category":23,"title":41,"summary":42,"cover":26,"tags":43,"publishAt":50},"managing-bugs-and-sprints-in-a-software-outsourcing-team-2","研发团队如何高效管理 BUG 和迭代：外包团队能落地的做法","外包团队的 BUG 往往散在微信群和 Excel 里，迭代永远被插单打乱。这篇讲怎么把 BUG 收口到一个池子、按客户可见度排优先级、把迭代排到 70%，以及每周该盯哪三个数。",[44,45,46,47,48,49],"BUG管理","迭代规划","缺陷跟踪","外包研发管理","客户门户","研发效能","2026-11-05T12:00:35",{"slug":52,"category":23,"title":53,"summary":54,"cover":26,"tags":55,"publishAt":60},"managing-bugs-and-sprints-for-software-teams-a-practical-3","研发团队如何高效管理 BUG 和迭代：外包项目实操指南","外包团队的 BUG 和迭代管不好，通常不是工具少，而是入口散、优先级乱、验收标准缺。这篇把 BUG 池、迭代节奏、看板和客户可见性拆成可执行动作，适合项目经理直接照着改。",[44,56,57,58,59],"迭代管理","外包研发","项目管理","研发效率","2026-11-05T09:00:49",{"slug":62,"category":23,"title":63,"summary":64,"cover":26,"tags":65,"publishAt":69},"how-software-teams-manage-bugs-and-sprints-a-practical-3","研发团队如何高效管理 BUG 和迭代：外包项目可落地的做法","外包团队管 BUG 和迭代，重点不是工具多，而是先把 BUG 边界、分级、站会节奏和迭代缓冲定清楚。本文给出可直接落地的规则、表格和常见坑。",[44,45,66,67,68],"外包项目","研发管理","项目复盘","2026-11-04T18:00:38"]