可用工时怎么做？研发团队效率提升：人力资源计划从0到1

2021 年我接手一个 40 人研发团队的效能诊断，第一件事是让项目经理把他们正在用的排期表发给我。表里每个人的可用工时都写着「21.75 天 × 8 小时 = 174 小时/月」，整齐得像印刷体。但那个季度他们的版本按期交付率只有 43%。我没有改任何流程，只做了一件事：把这 174 小时拆开，扣掉休假、会议、支持工单、面试、技术债、代码评审和上下文切换，重新算了一遍。真实可用工时是 102 小时。

也就是说，他们过去两年的所有排期，都建立在一个人为放大了 70% 的分母上。这篇文章讲的，就是怎么把这个分母算对，以及算对之后，人力资源计划从 0 到 1 该怎么落地。

一、核心结论：可用工时不是算出来的，是约定并校准出来的

先把结论放在前面，因为它决定了后面所有方法的取舍。我在十几个研发组织里推过可用工时，最后收敛出的判断是：可用工时本质上不是一道算术题，而是一份产能契约。它约定的是「团队向业务承诺多少可交付产能」，而不是「员工在物理上存在多少小时」。

这个区别听起来很虚，但它直接决定你算出来的数字能不能用。算术题的思路是穷尽扣减项，越精确越好；契约的思路是找到双方都能接受、且能被反复验证的口径，越稳定越好。前者会让你的模型越来越复杂，最后没人愿意维护；后者会让你得到一个粗糙但活的数字，能一直用下去。

1. 三个数字必须分开：日历工时、可用工时、有效工时

绝大多数团队出问题，不是算错了，是把三个不同的东西混成了一个。我建议从第一天起就把它们分开命名、分开存储、分开汇报。

日历工时是法律和公司制度意义上的工作时间，比如一个月 21.75 个工作日、每天 8 小时。它是上限，永远不等于产能。

可用工时是在日历工时基础上，扣掉所有「确定不产生交付」的时间：法定假期、年假、病假、婚育假、公司统一活动、培训、必要的组织会议。这个数字回答的是「理论上能干活的时间」。

有效工时是在可用工时基础上，再扣掉「干活但不在计划内」的时间：临时支持、线上救火、面试、跨部门协调、环境故障、等待依赖、上下文切换损耗。这个数字回答的是「真正能落到计划任务上的时间」。

三个数字的关系是层层收敛的。我在多个中大型研发组织里观察到的稳定区间是：可用工时约占日历工时的 82%-88%，有效工时约占日历工时的 60%-72%。低于 60% 说明组织损耗异常，高于 75% 基本可以判断是有人在往上报喜。

2. 算得越准，用得越差：一个反直觉的经验

我见过三个团队把可用工时精确到小数点后一位，按人、按月、按技能标签分别建模，Excel 里 20 多个 sheet。结果半年后全部废弃。原因很简单：精度越高，维护成本越高，而排期本身的不确定性远大于这点精度。

你现在算出的 0.3 小时差异，在需求变更面前毫无意义。真正决定交付成败的，是分母是不是量级正确，而不是小数位是否正确。我的经验阈值是：可用工时的估算误差控制在 ±5% 以内，就足够支撑 90% 的研发排期决策；继续往下抠，投入产出比会断崖式下降。

3. 一条可以直接用的基线，但必须自己校准一遍

如果你现在什么都没有，可以先从这条基线起步，然后用手上的历史数据校准。这是我在多个 100 人以上研发组织里反复验证后收敛出的起始值，不是行业标准，请当作起点而不是答案。

注意最后三行。管理者、产品、项目经理的有效工时占比往往不到一半，但很多团队在排期时默认他们也按开发的标准投入。这是人力资源计划里最常见、也最贵的一个错误。

二、背景与真实场景：为什么你的排期从第一天就是错的

1. 一个 87 人研发组织的复盘：排期偏差到底从哪来

2022 年我参与一家做工业软件的公司做交付诊断。他们 87 名研发，分 6 个小组，季度交付按期率长期在 50% 上下。管理层的第一反应是「执行力不够」，第二反应是「加人」。我先做了一件更便宜的事：把他们过去 12 个月的 214 个已交付需求拉出来，逐条比对「计划工时」和「实际工时」。

结果非常干净。实际工时是计划工时的 1.61 倍，偏差分布高度集中：87% 的超时发生在「计划工时估算本身就低于真实工作量」的项目上，而不是执行过程中被拖延。换句话说，不是员工不努力，是分母错了。

继续往下拆，偏差有四个主要来源，按贡献度排序：

• 可用工时按满勤计算（贡献 41%）：排期时默认每个人 100% 在岗，实际平均缺勤和请假占 13%。
• 未扣除协作与支持开销（贡献 27%）：开发人员平均每周 6.5 小时用于线上问题、答疑、跨组联调。
• 任务拆分粒度太粗（贡献 19%）：单个任务动辄 5 人天以上，估算误差被放大。
• 依赖等待未计入（贡献 13%）：前后端联调、测试环境排队、第三方接口等待。

这四项加起来，解释了 100% 的偏差。而其中前两项，正好是可用工时该解决的问题。

2. 为什么这两年突然都在问可用工时

我观察到一个明显的拐点：当研发团队规模跨过 60-80 人，或者同时并行 3 条以上产品线时，管理者会开始主动要可用工时。在这之前，大家靠项目经理的个人经验和口头协调就能撑住。

触发需求通常有三个具体场景，你可以对照看看自己在哪一个：

1. 要做年度人力预算。老板问「明年这 20 个需求需要多少人」，没有可用工时你只能拍脑袋。
2. 要跨项目调配资源。两个项目抢同一个后端，谁该等、等多久，需要一个共同的度量单位。
3. 要解释为什么交付不了。业务方觉得人不少，团队觉得人不够，双方需要一张能对话的产能账。

这三个场景的共同点是：可用工时的价值不在精度，而在「让争论有共同的分母」。只要双方认这个分母，讨论就能从互相指责转向共同决策。

3. 分母失真之后，会在三个地方同时爆雷

算错可用工时不会立刻出问题，它会延迟一到两个季度，然后在三个地方同时爆发。这个延迟正是它长期被忽视的原因。

第一层是排期层。承诺的交付时间普遍偏乐观，团队长期处于「赶不上，加班，勉强赶上，下个迭代更乐观」的循环。我在一家公司看到过连续 6 个季度按期率在 45%-55% 之间震荡，团队已经对「按期」这个词失去感觉。

第二层是人力层。基于虚高的产能做招聘计划，要么招多了导致闲置，要么招少了持续透支。更隐蔽的是结构性错误：按总人数算缺口，而不是按角色算，结果来了 5 个前端，缺的却是测试。

第三层是士气层。这是最少被讨论、但代价最大的一层。当排期长期建立在不可能完成的假设上，团队会发展出一套防御性行为：估算时故意加水、任务拆分时藏工作量、承诺时留后手。一旦这套行为形成，你后面所有基于工时的数据都会失效，因为数据本身就是被博弈过的。

三、拆解五个最常见误区

1. 误区一：把 21.75 天当成可用工时

这是最普遍的一个，也是最容易识别的：如果一份排期表里每个人的月度工时都一样、都是整数、都是满勤，那它一定没算过可用工时。

75 是国家规定的月计薪天数，它的用途是算工资，不是算产能。把它直接乘 8 小时写进排期，等于假设这个员工全年不请假、不生病、不参加任何公司活动、不参加任何会议。现实中这个假设的偏差通常在 12%-18%。

更麻烦的是，这个错误会被继承。一旦第一版排期用了 174 小时，后面所有基于它的产能测算、人力缺口、预算申请，全部带着这个 70% 的放大系数往下传。

2. 误区二：按个人算，不按角色算

很多团队做到「每个人有自己的可用工时」就停了，觉得已经很精细了。但人力资源计划要回答的问题从来不是「张三这个月有多少小时」，而是「我们缺几个后端、缺几个测试」。

按个人算，你得到的是一堆无法聚合的数字；按角色算，你得到的是可以拿去做招聘和调配的产能池。我的做法是双层结构：角色层用于计划和预算，个人层用于排期和负载均衡。两层用同一套扣减规则，但汇报口径只在角色层。

这样还有一个额外好处：当某个人的可用工时有异常（长期病假、借调、培训），你只需要在个人层调整，角色层的基线不会被污染。

3. 误区三：只减假期，不减协作开销

这是「算了一半」的典型状态。你能看到团队算出了 148 小时，但排期时仍然按 148 小时安排任务，结果当然还是交付不了。

协作开销是可用工时里最容易被低估的部分，因为它不在任何系统里有记录。会议有日历，但「被打断」「等一个人回复」「环境起不来」这些没有。我在做测时采样时，让 12 名开发连续两周每小时记录一次「当前在做什么」，结果非常一致：计划内任务占比 62%，临时支持与沟通 21%，环境与工具问题 9%，等待 8%。

这个 62% 就是有效工时的真实占比。它不会因为你假装看不见就消失，只会以「进度延期」的形式在季度末集中出现。

4. 误区四：一次算完全年不变

我见过最典型的一份「年度产能规划表」，1 月做好，12 月还在用。问题在于研发组织的产能结构变化非常快：Q2 招了 15 个人，新人前三个月有效产能只有老员工的 40%-55%；Q3 启动一个大版本，支持工单量翻倍；Q4 集中休假，可用工时直接掉 20%。

正确的做法是季度校准、月度滚动：角色级系数每季度用实际数据校准一次，个人级可用工时每月按实际休假和借调更新。全年不变的模型，第二个月就开始失真。

5. 误区五：可用工时和任务拆分脱节

这一条最隐蔽。有些团队把可用工时算得很漂亮，但排期时任务还是按「这个需求大概 10 天」来估，两边根本没接上。结果可用工时变成了一份漂亮的报表，对实际排期毫无影响。

判断标准很直接：如果你算出来的可用工时不能约束任何一个具体任务的排入，那这个数字就是装饰品。要让两者接上，任务必须拆到 8 小时以内，且每个任务明确归属到角色产能池，超出池子就无法排入。这是工具层面必须支持的约束，靠自觉做不到。

四、专业判断逻辑：三层模型、四种扣减法、一次校准

1. 扣减顺序比扣减项更重要

很多方法论只告诉你「要扣哪些东西」，但真正决定模型稳定性的，是扣减的先后顺序。我用的顺序是：先团队级、后个人级；先确定项、后估计项；先年度、后月度。

原因在于可验证性。团队级确定项（法定假期、公司统一活动）有唯一数据源，可以直接从人事系统取；个人级不确定项（临时请假、借调）需要动态更新，误差大。如果先扣个人再扣团队，两层误差会叠加；反过来，团队级作为基线先固定，个人级只做局部修正，误差被限制在局部。

具体执行顺序如下，这是一条我验证过、可以直接照做的链路：

1. 取年度法定工作日，扣掉法定假期，得到年度日历工时。
2. 扣掉公司统一的非工作日（年会、团建、统一培训），得到团队可用工时基线。
3. 按角色历史数据，扣掉平均年假、病假、婚育假占用，得到角色可用工时。
4. 按角色历史数据，扣掉协作、支持、会议、环境损耗，得到角色有效工时。
5. 留 8%-12% 的不确定性缓冲，得到可承诺产能。
6. 个人层只在第 5 步结果上做加减，不再重新走一遍链条。

2. 四种扣减方法的适用边界

市面上常用的扣减方法有四种，我在不同规模的团队里都用过，没有一种通吃。下面这张表是我自己的使用经验总结，不是理论分类。

我的推荐组合是「日历倒推法打底 + 回填校准法修正」。前者解决「能算出多少」，后者解决「算得对不对」。抽样测时法只在一种情况下值得做：你怀疑协作损耗异常，但又不知道具体出在哪，这时候两周的采样能给你答案。

3. 收敛校验：用历史交付数据反推你的系数到底对不对

这是我在实践中认为最有价值、却最少被使用的一步。方法很简单：拿一批已经完成的任务，比较「计划工时总和」和「实际投入工时总和」，用比值反推真实的有效工时系数。

举个例子。某团队过去半年完成了 180 个任务，计划工时合计 4200 小时，实际投入合计（按任务生命周期和人均投入折算）6300 小时，比值 1.5。如果他们的日历工时是 174 小时/人月，那么真实有效工时就约等于 174 ÷ 1.5 ≈ 116 小时/人月，占日历工时的 67%。

这个 67% 就是你的校准结果。它不需要你相信任何人给的系数，它来自你自己团队的真实数据。我在四家组织里做过同样的校准，得到的有效工时占比分别是 63%、67%、64%、71%，差异主要来自线上支持强度和会议密度。

关键点在于：校准要在角色层做，不要在全公司层做。全公司平均会把测试的 62% 和产品的 52% 混在一起，得到一个既不能用于排期、也不能用于招聘的数字。

4. 责任边界：可用工时管什么、不管什么

这一节是判断逻辑里最容易出事的地方。可用工时一旦被误用，反噬极快。我给自己定的边界是三条：

第一，可用工时用于计划，不用于考核。一旦和个人绩效挂钩，所有人都会低报可用工时来保护自己，数据立刻失效。它应该在角色层和项目层使用，永远不要下沉到个人评价。

第二，可用工时解释产能，不解释效率。两个团队可用工时相同但产出不同，说明的是效率差异，需要另外的度量（如需求吞吐量、缺陷密度、交付周期）。把两者混在一起，会让可用工时承担它无法承担的解释责任。

第三，可用工时是约束条件，不是目标。它的作用是让你在承诺时知道边界在哪，而不是让你把每个人的每一小时填满。100% 满载的排期一定失败，因为它没有给任何意外留空间。

五、从 0 到 1 的实录：一个 120 人研发组织的两年

1. 起点：症状不是「排期不准」，是「没人信排期」

这个案例来自一家做企业服务的公司，研发 120 人左右，分 4 个产品线、9 个小组。我介入时的核心症状不是延期本身，而是排期已经失去了信用：业务方看到排期会自己加两个月，研发承诺时会自己留一个月，双方都在博弈，没人相信那个日期。

这种状态下，任何精度改进都是无效的，因为数据本身已经是被污染过的。所以我做的第一件事不是建模，而是把「可用工时」定义成一个中立的、双方共用的口径，并且明确它只用于计划，不用于考核。这一步花了差不多三周，主要是沟通，不是技术。

2. 第一版：Excel 试点，三个月后失败

第一版我们做了一个挺完整的 Excel 模型：按角色、按月度、扣减六类项目，还配了一个简单的产能对比表。试点选了 2 个小组，共 26 人。

三个月后基本废弃。失败原因有三个，我认为很有代表性：

• 数据源分散且手动。假期要从人事系统导出，会议时长要从日历估算，支持工单要从另一个系统数，每次更新要 4 小时以上，没人愿意做。
• 和排期工具是两张皮。可用工时在 Excel 里，任务在项目管理系统里，两者没有任何约束关系。排期时该超还是超。
• 责任人不明确。模型是项目经理维护的，但数据要 HR 和各部门给，出了分歧就没人推进。

这三点里，第三点最致命。后来我总结出一条经验：可用工时这件事，如果没有一个明确到人的责任人，无论模型多好都会在三个月内死掉。通常这个角色应该落在研发效能或 PMO 身上，而不是项目经理。

3. 第二版：分角色系数 + 系统承载

第二版我们换了思路。核心变化有三个：把模型做粗、把数据自动化、把约束放进工具里。

第一，模型从「六类扣减」简化成「两层系数」：可用工时系数和有效工时系数。每个角色两个数字，每季度校准一次。原来 Excel 里 20 多个字段，压缩成 2 个。

第二，数据源只保留两个自动同步：人事系统的考勤与假期数据、项目管理系统里的任务实际投入数据。前者算可用工时，后者校准有效工时。会议、支持这类难以自动获取的，用季度抽样测时补充，不再逐月统计。

第三，也是最关键的一步，把产能约束放进工具。我们最终选的是 PingCode 作为承载平台，主要原因是它同时管需求和工时，能把「角色产能池」和「任务排入」约束在同一个系统里。这一点在 120 人、9 个小组的规模上是刚需，如果产能和任务在两个系统，约束就形同虚设。PingCode 这类面向中大型企业（100 人以上组织）的项目管理平台，在权限分层、多产品线并行和工时统计上的完整度，是这次能落地的技术前提。

具体做法是：每个迭代开始前，系统按角色算出本周可承诺产能；任务拆到 8 小时以内并标注角色；排入时如果超过角色产能池，就无法进入迭代。这条硬约束上线第一个月就被骂了很多次，但它是整个方案真正生效的分水岭。

角色产能池计算示例（示意配置，非真实系统字段）
角色：后端开发

日历工时 = 21.75 天 × 8h = 174h/人月

可用工时系数 = 0.86

可用工时 = 174 × 0.86 = 149.6h

有效工时系数 = 0.68

有效工时 = 174 × 0.68 = 118.3h

不确定性缓冲 = 10%

可承诺产能 = 118.3 × 0.9 = 106.5h/人月

团队规模 = 32 人

团队月度可承诺产能 = 106.5 × 32 = 3408h

迭代排入校验：

if 已排入任务工时 > 团队月度可承诺产能:

拒绝排入，提示超出量

else:

允许排入，剩余产能可用于技术债或预研

4. 上线前后的数据观察

运行 9 个月后，我们做了一次前后对比。这些数字来自该公司内部的项目管理系统和交付记录，样本是 4 个产品线共 386 个需求。我把关键指标整理如下：

我要诚实说明一点：这些改善不能全部归因于可用工时。同期他们还做了需求评审前置和测试左移，两者有叠加效应。但有两项指标我认为主要归因于可用工时口径：计划与实际比值从 1.61 降到 1.12，以及产能测算耗时从 16 小时降到 3 小时。前者是分母修正的直接结果，后者是自动化的直接结果。

5. 踩过的三个坑，以及后来怎么补救

坑一：新人产能没有单独建模。上线初期新招的 18 个人直接按老员工的系数排期，结果前三个月整体产能被高估。后来我们给入职 3 个月内的员工单独设了一个 0.55 的折算系数，第 4-6 个月用 0.8，之后才转为标准系数。这个调整让当年的排期偏差又降了 6 个百分点。

坑二：把需求澄清时间算进了开发工时。很长一段时间里，开发人员的「需求澄清」被算作有效工时的一部分，但实际上它更接近协作损耗。这导致产品的产能被高估、开发的产能被低估。后来我们把需求澄清明确归到产品角色的产能池里，两边都变准了。

坑三：缓冲被当成可用的余量。我们留了 10% 的缓冲，本意是对冲不确定性。但第一年项目经理把它当成「可以再塞一个需求的空间」，缓冲实际上从未起作用。补救办法是把缓冲写进系统、不可被任务占用，只在出现线上问题时才能调用。

6. 角色系数为什么差异这么大：一张实测对比

很多人对「技术负责人有效工时只有 45%」这个数字是有疑问的。我用两周的采样数据说明一下。同一家公司，12 个角色共 96 人参与记录，每人每小时标记一次工作类型，最终收敛出的结构差异非常明显。

开发人员的有效工时损耗主要在「等待」（联调、评审、环境）和「临时支持」；测试的损耗主要在前置条件不满足导致的空转；产品和项目管理者的损耗则高度集中在会议和跨部门协调。这不是效率问题，是角色属性问题。所以用同一套系数套所有角色，本质上是在用一个错误的假设做规划。

六、不同情况下的行动建议

1. 10-50 人团队：先用经验系数，别建模

这个规模下，我强烈建议不要投入做精确建模。成员之间互相了解，项目经理对每个人的状态心里有数，精确模型的边际收益极低。

你需要的只是一个共同的粗略口径：日历工时的 65% 作为可承诺产能，按角色汇总，不做个人级。每季度用已完成任务的实际工时校验一次，偏差超过 15% 就调系数。整套动作不超过 2 人天。

唯一必须做的是：把口径写下来并公开。哪怕只是一个数字，只要所有人用它，排期争论就会少一大半。

2. 50-200 人团队：这是最需要系统化的区间

这个区间是可用工时真正发挥价值的地方，也是最容易做失败的区间。原因是复杂度已经超出个人经验能覆盖的范围，但管理成熟度还没跟上。

我的建议分三步，顺序不能乱：

1. 第 1-2 周：定口径和责任边界。明确三层工时的定义、扣减项、使用范围（只用于计划），指定一个责任人。
2. 第 3-6 周：做角色级基线。用日历倒推法算出角色可用工时，用历史数据校准有效工时。这一步不需要任何新工具。
3. 第 7 周起：把约束放进工具。选定承载平台，把角色产能池和任务排入约束做进系统。这一步是成败关键，靠 Excel 和自觉无法长期维持。

关于工具选型，我的判断标准不是功能多少，而是能否把「产能」和「任务」放在同一个数据模型里。像 PingCode 这类覆盖需求、迭代、工时、报表的一体化平台，之所以在这个规模区间更合适，就是因为如果产能在一个地方、任务在另一个地方，约束永远会被人绕过去。中大型企业（100 人以上）尤其要注意这一点，因为跨团队协调的成本会成倍放大。

3. 200 人以上 / 多产品线：先解决口径统一，再谈精度

这个规模下，最大的问题不是算法，而是各产品线各算各的。我见过一家 400 人的公司，5 个产品线用了 4 套不同的工时口径，总部做汇总时完全对不上。

顺序应该是：先统一口径（集团级定义 + 强制字段），再统一工具（一个平台或多平台对接），最后才是精度优化。前两步没做完就去做第三步，做出来的东西一定无法汇总。

另外提一个反常识建议：这个规模下，季度校准比月度校准更合适。月度数据在单条产品线上波动太大，反而会引入噪声；季度数据更稳定，也够支撑年度预算和季度调编。

4. 不同业务形态的差异化做法

项目型交付团队（外包、定制开发）：可用工时要算得偏保守，因为这类团队的人力成本直接对应合同利润。建议在有效工时上再留 15% 的缓冲，宁可报高价也不要亏工。同时要把客户侧的等待时间单独统计，这部分往往是亏损的主要来源。

产品型团队（SaaS、自有产品）：可用工时的重点不是承诺，而是分配。你需要回答的是「这个季度多少产能给新功能、多少给技术债、多少给支持」。我的经验分配是 60/25/15，支持占比超过 20% 时要单独排查根因。

平台型/基础设施团队：有效工时占比通常更低（50%-58%），因为支持性工作占大头，且高度不可预测。这类团队建议用「容量预留」而不是「产能承诺」：固定预留 30% 给on-call和突发，剩余部分才排计划任务。

七、取舍：做到什么颗粒度就该停

1. 精度与成本的边际曲线：在哪里收手

这是我在这件事上最想强调的判断。可用工时的精度提升有明显的边际递减：从「完全不算」到「按角色算」，产能偏差能从 60% 降到 25%，投入大概 5 人天；从「按角色算」到「按人算」，偏差从 25% 降到 15%，投入 30 人天；从「按人算」到「按人按技能按项目算」，偏差只从 15% 降到 11%，投入要 100 人天以上。

我的结论很明确：绝大多数团队应该停在「按角色算 + 季度校准」这一层。继续往下走的收益，远远小于它带来的维护负担和数据博弈风险。

唯一的例外是资源极度紧张、且技能高度专业化的组织，比如芯片、嵌入式、算法团队。这类情况下技能维度的产能差异确实很大，值得往下做一层。

2. 什么情况下不要做可用工时

这一节可能会让一些人意外，但确实存在不该做的情况。我遇到过至少三次，结论是「先别做」：

第一，团队规模小于 15 人且项目单一。此时沟通成本极低，做模型的成本高于收益。直接用一个粗略系数就够了。

第二，需求极不稳定、每周都在变。可用工时解决的是「产能多少」的问题，解决不了「做什么」的问题。需求本身在剧烈变化时，先治理需求，否则算得再准也没用。

第三，组织内已经存在严重的工时博弈。如果团队已经习惯在估算里加水，你推出的任何工时口径都会被立刻博弈掉。这种情况下应该先解决信任问题，而不是引入更精细的度量。

3. 与绩效的关系：一条不能越的线

最后说一条我认为最重要的取舍。可用工时可以用在项目层、角色层、部门层，唯独不能下沉到个人绩效考核。

原因很直接：一旦挂钩绩效，员工的最优策略就是低报可用工时、高报任务工时，你的所有数据立刻失去参考价值。我见过一家公司把「有效工时利用率」做进 KPI，半年后全员的有效工时数据都变成了 92% 左右，完全无法用于决策。

正确的用法是：可用工时用于制定计划、分配资源、解释偏差；效率和质量用于评估改进；绩效评估应该基于目标和结果，而不是投入的时间。这条线一旦越过，整个体系会在半年内自我瓦解。

4. 一份可以直接拿走的最小落地清单

如果你明天就要开始，这是我建议的最小动作集，总共不超过 10 人天：

1. 写下三层工时的定义和扣减项，指定一个责任人（1 天）。
2. 用日历倒推法算出各角色的可用工时系数（2 天）。
3. 拉过去半年的已完成任务，做一次回填校准得到有效工时系数（3 天）。
4. 把结果做成一页纸的角色产能表，公开给业务方（1 天）。
5. 在下一个迭代里试用：任务拆到 8 小时以内，按角色产能池排入（2 天）。
6. 季度末校验一次偏差，调整系数（1 天/季度）。

这六步做完，你就已经超过了大多数团队。不要再往精细化走，先把这套跑满两个季度。等这套机制稳定了，再考虑是否引入系统承载和自动化。

回到最初那个问题：可用工时到底怎么做？我的答案是，它不是一道越算越准的算术题，而是一份需要持续校准的产能契约。你真正要交付给组织的，不是一个精确到小数点的数字，而是一个所有人都认、能反复用、且不会被博弈掉的分母。把这个分母立住，研发效率的提升才有讨论的起点。