项目工时统计与产能管理方法 | 外包团队实操指南

工时统计别做成监视器

外包团队一提工时统计，开发第一反应是“又来查岗”。这事一旦变成监视，数据就废了：大家会填满8小时，但项目该延期还是延期。

工时记录的目的只有两个：算清项目成本，看清团队产能。所以别只记“项目工时”，要分类型。比如：

颗粒度按天或按任务，别按分钟。每天下班前花两分钟填，比周末补一周的强。常见坑：只让开发填可计费工时，内部成本没人记，结果报价永远偏低；PM代填，数据全是“大概”，复盘时对不上。

五个开发，每周40小时，名义产能200小时。但真实产能呢？开会、代码评审、支持客户、处理线上问题、休假，这些都要扣。比较靠谱的算法：

可用产能 = 人数 × 每周有效工作小时 × (1 - 非项目时间占比) - 计划休假

举个例子：5人团队，每周40小时，会议和支持占20%，实际项目产能约160小时/周。如果这周有人休两天，再减16小时。排期按160小时排，别按200小时排。

用过去4到6周的工时数据校准这个比例。每个团队不一样，有的团队沟通多，有的返工多。别拍脑袋。

外包项目变更多，客户加需求、改流程、临时上线，都是常态。排期至少留15%到20%的缓冲。把每个人每周排到满，等于默认不会出任何意外，这不现实。

具体做法：每个迭代开始前，花半小时看上周实际工时。如果上周有人因为支持客户少做了两天开发，这周就少排两天的任务。迭代结束时再看一次，哪些任务实际工时超了，超在哪。下次估算就有数了。

常见坑：销售按理想产能承诺工期，交付时发现人不够；PM把多项目并行当常态，一个人同时干三个项目，切换成本没人算。实际工时里，切换项目花的时间经常被忽略。

工时统计不是为了月底考勤。项目结束，拉出各类工时占比：需求沟通占多少，返工占多少，测试占多少。下次报价时，把这些成本加进去。外包项目利润薄，靠感觉报价很容易亏。

另外，区分可计费工时和内部成本工时。客户合同里写100小时，实际投入120小时，那20小时就是内部成本，得知道花在哪了。

如果团队还在用Excel统计工时，每周汇总一次就要花半天，还容易错。Stepwise里工时按项目和任务记录，产能视图按成员可用时间算，排期时直接看谁负载过高。不用额外做表，也不用催着填。

如果你们团队还没开始做产能复盘，可以先从每周一次、半小时的工时回顾开始。Stepwise 的工时统计和迭代规划可以放在一起用，省得来回导数据。