人力资源计划可用工时全流程：研发团队实操方法与一文讲清

去年第三季度，我参与了一家 400 人研发组织的产能复盘。他们的项目管理系统里，Q3 排了 11.2 万小时的计划工时，季度结束实际交付折算不到 7.4 万小时，达成率 66%。更反常识的是，团队并没有闲着，平均每周加班 6.5 小时，工时填报率 92%，每个人的看板都排得满满当当。

问题不在执行力，而在计划端。从"人头数"到"真正能被计划消耗的工时"，中间隔了至少五层折算，而多数团队只算了第一层。这就是本文要讲清楚的事：研发团队的人力资源计划可用工时，到底该怎么算、怎么用、怎么校验。

一、核心结论：可用工时不是乘法，是一条被逐层挤压的供应链

先把结论摆在前面。研发团队做人力计划时，最常犯的错是把"可用工时"理解成一个乘法：人数 × 天数 × 8 小时。这个数字看起来很精确，实际上是一个几乎不会被任何项目消耗掉的虚数。

可用工时的本质，是一条从"名义产能"到"可承诺产能"的逐层衰减链。每往下走一层，都会掉一部分，而且掉的比例在不同组织里差异极大。计划做得准不准，取决于你有没有把每一层的衰减显性化、可解释、可回溯。

1. 我常用的五层折算口径

在服务过的十几个研发团队里，我逐步收敛出一套五层口径。它不是国标，也不是某本教科书的公式，而是被反复打脸之后调出来的实用版本。下面这组数字来自我对 12 个 100 人以上研发团队的样本观察（2022，2024 年，含互联网、企业软件、智能硬件三类），用中位数表达。

请注意最后一列：从 174 到 68，保留率只有 39%。也就是说，一个 10 人团队如果按 174 小时/人月去排计划，真实可承诺的产能大约只有 680 小时，而不是 1740 小时。这个差距，就是很多团队"永远排不满、永远延期"的数学根源。

2. 一个反直觉的判断：可承诺工时才是计划单位

很多团队纠结"可用工时要算多准"。我的判断是：你不用把可用工时算准，你只需要把可承诺工时定对。这两件事不是一回事。

可用工时是描述性的，回答"团队理论上能干多少"；可承诺工时是承诺性的，回答"团队敢对外答应多少"。前者用于复盘和校准，后者用于排期和对外交付。把两者混在一起，就会出现两种典型灾难：用可用工时排期，必然乐观；用可承诺工时做考核，必然保守。

我通常建议的比例是：可承诺工时 = 可计划工时 × (0.8 ~ 0.85)。这个缓冲不是拍脑袋，而是我用样本里"计划偏差绝对值的中位数"倒推出来的。后面第五节会给出具体数据。

3. 全流程五个动作，缺一不可

把上面的口径落到操作层面，可用工时全流程可以拆成五个动作。顺序不能乱，因为后一个动作依赖前一个动作的输出。

1. 建立日历基线：把组织假期、个人假期、培训计划、公共事件统一进一个日历，形成第 1 层数字。
2. 采集个人可用系数：按角色、按人，给出会议占比、行政占比、支持占比的经验系数，形成第 2 层数字。
3. 估算协同损耗：按依赖密度、跨时区程度、并行项目数，估算等待和切换损耗，形成第 3 层数字。
4. 剥离非项目占用：把技术支持、线上值班、临时插入需求单独立项核算，形成第 4 层数字。
5. 设定缓冲并滚动校准：按季度设缓冲，按月度用实际数据回填系数，形成第 5 层数字并持续修正。

第 5 步是最容易被跳过的，也是最值钱的。没有回填机制的可用工时，本质上是一次性估算，用两次就失真。我见过太多团队第一年算得很认真，第二年直接沿用，第三年发现模型完全对不上，最后干脆放弃。

二、背景与真实场景：为什么研发团队的可用工时特别难算

制造业算可用工时相对简单：设备有节拍，工序有标准工时，人机料法环相对稳定。研发不一样。研发的输入是需求，输出是代码、设计、测试报告，中间充满不确定性、创造性和协作摩擦。这让可用工时的计算难度高出一个量级。

1. 研发工作的三个非确定性来源

我在复盘时习惯把非确定性拆成三类，因为它们的处理方式完全不同。

第一类是需求非确定性。同一个需求，不同人理解不一样，估算可能差 3 倍。这类不确定性靠需求澄清和估算校准解决，不靠可用工时模型。

第二类是技术非确定性。架构选型、第三方依赖、性能瓶颈，都可能让一个 5 人天的任务变成 15 人天。这类不确定性靠技术预研和 Spike 解决，可用工时只能通过缓冲吸收。

第三类是协作非确定性。等待评审、等待环境、等待上游接口、等待跨团队决策。这类不确定性恰恰是可用工时模型最该处理、却最常被忽略的部分。我在样本里做过统计，协作等待平均消耗研发人员 18%，25% 的可工作时间。

换句话说，可用工时模型不是用来消灭不确定性的，而是用来把"可控的损耗"提前显性化，把"不可控的损耗"放进缓冲里。这个定位想清楚了，才不会把模型做成一个精确但无用的摆设。

2. 一个中大型研发组织的真实困境：三种口径在打架

去年那家 400 人组织，问题出在三个部门各有一套口径，而且互相不认。

HR 部门按 21.75 天 × 8 小时 × 人数算"人力供给"，这个数字进了年度人力预算。PMO 按项目排期汇总"计划工时"，口径是 20 天 × 7.5 小时 × 投入比例。研发经理按自己的经验拍"这个季度能干多少"，通常比 PMO 的数字再打七折。三套数字同时存在，谁都不服谁。

结果是：预算按 HR 口径批，排期按 PMO 口径排，执行按经理口径干。到了季度末，实际交付对不上任何一套数字，复盘会开成了甩锅会。

3. 为什么大组织比小团队更需要这套模型

小团队不太需要复杂的可用工时模型。5 个人坐在一起，谁忙谁闲一目了然，口头协调就够了。但当组织超过 100 人、跨 3 个以上项目、有 2 层以上汇报关系时，直觉就失效了。

我在样本里观察到一条规律：团队规模每翻一倍，可用工时的估算误差大约放大约 1.4 倍。10 人团队的估算误差可能是 ±10%，40 人团队变成 ±25%，150 人团队轻松到 ±40%。这不是因为大团队的人不专业，而是因为协调节点数按 n(n-1)/2 增长，而每个节点都在消耗可用工时。

这也解释了为什么中大型企业更愿意在工具上投入。像 PingCode 这类面向 100 人以上组织的项目管理平台，核心价值之一就是把"人、项目、工时、迭代"放在同一套数据模型里，让可用工时的计算和回填不必依赖 Excel 手工拼装。小团队用表格可以撑住，大组织用表格撑不住，不是因为表格不好，而是因为协作节点太多，手工同步的成本超过了收益。

三、拆解常见误区：六个让可用工时"虚高"的典型操作

下面六个误区，是我在复盘里出现频率最高的。按杀伤力排序，前三个几乎每个团队都中过。

1. 用 21.75 × 8 当计划基准

这个数字来自法定月计薪天数，用于算工资是对的，用于排计划是错的。它既没有扣年假，也没有扣会议，更没有扣协作等待。用计薪天数当计划天数，是可用工时虚高的第一来源。

我做过一个简单的对照：同一个月，用 174 小时排计划和用 82 小时排计划，项目数量相差 2.1 倍。团队按 174 排，必然超载；超载之后，管理动作变成"催"，而不是"调"，恶性循环就开始了。

2. 把加班当成可用产能

很多团队在算可用工时时，会默默加一行"平均加班 6 小时/周"。这个操作看起来很务实，实际上非常危险。

原因有两个。第一，加班产能的边际效率是递减的，我在样本里观察到的规律是：每周加班超过 8 小时后，单位小时的有效产出下降 30%，45%。第二，加班会侵蚀次日的可用工时，形成"今天多加 2 小时、明天少干 3 小时"的负循环。

我的建议是：加班不进计划，只进缓冲消耗记录。计划里不体现加班，但每周记录"缓冲被加班吃掉了多少"，作为下季度调整缓冲比例的输入。

3. 只算人不算时段

这是最隐蔽的一个误区。团队算了"张三是 0.8 人力投入"，但没算"张三在 10 月前两周被借调去做合规审计"。人 vs 时段，是两个维度。

我在做可用工时表时，会强制要求一行"不可用时段"：某人某周因为什么原因不可用，占多少比例。这个字段看起来琐碎，但它把"平均投入"变成了"分时段投入"，计划精度会明显提升。

4. 忽略上下文切换的隐性损耗

这是我见过被低估最严重的一项。一个人同时参与 3 个项目，看起来每个项目投入 33%，实际有效产出远低于 33%。

原因在于切换成本。每次从一个项目切到另一个，需要重新加载上下文、回忆进度、重新进入状态，这个过程平均消耗 15，25 分钟。如果一天切换 4 次，就是 1，1.5 小时，占 8 小时工作日的 12%，19%。

5. 用历史平均值代替计划值

有些团队进步了一点，开始用"过去 6 个月的平均可用工时"来做计划。这比 174 好，但仍有问题：平均值会掩盖季节性波动。

研发组织有明显的季节性。年初通常有规划会、述职、招聘，可用工时偏低；年中相对稳定；年末有结算、审计、年会，又会掉一截。用年度平均值排季度计划，等于把波峰波谷抹平，计划在波谷月份必然超载。

我的做法是：用"同季度历史中位数"而不是"全年度平均值"。比如排 Q4 计划，就看过去两年 Q4 的实际可用工时中位数，而不是全年平均。这个调整很小，但效果明显。

6. 把可用工时当考核指标

这一条不是计算误区，是使用误区，但杀伤力最大。一旦可用工时进入个人考核，数据立刻失真：填报会往高了报，任务会往细了拆，协作会变少，因为协作不产生"自己的工时"。

可用工时的正确用途是"预算"和"校准"，不是"考核"。它回答的是"这个季度我们能接多少活"，而不是"这个人这个月干了多少活"。用错了用途，再准的模型也会被玩坏。

四、专业判断逻辑：把可用工时拆成可校验的五层模型

这一节是全文的方法核心。我不打算给一个"万能公式"，因为不存在。我要给的是一套可拆解、可回填、可解释的折算逻辑，你可以按自己的组织情况调整系数，但不要跳过任何一层。

1. 第一层：日历层，把所有"人不在"先扣掉

日历层的输入是组织日历，输出是每个人每月的"在岗天数"。这一层看似机械，实际上最容易被做错，因为它需要处理三种不同类型的假期。

（1）全员假期：法定节假日、公司统一放假、年会、团建。这类假期对所有人影响一样，直接从日历扣除即可。

（2）个人假期：年假、调休、婚假、产假。这类假期需要落到人头，而且有时间分布。产假、陪产假这类长假期必须单独标注，否则会被平均掉。

（3）准假期：培训、出差、外派、借调。它们不是假期，但同样让人"不在项目上"，必须单独核算。

我在实操里的做法是做一个"日历基线表"，每个季度更新一次。这张表只有四列：人、日期区间、类型、影响比例。简单，但必须有人维护。

第一层的输出指标，我建议用"日历可用率"，公式是：日历可用天数 ÷ 自然工作日天数。健康值通常在 88%，93% 之间，低于 85% 说明假期密集，需要提前预警。

2. 第二层：个人可用层，把"人在但不在状态"扣掉

这一层最考验经验判断，因为它没有标准答案。同样是 8 小时在岗，一个 Tech Lead 和一个初级开发的可工作时间完全不同。前者的会议占比可能是 40%，后者可能是 15%。

我通常用"角色系数"来处理，而不是给每个人单独估。角色系数的含义是：该角色每周可被项目直接使用的时间占在岗时间的比例。下面是样本里观察到的典型区间。

需要注意的是，这些系数不是固定的，会随组织阶段变化。初创团队的技术负责人可能还有 70% 时间写代码，成熟组织的技术负责人可能只有 40%。系数要每年校准一次，用实际工时数据回填，而不是凭印象。

3. 第三层：协同层，把"人在状态但被卡住"扣掉

协同损耗是最难量化、也最容易被忽略的一层。它包含四类：

• 等待评审：代码评审、设计评审、需求评审的排队时间。
• 依赖阻塞：上游接口未就绪、环境未准备好、第三方未交付。
• 会议同步：第 2 层已经扣了会议，但跨团队对齐会往往超出系数范围，需要额外扣。
• 上下文切换：并行项目之间的切换成本，按并行度计算。

我的处理方法是分层扣减，而不是一刀切。等待评审和依赖阻塞，按"依赖密度"估算；上下文切换，按"并行项目数"折算；跨团队对齐会，按"上下游团队数"估算。

一个可用的经验公式是：协同可用率 = 1 − 依赖密度 × 0.15 − (并行项目数 − 1) × 0.12。依赖密度指"需要外部输入的开发任务占比"，并行项目数是"单人在本季度参与的项目数量"。这个公式是经验近似，不是精确科学，但它能把"感觉好像被卡住了"变成一个可以讨论的数字。

4. 第四层：项目占用层，把"人在项目上但没在做计划内的事"扣掉

这一层经常被整个跳过，因为它涉及"政治敏感"的问题：谁在承担技术支持？谁在值线上班？谁在救火？

在样本里，技术支持、线上问题、临时插入需求这三类，平均消耗研发团队可计划工时的 12%，18%。如果团队正在做平台化改造或大促支撑，这个比例会更高，我见过最高的一个团队达到 31%。

我的建议是：把这三类单独立项，不要混在项目工时里。混在一起会导致两个后果：一是项目进度看起来永远滞后，二是没人知道真实的"救火成本"是多少。

单独立项之后，你至少能回答三个问题：本季度支持类工作占了多少？谁承担了最多？下季度是否需要调整？这三个问题回答不了，可用工时模型就只是半成品。

5. 第五层：可计划层，给承诺留出缓冲

走完前四层，你得到的是"可计划工时"。它已经比较接近真实产能，但还不能直接对外承诺，因为还有风险缓冲没算。

缓冲比例的设定，取决于三个因素：需求确定性、技术确定性、团队成熟度。需求越不确定、技术越新、团队越新，缓冲越大。我在实操里的建议区间是 15%，20%，具体见下表。

缓冲不是浪费，是承诺的保险费。没有缓冲的计划，等于把不确定性全部转嫁给执行者。执行者扛不住，就会用延期、降质、加班三种方式还债，哪一种都不是组织想要的。

6. 校验机制：没有回填的模型只能活一个季度

五层模型建好之后，最重要的动作是回填校验。我的建议是每月一次小幅校准、每季度一次大幅校准。

月度校准看三个指标：计划工时 vs 实际工时偏差、缓冲消耗率、并行项目数变化。季度校准看两个：角色系数偏差、协同可用率偏差。偏差超过 10% 的系数，必须重估。

这个机制听起来很重，实际上每月只需要半天。但它是模型能不能活过三个季度的关键。我见过太多团队第一版模型做得漂亮，第二季度不校准，第三季度彻底失真，最后结论是"这套方法不适合我们"，其实不是方法不对，是没维护。

五、案例与数据观察：一家 400 人研发组织的 90 天改造

回到开头那家 400 人组织。他们在 Q3 复盘后决定做一次系统性改造，我参与了整个过程。这一节把改造前后的数据摊开讲，给正在考虑落地的团队一个参照。

1. 改造前的基线：三个数字暴露问题

改造前的 Q3，有三个数字很说明问题。

第一，计划工时 11.2 万小时，实际交付折算 7.4 万小时，达成率 66%。第二，平均并行项目数 3.4 个，其中核心模块负责人平均并行 4.2 个。第三，技术支持与线上问题占用可计划工时的 21%，但从未单独立项。

这三个数字放在一起，结论很清楚：不是团队不努力，是计划本身建立在错误的假设上。按名义工时排计划，忽略了协同损耗和非项目占用，结果必然是全面超载。

2. 改造动作：四步走，先慢后快

（1）统一口径：把 HR、PMO、研发经理叫到一张桌子上，用五层模型重新定义"可用工时"的含义。这一步花了三周，比预期长，但值得。口径不统一，后面所有动作都是白做。

（2）建立基线表：以季度为单位，做了一张包含"人、角色、日历可用率、角色系数、并行项目数、非项目占用"的基线表。第一个版本是 Excel，后来迁到了项目管理系统里。

（3）单独立项支持类工作：把技术支持、线上问题、临时插入需求做成独立的工作类型，计入工时不进项目排期。这一步让项目排期立刻"松"了下来，也让救火成本第一次可见。

（4）建立月度回填机制：每月最后一个周五，各团队用半天时间校准系数，更新下月可用工时。这个动作坚持了三个月，成为制度。

3. 工具落地：为什么最终选了 PingCode

改造初期他们用 Excel 维护基线表，两个月后开始吃力。原因是并行项目数、角色系数、非项目占用三类数据分散在三个系统里，手工同步每月要花 2，3 人天，而且经常对不上。

他们最终选了 PingCode，看中的不是功能多，而是三件事能在一套数据模型里闭环：人员与角色、项目与迭代、工时与实际投入。对一家 400 人、跨 6 个产品线的组织来说，这个闭环价值很直接，基线表可以自动生成，月度校准从手工搬数据变成核对异常值。

需要说明的是，这不是"必须上工具"的结论。100 人以下的团队，用表格完全可以撑住。但当组织超过 100 人、项目数超过 10 个、跨 2 层以上汇报关系时，手工维护的成本会快速超过工具成本。这个临界点，我在样本里观察到大约在 120，150 人之间。

4. 90 天后的数据：达成率提升了，但不是靠加人

改造后的第一个完整季度（Q4），关键数据如下。这里要强调：他们没有加人，没有延长工时，也没有降低交付标准。

有一组数据特别值得说：改造后计划工时总量从 11.2 万降到 8.2 万，降幅 27%，但实际交付从 7.4 万微升到 7.6 万。这意味着挤掉的 3 万小时几乎全是"虚高"，真实产能并没有减少。这个发现让管理层第一次直观理解了"计划虚高"的代价，它不只是数字问题，它会让组织长期处于"看起来忙、实际低效"的状态。

5. 一个意外收获：缓冲消耗率成了新的管理指标

改造后他们意外发现，缓冲消耗率比达成率更好用。达成率是结果指标，滞后；缓冲消耗率是过程指标，领先。

他们的用法是：某月缓冲消耗率超过 80%，说明这个团队本月被突发事件打得很惨，下月要主动减负；连续两个月低于 40%，说明缓冲设得过大，可以适当收紧。这个指标每月看一次，比季度复盘及时得多。

我在其他团队也验证过这个用法，效果稳定。缓冲消耗率的健康区间大致是 55%，75%，低于 50% 说明保守，高于 85% 说明缓冲不足或突发事件失控。

六、行动建议：按组织规模分档落地

同样一套方法，10 人团队和 1000 人组织的落地方式完全不同。这一节按规模分四档，给出可操作的起点。不要跨档照搬，跨档照搬是这类方法最常见的失败原因。

1. 50 人以下团队：轻量版，两个字段就够

小团队不需要五层模型，太重。我的建议是只做两件事：一是按角色给一个可工作系数，二是每月记录一次并行项目数。

可工作系数可以直接用经验值：开发 80%、测试 75%、产品 62%。并行项目数超过 2 的，主动收敛。这两件事加起来，每月花不到 1 小时，但能解决 80% 的超载问题。

小团队最容易犯的错是"照搬大厂模型"。我见过 15 人团队做五层折算表，做了两周，用了一次就放弃。方法要和组织的协调复杂度匹配，不是越精细越好。

2. 100，300 人团队：标准版，五层模型 + 月度校准

这个规模是五层模型的最佳适用区间。协调节点已经多到直觉失效，但还没多到需要复杂系统支撑。

落地顺序建议是：先做第 1、2 层（日历 + 角色系数），跑一个季度；再加入第 3 层（协同损耗），再跑一个季度；最后加第 4、5 层（非项目占用 + 缓冲）。分三步走，比一次性上线成功率高得多。

工具上，Excel 可以撑住，但当项目数超过 8 个、需要每月校准 3 个以上系数时，建议考虑专业平台。PingCode 在这个规模区间的适配度较高，主要因为它的数据模型天然包含"人，项目，迭代，工时"四层关系，不需要手工拼表。

3. 300，1000 人团队：系统版，模型 + 工具 + 治理

这个规模，光有模型不够，还需要治理机制。三个动作缺一不可。

第一，设立口径 owner。谁负责维护五层模型的系数？谁批准口径变更？没有 owner，模型会在半年内被各种"临时调整"拆散。

第二，建立数据回填流程。月度校准不能靠自觉，要进流程。我的建议是挂在月度经营分析会上，用 15 分钟过一遍异常值。

第三，工具承载数据。这个规模手工维护成本已经很高，需要系统承载。选型时重点看三点：能否按角色配置系数、能否自动汇总并行项目数、能否导出月度校准报表。这三点比功能清单长度重要得多。

4. 1000 人以上 / 多 BU 组织：分层版，统一框架 + 局部参数

超大规模组织的核心矛盾是"统一"和"灵活"的冲突。总部想要统一口径，BU 想要本地灵活。我的建议是分层设计。

总部定框架：五层的定义、计算公式、校准周期、报表口径。BU 定参数：角色系数、缓冲比例、并行度上限。框架统一保证可比性，参数灵活保证可执行。

这种分层设计的难点在于"参数变更的审批边界"。我的经验是：±5% 以内的参数调整，BU 自主决定；超过 ±5%，需要总部口径 owner 审批。这个边界既能保证灵活性，又能防止口径漂移。

七、取舍：四组必须做的选择

可用工时这套方法，真正难的不是算，是选。下面四组取舍，每一组都没有标准答案，只有适配你组织的答案。

1. 精度 vs 维护成本

五层模型比三层准，但维护成本高 3，4 倍。我的判断标准是：如果模型精度提升带来的决策改善，抵不过维护成本，就该降级。

一个可操作的检验方法是：问自己"如果这个系数错 10%，我的决策会变吗？"如果不会变，这个系数就不值得单独维护。很多团队在角色系数上做到 20 个角色，实际上决策只区分"开发/非开发"两类，多出来的 18 个角色纯属自嗨。

2. 统一口径 vs 局部灵活

统一口径便于横向比较和资源调配，局部灵活便于贴合业务实际。这两者的张力在 300 人以上组织尤其明显。

我的建议是"框架统一、参数分层"，前面已经讲过。这里补充一个判断：当 BU 之间的业务差异超过 2 倍（比如一个做 To B 软件、一个做硬件），参数必须分层；差异在 1.5 倍以内，优先统一。统一带来的管理收益，通常大于局部优化的收益。

3. 刚性计划 vs 滚动调整

刚性计划便于承诺和考核，滚动调整便于应对变化。研发组织变化快，我倾向于"季度刚性、月度滚动"。

具体做法是：季度初锁定可承诺工时，作为对外承诺依据；每月根据缓冲消耗率和实际偏差，滚动调整下月计划，但不改季度承诺。这样既保证了承诺的严肃性，又保留了执行的灵活性。

需要警惕的是"滚动变成随意"。滚动调整必须有触发条件，比如缓冲消耗率超过 80%、并行项目数变化超过 30%、关键人员变动。没有触发条件的滚动，等于没有计划。

4. 工具自动化 vs 机制约束

工具能自动算，但不能自动管。我见过团队上了工具，系数半年不校准，报表漂亮但数字失真。也见过团队纯手工，但每月准时校准，数字反而可信。

工具解决"算得快"，机制解决"算得对"。两者的优先级是机制在前、工具在后。先有校准机制，再上工具；反过来做，工具只会让错误的数据跑得更快。

八、总结与下一步：先算对，再算细

把全文压缩成一句话：可用工时的核心不是"算得多准"，而是"口径统一、逐层折算、持续回填"。12 个样本团队里，凡是做到这三点的，计划达成率普遍从 60% 区间提升到 80% 区间；凡是只做第一点的，半年内基本回到原点。

还有一个更重要的判断：可用工时是预算，不是考核。把它当预算，它会帮你做减法，让组织接该接的活；把它当考核，它会逼出数据造假和协作萎缩，最后连预算都做不准。这个定位如果错了，方法越精细，伤害越大。

如果你准备动手，我建议从一个 30 天的最小路径开始，不要一上来就做全量模型。

1. 第 1 周：把过去一个季度的"计划工时"和"实际交付"拉出来，算一个达成率。这个数字会让你知道问题有多大。
2. 第 2 周：给团队做一次角色系数盘点，只分三档（开发/测试/产品），用经验值先跑起来。
3. 第 3 周：统计并行项目数，找出并行度最高的 20% 人员，尝试收敛 1 个项目。
4. 第 4 周：设定 15% 缓冲，建立月度校准的第一次会议，把"缓冲消耗率"作为第一个跟踪指标。

30 天后你会得到两个东西：一个比原来更真的可用工时数字，和一个能持续校准的机制。这两样加起来，比任何一套精细模型都值钱。

最后提醒一句：不要追求一步到位。可用工时模型的成熟周期通常是 3，4 个季度，第一版一定不准，第二版开始收敛，第三版才稳定。能坚持校准的团队，最终都会得到一套贴合自己的模型；追求一次算准的团队，通常连第一版都活不过去。