[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-contact":3,"article:zh:tracking-developer-hours-and-team-capacity-a-practical-2":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-2","practice","项目工时统计与产能管理：外包团队怎么把账算清楚","工时统计不是填表交差，产能管理也不是数人头。这篇聊几个外包团队能直接上手的方法：怎么记工时、怎么算真实产能、怎么在排期时留缓冲，以及常见的坑。",null,[28,29,30,31,32],"工时统计","产能管理","外包团队","项目排期","研发管理","2026-11-06T18:00:34","## 工时统计别做成监视器\n\n外包团队一提工时统计，开发第一反应是“又来查岗”。这事一旦变成监视，数据就废了：大家会填满8小时，但项目该延期还是延期。\n\n工时记录的目的只有两个：算清项目成本，看清团队产能。所以别只记“项目工时”，要分类型。比如：\n\n| 类型 | 例子 | 用途 |\n|------|------|------|\n| 需求与沟通 | 客户会议、需求澄清、写文档 | 看沟通成本 |\n| 开发 | 编码、自测、代码评审 | 看核心产出 |\n| 测试与返工 | 修BUG、回归测试 | 看质量成本 |\n| 支持与内部 | 售前支持、内部培训、环境维护 | 看非项目消耗 |\n\n颗粒度按天或按任务，别按分钟。每天下班前花两分钟填，比周末补一周的强。常见坑：只让开发填可计费工时，内部成本没人记，结果报价永远偏低；PM代填，数据全是“大概”，复盘时对不上。\n\n## 产能不是人头数\n\n五个开发，每周40小时，名义产能200小时。但真实产能呢？开会、代码评审、支持客户、处理线上问题、休假，这些都要扣。比较靠谱的算法：\n\n可用产能 = 人数 × 每周有效工作小时 × (1 - 非项目时间占比) - 计划休假\n\n举个例子：5人团队，每周40小时，会议和支持占20%，实际项目产能约160小时\u002F周。如果这周有人休两天，再减16小时。排期按160小时排，别按200小时排。\n\n用过去4到6周的工时数据校准这个比例。每个团队不一样，有的团队沟通多，有的返工多。别拍脑袋。\n\n## 排期留缓冲，别把产能排满\n\n外包项目变更多，客户加需求、改流程、临时上线，都是常态。排期至少留15%到20%的缓冲。把每个人每周排到满，等于默认不会出任何意外，这不现实。\n\n具体做法：每个迭代开始前，花半小时看上周实际工时。如果上周有人因为支持客户少做了两天开发，这周就少排两天的任务。迭代结束时再看一次，哪些任务实际工时超了，超在哪。下次估算就有数了。\n\n常见坑：销售按理想产能承诺工期，交付时发现人不够；PM把多项目并行当常态，一个人同时干三个项目，切换成本没人算。实际工时里，切换项目花的时间经常被忽略。\n\n## 工时数据要用来报价和复盘\n\n工时统计不是为了月底考勤。项目结束，拉出各类工时占比：需求沟通占多少，返工占多少，测试占多少。下次报价时，把这些成本加进去。外包项目利润薄，靠感觉报价很容易亏。\n\n另外，区分可计费工时和内部成本工时。客户合同里写100小时，实际投入120小时，那20小时就是内部成本，得知道花在哪了。\n\n## 工具配合：轻量记录，自动汇总\n\n如果团队还在用Excel统计工时，每周汇总一次就要花半天，还容易错。Stepwise里工时按项目和任务记录，产能视图按成员可用时间算，排期时直接看谁负载过高。不用额外做表，也不用催着填。\n\n如果你们团队还没开始做产能复盘，可以先从每周一次、半小时的工时回顾开始。Stepwise 的工时统计和迭代规划可以放在一起用，省得来回导数据。","项目工时统计与产能管理方法 | 外包团队实操指南","外包团队怎么做工时统计和产能管理？从记录分类、真实产能计算、排期缓冲到报价复盘，几个能直接上手的方法和常见坑。","项目工时统计,产能管理,外包团队工时,研发产能,项目排期",[39,50,59],{"slug":40,"category":23,"title":41,"summary":42,"cover":26,"tags":43,"publishAt":49},"how-to-prioritize-software-requirements-in-outsourcing","需求优先级排序怎么做：外包项目可落地的四层法","外包项目里需求优先级最容易变成“都急”。这篇给你一套能落地的做法：先分合同边界，再用四层优先级、三个争议问题和工时里程碑把排序落到迭代里，并避开常见坑。",[44,45,46,47,48],"需求优先级","外包项目管理","迭代规划","需求管理","工时估算","2026-11-07T18:01:00",{"slug":51,"category":23,"title":52,"summary":53,"cover":26,"tags":54,"publishAt":58},"managing-changing-requirements-how-outsourcing-teams","需求频繁变更时如何控制范围：外包团队的变更管理实操","需求变更本身不是问题，没人管的变更是。这篇讲一套外包团队能落地的做法：把范围写成可验收的句子、给变更设一个入口、把代价摆到客户面前，以及在合同和迭代节奏上留缓冲。",[55,56,45,28,57],"需求变更","范围蔓延","客户门户","2026-11-07T15:00:46",{"slug":60,"category":23,"title":61,"summary":62,"cover":26,"tags":63,"publishAt":66},"scheduling-multiple-software-projects-find-the-bottleneck","多项目并行的研发团队怎么排期：别先画甘特图，先把瓶颈排出来","外包团队多项目并行，排期难点不是画图，而是共享人力的冲突。本文给出一套能落地的周排期方法：容量基线、交付切片、瓶颈资源、WIP 限制和每周复盘。",[64,32,30,65,28],"多项目排期","资源调度","2026-11-07T12:00:44"]