可用工时落地方案：研发团队开展人力资源计划的效率提升案例解析

去年 Q3，我参与了一家工业软件公司的研发资源复盘。这家公司有 11 个研发小组、212 人，其中真正参与交付的 186 人，工时填报系统上线两年，填报率常年在 92% 以上。数据看起来很全，但当我问"下个季度你们还能接多少需求"时，三个人给了我三个答案：技术总监说"大概 40 个"，PMO 按产能公式算是"65 个"，而一线组长说"能接 20 个就不错了"。三个数字差了 3 倍。

问题不在填报，也不在态度。问题在于"可用工时"这四个字，在这个组织里从来没有被真正定义过。有人把它当考勤记录，有人把它当产能公式，有人把它当"我手下有几个人"。三种理解并存，任何一个资源计划都会在落地第一周就崩掉。

这篇文章我想把这套东西讲透：可用工时到底该怎么算、为什么大多数团队算出来是虚高的、落地时要拆成哪几层、以及在 30 人、100 人、500 人三种规模下分别该怎么取舍。文中的数据来自我参与的三个研发组织（合计约 460 人）在 2023-2025 年间的实施记录，部分为样本推演值，我会在对应位置标明。

一、核心结论：可用工时是"供给账户"，不是"考勤记录"

先把结论摆出来。如果你只记住五句话，记住下面这五句，剩下的都是展开。

1. 结论一：可用工时的本质是"供给账户"

考勤回答的是"这个人今天来没来"，可用工时回答的是"这个人在未来某个时间窗口内，能被投入到新工作上的净时间是多少"。前者是历史记录，后者是未来承诺。这两个东西的数据源可以重合，但口径、更新频率、责任人完全不同。

把可用工时挂靠在考勤或工时填报上，是这类项目失败的第一大原因。因为考勤系统的设计目标是"准确记录过去"，它天然不关心"未来还能干多少"。你会得到一个漂亮的报表，但它对你的排期毫无帮助。

2. 结论二：三个口径必须分开，名义、可用、可承诺

我在所有项目里都会强行切开三个数字，并且要求它们分别有独立负责人：

• 名义工时：人数 × 工作日 × 标准日工时。这是最没有信息量的数字，但它是一切的基数，也是老板最爱引用的数字。
• 可用工时：扣掉假期、会议、支持、培训、管理事务之后，真正能用于交付的净时间。
• 可承诺工时：在可用工时基础上再扣掉缓冲（需求波动、返工、上线支持），这才是你能对外承诺的量。

三者之间的关系不是"略微递减"，而是断崖式的。在上面那家 186 人的研发中心，名义工时约 4036 人天/月，可承诺工时只有约 2120 人天/月，不到名义值的 53%。这意味着，任何用名义工时做的产能规划，天生就高估了将近一倍。

3. 结论三：算不准的根因，80% 出在损耗项分类

很多人以为可用工时算不准是因为数据不全。我的经验正好相反：绝大多数团队的原始数据是够的，错在分类。他们把"会议"和"支持"混在一起，把"项目内返工"和"需求变更"混在一起，把"带教"算进"开发"里。分类一错，你就永远不知道到底该优化哪一块。

我们做过一次交叉核对：同一批 186 人、同一个月的原始日志，用两种分类方式统计，可用工时的结果相差 17%。数据源一模一样，只是分类粒度不同。所以别急着上系统，先把分类表定下来。

4. 结论四：可用工时的价值在"提前 2-6 周"，不在"事后统计"

这是我判断一个可用工时方案是否成功的唯一标准：它有没有改变排期决策。如果它只在月末出一张报表，让 PMO 写进月报，那它的价值接近于零。

真正有价值的场景是：当销售在第 3 周提一个大需求进来，PM 能在 10 分钟内回答"接了它，哪两个需求的交付会推迟，推迟几天"。这个回答依赖的是未来 6 周的可用工时预测，而不是过去 3 个月的统计。

5. 结论五：落地靠化解三层反对，不靠制度强推

可用工时天然会遭遇三层反对：一线觉得"被监控"，组长觉得"我的灵活调配空间被锁死了"，总监觉得"这套数字挑战了我的经验判断"。这三层反对不会因为一纸制度消失。

我的做法是分层给不同的东西：给一线的是"减少重复填报 + 让他看到自己的负荷曲线"；给组长的是"调配依据 + 争取资源的弹药"；给总监的是"承诺兑现率的趋势"。同一套数据，三种叙事，缺一个都推不动。

二、背景与真实场景：210 人组织的三个季度

1. 起点：从"感觉缺人"到"说不清缺几个人"

2023 年底，这家公司连续三个季度出现同一种事故：某个关键版本临上线前两周，突然发现测试资源被另一个项目占满，导致版本延期 11 天。复盘会上的结论永远是"资源不足，需要招人"。但 HR 反问"缺几个人、缺什么岗"时，没人答得上来。

这种情况我见过太多次。"缺人"是一个情绪判断，不是一个可执行的结论。要把情绪转成结论，中间必须有一个东西：按角色、按时间窗口切分的可用工时缺口。只有到"Q2 我们需要 3.5 个后端人天/天的净增供给，或者砍掉 2 个中优先级需求"这个粒度，招人申请才立得住。

2. 我们试过的三种失败做法

这里我把踩过的坑完整写出来，因为它们非常典型，你大概率正在其中一条路上。

第一种：直接拿工时填报记录算平均。统计过去 6 个月每个人的项目工时占比，取平均，当作未来可用工时的估计。看起来很科学，实际错得离谱，因为填报只填了"项目工时"，会议、支持、答疑、带教这些根本没进系统，导致可用工时被系统性高估。我们算出来的数字是 3400 人天/月，实际盘点只有 2900。

第二种：用"人数 × 8 小时 × 22 天"做产能计划。这是最省事的做法，也是最危险的。它把 4036 人天当成真实产能，直接导致销售端承诺过量、交付端持续加班、离职率上升。用名义工时做承诺，本质上是在向客户借未来员工的健康。

第三种：让组长手工报"我的组这个月能出多少"。第一周效果不错，因为组长最了解自己的组。第三周开始崩：11 个组长有 11 套口径，有人按理想产能报，有人按保守值报，有人干脆按上个月实际数报。数据不可比，汇总起来没有任何意义。

3. 一次把账算清：186 人的供给盘点

2024 年 Q1，我们做了一次彻底的供给盘点。方法很笨：连续 4 周，让所有参与交付的人按 15 分钟粒度记录"不可用于交付的时间"，注意，记录的是不可用时间，不是可用时间。这是一个关键设计。

为什么记不可用？因为人对自己被占用的时间记忆更准确，而且记录"被占用"的心理抵触远小于"汇报我干了什么"。这条经验后来被我们沿用到了所有项目里，效果差异非常明显：记录不可用时间的完成率是 91%，记录可用时间（正向工时）的完成率只有 74%。

4 周的数据汇总出来，损耗结构是这样的：

4. 数据观察：损耗从来不在你以为的地方

盘点结果里有两个发现让我印象很深。

第一，"支持与答疑"占了 8.9%，几乎和"会议"处在同一量级。但在这家公司之前的认知里，支持答疑是"顺手的事"，从来没被计入产能。8.9% 意味着每 11 个人里就有 1 个人整天在做支持。这个数字一摆出来，技术总监当场决定设两个专职支持岗，反而释放了更多产能。

第二，"项目内返工"只占 4.5%，远低于我的预期。我原本以为是 10% 以上。追问之后发现，返工被大量记进了"开发"里，因为大家在心理上不认为"改需求"是返工。这说明损耗分类的第一版永远不准，你必须允许分类表在 2-3 个迭代内持续修订。

三、常见误区拆解：六个让你算不准的坑

下面六个误区，按我遇到的频率排序。前三个几乎每个团队都会踩，后三个主要出现在 100 人以上的组织。

1. 误区一：填报率高就等于可用工时准

这是最普遍的误解。填报率只反映"有没有填"，不反映"填得对不对、全不全"。我们见过填报率 96% 的团队，可用工时依然虚高 20%，因为大家只填项目工时，不填会议和支持。

正确的替代指标不是填报率，而是"损耗覆盖率"，即已记录的不可用时间占实测不可用时间的比例。这个指标才是真正决定可用工时是否可信的东西。我的经验阈值是：损耗覆盖率低于 80%，可用工时不能用于对外承诺。

2. 误区二：8 小时 × 22 天 × 人数 = 产能

这个公式的问题不只是"没扣损耗"，更深的问题是它假设了所有人的时间价值相同。一个团队里，2 个高级工程师和 5 个初级工程师，名义工时同样算，可承诺产出可能差 3 倍。

所以我坚持在可用工时里加一个"角色系数"，用技能等级和任务匹配度做加权。这一步会让计算变复杂，但它是从"人力统计"跨到"资源计划"的关键一步。

3. 误区三：只算个人可用，不算团队可用

一个 8 人团队，每个人可用 60%，团队可用不是 60%。因为存在协调成本和关键人瓶颈：如果这个团队里只有 1 个人能改某个核心模块，那这个人一旦请假，团队实际可用会断崖式下跌。

团队可用工时的正确算法是"取瓶颈角色的可用量"，而不是"求和"。这是我见过最多 PMO 算错的地方。他们把所有人工时加起来除以天数，得到一个看起来很美的团队产能，但一到排期就被单点卡死。

4. 误区四：把"忙碌"当成"可承诺"

有些团队已经扣了会议、扣了支持，算出来 70% 的可用率，觉得很严谨了。但他们没有扣缓冲。结果是：计划排到 100% 满载，任何一次需求变更、任何一次线上事故，整个排期就崩。

我在所有项目里都强制要求留 15%-25% 的缓冲，并且这个缓冲不能藏在个人身上，必须显式地在计划里留出来。藏在个人身上的缓冲会被组长不自觉用掉，等于没有。

5. 误区五：一次性算准，然后一年不动

组织是活的。招人、离职、转岗、技能提升、业务线调整，任何一个变化都会让可用工时漂移。我见过一个团队 2023 年 3 月做的可用工时模型，到 2024 年 1 月还在用，误差已经超过 30%，但没人质疑，因为"这是系统算的"。

我的建议是分层设不同的更新频率：日历层按月、个人供给层按周、角色供给层按季、承诺缓冲层每季度校准一次。这个节奏后面会详细讲。

6. 误区六：可用工时只给 PMO 看

这是组织层面的误区，也是最难改的。如果可用工时只用于 PMO 出报表、考核项目进度，那它一定会被"美化"。一线会用各种方式让数字好看，组长会争取更宽松的系数，最后系统里的数据和真实情况脱节。

破解方法是双用途设计：数据既要向上（用于计划与承诺），也要向下（用于减负与争取资源）。当一线发现"填了这些数据，组长真的去申请了人手、真的砍掉了一个无效会议"，配合度会完全不一样。

四、专业判断逻辑：可用工时的四层模型

讲完误区，该讲方法了。我用的是一套四层模型，从下往上，每一层解决一类问题。这套模型的好处是：你可以只做前两层就先跑起来，不必等所有层都完备。这对资源有限的团队非常重要。

1. 第一层：组织日历层

这一层最简单，也最容易被跳过。内容包括：法定节假日、公司统一假期、调休安排、双周/单周工作制、值班轮换表。

看起来是体力活，但它的价值在于把"不可谈判的刚性损耗"先钉死。很多团队算可用工时时，把这些和弹性损耗混在一起讨论，导致每次开会都在争"年假算不算损耗"，浪费时间且没有结论。先钉死这一层，后面的讨论才有基础。

这一层的更新频率：按月，由 HR 或行政统一维护，其他人只读。

2. 第二层：个人供给层

这一层是可用工时的主体，包含：请假（年假、病假、事假）、培训、出差、会议、支持答疑、管理事务。

我的做法是把它拆成"刚性"和"弹性"两类。请假、出差是刚性的，可以精确到天；会议、支持、答疑是弹性的，用"周均值 + 波动区间"来估，而不是精确到小时。

这里有一个反直觉的判断：弹性损耗不要追求精确。你花两周时间去精确统计每个人每天开了多少分钟会，得到的精度提升可能只有 2 个百分点，但付出的填报成本会让整个系统在三个月内被弃用。用"日均 1.2 小时，区间 0.9-1.6"这样的估算，反而更可持续。

3. 第三层：角色与技能供给层

这一层是从"人力统计"升级到"资源计划"的分水岭。它回答的不是"有多少人"，而是"有多少个能干活的后端"、"有几个能做架构评审的人"、"测试里能独立写自动化脚本的有几个"。

具体做法是给每个人打上 1-3 个技能标签，并标注熟练度（可独立、需指导、可指导他人）。然后在计算可用工时时，按角色维度聚合，而不是按部门聚合。

（1）技能标签不要超过 3 个。超过 3 个就失去了区分度，等于没打。

（2）熟练度必须由组长校准，不能自评。自评的通货膨胀率我见过高达 40%。

（3）每季度校准一次，跟着绩效回顾走，不额外增加流程。

4. 第四层：可承诺层（缓冲系数）

前三层算出来的是"可用工时"，第四层才是"可承诺工时"。区别就是缓冲系数。

缓冲系数怎么定？我的经验公式是三部分相加：需求波动（通常 8%-12%）、返工（4%-6%）、上线与运维支持（3%-6%）。加起来 15%-24%，取中位数 20% 作为默认值。

这个系数必须每季度用实际数据校准一次。校准方法是：看过去一个季度"计划工时 vs 实际工时"的平均偏差，如果偏差是 +18%，说明缓冲定低了；如果是 +8%，说明缓冲过高，可以适度收紧。这个反馈闭环是整套模型能持续存活的关键。

5. 折算链路：从名义到可承诺的一个可执行公式

把四层串起来，就是一个可以写进系统或表格的折算链路。我通常用下面这段伪代码跟工程团队对齐口径，比用文字描述准确得多。

可承诺工时(人天) = Σ_每个角色 [
(组织日历工作日 – 个人不可用日)

× 日均有效工时

× 角色可用系数

] × (1 – 缓冲系数)

参数口径：

日均有效工时 = 8.0h – 会议均值(1.1~1.4h) – 支持答疑均值(0.6~0.9h) – 事务均值(0.4~0.6h)

→ 实测常见区间 5.0 ~ 6.2h

角色可用系数 = 该角色在本计划期内可被调用的比例

→ 兼职 0.5，跨项目借用 0.3~0.6，带教期 0.7，全职 1.0

缓冲系数 = 需求波动(8%~12%) + 返工(4%~6%) + 上线支持(3%~6%)

→ 默认 0.20，按季度用实际偏差校准

校验规则：

若 可承诺工时 / 名义工时 > 0.65 → 大概率损耗覆盖率不足，需复核

若 可承诺工时 / 名义工时

这两条校验规则很实用。我们在三个组织里都用了它，第一年就靠它抓出了 4 次明显的口径错误，其中一次是某团队把"会议"在两层里各扣了一遍，导致可用工时被低估 12%，差点误判要招人。

6. 更新频率：哪一层该周更、哪一层该季更

这一节是落地时最容易被忽略、但决定系统能否长期存活的细节。

• 组织日历层：月更，HR 统一维护，其他人只读。变更需要审批，否则会出现"为了排期方便私自改日历"。
• 个人供给层：周更。请假、出差这类刚性项实时更新；会议、支持这类弹性项用滚动 4 周均值，不追实时。
• 角色供给层：季更，跟绩效回顾或技能评估同步。不要单独搞一套流程。
• 承诺缓冲层：季更，用上一季度的计划偏差率反向校准。

最关键的一条：越低频的层，越要固化；越高频的层，越要轻量。很多系统失败是因为把高频层做得太重（每天填一堆字段），把低频层做得太随意（缓冲系数三年不变）。

五、案例与数据：186 人团队六个月的前后对比

1. 落地路径：五个阶段

这套东西我们从 2024 年 4 月开始推，到 10 月基本稳定，历时约 6 个月。路径大致是五段：

1. 第 1 个月：口径对齐。只做一件事，把损耗分类表定下来，11 个组长逐个过一遍，确保每个人对"返工""支持""事务"的理解一致。这一步花的时间最长，也最值。
2. 第 2 个月：基线测量。连续 4 周记录不可用时间，得到第一份真实损耗结构。这一步不做任何优化，只测量。
3. 第 3 个月：模型搭建。把四层模型落进工具，先只做日历层和个人供给层的刚性部分。
4. 第 4-5 个月：试点与校准。选 3 个组试点，用实际排期结果反向校准缓冲系数和角色系数。
5. 第 6 个月：全量推开 + 建立季度校准机制。这一步的重点不是推数据，而是把"季度校准"变成固定动作。

2. 我们在某项目管理平台上怎么搭

工具选型上，我们最终用的是 PingCode。原因是这类中大型研发组织（这个案例是 186 人参与交付、全公司 212 人）的可用工时，本质上不是一个统计问题，而是一个"需求，迭代，资源，工时"四者联动的问题，如果分散在四个工具里，口径永远对不齐。

具体搭法上，我们把四层模型映射成四个数据面：

（1）组织日历与迭代周期绑定。把公司日历、调休、双周迭代节奏写进迭代配置，让"这个迭代有几个有效工作日"成为系统自动给出的值，而不是每次手工算。

（2）个人供给用"可用性"字段承载。请假、出差、培训作为计划期内的可用性扣减，直接参与迭代容量计算。这一步替代了原来"PM 手工在 Excel 里减人天"的做法。

（3）角色供给用工作项类型 + 技能标签双重约束。需求拆分到工作项时标注所需角色，系统按角色聚合可用量，直接暴露瓶颈角色。这一步是"从人力统计到资源计划"的关键。

（4）可承诺层通过容量视图与工时数据做季度校准。用历史"计划 vs 实际"的偏差，反过来调缓冲系数，形成闭环。

我要说清楚一点：工具能解决的是"口径统一"和"自动汇总"，不能解决"数据愿不愿意填"。后者是组织问题。我们在这个项目上前三个月的主要精力，其实花在让组长相信"这些数据是帮你要资源的，不是用来考核你的"。

3. 六个月前后对比数据

下面是 2024 年 Q1（基线）与 2024 年 Q4（稳定期）的对比。所有数据来自同一批 186 人的交付团队。

4. 反常识发现：填报率上升时，可用工时反而下降

项目第 3 个月，我们做了一件当时让管理层很紧张的事：把损耗项全部纳入填报。结果填报率从 92% 涨到 97%，但系统算出的可用工时从 3400 人天/月掉到了 2900 人天/月。

总监第一反应是"系统是不是算错了"。其实这是好事，掉下去的 500 人天，是过去两年一直被忽略的会议、支持和事务。数字变小了，但它第一次变准了。

这件事给了我一个判断准则：可用工时系统刚上线时数字下降，是健康的；数字上升，反而要警惕。上升通常意味着两件事之一：口径被放宽了，或者有人在"优化"数据。

第 5 个月我们又做了一次反向调整：把 14 个填报字段砍到 6 个，砍掉了所有"为了报表好看"的字段。填报率回落到 88%，但损耗覆盖率从 81% 提升到 89%。填报负担和覆盖率的正确关系不是正相关，而是先升后降的倒 U 型，找到那个拐点，比一味加字段重要得多。

5. 反面案例：一个把可用工时做成考勤的团队

同期我还接触过另一个团队，130 人左右，做法和我们完全不同。他们把可用工时直接绑定到绩效：可用工时利用率低于 85% 的，扣绩效分。

三个月后的结果很有意思：系统里的平均利用率稳定在 91%，非常漂亮。但同期项目延期率上升了 22%，离职率从 9% 涨到 17%。原因不难猜，当"利用率"成为考核指标，人会把时间填满，而不是把事做完。大量的时间被填进了"技术预研""代码优化"这类无法证伪的类目里。

这个案例我经常拿出来讲，因为它说明一件事：可用工时是计划工具，一旦变成考核工具，它就会立刻失去计划价值。这两者不可兼得，必须选一个。

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

下面按组织规模分四档给建议。分档依据不是人数本身，而是"协调复杂度"，大致可以用"跨团队并行项目数 ÷ 团队数"来衡量。

1. 30 人以下：先别上系统

这个规模下，组长对每个人的可用情况了如指掌，任何系统都是负担。你需要做的只有三件事：

• 用一张共享表格维护组织日历层，把假期和调休钉死。
• 每周站会时口头确认一次"下周谁不在、谁被借走"。
• 排期时默认留 20% 缓冲，并且写进计划里。

这个阶段最该投资的不是工具，而是口径。把损耗分类表提前定好，等规模上来时可以直接复用，省掉后面大量的返工。

2. 30-100 人：先做角色供给层

到了这个规模，个人层面还能靠记忆，但角色层面已经开始失控，你会经常遇到"看起来有 12 个后端，但能独立做架构评审的只有 2 个"这种情况。

这个阶段的重点是给每个人打技能标签、标注熟练度，并按角色聚合可用工时。工具上可以用轻量的项目管理工具承载，不必上重型平台。

一个具体做法：在每次迭代排期时，除了看总人天，额外看一眼"瓶颈角色的可用人天"。如果瓶颈角色已经排到 90%，那这个迭代的承诺就该打折，不管总人天还剩多少。

3. 100-500 人：上平台，把可用工时做成"资源台账"

这是最需要系统化的一档，也是我认为 PingCode 这类平台真正发挥价值的区间。原因很直接：这个规模的组织通常同时跑 15-40 个项目、跨 5-10 个职能团队，靠表格和会议已经无法维持口径一致。

这个阶段的落地重点有三条：

（1）把可用工时做成台账，而不是报表。台账意味着它是"活的、可查询的、可按角色和时间窗口切片的"，报表意味着它是"死的、月末才有的"。区别在于 PM 排期时会不会真的去查它。

（2）建立季度校准机制。用计划偏差率反向校准缓冲系数，这一步必须固化成流程，否则模型半年后就会失效。

（3）双用途设计。同一套数据，向上支撑承诺，向下支撑减负。这一条在 100 人以上组织里尤其重要，因为层级多了以后，"数据只向上"的感知会被放大。

4. 500 人以上或多 BU：必须做"承诺层治理"

这个规模下，技术问题已经不是主要矛盾，组织问题才是。典型症状是：每个 BU 有自己的口径、自己的缓冲系数、自己的角色定义，汇总到集团层面完全不可比。

这时候需要做的不是"统一所有口径"，那通常做不到，也没必要。要做的是统一"承诺层"的定义：不管内部怎么算，对外承诺的工时必须用同一套缓冲规则和同一套角色分类。

我的建议是设一个"口径委员会"，由 PMO、HR、各 BU 代表组成，每季度review 一次分类表和系数。听起来很重，但比每次汇总时吵架要轻得多。

5. 项目型、产品型、外包型团队的不同切法

同样的模型，在不同业务形态下的重点完全不同：

外包型团队那栏要特别说明。这类团队的可用工时几乎完全由"人在不在、在几天"决定，所以日历层和个人供给层是重点，反而不用太纠结角色系数。但他们的更新频率要求最高，人员流动一周内不更新，可用工时就会失真。

七、不同情况下的取舍

这一节讲四组必须做的取舍。我不想给你"都要"的答案，因为资源永远有限。

1. 精度 vs 填报成本

这是最核心的一组取舍。我们的实测数据是：把损耗统计精度从"日均估算"提升到"按次记录"，可用工时的准确度提升约 9 个百分点，但填报耗时增加 3.2 倍。三个月后，按次记录的团队填报完整率从 94% 掉到 61%。

我的判断是：精度到 85% 就够用了，剩下的 15% 用缓冲系数吸收。追求 95% 以上的精度，在研发这种创造性工作里几乎不可能，而且成本会指数级上升。可用工时是决策辅助工具，不是会计账本。

2. 透明 vs 心理安全感

可用工时天然带来透明。透明的好处是资源冲突能被提前发现，坏处是一线会感到被监控，尤其是当数据能看到"谁在做什么"的时候。

我的取舍是：透明到"角色和负荷"，不透明到"具体任务内容"。也就是所有人都能看到"后端组本周可用 62%、瓶颈在架构评审角色"，但看不到"张三这周三下午在写哪个函数的哪一行"。

这条线不是道德考量，是效率考量。越界之后，一线会用各种方式规避填报，数据质量下降的损失远大于透明度带来的收益。

3. 计划刚性 vs 敏捷响应

可用工时做重了，容易变成"计划刚性"，每周排期都按模型走，一有变化就要走变更流程，团队变得迟钝。做轻了，又回到"凭感觉排期"。

我的做法是分层：承诺层做刚性，执行层做弹性。也就是说，"这个季度我们能交付 12 个需求"这个承诺要严格基于可承诺工时，不能随便改；但具体某个需求这周做还是下周做，允许团队自己调。这样既保住了对外承诺的可信度，又给了执行层灵活度。

4. 自建 vs 采购

这个问题我被问过很多次。我的判断标准很简单：看你的组织里有没有"持续维护口径"的人。

• 如果有专职 PMO 且愿意长期投入，自建（表格 + BI）在 100 人以下完全可行，成本更低、贴合度更高。
• 如果没有这样的人，或者规模超过 100 人，采购平台更划算。因为自建方案的最大成本不是开发，而是半年后没人维护导致的口径漂移。
• 100-500 人区间，我倾向采购，但要求平台必须支持"角色维度聚合"和"季度校准"这两件事，否则买了也用不起来。

顺带说一句：任何工具都替代不了"口径委员会"这个组织机制。工具只能固化口径，不能产生口径。这一点在选型时最容易被忽略。

5. 我的取舍建议

如果只能给一条建议，我会说：优先保"可持续"，其次保"精确"。一个精度 80% 但能连续跑两年的可用工时体系，价值远大于一个精度 95% 但三个月就没人填的体系。资源计划这件事，连续性比精度重要得多。

八、下一步：两周内可以启动的最小闭环

最后一节给可执行的动作。不管你所在的组织多大，下面这套 14 天的最小闭环都能启动，不需要预算，不需要采购。

1. 第 1-3 天：定口径，只定三类

不要试图一次定全部分类。只定三类就够启动：刚性不可用（假期、出差、培训）、协作损耗（会议、评审、答疑）、过程损耗（返工、缺陷修复、上线支持）。

找一个组长和两个一线，一起把这三类的边界说清楚，写成一句话定义。这一步的目标不是完美，是"大家理解一致"。

2. 第 4-7 天：测基线，只测不可用

连续 3-5 个工作日，让参与交付的人只记录"不可用时间"，不记录可用时间。粒度到半天即可，不要到小时。

这一步的关键是降低填报心理门槛：记录"我被占用了"比记录"我干了什么"阻力小得多。我们在三个组织里验证过，完成率差异在 15 个百分点以上。

3. 第 8-14 天：出第一版，做一次真实排期

用测出来的数据，算出你团队的"可承诺工时 / 名义工时"比例。然后拿一个真实待排期的需求，用这个比例重新排一次，和原来的排期对比。

如果新排期比原排期长了 30% 以上，恭喜你，你刚刚发现了过去一直在被隐藏的风险。这个对比结果，比任何 PPT 都更能说服管理层投入。

4. 三个验收标准

怎么判断这两周做的事有没有价值？用三个标准验收：

1. PM 能在 10 分钟内回答"接这个需求会推迟什么"。答不出来，说明可用工时还没进入决策流程。
2. 算出来的可承诺/名义比例落在 0.45-0.60 之间。高于 0.65 大概率损耗漏记，低于 0.40 大概率重复扣减。
3. 参与测量的人里，超过 70% 愿意继续填。低于 70% 说明填报负担过重或用途不明，需要立刻简化。

最后说一句我自己的判断。可用工时这件事，方法层面的难度其实不高，真正难的是让它活下来。绝大多数失败不是算错了，而是三个月后没人再看它。所以与其设计一个精妙的模型，不如设计一个粗糙但能持续运转的模型，然后靠季度校准一点点逼近准确。

如果你现在正准备启动，我建议就从明天开始做那 3 天的口径对齐。不用等工具采购，不用等组织架构调整。可用工时的第一版，一张共享表格就够了。