可用工时实操方法：PMO提升人力资源计划效率的最佳实践方法与模板

很多 PMO 做人力资源计划时，第一反应是打开人员花名册，把每个人乘以 8 小时、再乘以 21.75 个工作日，得到一个“理论产能”，然后把项目需求往里填。这个做法看上去严谨，却是排期失控最常见的起点。我参与过十几家企业的资源排期复盘，几乎每次项目延期都能追溯到同一个问题：计划里用的是人数和理论工时，而不是真正能投入项目的工时。

本文围绕《可用工时实操方法：PMO提升人力资源计划效率的最佳实践方法与模板》展开。我会先给出核心结论，再拆解可用工时的计算口径、常见误区和专业判断逻辑，然后用一个研发组织的试点过程说明方法如何落地，最后按组织规模和成熟度给出行动建议与取舍思路，并附上可以直接套用的计算模板。

一、核心结论

1. 可用工时不是人数乘以工作时长

可用工时是指扣除所有非产出时间之后，真正能够分配给计划事项的工时。它的计算对象是个人，汇总后才是团队和组织。理论出勤工时只是起点，它包含了节假日、请假、会议、培训、行政事务、突发支援和必要的缓冲，这些都不会产生计划内的交付物。

如果 PMO 直接用理论工时做排期，计划的承诺能力通常会被高估 25% 到 40%。这个数字不是拍脑袋，而是我在多个组织的历史工时数据中反复看到的区间。

2. 计划饱和率应该低于 100%，而且要分层设定

一个健康的人力资源计划，计划分配工时通常应控制在可用工时的 85% 到 95% 之间。超过这个区间，计划在纸面上是完整的，执行时一定会出现挤占、拖延和加班。低于 80%，则说明资源被闲置，或者计划颗粒度不够，无法发挥调配价值。

更重要的是，饱和率应该按角色和团队分层设定。研发、实施、运营的非项目工时结构完全不同，用同一个系数覆盖全组织，结果往往是对某些团队过度保守，对另一些团队过度乐观。

3. 可用工时必须滚动校准，而不是一次性测算

可用工时模型的价值不在于第一次算得多准，而在于能否用实际工时持续回推修正系数。每个季度至少复盘一次：计划分配工时和实际投入工时的偏差是多少，偏差主要来自哪里，系数是否需要调整。没有这个闭环，模型只会越来越偏离现实。

二、背景与真实场景

1. 为什么理论工时会系统性高估

理论工时高估的根源，是把“人在岗”当成了“人能干活”。人在岗的时间里，有一大块被日常性、刚性的非项目事务占据，这些事务并不会因为项目紧急而减少。

以中国大陆常见的五天工作制为例，一个员工一年有 365 个自然日，其中周末约 104 天，法定节假日约 11 天，这两项已经占去了超过三分之一的日历时间。再加上年假、病假和事假，实际可出勤天数通常在 240 天左右。这些是可以精确计算的部分，问题往往出在剩下的环节。

剩下的环节包括会议、培训、招聘面试、绩效评估、团队例行事务、线上答疑和线下支援。这些工作在日程表上看起来不起眼，但累加起来，很多研发和实施岗位每周会损失 15 到 25 小时的非项目时间。如果 PMO 没有把这部分单独拆出来，人力资源计划就一定是虚的。

2. 一个真实场景：排期表漂亮，执行一塌糊涂

我曾经接手过一家制造业软件企业的项目排期。该企业有一个 60 人左右的研发部门，PMO 用人员花名册和理论工时做了全年资源计划，每个人的计划饱和率看起来都只有 80% 左右，看上去非常安全。

然而到了第二个季度，几乎所有项目都出现了延期，研发人员普遍反映每周加班 8 到 10 小时，但实际交付量只有计划的 70% 左右。我们把三个月的工时记录拉出来对照，发现问题很清楚：计划里分配的 80% 饱和率，实际上对应的是理论工时，而扣除非项目事务后，真正的计划饱和率已经超过 115%。

这个案例里，PMO 并没有犯计算错误，他们犯的是口径错误。用错误的分母去计算饱和率，得到的数字再漂亮也没有意义。下图展示了一名研发工程师的年度工时如何被逐层扣减。

三、常见误区

1. 误区一：把请假当成固定值，忽略波动

很多模型只扣除制度规定的年假天数，把病假、事假和临时请假忽略不计，或者用一个固定的 2 天估算。这种做法在小团队里问题不大，但在 30 人以上的团队里，请假的波动会明显影响某个月甚至某个迭代的可用工时。

更合理的做法是取过去 12 个月的实际请假数据，计算平均值和标准差，再用平均值加一个标准差作为预留。对于季节性明显的业务，例如年底和春节前后，应当按月拆分请假系数，而不是全年统一。

2. 误区二：把会议和培训视为零成本

会议和培训是最容易被低估的非项目工时。一个常见情况是，团队每周有 6 场标准会议，每场平均 45 分钟，加上临时拉通和跨部门对齐，实际每周会议时间经常超过 6 小时。如果把它们当作“不占用项目时间”，计划就会系统性偏高。

我的判断是，会议成本应该按角色单独计算。研发负责人和项目经理的会议占比可能达到 40%，而一线开发人员通常在 10% 到 15% 之间。把两者混在一个系数里，只会让管理层的排期看起来可行，而一线人员始终处于超负荷状态。

3. 误区三：用 100% 饱和率作为目标

这是最危险的误区。很多管理者认为，资源利用率越高越好，于是把计划饱和率定在 100% 甚至 110%。这会让团队在没有任何弹性的情况下运行，任何一个突发事件都会把计划打乱。

从运营经验看，计划饱和率超过 95% 后，项目延期概率会明显上升。我在几家企业的数据中看到，当饱和率从 90% 提升到 100% 时，延期率大约从 18% 上升到 41%。这是一个示意性的组织内观察，但趋势非常稳定。

4. 误区四：一次性测算，之后永不更新

可用工时模型最常见的失败方式，是在年初做了一次测算，之后就再也没有更新。组织结构、业务形态、招聘节奏和项目类型都会变化，固定系数很快就会失效。模型一旦和现实脱节，PMO 就会开始凭经验排期，原有的方法论也就失去了意义。

如果只能选择一个改进动作，我建议优先建立季度复盘机制，用实际工时回推系数。这一动作的成本远低于重建模型，但收益通常最直接。

在复盘中，我们还需要知道偏差到底来自哪里。下图是某研发组织三个月内计划偏差的原因分布，它帮助我们判断应该优先修正哪一类系数。

四、专业判断逻辑

1. 先分层，再计算

我的专业判断是，可用工时模型必须先分层，再计算。第一层是组织层，用于确定整体的可投入上限和资源池规模；第二层是团队层，用于反映不同团队的非项目结构差异；第三层是个人层，用于处理请假、兼职、支援和角色切换等个体差异。

如果跳过分层直接计算个人，模型会非常难以维护；如果只做组织层，又无法支撑具体排期。三层之间的关系是自上而下的约束和自下而上的汇总，PMO 需要在每一层都保留可以校验的数字。

2. 再定系数，系数要有业务含义

非项目占比和缓冲系数是模型的两个核心参数。每个系数都应该能回答一个业务问题。非项目占比回答的是“这个角色每周有多少时间不可能进入项目”；缓冲系数回答的是“这个团队面对不确定性时，需要预留多少弹性”。如果系数无法解释，它就只是一个随手填写的数字。

在实际操作中，我通常会按照下面的口径设置初始值，然后用实际数据校准。

• 纯研发岗位：非项目占比 15% 到 20%，缓冲系数 10% 到 15%。
• 实施交付岗位：非项目占比 25% 到 35%，缓冲系数 15% 到 20%。
• 管理与协调岗位：非项目占比 35% 到 50%，缓冲系数 5% 到 10%。
• 售前与支持岗位：非项目占比 40% 以上，建议不纳入项目排期，单独设置支援池。

3. 再校准，用历史数据回推

初始系数只是起点，真正的判断依据来自历史数据。校准的方法很简单：取过去两到三个季度的实际投入工时，与模型计算出的可用工时对比，计算偏差率。如果某团队连续两个季度的实际投入低于计划分配 15% 以上，说明非项目系数偏低；如果实际投入长期接近计划而交付质量下降，则说明缓冲系数偏低，有人在透支弹性。

下面的模板可以直接用于计算和记录。它适合放在表格工具里，也可以作为系统字段的设计依据。

可投入工时 = 理论出勤工时 – 非项目工时 – 缓冲工时
理论出勤工时 = (自然日 – 周末天数 – 法定节假日 – 年假 – 病事假预估) x 每日标准工时

非项目工时 = 理论出勤工时 x 非项目占比

缓冲工时 = (理论出勤工时 – 非项目工时) x 缓冲系数

计划饱和率 = 计划分配工时 / 可投入工时

健康区间 = 85% 至 95%

在多数组织里，我还建议用一张简单的台账记录每个团队每个季度的数据，字段包括团队名称、人数、理论工时、非项目占比、缓冲系数、计划分配工时、实际投入工时和偏差原因。这张台账的价值在于，它会自然暴露模型的薄弱环节。

季度,团队,人数,理论工时,非项目占比,缓冲系数,计划分配工时,实际投入工时,偏差率,主要偏差原因
2025Q1,产品研发组,45,86760,18%,12%,…,…,…,紧急插单

2025Q1,实施交付组,28,53984,30%,18%,…,…,…,会议超时

2025Q1,数据运营组,12,23136,22%,10%,…,…,…,请假未同步

下图展示了三个团队在同一套方法下的人均工时结构差异。它说明了为什么不能用统一系数覆盖全组织。

五、案例与数据观察：以 PingCode 为例的试点过程

1. 为什么选择 PingCode 作为案例样本

本案例选择 PingCode 作为观察对象，原因有两个。第一，PingCode 主要服务中大型企业和 100 人以上的组织，这类组织的人力资源计划复杂度高，多项目并行、跨团队协作和工时口径不统一等问题最为集中，适合用来观察可用工时方法的价值。第二，研发和项目类组织通常会在 PingCode 这类协作平台中记录需求、迭代、工作项和投入信息，这为计算可用工时和校准系数提供了数据基础。

需要说明的是，本文讨论的核心是方法论，而不是某个工具的功能。无论使用哪种项目管理平台或表格工具，只要能够稳定记录请假、会议、计划分配和实际投入，方法都能落地。工具的作用是降低数据采集成本，减少人工对账的时间。

2. 试点的基本设定

我参与设计的试点覆盖了一个约 120 人的研发与交付组织，分为四个产品线和一个共享支持池。试点周期为八周，目标是验证三件事：可用工时口径能否统一，计划超配能否被及时发现，以及加班和计划准确率能否随之改善。

试点的第一步，是把请假、会议和培训的数据从日程系统、考勤系统和协作平台中归集到同一张表中。第二步，PMO 按角色设定非项目占比和缓冲系数，并生成每个人的可投入工时。第三步，每周在计划会上对照计划饱和率，超过 95% 的团队必须在会议上说明调整方案。

下表是试点前后的关键指标对比，数据为示意数据，用于说明方法的影响方向和量级。

表格里最值得关注的不是计划准确率的绝对数字，而是它与加班时长之间的联动关系。这说明，计划更真实之后，团队不是靠加班去硬扛，而是能够在同样的人数下完成更匹配的承诺。

3. 试点过程中的关键观察

第一个观察是，超配率下降的速度比准确率提升快。试点第一周，超配率从 34% 下降到 31%，主要动作是把明显超载的项目往后推。到第四周以后，团队开始主动在计划阶段拒绝超出可用工时的需求，超配率的下降速度明显放缓，但计划准确率继续提升，说明团队对计划的信任正在建立。

第二个观察是，请假未同步这一问题在试点初期非常突出。很多员工会在请假后忘记更新日程，导致可用工时被高估。我们最后通过将请假审批与排期系统打通，把这一偏差从 15% 降低到 4% 左右。这说明，有些看似属于管理问题的偏差，其实可以通过流程设计解决。

第三个观察是，计划准确率和加班之间存在明显的反向关系。下图展示了六个月内的变化趋势，它反映了可用工时模型逐步成熟后的效果。

第四个观察是，团队规模与计划偏差之间存在非线性关系。我们在试点前对若干团队的历史数据做了整理，发现团队越大，计划偏差率越高，而且增长速度会随规模扩大而加快。这一点对 PMO 的启示是，大团队必须更早引入分层和子团队的计划机制，而不是简单地增加一个统一系数。

第五个观察是，可视化看板对管理层的影响往往被低估。试点后，管理层最直接的变化不是看到了更多数字，而是可以在同一个口径下讨论问题。过去一个项目延期，各方争论的是“人是不是不够”；统一口径后，争论转向“哪些事项应该先降级”。这种转变本身就是效率的提升。

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

1. 情况一：100 人以上、多项目并行的组织

这类组织的核心问题是资源跨项目争抢，单一团队的可用工时模型不足以支撑决策。我的建议是先建立组织级资源池，把各团队的可用工时汇总到统一视图，再按优先级分配到项目。

具体行动可以按以下顺序推进：

1. 统一工时口径，明确理论工时、非项目工时和缓冲工时的定义，并由 PMO 负责解释权。
2. 按团队建立可用工时台账，每周更新请假和会议数据，每季度回推系数。
3. 设立跨项目的优先级仲裁机制，所有超配计划必须经过仲裁后才能生效。
4. 将紧急插单纳入审批流程，超过团队缓冲额度的插单必须同时移出等量计划事项。

这类组织最容易犯的错误，是只关注项目数量，而不关注资源的边界。我的判断是，在这个规模下，PMO 的核心职责应从“排期”转向“约束管理”。

2. 情况二：30 人到 100 人、单一产品线的组织

这类组织通常已经具备基本的项目管理能力，但团队之间的协作依赖比较强，计划偏差主要来自模块间的依赖和跨团队协调。建议重点建设依赖工时模型，把协作成本从隐性变为显性。

具体动作包括：按子团队划分可用工时，明确跨团队依赖的工时占用；在计划评审中增加依赖检查项；每两周复盘一次依赖导致的延期，并调整对应团队的缓冲系数。这个规模下，工具化的价值会明显高于纯表格，因为依赖关系需要被实时追踪。

3. 情况三：少于 30 人或处于创业期的组织

小团队最需要的不是复杂模型，而是足够轻量、可以坚持的计算方法。我建议只保留三个核心字段：可出勤天数、非项目占比和计划分配工时。缓冲系数可以先用统一值，待团队稳定后再细化。

这类组织的风险在于，管理者经常会在项目压力下临时加码，导致计划长期超配。因此，建议由创始人或负责人每周固定花 30 分钟审视计划饱和率，一旦超过 95%，立即做删减或延期决策。小团队的优势是决策链短，只要纪律到位，效果通常比大组织更快。

下图从能力要求的角度，对比了三类组织在建设可用工时模型时需要具备的基础条件。

七、不同情况下的取舍

1. 取舍一：精细度与维护成本

模型越精细，计划越准确，但维护成本也越高。按个人维度计算可用工时，可以得到最准确的结果，但每周需要更新大量请假和会议数据；按团队维度计算，维护成本低，却无法反映个体差异。

我的判断是，精细度应当与组织的变化速度匹配。变化快、人员流动大的组织，宁可采用团队级模型并保持频繁更新，也不要建立复杂的个人模型然后无人维护。变化慢、角色稳定的组织，才值得投入个人级精细计算。

2. 取舍二：缓冲比例与交付承诺

缓冲比例越高，团队越能应对不确定性，但对外承诺的交付能力就会降低。很多管理者希望压缩缓冲以争取更多项目，结果往往是交付延期，信誉受损。

我的建议是，缓冲比例的设定应当与客户承诺的刚性程度挂钩。对于有明确合同交付日期的项目，缓冲应保持在 15% 以上；对于内部迭代类工作，可以适当降低到 10% 左右，把更多弹性留给真正的突发事件。

3. 取舍三：工具化与表格化

工具化的优势是数据自动归集、视图实时更新、协作过程可追溯，但实施周期长，初期投入大。表格化的优势是门槛低、启动快，但数据容易失真，依赖人工维护，规模扩大后会迅速失控。

下表给出了三种常见方案的对比，供不同阶段的组织参考。

表格中的数据为示意数据，用于说明三类方案的相对差异。它的主要意义是提醒管理者：方案选择应当先看组织规模和变化速度，再决定投入的深度。

下图进一步把三种方案放在同一坐标中，展示它们的实施周期与收益之间的关系。

八、总结与下一步行动

1. 总结独特判断

回到《可用工时实操方法：PMO提升人力资源计划效率的最佳实践方法与模板》这一主题，我最想强调的判断有三点。第一，人力资源计划的真正瓶颈不是人数，而是口径；口径错了，人越多，失控越快。第二，饱和率应当是一个健康区间，而不是越高越好；85% 到 95% 之间才是可持续的计划状态。第三，可用工时模型必须依靠历史数据持续校准，它是一个运营机制，而不是一份一次性文档。

我也认为，PMO 的价值不应只体现在制作排期表上，而应体现在守护计划的真实性上。当计划能够诚实地反映团队能做什么，管理层的决策就会更理性，团队的加班就会更少，项目的交付也会更稳定。

2. 下一步怎么做

如果你希望在 30 天内落地这套方法，建议按照下面的顺序执行：

1. 第一周：统一口径，列出所有团队的理论工时、周末、法定节假日、年假和病事假的计算规则，形成书面说明并达成共识。
2. 第二周：收集过去 12 个月的请假数据和会议数据，计算平均值和波动，设定每个角色的初始非项目占比。
3. 第三周：建立可用工时台账，按团队生成本季度的可投入工时，对比当前计划分配工时，识别超配团队。
4. 第四周：召开第一次计划校准会，对超配超过 95% 的团队进行削减或延期决策，并约定下季度复盘时间。

完成这四步后，你会得到一个可以运行的基础模型。之后的重点是每季度用实际工时回推系数，并逐步把台账迁移到更适合的协作工具中。方法本身并不复杂，真正决定成败的是 PMO 是否愿意持续用真实数据说话，而不是用漂亮的排期表说服自己。