可用工时怎么做？产品经理入门指南：人力资源计划从0到1

很多产品经理第一次做排期时，都会犯同一个错误：把团队每人每天 8 小时都算成可以投入需求的时间，然后用“需求点数 ÷ 人数”推出上线日期。结果到了迭代中段，计划明显落后，团队却说“大家每天都在干活”。问题不在于大家不努力，而在于可用工时从来不等于总工时。本文围绕《可用工时怎么做？产品经理入门指南：人力资源计划从0到1》展开，从核心结论讲到背景场景、常见误区、判断逻辑、案例观察、行动建议与取舍，帮助你在没有成熟资源管理体系的情况下，先搭出一套能用、能校准、能持续迭代的人力资源计划方法。

一、核心结论：先算可用工时，再谈排期

我的基本判断是：人力资源计划的起点不是人头数，而是可用工时；可用工时的起点不是标准工时，而是扣除非项目性消耗之后的净投入时间。如果这一步错了，后面的甘特图、里程碑和承诺日期都会建立在虚假的容量之上。

从产品经理视角看，可用工时至少要回答三个问题：一是某个周期内，团队总共有多少小时可以被计划；二是其中有多少会被会议、缺陷、运维、培训、突发支持等事务吃掉；三是剩下的小时，能否被分配到具体角色和具体需求上。只有这三个问题都能回答，人力资源计划才算从“拍脑袋”进入“可推演”的阶段。

我对入门阶段团队的建议很直接：先用一个保守的可用系数跑通流程，再用真实数据逐步校准。在大多数研发与业务协同团队中，我会把 70% 到 80% 作为起始基准，而不是 100%。这个数字不是行业standard，而是一个能让团队先开始计划的经验起点。它的价值在于让“计划”和“现实”之间的差距暴露出来，而不是掩盖起来。

因此，本文的核心主张可以概括为一句话：可用工时是人力资源计划的地基，校准比精确更重要，流程比工具更关键。下面我会沿着真实场景展开，说明为什么大多数团队会在这一步失真，以及如何从 0 到 1 把它搭起来。

二、背景与真实场景：为什么排期总是“差一点”

我第一次系统性地处理可用工时问题，是在一个做 B 端管理后台的产品团队。当时团队有 6 名研发、2 名测试、1 名设计和 1 名产品。季度规划会上，我们估算了 14 个需求，总工作量约 420 人时，按每人每月 170 个标准工时计算，团队月投入约为 1190 小时，看起来绰绰有余。结果第一个月末，只完成了约 60% 的计划内需求，团队的感受却是“每个人都很忙”。

复盘时我们做了一次粗略的时间拆解：有人每天固定参加 1 小时站会与需求评审；有人被售后工单打断，平均每周花 6 到 8 小时处理线上问题；测试同学需要参与回归验证和版本发布；设计同学同时兼任两个业务线的临时需求支持。这些工作都真实存在，也都有价值，但它们几乎从未被计入排期。换句话说，我们在计划中使用的是“理论容量”，而团队真正能投入需求的是“净容量”。

这个场景非常典型。在中小团队里，很多人并不缺乏计划意识，缺的是把“非需求工作”显性化的方法。一方面，这些工作零散、碎片化，很难单独记录；另一方面，它们往往由不同角色临时承担，没有统一的归属。于是，产品经理看到的是“进度落后”，研发看到的是“被打断”，管理者看到的是“效率不高”，但真正的原因是容量模型失真。

另一个常见场景是跨团队协作。当一个产品需要同时依赖后端、移动端、数据团队和运营团队时，每个团队的可用工时都不一样，有的团队已经被其他项目占满，有的团队几乎空闲。如果只按项目总人数来估算，最后往往会出现“某个角色成为瓶颈”的情况。这也是为什么人力资源计划不能只看总量，还必须按角色、按周期拆开看。

所以，我把可用工时问题定义为：在一个明确周期内，把团队的理论工时扣减掉非项目性消耗、突发消耗和不可分配时间后，得到可以被需求承接的净工时，并将其分配到具体角色与具体事项上的过程。这个定义看起来朴素，却是后续一切资源决策的基础。

三、拆解常见误区：你可能正在高估团队产能

在入门阶段，我观察到几个高频误区。它们不一定错得离谱，但每一个都会让计划整体偏乐观。下面逐一拆解。

1. 把标准工时当成可用工时

这是最常见、也最致命的误区。标准工时通常按每天 8 小时、每月 21.75 个工作日折算，约为 174 小时，但扣除法定节假日、年假、病假以及正常的休息安排后，实际可用时间会明显下降。更重要的是，即使在工作日内，也不是所有时间都能投入到需求开发中。

我的经验是，一个新人产品经理在做人力资源计划时，几乎都会直接使用标准工时。这种做法的问题在于，它默认团队是一台满负荷运转的机器，而现实中的团队更像一个会被不断打断的服务系统。

2. 忽略会议与沟通的隐性成本

很多团队会把会议视为“无成本”的协作方式。然而，一个包含站会、需求评审、技术方案讨论、跨部门对齐、周会和复盘的标准研发团队，每周的会议时间很容易超过 8 到 10 小时。对于单个研发来说，这意味着每周约 20% 的时间已经被占用。

更值得注意的是上下文切换成本。一个 30 分钟的会议，往往会打断前后各一段深度工作，实际损耗可能远超会议本身的时长。因此，在估算可用工时时，会议不能只算会议时长，还要考虑它对专注时间的切割。

3. 把缺陷修复与线上支持当成“偶发事件”

在很多团队的计划中，线上缺陷、客户反馈和紧急支持都被视为偶发事件，因此不纳入排期。但从历史数据看，这些事件往往具有稳定的周期性。例如，每次版本发布后的前两周通常会出现一波缺陷修复；每个月末的报表任务会带来一批数据核对需求；大客户上线前的支持需求也会集中出现。

如果你不把这些消耗预留出来，它们就会以“插队”的方式吞噬原本的需求工时。我的建议是：偶发事件可以不逐条预测，但必须按历史比例预留缓冲。

4. 没有区分角色差异

另一个误区是用同一个可用系数套用所有角色。事实上，研发、测试、设计、产品和运营的非项目消耗结构完全不同。研发可能受线上问题影响较大，测试会在发布前后被集中占用，设计则常常被多个项目同时调用。把所有人都统一为 75%，会让某些角色严重超载，另一些角色却闲置。

5. 只在立项时估算，不在执行中校准

最后一个误区是把人力资源计划当成一次性的文档。立项时做了一次估算，之后很少回头检查。实际上，可用工时是动态变化的：团队人员会调整，业务节奏会变化，线上稳定性也会波动。如果没有周期性复盘，计划会越来越脱离现实。

四、专业判断逻辑：从“人数”走向“净工时”的推导过程

要解决上述误区，核心在于建立一套清晰的判断逻辑。我通常把它拆成四步：定义周期、计算理论容量、扣减非项目消耗、分配到角色与需求。每一步都不复杂，但顺序不能颠倒。

1. 先定义周期与口径

人力资源计划最好以周或双周为基本单位。周期太长，偏差会被平均掉，看不出问题；周期太短，又会因为临时波动而难以判断趋势。对大多数团队来说，两周是一个兼顾稳定性与敏感度的选择。

口径同样重要。你需要明确：工时按人时计算还是人天计算；是否包含加班；外包与实习生如何折算；请假是否按实际日历扣减。口径不统一，后续所有对比都会失效。

2. 计算理论容量

理论容量是最简单的一步。以两周为例，一名全职员工在标准情况下的理论工时约为 80 小时（每天 8 小时、10 个工作日）。如果团队有 6 名研发，理论容量就是 480 小时。注意，这里的理论容量应当扣除节假日和已知的长期请假，否则会虚高。

3. 扣减非项目消耗

这是最关键的一步。我通常把非项目消耗分为四类：固定消耗（站会、周会、例行评审），周期消耗（发布、回归、月度报表），波动消耗（线上缺陷、客户支持、临时需求），以及培训与成长消耗（技术分享、新人培养、学习时间）。

扣减时不必追求每一分钟的精确，而要尽量用历史数据估算比例。例如，你可以回看过去四周的工单记录和会议日历，估算出某类角色在非项目事务上的平均占比。这个比例就是你的可用系数的重要依据。

4. 分配到角色与需求

得到角色层面的净工时后，接下来是分配。这一步要回答两个问题：某个需求需要哪些角色参与；这些角色的净工时是否足够支撑它。只要某个角色在关键周期内出现超载，就需要调整需求顺序、拆分需求或增加缓冲。

在入门阶段，我推荐一个简单的计算方式。假设某角色两周理论工时为 80 小时，其非项目消耗估计为 20 小时，则净工时为 60 小时，可用系数为 75%。如果某个需求预估需要 45 小时，则该角色在这一周期内可以承接，但剩余空间只有 15 小时，需要为波动预留余量。

下面是一段可以直接用于表格或脚本的计算逻辑示例：

# 可用工时计算示例（按角色、按两周周期）
def net_capacity(headcount, hours_per_person=80, non_project_hours=0):

"""

headcount: 该角色人数

hours_per_person: 两周理论工时，默认 80 小时

non_project_hours: 该角色两周内估计的非项目消耗（会议、缺陷、支持、培训等）

"""

theoretical = headcount * hours_per_person

net = theoretical - non_project_hours

coefficient = net / theoretical if theoretical else 0

return {

"理论工时": theoretical,

"净可用工时": net,

"可用系数": round(coefficient, 2)

}

示例：6 名研发，两周非项目消耗估计为 120 小时

print(net_capacity(headcount=6, non_project_hours=120))

输出：理论工时 480，净可用工时 360，可用系数 0.75

这段代码本身很简单，但它的意义在于强迫你把“理论工时”和“净可用工时”分开写。只要这两个数字在团队里被明确讨论，计划的质量就会显著提升。

5. 用反馈校准系数

判断逻辑的最后一环是校准。每个周期结束后，比较计划净工时与实际投入工时，计算偏差。如果实际非项目消耗持续高于预期，就要上调非项目预留；如果某类事务已经明显下降，也要及时下调，避免过度保守。

我的经验是，连续三到四个周期的数据，就足以看出系数是否稳定。在此之前，不要急于下结论，也不要频繁调整，否则你会把偶然波动误判为结构性变化。

五、案例与数据观察：一次从估算失真到稳定排期的过程

这里我以 PingCode 为例，说明一个中大型组织如何在研发管理与人力资源计划中落地可用工时模型。之所以选择它，是因为它服务的通常是 100 人以上的中大型企业和团队，组织内的角色分工、跨团队依赖和多项目并行问题更加突出，因此更能体现可用工时管理的复杂性。

在类似的组织中，我们常见的情况是：研发、测试、产品、运维和业务支持分布在不同项目组，每个人同时参与两到三个需求，工单、缺陷和版本计划分散在不同系统里。管理者很难从单一视图看出“谁还有多少真实可投入时间”。在这种情况下，借助研发管理平台把需求、任务、缺陷、迭代与工时记录串联起来，就能让可用工时从经验判断转化为可观察的数据。

以下数据是基于典型中大型团队改造过程整理的示意性观察，用于说明方法效果，并非某一家企业的公开统计。可以把它理解为情景模拟，而非行业standard。

1. 改造前的典型问题

在改造前，团队通常面临三类问题：第一，迭代计划的承诺达成率较低，经常在周期中段进行范围调整；第二，跨团队协调依赖大量人工沟通，产品经理每周需要花费较多时间去同步进度；第三，非项目工作无法被识别，导致研发在统计上“看起来很忙”，但需求交付速度并未提升。

这些问题的根源，正是前文所说的容量模型失真。团队缺少对净可用工时的统一定义，也缺少对缺陷、支持和会议等消耗的记录方式，于是每次排期都要靠经验和讨论完成。

2. 改造中的关键动作

改造通常分为三步。第一步是统一口径：把需求、缺陷、线上支持和会议分别标记为不同类型，明确哪些属于项目工时，哪些属于非项目工时。第二步是建立角色视图：按周查看每个角色的理论工时、已分配工时和非项目消耗，形成负载可视化。第三步是周期复盘：每两周对比计划与实际，更新可用系数。

在这一过程中，研发管理平台的价值主要体现在两个方面。其一，它让需求、任务与缺陷之间的关联更加清晰，减少了“做了很多事但无法归档”的情况；其二，它让负载视图可以被团队共同查看，避免排期只存在于个别人的脑海中。

3. 改造后的结果观察

在经过三到四个迭代周期后，团队的变化通常比较明显。以下是一组示意性对比：

• 迭代承诺达成率：改造前约 58%，改造后约 76%，说明计划与实际之间的差距明显缩小，但仍未达到理想水平，因为业务临时变更依然存在。
• 周期中段范围调整次数：改造前平均每个迭代 3.2 次，改造后约 1.4 次，说明团队更少依赖“边做边改”的救火式调整。
• 产品经理协调同步耗时：改造前每周约 9 小时，改造后约 4 小时，主要减少在于进度信息有了统一视图，不再需要逐人追问。
• 非项目消耗占比识别率：改造前几乎无法统计，改造后可以覆盖约 85% 的非项目事务，剩余部分主要来自口头临时请求。

需要强调的是，这些变化不是工具本身带来的，而是“统一口径 + 负载可视化 + 周期复盘”三者共同作用的结果。工具只是把这套方法更容易执行下去。如果团队没有建立对可用工时的共识，即使使用再好的系统，也只会得到更精致的错误计划。

4. 从这个案例中得到的判断

我从这个案例中得到的最重要判断是：可用工时管理的收益主要来自“看见非项目消耗”，而不是“把每个人压满”。很多团队在引入管理工具后，第一反应是提升每个人的排期饱和度，结果反而导致超载、质量下降和离职率上升。真正健康的做法，是承认合理的非项目消耗，并把它纳入计划，而不是把它当成需要消灭的“浪费”。

另外，案例也说明，产品经理在其中的角色不只是提出需求，更要成为容量的“翻译者”。当业务方要求提前上线时，你需要能够用净可用工时解释：如果不调整范围，哪些角色会超载，超载会带来什么风险。这种表达方式比单纯说“团队很忙”更有说服力。

六、不同情况下的行动建议：按团队阶段选择起步方式

可用工时的做法并非一套固定模板，而需要根据团队规模、业务复杂度和数据基础来调整。下面我按三种常见情况给出建议。

1. 小团队（5 人以下）：先用手工表格跑通

小团队的优势是沟通成本低，劣势是数据基础薄弱。我建议先用一张共享表格完成最小闭环：列出每个人两周的理论工时，填写已知会议与支持时间，估算非项目比例，计算净可用工时，然后把需求分配进去。表格不需要复杂公式，关键是每个周期都更新一次。

在这个阶段，不要追求精确到小时的统计。你只需要知道：团队大致有多少净工时，哪些需求会占满它，哪些角色是瓶颈。跑通三到四个周期后，你就能判断自己的可用系数是否靠谱。

2. 中等团队（5 到 30 人）：建立角色视图与固定复盘

中等团队通常已经有多个角色和并行项目，单靠表格会越来越难维护。这时候，应当建立按角色分组的负载视图，并把非项目消耗细分为会议、缺陷、支持、发布和培训五类。每周或每两周做一次简短复盘，只回答三个问题：计划净工时和实际投入差多少；差异主要来自哪类消耗；下个周期的系数要不要调整。

此时，产品经理应与技术负责人共同维护可用工时模型，避免变成产品单方面的排期工具。只有研发认可这套口径，它才会真正有用。

3. 大型组织（100 人以上）：统一平台与跨团队依赖管理

大型组织的核心难点不在于计算，而在于协调。多个团队共享人员、共享测试环境和共享发布窗口时，单个团队的可用工时无法独立决定排期。这时需要建立跨团队的资源池视图，明确哪些角色是共享资源，它们在各项目中的分配比例如何，以及哪些时间窗口存在冲突。

在这一阶段，使用研发管理类平台的价值会更加明显。它可以把需求、迭代、缺陷、版本和工时记录串在一起，让管理者看到跨项目的真实负载。但也要注意，平台只能提供数据，最终的分配决策仍然需要基于对业务优先级的判断。

4. 通用行动清单

无论团队处于哪个阶段，我都建议按以下步骤推进：

1. 统一口径：明确工时单位、周期长度、非项目事务分类和请假扣减规则。
2. 计算理论容量：按角色、按周期计算理论工时，并扣除已知的节假日和长期请假。
3. 估算非项目消耗：用过去四周的历史数据估算会议、缺陷、支持、培训等占比。
4. 得到净可用工时：用理论工时减去非项目消耗，得到每个角色的净工时与可用系数。
5. 分配需求并预留缓冲：按优先级分配需求，并为波动事务保留 10% 到 15% 的余量。
6. 周期复盘校准：每个周期对比计划与实际，连续三到四个周期后再调整可用系数。

这套步骤的关键在于“先跑起来”。很多团队会花大量时间讨论模型是否完美，却迟迟没有开始执行。我的建议是，先接受一个粗糙但可执行的版本，然后在实践中迭代。

七、不同情况下的取舍：精细度、成本与速度之间怎么平衡

可用工时管理并不是越精细越好。精细度提高，数据采集成本和维护成本也会同步上升。产品经理需要根据团队的实际情况，在精细度、执行成本和决策速度之间做出取舍。下面给出几种典型方案的对比。

1. 三种常见方案的对比

从表格可以看出，三种方案没有绝对的优劣，只有适配与不适配。很多团队的失败，不是因为选错了方案，而是因为在不适合的阶段上了过于复杂的方法，结果被维护成本压垮。

2. 精细度与准确率的关系

我用一组模拟数据来说明精细度与准确率的关系。假设某团队在四种精细度下，连续六个周期的排期偏差分布如下，这是基于经验规律构造的示意数据，用于说明趋势，而非真实统计。

这组示意数据的启示是：从粗粒度到角色净工时，偏差下降最明显；之后每增加一层精细度，收益都在缩小，而成本却在增加。因此，我的判断是，大多数团队应当在角色净工时法这一层找到平衡点，而不是一开始就追求最精细的平台化方案。

3. 速度与准确的取舍

另一个常见取舍是速度与准确。在业务窗口期紧张时，团队可能没有时间做完整的工时统计，只能用经验快速排期。这时可以接受较粗的估算，但要做两件事：一是对关键路径上的角色预留更多缓冲；二是明确告知业务方，排期的置信度较低，后续需要再校准。

相反，在长期项目或资源紧张的情况下，准确性的价值会显著提高。一次错误的排期可能导致跨团队的连锁延误，修正成本远高于前期的统计成本。这时，投入更多时间在可用工时建模上，往往是划算的。

4. 角色瓶颈的风险分布

在多角色协作中，风险通常并不均匀分布。少数角色往往承担了大部分的非项目消耗，成为事实上的瓶颈。下面这组示意数据展示了某团队两周内各类非项目消耗的占比分布，可以帮助我们判断应该优先治理哪一类问题。

从帕累托结构看，缺陷修复和临时支持两项合计占比超过六成，这意味着提升可用工时的最快路径，往往不是减少会议，而是降低缺陷率和规范支持入口。这一点很容易被忽视，因为会议是最显眼的消耗，但它未必是最大的消耗。

八、总结与下一步：把可用工时变成团队的共同语言

回到开头的问题：可用工时怎么做？我的答案是，先承认团队的理论工时不等于可投入工时，再用一套可重复的口径把非项目消耗显性化，最后通过周期复盘不断校准系数。这套方法看似朴素，却是人力资源计划从 0 到 1 最扎实的一步。

我想强调三个独特观点。第一，可用系数不是一个需要追求的“效率指标”，而是一个需要被诚实面对的现实指标。把它压到 100%，只会让排期更脆弱。第二，产品经理的价值不在于让团队每天更忙，而在于用净工时让业务方理解取舍，让研发愿意共同承诺。第三，工具可以放大方法，但不能替代方法。没有统一口径和复盘习惯，再好的平台也只是数据的展示板。

如果你现在就要开始，我建议按以下顺序行动：第一周，统一团队对可用工时的定义，并选一个两周周期做试点；第二周，记录会议、缺陷、支持和发布等非项目消耗，形成第一版历史数据；第三周，计算角色净工时并据此做需求分配，预留合理缓冲；之后每个周期结束后，做一次十五分钟左右的复盘，只讨论计划与实际的差距，以及系数是否需要调整。

坚持三到四个周期后，你会发现团队的排期开始变得可信，争论也会从“谁在偷懒”转向“哪类事务在吃掉时间”。这才是人力资源计划真正的价值：它不是用来约束人的表格，而是帮助团队看清自己能做什么、不能做什么，并在此基础上做出更好的承诺。