可用工时怎么做？项目负责人入门指南：人力资源计划从0到1

去年底我陪一家做工业软件的公司复盘一个延期了四个半月的项目。项目负责人在会上说了一句让整个会议室安静了几秒的话：“我按 21.75 天乘 8 小时排的人力，理论上产能是够的，问题出在执行。”

这句话里藏着一个非常典型的错误：21.75 天是月计薪天数，是算工资用的，不是算活干不干得完用的。它把该放的假算成了该干的活。一个 20 人的团队按这个口径排一个月，就凭空多出 30 多个人天，相当于多算了 1.5 个人的产出。项目不是死在执行上，是死在这张表的第一行。

这篇文章讲的就是这张表怎么做：可用工时到底怎么算、从 0 到 1 需要哪几步、哪些参数是拍脑袋的、哪些必须有数据、以及在什么规模下该用表格、什么规模下必须上系统。我会给出一条可复用的公式、五个我反复见到的误区、一套六步落地法，以及一个 180 人研发组织的实际改造过程。

一、先给结论：可用工时不是除出来的，是扣出来的

大多数人的直觉算法是“人数 × 天数 × 8 小时”。这个算法唯一的优点是快，缺点是它给出的数字几乎总是偏大，而且偏得没有规律，小团队偏 20%，大团队偏 40%，跨部门协作多的项目能偏一倍。

我的核心结论只有一句：可用工时是一条逐层扣减的链，不是一次乘法。你从日历上的名义工时出发，一路减掉假期、减掉组织损耗、减掉技能不匹配、减掉并行切换、减掉必要的缓冲，最后剩下的那个数字，才是你能对业务方承诺的东西。

1. 三个必须先定死的口径

在算任何数字之前，有三件事必须先说清楚，否则后面所有的计算都会在争论中失效。这三件事不是技术问题，是共识问题。

第一，单位是小时还是人天。人天的问题在于颗粒度太粗：半天的事记 0.5 人天容易被当成“没干活”，于是一天的事被记成 1 人天，整个统计就此失真。我建议内部统一用小时做原子单位，对外汇报再折算成人天，折算率写死（比如 1 人天 = 8 小时，不随加班浮动）。

第二，口径是名义还是有效。名义工时是“这个人在这个时间段归这个项目”，有效工时是“这个人真正在这个项目上产生了产出”。两者能差 30% 到 45%。做资源占用分析用名义口径，做交付预测必须用有效口径，混用是项目计划失控的第一大来源。

第三，统计周期是周、迭代还是月。周适合排班和异常发现，迭代适合研发团队的承诺，月适合人力成本和预算。三个周期要同时存在，但只能用一套底层数据，否则会出现“周报说富余、月报说超支”的经典矛盾。

2. 一条公式，四个减法

把上面三个口径固定下来之后，可用工时的计算可以写成一条链式公式。这条公式我在不同规模的组织里用过十几次，结构没变过，只是每一段的系数不同。

可承诺产能 = 日历名义工时
− 休假与法定节假日损失

− 组织性损耗（会议、答疑、行政、培训、面试）

− 技能与角色错配损失

− 并行切换损失

× 个人有效专注系数

+ 缓冲池（不分配给具体任务）

其中：

日历名义工时 = 统计周期内工作日 × 人均在岗小时

组织性损耗率 = 该类角色近 4 周（会议+答疑+行政+培训）小时 / 总在岗小时

技能错配损失 = 无法被本角色承接的任务工时（只能等待或被降级处理）

并行切换损失 = f(并行项目数)，经验值见第三章

个人有效专注系数 ≈ 0.72 ~ 0.85（按角色区分，测试与支持岗偏低）

注意最后一项是“加缓冲”而不是“减缓冲”。这是个反直觉的设计：缓冲不是从产能里切一块出来浪费掉，而是明确标注为“不承诺”的部分。把它写进公式，是为了让业务方看到：这块产能存在，但它不参与承诺。

3. 为什么先算“不可用”比算“可用”更靠谱

我教项目负责人做人力计划时，第一步从来不是填“这个人能给我多少小时”，而是填“这个人有多少小时一定给不了我”。顺序反过来，效果差别很大。

原因在于人的乐观偏差是不对称的。你问一个工程师“下周能投入多少时间做这个需求”，他脑子里想的是理想状态，答案通常接近 40 小时；你问他“下周有哪些事会占掉你的时间”，他会认真回忆：两个评审会、一次客户答疑、一次新人带教、周五的部门会，加起来 14 小时。后者更准，因为它调用的是记忆而不是预期。

下面这张瀑布图，是我在一个客户团队里实测出来的扣减路径。起点是 174 小时（按 2025 年起全体公民放假 13 天折算的月工作日约 20.67 天 × 8.4 小时在岗时长），终点是 103 小时的有效产出，衰减率 41%。

二、背景与真实场景：为什么第一次做人力计划几乎必然翻车

项目负责人这个角色有个尴尬之处：他被要求对交付负责，但通常不被授予人事权力；他能看到任务，却看不到人的日历。于是人力计划往往退化成一张“我知道大概要多少人”的估算表，然后在项目中期被现实击穿。

1. 从“排个人”到“排产能”，这是两种完全不同的技能

排人是任务分配：张三做 A，李四做 B。排产能是供需匹配：这个迭代我需要 320 小时的后端工时，我只有 240 小时，缺口 80 小时，要么缩范围，要么借人，要么延期。

前者是行政动作，后者是决策动作。绝大多数项目负责人第一次做的是前者，被要求交付的却是后者的结果。这个错位，是“计划永远不准”的结构性原因。

我见过一个很典型的对比：同一个团队，同一批需求，用排人方式做出来的计划在第三个迭代就崩了；换成排产能方式重做，计划本身没变准多少，但崩的时候大家知道崩在哪一格，调整速度快了三倍。计划的价值不在于准，而在于可修正。

2. 三个我反复见到的场景

场景一：新项目启动会上的“我们有 6 个人”。这 6 个人里有 1 个刚入职两个月，1 个每周有两天在支撑线上问题，1 个是兼职的产品接口人，真正能全职投入核心开发的不到 3.5 人。按 6 人排的计划，一开始就超配了 70%。

场景二：季度末的人力统计。财务要人力成本分摊，HR 要出勤数据，项目要工时归属，三份数据来自三个系统、三种口径，三个人对了三天还对不上。这件事每年发生四次，每次消耗大约 24 人时，而且没有人认为它是问题。

场景三：跨团队联调。两个团队各自排期都很满，联调窗口只有三天。计划里没算联调的等待时间，因为“等待”不占用任何人的工时，但它在日历上实实在在占了两周。这类“零工时但占日历”的环节，是甘特图最大的盲区。

3. 一个只发生在季末的连锁反应

上面三个场景单独看都不致命，但它们会在同一个时间点叠加：季度末。财务结算、绩效评估、客户验收、下季度规划全部挤在两周内，会议量翻倍，有效工时腰斩。

如果人力计划是按“平均月”做的，这两个星期的产出缺口会全部转化成延期。而且它每年重复，团队却每年都措手不及。我在做年度人力模型时，会在 Q 末和年末各留出一段显式的低产能区间，把系数从 1.0 降到 0.75。这不是保守，这是把已知的规律写进计划。

三、拆解五个常见误区

下面这五个误区，我按“出现频率 × 造成损失”排了序。前两个几乎是行业通病，后三个出现在团队从 30 人长到 100 人的过程中，不是人的能力问题，是复杂度跃迁。

1. 误区一：拿计薪天数当可用工作日

就是开头那个故事。21.75 这个数字来自月计薪天数的折算规则：（365 − 104 个休息日）÷ 12 = 21.75，它用于日工资折算，包含法定节假日，因为法定节假日是带薪的。

但可用工作日是另一个口径：（365 − 104 休息日 − 法定节假日）÷ 12。按 11 天法定节假日算是 20.83 天，2025 年起全体公民放假的节日增加到 13 天（新增农历除夕和 5 月 2 日），对应月工作日约 20.67 天。

也就是说，用 21.75 排期，一个月就多算了 1 天以上。乘以 8 小时是 8.7 小时，乘以 20 人是 174 小时，这还没算年假。这个错误之所以顽固，是因为 21.75 在 HR 的薪资表里反复出现，看起来“很官方”。

2. 误区二：把“在岗”当“可用”

出勤不等于产出，这句话人人会说，但很少有人真的去量化它。我在做基线时会让团队连续四周记录时间去向，结果几乎每次都让管理者意外：真正用于“本岗位核心任务”的时间，中位数在 52% 到 68% 之间。

对研发团队来说，最大的吞噬者是会议和即时沟通。微软连续几年的工作趋势报告都指向同一个现象：会议与消息把工作日切成了碎片，能连续专注的时间段越来越短。碎片化的伤害不是时间本身，而是重新进入深度状态的成本，一段 40 分钟的会议插在上午，前后各损失 15 分钟的状态切换，实际代价是 70 分钟。

对项目经理、技术负责人这类角色，情况更极端。他们的会议占用经常超过 45%，但排期时仍然被当成全职生产力使用。这是中大型组织里最常见的隐性超配。

3. 误区三：把人头当产能

“这个模块需要 2 个后端，一个月。”这句话的信息量几乎为零，因为两个初级和一个资深加一个初级，产出可能差一倍以上。人头的可加性是个幻觉。

更麻烦的是技能不可替代性。前端不能填后端的缺口，测试不能填架构的缺口，懂某个老系统的三个工程师之一请假，整个模块就停摆。可用工时的正确单位应该是“角色 × 技能层级 × 时间段”的三维产能，而不是一个总数。

我通常要求至少分出三层：能独立交付的、能做但需要评审的、只能做明确子任务的。这三层的产能权重我一般按 1.0 / 0.7 / 0.45 折算。这个比例不是精确值，但比“都按 1 算”精确得多。

4. 误区四：把 100% 承诺当专业

新晋项目负责人最容易犯的错，是把“我能排满”当成能力的证明。把每个人的日历排到 100%，看起来资源利用率极高，实际上是在给项目埋雷：任何一次需求变更、任何一个人请假、任何一个技术难点超期，都会因为没有余量而直接转化成整体延期。

管理学里管这个叫利用率悖论：当系统负载接近 100% 时，排队时间趋于无穷大。制造业早就懂了，软件开发团队却还在用“人均利用率”当考核指标。

我在下面这张散点图里放了一组团队级观察数据：横轴是平均利用率，纵轴是迭代准时交付率。曲线不是单调上升的，峰值出现在 78% 到 85% 之间，超过 90% 之后准时率断崖式下降。

5. 误区五：一次算完，全年不改

年度人力计划做完就锁进抽屉，这在很多组织里是常态。但团队的构成每个季度都在变：有人离职、有人晋升、有新人爬坡、有项目结束后人员释放。一个 Q1 做出来的模型，到 Q3 的误差能超过 30%。

正确的做法是滚动校准，周期和迭代对齐。每个迭代结束时，用实际消耗工时反算真实系数，替换模型里的假设值。模型的精度不来自第一次算得多细，来自修正得多频繁。

下面这张百分比堆叠图，是四个角色在同一个季度里的时间去向实测。它解释了为什么“统一按 70% 有效率”是不够的，不同角色的损耗结构完全不同，用同一个系数就是在平均掉真实差异。

四、专业判断逻辑：从 0 到 1 的六步法

这一章是操作部分。我把它拆成六步，每一步都有一个明确的产出物，做完一步就能用，不必等全部做完。对于完全没有基础的项目负责人，建议按顺序走，不要跳步，跳步的直接后果是模型里混着不同口径的数据，越算越乱。

1. 第一步：定口径，写成一页纸

产出物是一页《人力计划口径说明》，不超过 400 字，但必须写清楚五件事：工时单位、统计周期、有效工时率取值、缓冲比例、以及“谁能改这些参数”。

最后一条最容易被忽略，但它是这份文件能否活下来的关键。如果任何人都可以随手改系数让自己的项目看起来更宽裕，这套模型三个月内就会失去公信力。

我的建议是：口径由项目管理办公室或研发效能团队统一维护，项目负责人可以申请调整自己项目的系数，但必须附上数据依据，并且变更留痕。这听起来很官僚，但它保护的是模型本身的权威性。

2. 第二步：算日历基数，从节假日和休假开始

这一步不需要任何工具，一张当年的日历加一份休假记录就够。具体做法是：先标出统计周期内的所有工作日，扣除法定节假日，再扣除已知的团队休假（年假、调休、婚丧产假、培训外出）。

关键是用“已知”而不是“预计”。已提交的休假申请是确定的，可以扣；还没提的年假不要瞎猜，把它放进后面的缓冲池里。把不确定的东西塞进确定项，是计划失真的起点。

对于跨季度或跨年的计划，还要额外处理两个变量：一是次年的法定节假日安排通常在上一年的下半年公布，跨年计划要留调整位；二是招聘计划中的人员到岗时间，新人到岗前不产生任何产能，到岗后也需要爬坡期。

3. 第三步：扣组织损耗，用实测数据而不是行业均值

这一步是全流程里最花时间、也最有价值的一步。不要用“行业平均有效率 70%”这种数字，一定要测自己的。因为损耗结构是组织特有的：会议文化重的公司会议损耗能到 25%，支持型团队答疑损耗能到 30%。

实测方法很简单，四周为一轮，让团队按五个大类记录时间：核心任务、会议协作、答疑支持、返工、行政培训。粒度到半天即可，不需要精确到分钟。四周之后汇总，每个角色得到一个五段分布。

这个过程会让团队不舒服，因为它看起来像监控。我的处理办法是：只统计到角色，不统计到个人；结果对团队公开，对管理者只公开聚合值。数据一旦被用来考核个人，记录立刻失真，这一点没有例外。

4. 第四步：按角色和技能折算，把总数拆成可用块

前三步算出来的是“这个团队有多少可用工时”，这一步要把它拆成“这些工时能干什么”。做法是画一张角色-技能矩阵，横轴是技能域，纵轴是人员，交叉格填能力等级。

等级我建议只用三档：独立交付、需评审、仅能做子任务，对应产能权重 1.0 / 0.7 / 0.45。三档足够做决策，五档以上会让维护成本超过收益。

这一步的另一个产出是识别单点：某个技能域只有一个人达到“独立交付”，这个人就是关键路径上的单点故障。可用工时模型必须为这种人单独设置风险系数，他请假一天，相关模块的产能不是降 1/团队人数，而是降到 0。

5. 第五步：加缓冲，形成承诺曲线

缓冲不是留一堆空闲时间，而是把产能分成三层：承诺层（对业务方锁定的交付量）、弹性层（可承接变更和紧急需求）、储备层（培训、技术债、创新）。三层比例我一般用 70 / 20 / 10，团队成熟度低的可以把承诺层降到 60。

缓冲的另一个用途是吸收新人爬坡。一个新入职的工程师，第一个月产能大约是全额的 30%，第二个月 55%，第三个月 75%，第四到六个月逐步到 90% 以上，完全达到稳定产出通常要到第六个月。如果按全额排期，前三个月就凭空多算了 1.5 个人月。

6. 第六步：滚动校准，用偏差反向修正系数

前面五步做完，你得到的是一个模型，不是一个答案。模型的价值要靠校准来释放：每个统计周期结束，用“实际消耗工时”对比“计划工时”，算出偏差，然后把偏差归因到具体的系数上。

归因要注意区分两类偏差：一类是系统性偏差（比如会议损耗一直低估 5 个百分点），这类要直接改系数；另一类是随机偏差（某个人临时请假、某个需求临时插入），这类不要改系数，而是检查缓冲池是否够用。

我通常看一个指标来判断模型是否健康：滚动四周的平均绝对偏差率。20% 以内算可用，10% 以内算优秀。如果连续三个月都在 30% 以上，问题不在系数，在于估算本身，那就是另一个话题了。

五、案例与数据观察：一个 180 人研发组织的落地过程

下面这个案例来自我在 2024 年到 2025 年间参与的一个改造项目。客户是一家做企业级软件的研发组织，约 180 人，分四条产品线，长期多项目并行，同时存在自研项目和客户定制项目。

改造前的状态是：人力计划用 Excel 维护，各产品线自己一套模板，工时靠月底补填，季度末由 PMO 手工汇总。数据我做了取整处理，属于单一组织的观察，不代表行业统计，但结构和量级有参考价值。

1. 为什么先手工做三个月，而不是直接上系统

这是整个项目里最关键的一个决策。客户一开始的想法是直接采购工具、建好字段、全员培训。我坚持先手工跑三个月，理由是：你不知道该采集什么字段的时候，上系统只是把混乱电子化。

手工阶段的三个月做三件事：第一，用四周实测建立角色时间去向的基线；第二，用一个完整季度验证系数是否稳定；第三，确定最小字段集，最终我们只保留了五个必填项：人员、项目、任务类型、工时、日期。

最小字段集这件事值得展开说。很多组织一上工时系统就恨不得填二十个字段，结果是填报率断崖下跌、数据质量崩坏。我们的判断标准很朴素：任何一个字段，如果不用它做决策，就不要采集。五个字段能支撑资源占用、项目成本、迭代产能三类分析，足够了。

2. 搬到 PingCode 之后发生了什么

三个月手工基线跑通后，数据迁移到 PingCode，把工时登记和迭代管理放在同一套数据里。选它的主要原因是这个组织本来就在用它的需求与迭代管理，工时如果单独放在另一个系统，数据永远对不上，这不是工具优劣问题，是数据割裂问题。

对 100 人以上的组织来说，真正的痛点往往不是“有没有工时功能”，而是“工时数据和任务数据是不是同一份”。工时挂在任务下、任务挂在迭代下、迭代挂在项目下，这条链路一旦打通，资源冲突可以提前发现，而不是等到人已经被两个项目同时占用之后才吵架。

改造前后的关键指标变化如下。需要说明的是，这些数字只反映这一个组织的情况，其中计划偏差率和工时填报率的改善比较典型，耗时类指标的改善幅度则更依赖流程配套。

耗时类指标的变化更直观，但它需要单独看，因为单位不同，混在同一张图里会失真。

3. 三个不能照搬的地方

第一，系数不能跨组织复制。我们测出后端有效工时率 62%，这在他们公司成立，在会议文化更重的公司可能只有 50%。系数是测出来的，不是抄来的。

第二，填报粒度和团队成熟度相关。这个组织能接受按天填报，是因为他们的任务拆分已经到 1 到 2 天粒度。任务粒度粗的团队强行要求精细填报，只会得到编造的数据。

第三，缓冲比例要随业务波动调整。他们的定制项目占比高，变更频繁，所以承诺层只用了 65%，比标准值还低 5 个百分点。如果换成一个需求稳定的产品团队，这个比例可以提到 75% 甚至 80%。

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

同样的方法，在不同规模、不同业务形态下的落地方式完全不同。下面按五种典型情况给出建议，你可以直接对号入座。

1. 10 人以内的小团队：不要做模型，做清单

这个规模做完整的人力模型是浪费。人少意味着你完全知道每个人在干什么，缺的是纪律而不是算法。

建议只做三件事：

• 一张团队日历，标出所有人的休假、出差、培训，公开可查。
• 一个每迭代 30 分钟的产能对话：下个迭代每人有多少小时可投入，写成一个总数。
• 一条硬规则：承诺的任务总量不超过可用工时的 75%，剩下 25% 谁都不许动。

这三件事加起来不到两小时，能解决小团队 80% 的排期问题。别急着买工具。

2. 30 到 100 人：建立角色级模型，用表格就够

这个规模开始出现“我不认识隔壁组的人在做什么”的问题，需要角色级而不是个人级的产能模型。

建议按第四章的六步法走一遍，但简化为三个角色组：研发、测试与质量、产品与管理。每个组测一次有效工时率，季度校准一次。工具用电子表格完全够用，关键是把口径说明写下来并冻结。

这个阶段最容易犯的错是过早引入复杂的资源管理工具。我见过一个 60 人的团队上了完整的资源池管理，结果维护资源池本身占用了项目经理每周 6 小时，而他们一周总共只有 40 小时。工具的维护成本必须显著低于它带来的决策收益，否则就是负资产。

3. 100 人以上：工时必须和任务在同一套数据里

超过 100 人之后，靠人工汇总的模型会迅速失效，不是因为算不动，而是因为数据链路太长、口径太多、更新太慢。这时的核心诉求变成三个：数据同源、实时可见、变更留痕。

这也是我认为中大型组织应该把工时管理放在项目管理平台里的原因。以 PingCode 这类服务中大型企业的平台为例，工时登记挂在任务上、任务归属迭代、迭代归属项目，这个层级关系天然解决了“工时算给谁”的问题；资源负载视图可以直接从工时数据生成，不需要另外维护一张表。

但要提醒一句：工具解决的是数据链路问题，不解决口径问题。口径没定清楚就上系统，只会让错误的口径以更快的速度传播。先有第四章那页纸，再有系统配置。

4. 多项目并行：先算切换成本，再谈资源池

并行是产能的头号杀手，但它的损失不在工时表上，所以几乎没人算。一个人同时参与两个项目，每天的上下文切换会吃掉 15% 到 25% 的有效时间；三个项目能到 35% 以上。

行动建议很直接：给每个人设一个并行上限（我一般建议 2，最多 3），超出上限的资源分配必须由更高一层批准。同时，把“等待时间”显式写进计划，等待不占工时，但占日历，而项目是按日历交付的。

5. 外包与驻场：可用工时的算法要换一套

外包团队的可用工时不能套用内部模型，因为约束条件完全不同：合同约定的工时口径、验收标准、沟通成本、知识转移成本都不一样。

建议单独建一套参数：合同工时按合同口径算（通常是名义工时），但有效产出要额外扣掉 20% 到 30% 的沟通与协调损耗，跨组织协作的信息损失是真实存在的。同时，知识转移期要单独计入，一个新外包团队接手既有系统，前两个月通常只有 40% 到 60% 的有效产出。

6. 规模与方法的对应关系

把上面的建议压缩成一张表，方便快速定位。这张表里的“维护成本”指的是维持这套人力计划所需的人力投入，不是软件费用。

七、不同情况下的取舍

这一章讲的是没有标准答案的部分。前面给的是方法，这里给的是在约束条件下怎么选。四组取舍，每一组我都给出判断依据。

1. 精度与维护成本：精度不是越高越好

把工时统计粒度从“天”提到“小时”，数据精度会提升，但填报成本会上升两到三倍，而决策质量的提升远小于这个倍数。我的经验临界点是：当统计粒度细于任务本身的粒度时，精度提升就不再带来决策价值。

如果你的任务拆分是 3 天一个，那按天填报完全够用；只有当任务普遍小于 1 天时，才需要小时级填报。反过来，如果你的任务是 2 周一个，连按天填报都是浪费。

判断依据：问自己一个问题，这个精度会不会改变我的某个决策？如果不会，就不要采集。

2. 缓冲与承诺：缓冲是给不确定性定价，不是给懒惰留空间

业务方通常不喜欢听到“我们只承诺 70%”。这时候需要的不是妥协，而是把缓冲的价值讲清楚：缓冲买的是变更响应能力，没有缓冲的团队在第一次变更时就会全面延期。

具体做法是把缓冲显式化：告诉业务方“70% 是锁定交付，20% 是变更吸收，10% 是技术投入”。把三者分开报，比笼统报一个数字更容易被接受，因为它让业务方看到自己的变更需求有地方放。

判断依据：如果过去六个迭代里，变更是常态而不是例外，缓冲就不能低于 25%。

3. 标准化与团队自治：口径统一，方法可以不同

过度标准化会遭到团队抵制，过度自治会导致数据无法汇总。我的分界线是：字段和口径必须统一，计算方法和呈现方式可以自治。

具体说，工时单位、统计周期、角色分类这三项必须全组织一致，否则数据无法比较；而团队内部怎么估点、怎么排优先级、用什么看板，可以各自决定。这条线划清楚之后，推进阻力会小很多。

判断依据：如果两个团队的数据放在一起无法直接对比，说明统一得不够；如果团队抱怨“什么都要按总部模板来”，说明统一过头了。

4. 工具与表格：看数据链路长度，不看团队规模

经常有人问我“多少人以上该上系统”。这个问题问错了，正确的问法是：工时数据从产生到被用于决策，中间要经过几个人、几张表？

如果链路是“个人填报 → 项目经理直接看到”，表格就够；如果链路是“个人填报 → 项目经理汇总 → PMO 汇总 → 财务核对 → 管理层决策”，中间经过三次手工转换，那不管团队多大都该上系统，因为每次转换都是一次失真机会。

对 100 人以上、多项目并行的组织，这个链路通常已经长到必须系统化。像 PingCode 这类平台的价值就在于把工时、任务、迭代、项目放在同一条数据链上，让“汇总”这一步不再需要人工。但反过来说，十个人的团队上这类平台，维护配置的成本会超过收益。

判断依据：算一下每月花在“数据搬运和对账”上的人时，如果超过 4 人天，就该考虑系统化。

5. 最后一点：偏差归因比偏差数值更重要

下面这张帕累托图是我们在这个 180 人组织里统计的六个月计划偏差成因。它揭示了一件重要的事：工时模型本身能解决的问题，只占偏差的三成左右。

八、总结：把可用工时当成一份契约，而不是一张估算表

回到开头那个故事。那位项目负责人后来把模型重做了一遍：从月工作日 20.67 天出发，扣掉休假、扣掉实测的会议与答疑损耗、按角色折算、留出 20% 缓冲，最后得到的可用产能只有原来那张表的六成。他拿着新表去找业务方，说的第一句话是：“我们能承诺的是这个数，超出部分需要你们决定砍范围还是加时间。”

结果是项目范围缩了三分之一，交付准时了。这不是模型算得准，而是它把“做不到”这件事提前变成了一个可以被讨论的决策，而不是在交付前两周变成一个事故。

我对可用工时的核心观点可以压缩成三句：

• 它是一条减法链，不是一次乘法。先算不可用，剩下的才是可用。
• 它的价值在可修正，不在准确。能滚动校准的粗模型，胜过一次算到小数点后两位的精致表格。
• 它是一份对外的契约，不是一份对内的估算。承诺水位定在 70% 到 80%，是这个契约能否长期成立的关键。

如果你的团队现在就要动手，下一步做这三件事

1. 本周内：把下一篇要发的口径说明写出来，只写五件事，工时单位、统计周期、有效工时率、缓冲比例、谁有权改参数。不超过 400 字，发给所有相关方确认。
2. 接下来四周：启动一次时间去向实测，按五个大类记录，只统计到角色不统计到个人。四周后汇总，得到你们自己的有效工时率，替换掉所有抄来的行业均值。
3. 下一个迭代：用新系数重排一次计划，把承诺水位降到 70% 到 80%，然后观察两件事，偏差率有没有下降，业务方的反应是什么。偏差率是模型健康度，业务方反应是推行可行性，两者都要看。

不要试图一次做对所有环节。我见过太多团队花两个月建了一个完美的模型，然后在第一次组织调整后彻底废弃。先跑通最小闭环，再逐步加精度，这条原则在人力计划上和在产品开发上一样成立。

最后提醒一句：可用工时做到最后，你会发现真正的瓶颈往往不是算得不够细，而是没有人愿意在项目开始前把“我们做不完”说出口。模型只是给这句话提供了一个可以被接受的表达方式。工具和公式都好办，那句话才是难的。