可用工时怎么做？产品经理协同管理：人力资源计划从0到1

很多产品经理在做排期时都遇到过同一个尴尬：周会上每个人都说“这个需求两周能做完”，迭代结束时却只完成了六成。问题通常不在个人能力，而在于团队从一开始就把“理论工时”当成了“可用工时”。本文围绕《可用工时怎么做？产品经理协同管理：人力资源计划从0到1》展开，从一个人一个月到底能承接多少项目工作讲起，拆解可用工时的计算逻辑、常见误区，以及在中大型组织中如何借助项目管理平台把人力资源计划落到可执行的层面。

一、核心结论

先给出最重要的判断：可用工时不是“标准工时减去请假”，而是在日历工时的基础上，系统性扣除所有非项目性消耗、组织协同成本和不确定性缓冲之后，真正能被投入到计划性项目工作中的时间。多数团队的排期失真，根源是只扣了请假，没有扣会议、答疑、线上支持、跨部门对齐和突发需求。

第二个结论同样关键：可用工时应当按人、按角色、按阶段分别测算，而不是按团队平均值一刀切。产品经理与研发、测试、设计的工时结构完全不同，一个长期承担客户对接和运营支持的产品经理，其可用工时可能只有名义工时的五到六成。

第三个结论是从0到1搭建人力资源计划时最容易被忽略的：可用工时的价值不在于算得多精确，而在于让承诺和现实之间的偏差可以被看见、被修正。一个误差在15%以内、并且每月复盘校准的模型，远比一个看起来很精确但从不更新的表格更有用。

二、背景与真实场景

过去两三年，我参与和观察过不少中大型组织的产品迭代规划，发现一个共同现象：年度规划会议上，业务方拿着一份人力资源计划表，每个产品经理名下都标着“100%可投入”，但到了季度中期，超过一半的人已经处于超负荷状态。表面上看是需求太多，实际上是人力计划的底层假设出了问题。

这种场景在100人以上的组织中尤为突出。组织规模一大，协同链路变长，产品经理不再只是“写需求、画原型、跟进开发”，还要参加跨部门评审、回应销售和客服的紧急诉求、准备管理层汇报、参与招聘面试、协助培训新人。这些事情单独看都不大，叠加起来却会吃掉团队大量的有效时间。

另一个常见场景是“隐形承接”。某个资深产品经理因为熟悉业务，被默认成为多个项目的“兜底人”，他的日程表上每个项目都有他的名字，但没有任何一个项目把他的时间量化出来。结果是项目A延期，大家第一反应是研发效率低，而不是这位产品经理同时在七个项目里各占一小块时间。

因此，可用工时管理的真实痛点不是计算公式本身，而是三件事：谁的时间被用了、用在了哪里、这些使用是否被计入计划。只要这三件事说不清楚，任何排期都只是一厢情愿。

三、拆解常见误区

1. 把法定工时当成可用工时

最常见的误区是直接用“每月21.75天乘以每天8小时”得到174小时，然后把这个数字当作可投入的项目工时。法定工时是劳动合同的上限概念，它不包含组织运行本身所需的时间，也不包含个人的状态波动。把它当作项目可用量，等于默认每个人每天八小时都在做计划内的产出，这在现实中几乎不可能成立。

2. 只扣请假，不扣协同成本

很多团队在做人力计划时会扣除年假、病假、法定节假日，却把例会、评审、答疑、临时拉群处理线上问题都当作“工作的一部分”，不予扣除。问题在于，这些活动并不产出计划内的项目成果，它们对项目而言是必要但不可承诺的成本。如果不把它们显式扣除，计划就会在无形中被透支。

3. 用团队平均值替代个人差异

将所有产品经理的非项目工时取平均，再统一应用到每个人身上，这种做法看似公平，实则掩盖了关键风险。一个负责对外客户支持的产品经理和一个专注内部平台建设的产品经理，其非项目工时占比可能相差二十个百分点以上。平均值会让前者持续超负荷，后者则闲置，最终两边都无法被准确调配。

4. 不设缓冲，或者缓冲设置成拍脑袋

另一个极端是完全不设缓冲，认为“计划就是要满负荷才有效率”。还有一种是随便写一个10%或者20%，既不解释来源，也从不校准。缓冲的本质是对估算误差和突发事件的预留，它应当随着团队历史数据的积累而调整，而不是一个固定的装饰性数字。

5. 以为把表格做出来就完成了

人力资源计划最怕的是“一次性工程”。很多团队花了一周时间做出漂亮的人力排班表，之后再也没有更新，等到真正的项目冲突发生时，表格早已与现实脱节。可用工时必须是一个持续运行的机制，而不是某次会议的附件。

四、专业判断逻辑

在我看来，可用工时的判断应当遵循一条清晰的链路：先确定理论上限，再逐层扣除不可承诺部分，最后留出与不确定性相匹配的缓冲，得到的数字才是可以放进排期里的承诺量。这条链路的每一步都应该有依据，并且可以被追溯。

第一步是确定理论工时。这里要区分自然月的日历天数与实际工作日。以一个标准月为例，工作日通常在21到22天之间，按每天8小时计算，理论工时约为168到176小时。关键是要把当月的法定节假日和团队统一的调休日显式减掉，而不是用一个固定的月均值。

第二步是扣除个人休假。年假、病假、事假的历史平均值是比较合理的依据。对于新员工，应当结合入职和转正安排做单独处理。这一步扣减的是“个人确定会缺席的时间”，不应当把偶发情况也一并计入，否则会过度保守。

第三步是扣除非项目性工作。这是可用工时管理中最需要专业判断的环节，建议拆分为四类：一是固定会议，如周会、评审会、站会；二是运营支持，如客户答疑、线上问题响应、数据需求；三是组织事务，如招聘面试、培训、跨部门协调；四是临时插入，如紧急需求和突发故障。前三类可以通过历史日程数据测算，第四类则需要用过去三到六个月的实际发生量来估计。

第四步是设置缓冲。缓冲的比例取决于两个因素：估算的历史准确度，以及项目的不确定性。如果团队过去三个迭代的估算偏差一直在20%左右，那么缓冲设置在15%到20%之间是合理的；如果项目是全新领域，不确定性更高，可以适当提高。

综合以上四步，可以用下面的计算框架表达可用工时：

可用工时 = 理论工时

个人休假工时

固定会议工时

运营支持工时

组织事务工时

临时插入工时（历史均值）

缓冲工时（剩余工时 × 缓冲比例）

这个公式的价值不在于复杂，而在于它把每一个被扣除的部分都变成了可以讨论、可以调整的变量。当排期出现偏差时，团队可以逐项检查：是休假估计偏少，还是运营支持超出了预期，抑或缓冲不足，从而定位问题而不是互相指责。

五、具体案例与数据观察

1. 一个典型的产品经理工时拆解

下面用一个情景模拟来说明这套逻辑。假设某产品经理的理论工时为174小时，个人年假与病假月均摊为12小时，固定会议约28小时，运营支持约10小时，组织事务约8小时，临时插入约12小时。按照上面的公式，剩余工时约为104小时，若缓冲比例取15%，则可用于计划内项目工作的承诺工时约为88小时。

这个数字与直接用174小时排期之间的差距接近一半。也就是说，如果团队按照理论工时排期，这位产品经理在计划中会被安排接近两倍的工作量，最终的延期几乎是必然的。

需要强调的是，上述数字是为说明方法而设计的情景模拟，并非某个真实团队的统计结果。真正有价值的是，你在自己的团队里用同样的方法去测算，然后用真实数据替换每一项假设。

2. 中大型组织中的系统化实践

在组织规模超过100人、同时存在多个产品线和多个协同团队的情况下，手工维护可用工时表会迅速变得不可持续。这时候，借助成熟的项目管理平台来承载人力资源计划，是更稳妥的选择。以PingCode为例，它主要服务中大型企业及100人以上的组织，在工时与人力资源计划相关的场景中，常见的使用方式包括：将成员的项目分配、迭代计划和非项目任务统一登记在同一套视图中；通过工作项的预估工时与实际工时对比，积累团队的估算准确度数据；

以及按角色、按小组查看负载分布，提前发现超负荷风险。

我更看重的不是工具本身，而是它让“非项目工时”第一次变得可见。当会议、支持和临时事务都能被登记为任务并归属到具体成员名下，团队就能自然地得到一份真实的非项目工时画像，而不必依赖记忆或估计。

3. 数据观察：非项目工时占比与延期率的关系

在多个团队的复盘中，我反复看到一个规律：非项目工时占比越高，迭代延期的概率越大，而且两者之间并非线性关系，而是在占比超过三成之后迅速恶化。下面的图表用情景模拟数据展示了这一趋势，它的作用是帮助团队判断自己处在哪个区间，而不是给出一个普适的阈值。

从图中可以看到，占比在18%到27%之间时，延期率的上升相对平缓；一旦越过三成，延期率的增速明显加快。这意味着，团队在做人力资源计划时，应当把非项目工时占比作为一个需要监控的核心指标，而不是只关注项目进度本身。

4. 从理论工时到承诺工时的分解

为了让团队理解扣减的累积效应，我通常会用瀑布图把整个过程可视化。它的价值在于，每一次扣减都是一个独立的决策点，团队可以逐项讨论其合理性，而不是面对一个最终数字时感到困惑。

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

1. 刚开始搭建人力资源计划的团队

如果团队此前从未系统地测算过可用工时，我建议先不要追求精确，而是用两到三个月的时间做“只记录、不考核”的数据收集。具体做法是让每位成员用简单的方式记录每周的非项目工作，包括会议、支持、临时事务和休假，记录精度到半天即可。这样得到的数据虽然粗糙，但足以支撑第一版可用工时模型。

在这个阶段，最重要的不是算出一个完美数字，而是让团队养成“先扣减、再排期”的习惯。哪怕第一版的缓冲比例只是经验值，只要它被写进规则并每月复盘，模型就会逐步变得可靠。

2. 已有排期体系但经常延期的团队

这类团队通常不缺计划，缺的是对现实的校准。我的建议是先做一次“反向核算”：找出过去三到六个迭代中实际完成的工时，与当初排期的承诺工时做对比。如果偏差长期为正，说明承诺偏高，应当降低可承诺比例或提高缓冲；如果偏差集中在某几个人身上，说明个体负载分配有问题，需要重新调配运营支持任务。

在工具层面，可以借助项目管理平台把任务的预估与实际工时关联起来，形成可追溯的偏差数据。对于PingCode这类服务中大型组织的平台，其优势在于能够把跨项目的任务归集到同一视图中，便于发现某个产品经理同时挂在多个项目上的隐形负载。

3. 需要支撑多个产品线的组织

多产品线的组织最容易陷入“每条线都说自己很忙”的僵局。此时，可用工时的管理重点应当从个人转向资源池。具体来说，可以先把每个产品经理的可用工时汇总成组织级资源池，再按优先级和战略目标分配给各条产品线，并明确每条线的最低保障工时。

在这种场景下，我建议设立一个由人力资源或运营负责人牵头的月度资源评审机制。评审的输入是各团队的可用工时报告和延期数据，输出是下个月的资源调配决议。关键在于，调配决议必须有书面记录，并在下次评审时被回看，否则资源池很快会沦为形式。

4. 处在快速扩张期的团队

快速扩张期的团队面临的最大变量是新人占比上升。新人在前三个月的有效产出通常只有成熟员工的一半左右，而且需要老员工投入额外的带教时间。如果计划时不考虑这一点，老员工的非项目工时会急剧上升，连带拖慢整个团队的节奏。

我的建议是为新人设置单独的产能系数，并在计划中把带教时间作为固定的非项目工时显式登记。等新人转正之后，再逐步恢复到标准系数。这种做法看似繁琐，却能避免“招人越多、项目越慢”的反常现象。

七、不同情况下的取舍

1. 精确度与维护成本之间的取舍

可用工时模型的精度越高，需要的数据采集和维护成本就越大。一个按小时、按任务记录的精细模型，可以帮助团队做出非常准确的排期，但如果没有人愿意持续填写，它很快就会失效。我的判断是，对于50人以下的团队，按周或按半天粗颗粒度记录，反而比追求小时级精度更可持续；对于100人以上的组织，则应当借助工具自动归集，减少人工干预。

2. 保守承诺与资源利用率之间的取舍

缓冲设置得越大，排期越安全，但团队的资源利用率会下降，部分产能会被闲置。这是一个典型的权衡。在我看来，对于交付承诺对外可见、延期成本高的项目，应当偏向保守；对于内部探索性项目，则可以适当降低缓冲，接受一定的不确定性。关键是这个取舍应当被显式讨论，而不是默认选择某一端。

3. 个体公平与整体效率之间的取舍

当某个产品经理承担了大量隐形支持工作时，如果把他的可承诺工时降低，整体项目的进度可能会受益，但他可能会觉得自己的付出没有被看见。反过来，如果维持原有的项目承诺，他的超负荷会持续累积，最终影响留存与产出质量。我的建议是，将隐形支持工作显式登记并纳入考核口径，让个体的付出以可见的形式体现在计划中，而不是通过压缩项目承诺来隐性补偿。

4. 工具自动化与流程灵活性之间的取舍

引入项目管理平台可以显著提升工时数据的可追溯性，但过度标准化的流程也可能让团队失去应对特殊情况的灵活性。例如，某些紧急事务需要跳过常规的登记流程直接处理，如果系统强制要求事前登记，团队就会想办法绕过系统，数据反而会失真。因此，建议在流程中为紧急事务保留快速通道，并要求事后补录，用制度换取数据的完整性。

八、总结与下一步

回到开头的问题：可用工时怎么做？我的核心判断是，它应当是一个“从理论工时出发、逐层扣减、保留缓冲、持续校准”的机制，而不是一张静态的表格。真正决定排期能否兑现的，不是公式有多复杂，而是团队是否愿意把那些被忽略的非项目工时摆到桌面上，并用真实数据去修正假设。

如果你现在就想开始，我建议按照以下顺序行动：第一，选定一个试点团队，用两周时间记录每位成员的理论工时、休假、会议、支持和临时事务；第二，用上文的公式测算该团队的可承诺工时，并与过去三个迭代的实际完成量做对比；第三，根据对比结果调整缓冲比例，并确定每月复盘的时间点；第四，当试点跑通之后，再考虑引入项目管理平台，把任务、工时和负载统一到一套视图中，逐步推广到其他团队。

可用工时管理没有一步到位的答案，它需要的是耐心和持续的校准。从0到1搭建人力资源计划，第一步不是做出完美的模型，而是让每一个承诺都有据可查、每一次偏差都有人复盘。当这套习惯真正形成，你会发现团队的排期不再依赖运气，而是建立在对自己时间的真实理解之上。