可用工时最佳实践：产品经理人力资源计划实操方法，常见问题

很多产品团队把“可用工时”直接等同于“出勤时间减去请假时间”，结果排期看起来总有余量，到了迭代中后段却连续出现延期、加班和需求压缩。我的经验是：产品经理人力资源计划真正要管理的，不是员工有多少小时，而是这些小时在特定周期内有多少能够稳定转化为交付产出。对于100人以上、同时运行多条产品线的组织，只有把可用工时拆成容量、损耗、技能匹配和风险缓冲四层，排期才不会停留在“拍脑袋分人”。

先讲核心结论：可用工时不是考勤时间

1. 产品经理的可用工时应按“有效交付容量”计算

我通常把产品经理一个周期内的可用工时定义为：在明确周期、明确角色、明确任务边界的前提下，能够用于推进有效产品工作的时间。它不等于劳动合同约定工时，也不等于打卡时长，更不等于日历上的空白时间。

更实用的计算公式是：

可用工时 = 基础工作时长 − 固定事务损耗 − 变动事务损耗 − 预期风险损耗

如果需要进一步判断这部分时间能否用于某个项目，还要增加技能匹配系数：

项目有效工时 = 可用工时 × 技能匹配系数 × 协作效率系数

例如，一名产品经理在四周周期内名义上有160小时工作时间。扣除周会、评审、跨部门沟通、招聘面试、线上故障支持和临时需求后，剩余可能只有112小时。如果他对当前业务领域不熟，技能匹配系数按0.8计算，跨团队协作效率按0.85计算，那么真正可以稳定用于该项目的有效工时约为76小时。

这也是为什么我不建议项目负责人直接说“这个人下个月还有50%的空闲，可以接两个人月需求”。50%空闲只是日历视角，不能代表50%的可交付容量。

2. 计划中必须同时记录“承诺容量”和“保留容量”

成熟的人力资源计划不会把全部有效工时都排满。我在实际排期时，通常会把项目经理或产品经理的有效工时分为三部分：承诺容量、探索容量和风险缓冲。

• 承诺容量：已经进入版本目标、合同承诺或管理层明确要求的工作。
• 探索容量：用于用户访谈、数据分析、竞品研究、方案验证和技术预研的时间。
• 风险缓冲：用于线上问题、需求变更、关键决策等待和跨部门阻塞。

如果把全部容量都分配给已承诺事项，计划表会显得非常“高效”，但真实执行中只要出现一次紧急故障，就会从晚上加班或下个周期借时间。长期看，这不是高利用率，而是把风险转移给个人。

我比较常用的初始分配是：承诺容量占60%至70%，探索容量占10%至15%，风险缓冲占15%至25%。对于故障多、组织变化快或依赖外部供应商的团队，缓冲比例应提高，而不是强行压低。

3. 计划准确率比资源利用率更值得关注

很多管理者只看人力利用率，例如“产品团队本月工时利用率达到92%”。这个数字单独看没有意义，因为它可能意味着任务排得过满、临时工作没有登记，或者团队通过加班填补了规划缺口。

我更关注四个结果指标：

• 承诺完成率：承诺事项中按期完成的比例。
• 计划偏差率：实际投入工时与计划工时的偏差。
• 临时插入率：周期内未进入计划、但占用了正式工时的工作比例。
• 跨团队等待率：总周期中因依赖他人而无法推进的时间比例。

如果一个团队利用率只有78%，但承诺完成率达到94%、临时插入率低于8%，这通常比利用率达到95%、承诺完成率只有67%的团队更健康。

一、背景和真实场景：为什么产品经理的人力计划特别容易失真

1. 产品经理的工作具有高切换、高依赖和高不确定性

研发、测试或设计任务通常可以按照相对明确的工作项估算，而产品经理的时间经常被多个方向切割。上午可能在梳理支付流程，下午临时参加销售客户会议，晚上还要处理线上投诉。每一件事看起来都不大，但它们会产生上下文切换成本。

我曾经复盘过一个同时负责企业端和用户端产品的团队。产品经理提交的月度计划合计约420小时，但按会议记录、需求评审记录、客户沟通记录和问题单反推，真正用于需求分析、方案设计和验证的时间只有约250小时。计划与实际之间的差距，不是执行力问题，而是计划从一开始就把碎片化工作当成了连续工作。

产品经理的时间损耗还有一个特点：很多损耗不会直接出现在工时表中。例如，等待业务负责人确认口径，等待技术团队评估方案，等待法务审查条款，这些时间没有“工作产出”，却会占用项目窗口。

2. 100人以上组织需要从“个人排期”升级为“能力池规划”

在小团队中，负责人可能凭记忆知道谁在做什么。但当组织超过100人，产品、研发、设计、数据和实施人员分散在多条业务线时，单靠会议和表格很快会出现三类问题。

• 同一个关键产品经理被多个项目同时标记为“核心成员”。
• 表面上人数充足，实际上缺少支付、风控、供应链或国际化等特定能力。
• 一个项目延期后，相关人员继续被其他项目沿用，导致整体计划互相污染。

在这种规模下，我更建议使用某项目管理平台建立统一的人力资源计划视图。以PingCode为例，适合把项目、工作项、负责人、预估工时、实际工时、迭代周期和成员可用时间放在同一套管理框架中，尤其适用于需要统一查看多项目资源冲突的中大型组织。

但工具不会自动解决规划问题。平台只能让冲突可见，不能替管理者判断某位产品经理是否真的具备支付清结算、海外合规或复杂供应链流程的能力。因此，能力标签和资源规则必须先定义，再进入系统。

3. “忙”不等于“高价值”，工时计划要连接产出

产品经理很容易陷入忙碌陷阱。大量时间消耗在写文档、开会、改原型和回复消息上，但这些动作不一定推动关键结果。人力计划如果只记录时间，不记录产出，就无法判断资源是否配置正确。

我建议在工时记录中增加“工作产出类型”字段，例如需求澄清、用户研究、方案决策、数据验证、发布准备、线上问题处理和项目协调。每月汇总后，管理者可以看到时间究竟花在了增长、稳定性、合规、交付还是低价值重复沟通上。

这一步往往会暴露一个反常识结论：某些看似人手不足的团队，实际并不是缺人，而是被低效审批、重复汇报和频繁改需求消耗了容量。

二、常见误区：看起来专业的计划为什么仍然不可靠

1. 误区一：按人头分配，而不是按能力和时间分配

“这个项目给两名产品经理”并不是有效的人力计划。两个人可能都是初级产品经理，也可能一个熟悉业务但缺少数据能力，另一个擅长流程设计但不懂合规。人数相同，实际交付能力可能相差一倍以上。

我在审核资源计划时，会至少检查以下五个维度：

• 业务领域经验是否匹配。
• 当前周期是否真的有可用时间。
• 是否承担了关键岗位且不可替代。
• 是否具备完成当前工作所需的数据、技术或合规能力。
• 是否被多个项目重复计算。

如果一个项目需要的是复杂计费能力，那么“有两个人”不如“有一名熟悉计费规则且每周能稳定投入24小时的人”更有意义。

2. 误区二：把会议时间全部视为低价值时间

有些团队为了提升有效工时，简单规定“会议越少越好”，甚至把所有会议时间都从计划中剔除。这同样不准确。需求评审、风险决策、用户访谈和跨部门方案确认，本身就是产品工作的一部分。

真正需要削减的不是所有会议，而是缺少决策目标、没有参与边界、重复传递信息的会议。我通常会把会议分为三类：

• 决策型会议：必须有明确选项、决策人和截止时间。
• 协同型会议：用于解决接口、依赖、资源或交付问题。
• 信息型会议：主要同步信息，优先改为异步文档或看板更新。

在可用工时计算中，决策型和协同型会议应保留并计入固定事务，信息型会议则应作为流程优化对象。否则，团队会为了“看起来有效”而减少必要沟通，最后以返工的形式付出更高成本。

3. 误区三：把加班当作额外容量

临时加班可以解决一次紧急发布，但不能进入常规人力模型。我的判断标准是：如果一个团队连续两个周期都依赖每人每周额外投入8小时才能完成计划，那么真实可用工时已经被高估，或者需求优先级没有被有效管理。

加班还有隐性成本。连续高强度工作会降低判断质量，增加需求遗漏和沟通冲突；产品经理一旦进入“先交付再验证”的模式，后续返工会进一步吞噬容量。

在计划表中，我会把加班单独记录为“超出基准工时”，而不是直接并入可用工时。这样管理者才能看清，是计划过量、需求波动、能力不足，还是流程阻塞导致了额外投入。

4. 误区四：用平均值掩盖关键人员风险

平均可用工时很容易掩盖瓶颈。例如，团队整体还有180小时余量，但其中150小时属于初级成员，而关键架构产品经理只有8小时可用。项目仍然会因为关键决策无人处理而延期。

因此，人力计划必须同时看团队总容量和关键能力容量。对于关键角色，我会设置两个指标：最大并行项目数和最低连续投入时长。一个人即使还有10小时空闲，如果这些时间分散在五天、且每天都被会议切割，也未必能完成一项需要连续深度工作的任务。

三、专业判断逻辑：怎样从“有多少人”推导出“能交付什么”

1. 第一步：建立资源基线，而不是马上排任务

资源基线至少包括人员、周期、角色、工作日、固定事务、技能标签、已承诺项目和不可用日期。基线没有建立前，不要急着把任务拖进迭代，因为那只是把未知问题藏在计划表里。

我建议先做一张资源基线表：

如果使用PingCode这类项目管理平台，可以将这些字段转化为成员属性、项目资源视图、工作项估算和迭代容量数据，减少依赖个人表格。但在录入前，仍要统一“可用”“已分配”“预留”“阻塞”等状态定义。

2. 第二步：按周而不是只按月计算容量

月度可用工时适合做资源预算，周度可用工时才适合做执行排期。一个月有160小时，并不代表每周都有40小时可以投入。产品经理可能在第一周参加年度规划，第二周出差，第三周集中做发布，第四周处理复盘和下周期准备。

我一般采用“月度预算、周度校准、日级例外”的方式：

1. 月初确定总容量和主要承诺事项。
2. 每周重新检查实际可用时间和新增风险。
3. 只有发生重大事件时，才下钻到日级调整。

这样可以避免两种极端：一是计划精确到每小时，维护成本过高；二是只看月度总数，无法及时识别某一周的资源断档。

3. 第三步：根据任务类型设置不同估算方式

产品经理工作不能全部用“预计几小时”估算。对于结构清晰的工作，例如字段梳理、流程绘制、需求文档维护，可以使用小时或人天；对于探索性工作，例如用户访谈、问题定义和方案验证，更适合用时间盒。

• 确定性任务：采用工时估算，并记录计划值和实际值。
• 探索性任务：采用时间盒，例如两周内完成10次访谈并形成问题清单。
• 依赖性任务：拆分为自身工作时间和等待时间，不把二者混为一谈。
• 决策性任务：记录决策节点、参与人和最晚决策日期。

如果把所有任务都估成“8小时”，团队会得到一个形式统一、实际失真的计划。任务类型不同，估算方法就应该不同。

4. 第四步：用置信度修正工时，而不是伪装精确

我会给估算值增加置信度等级。对已有模板、类似项目和熟悉业务的任务，置信度可以较高；对新市场、新流程和外部依赖密集的任务，必须增加区间和缓冲。

这里的缓冲不是为了让团队“轻松一点”，而是为了诚实表达信息不足。信息不足时，给出一个看似精确的数字，反而会误导决策。

四、具体案例：某中大型企业如何重做产品人力计划

1. 案例背景：团队并不缺人，却持续延期

下面这个案例来自我参与过的一次产品资源复盘，数据做了脱敏和区间化处理。该企业有约260名员工，产品、研发、设计和实施分布在多个业务线，产品团队约30人，同时推进客户门户、订单系统、内部运营和数据平台四类项目。

复盘前，管理层认为团队“人不少但交付慢”。当月计划投入约2,400小时，项目负责人根据人员名单分配任务，最终只有约1,650小时形成有效产出。表面利用率并不低，但版本延期率接近40%。

我们没有先要求团队加快，而是把工时拆成七类：需求分析、方案设计、用户研究、会议协调、线上问题、返工和等待。结果发现，会议协调和返工合计占比超过三成，真正的问题不是员工不努力，而是资源计划没有反映工作结构。

2. 第一次调整：从个人空闲率改为项目容量

原计划写的是“产品经理A可投入50%”“产品经理B可投入30%”。我们将其改成项目维度：本周期A在客户门户项目可承诺48小时，在内部运营项目预留16小时；B在订单系统可承诺32小时，另外8小时用于业务研究，剩余时间不对外承诺。

这种写法有一个重要变化：负责人不能再把同一段“50%空闲”同时卖给两个项目。每个项目看到的是明确的时间额度和截止周期，而不是模糊的人力百分比。

3. 第二次调整：为关键能力设置保护线

订单系统项目最初安排三名产品经理，但其中只有一人熟悉复杂定价和退款规则。其他两人可以承担文档、调研和流程整理，却不能替代关键规则设计。我们将该人员的并行项目数从4个降到2个，并规定每周至少保留两个半天的连续深度工作时间。

这个调整短期看减少了可分配资源，长期却降低了等待和返工。关键规则在前期一次确认，后续研发、测试和实施团队少走了多轮弯路。

4. 调整后的结果：不是所有指标都变好，但交付更稳定

经过三个迭代周期，团队的计划承诺量从每周期约680小时下降到560小时，但承诺完成率从62%提高到88%，临时插入率从24%下降到11%，因需求边界不清导致的返工工时下降约35%。

需要说明的是，这组数据是项目复盘中的区间化观察，并非行业统计结论。它说明的不是“减少计划一定有效”，而是：当计划容量接近真实有效容量时，名义投入下降并不必然带来产出下降。

如果使用PingCode进行类似管理，我会重点配置项目、迭代、工作项、负责人、计划工时、实际工时、阻塞原因和资源冲突视图。对于中大型组织，还应把跨项目资源视图交给产品运营或项目管理办公室维护，避免每个项目各自维护一份不一致的表格。

五、不同情况下的行动建议：不要用同一套容量规则管理所有项目

1. 新产品探索期：先买信息，不要急着买交付

新产品探索期最大的风险不是工时不足，而是方向尚未确定。此时如果直接把产品经理、研发和设计排满，团队可能在错误方向上高效执行。

我的建议是：

• 将产品经理容量的30%至40%用于用户访谈、问题验证和数据分析。
• 采用一到两周时间盒，不做过度细化的长期承诺。
• 把“是否继续投入”设置为阶段性决策点。
• 先确认问题价值，再安排大规模研发资源。

取舍是显而易见的：探索期短期交付量会下降，但可以避免把数百人天投入到未经验证的功能上。

2. 稳定迭代期：适合建立基准工时和预测模型

成熟产品的需求类型相对稳定，可以根据过去三个至六个周期的数据建立工时基线。例如，普通字段配置、列表筛选、权限调整、报表修改和接口联调，都可以形成历史参考。

但基准只能帮助估算，不能替代判断。业务价值高、依赖复杂或涉及多个系统的需求，即使表面上与过去相似，也可能有完全不同的协调成本。

在稳定迭代期，我建议每周期复盘：

1. 计划工时与实际工时的偏差。
2. 偏差来自估算错误、等待、返工还是临时插入。
3. 哪些任务可以形成模板或自动化流程。
4. 哪些关键能力持续成为瓶颈。

3. 高峰交付期：提高缓冲，而不是把每个人排到100%

版本发布、重大客户上线或年度结算前，团队往往会进入高峰期。很多负责人会把所有人力排到100%，认为这是特殊时期的正常做法。我的判断是，高峰期更应该提高风险缓冲，因为外部问题和沟通量通常会同步上升。

如果平时产品经理每周可承诺32小时，高峰期可以增加到36小时，但不建议长期超过40小时。剩余时间应保留给线上问题、客户反馈、发布验证和决策等待。

高峰期还要明确“停止做什么”。没有停止清单，新增需求会不断侵入计划，最终所有任务都变成最高优先级。

4. 故障频发期：先修复系统性损耗，再补人

如果团队每周都被线上问题打断，直接增加产品经理人数往往效果有限。新加入的人同样会被故障、紧急沟通和历史债务拖住。

我会先做四项检查：

• 线上问题是否有统一分级和责任边界。
• 是否存在重复录入、重复确认和重复汇报。
• 发布前验证是否缺少固定清单。
• 产品经理是否被迫承担本应由支持或运营承担的工作。

只有确认问题主要来自绝对人手不足，才适合增加人员。否则，补人可能只是扩大低效系统的规模。

六、工具落地与管理机制：怎样让计划真正被执行

1. 先统一字段，再选择工具

很多组织购买项目管理软件后，第一件事是建立大量字段，最后没人愿意维护。可用工时管理不需要一开始就做得很复杂，至少统一以下字段即可：

• 项目和业务线。
• 周期或迭代。
• 工作类型。
• 负责人和协作人。
• 计划工时与实际工时。
• 状态和阻塞原因。
• 技能要求与优先级。

以PingCode为例，如果组织已经使用其项目、迭代和工作项管理能力，可以进一步建立成员可用容量和跨项目资源视图。但我不建议把所有会议、聊天和临时沟通都强制拆成工时任务，否则记录成本会迅速超过管理收益。

2. 建立“计划，执行，复盘”闭环

可用工时管理最怕只做计划、不做回收。计划数据如果没有进入执行，实际数据如果没有进入复盘，最后就会变成一张漂亮但无效的表。

一个可执行的闭环包括：

1. 计划：按周期确认人员容量、能力匹配和任务承诺。
2. 执行：实时记录阻塞、临时插入和关键变更。
3. 校准：每周检查容量消耗和剩余承诺。
4. 复盘：分析偏差原因，不只追问谁延期。
5. 改进：调整估算基线、流程、角色边界或人员配置。

复盘时不要只问“为什么用了这么多时间”，还要问“这部分工作是否本来就应该由这个角色承担”。这是区分工时优化和组织设计优化的关键。

3. 用三种视图服务三类管理者

不同角色需要看到不同信息。产品经理关注自己本周期能承诺什么，项目负责人关注里程碑是否有资源，管理层关注哪些能力是系统瓶颈。把所有人塞进同一张资源表，通常会造成信息过载。

4. 设定数据质量规则，防止工时失真

工具上线后，最常见的问题不是没人填，而是大家填得不一致。有人把沟通记为需求分析，有人把等待时间完全忽略，还有人为了完成率直接修改计划工时。

我建议设置简单的数据质量规则：

• 计划工时在任务开始前确认，不能事后随意修改。
• 实际工时按工作类型归类，临时事务不得隐藏在正常任务中。
• 阻塞超过半个工作日必须记录原因和责任方。
• 周期结束后冻结数据，避免复盘时反复改数。
• 不把工时记录用于简单的个人绩效排名。

最后一点尤其重要。如果员工认为工时数据会直接决定绩效，他们会倾向于填报“看起来合理”的数字，而不是反映真实情况。管理者需要把工时数据首先用于改善计划质量，而不是制造新的考核压力。

七、不同方案的取舍：什么时候该加人，什么时候该砍范围

1. 加人、延期、砍范围，三种选择没有绝对优劣

当可用工时不足时，管理者通常有三种选择：增加人员、延长周期、缩减范围。正确答案取决于约束条件，而不是哪种方式看起来更积极。

我通常不会在项目中途直接增加一名完全陌生的产品经理。产品工作存在较高领域知识成本，加入人员后可能先消耗原成员的培训时间。除非任务可以清晰拆分，或者新增人员具备高度匹配的经验，否则砍掉低价值范围往往更快。

2. 用“边际收益”决定是否投入更多人力

增加一个人不一定增加一个人的产能。项目越接近尾声，新增人员的边际收益可能越低；项目越依赖单一决策人，增加普通执行人员也无法解决瓶颈。

我会问三个问题：

• 新增人员能否在当前周期内独立承担完整工作包？
• 是否存在足够明确的接口，避免增加沟通成本？
• 真正的瓶颈是工作量，还是决策权、领域知识和外部依赖？

如果答案是否定的，优先考虑缩减范围、调整优先级或移除依赖，而不是机械加人。

3. 对关键人员要保留不可替代性预算

很多人力计划把关键人员当作普通容量使用，直到他请假、转岗或同时被三个项目需要时，组织才发现没有替代方案。

我建议对关键人员设置不可替代性预算：

• 限制其同时承担的关键项目数量。
• 为核心业务规则安排第二负责人。
• 把关键决策、业务知识和历史背景沉淀到可检索文档。
• 在周期内保留一定时间用于辅导和知识转移。

这部分时间短期看没有直接交付，但它能降低单点故障。对于企业级产品，关键人员的知识转移往往比再招一名普通执行人员更有长期价值。

八、常见问题：可用工时计划中最容易卡住的细节

1. 可用工时应该按8小时工作日计算吗？

不建议直接按8小时计算。8小时是名义工作日长度，不是产品经理可以连续用于项目交付的时间。应先扣除固定会议、管理事务、沟通、休假、培训和合理缓冲。

如果没有历史数据，可以先按每天5.5至6.5小时作为基础可计划时间，再根据团队实际复盘调整。稳定交付团队可能接近6小时，高度协同或故障频发团队可能低于5小时。

2. 会议时间到底算不算可用工时？

算，但要按会议类型记录。需求评审、用户访谈和方案决策属于产品工作，应计入对应工作类型；重复汇报和无明确目标的信息会议，虽然占用时间，也应单独记录为事务损耗，便于后续优化。

3. 实际工时和计划工时偏差多大算异常？

不能只看一个固定阈值。对于确定性任务，偏差超过20%就值得复盘；对于探索性任务，偏差超过30%并不一定异常，但需要检查是否已经获得了新的信息。

比偏差大小更重要的是偏差方向。如果某类任务连续三个周期都低估，说明估算基线有系统性问题；如果偏差来源始终是等待某个部门，则应优化依赖机制，而不是要求产品经理估得更保守。

4. 产品经理同时负责多个项目，怎样计算容量？

先按项目分配明确小时，再检查每周是否存在连续深度工作时间。不要只填“项目A 40%、项目B 30%、项目C 30%”，而要写成“项目A每周16小时、项目B每周12小时、项目C每周8小时”，并明确项目优先级和冲突处理规则。

如果三个项目都要求同一周完成关键决策，那么总工时没有超标也可能无法执行。跨项目冲突不仅是数量问题，也是时间分布问题。

5. 可不可以用工时数据评价个人绩效？

不建议直接用工时长评价个人绩效。工时长可能意味着任务复杂，也可能意味着流程低效；工时短可能意味着能力强，也可能意味着记录不完整。

工时数据更适合用于评价计划质量、流程效率、资源配置和团队负载。个人绩效应结合目标完成、决策质量、问题解决、协作反馈和业务结果综合判断。

6. 什么时候应该使用某项目管理平台？

当组织出现跨项目资源冲突、负责人重复分配、计划数据分散、工时无法复盘或管理层无法看到整体容量时，就值得使用统一平台。对于100人以上、项目数量较多的企业，PingCode这类平台可以减少多套表格和手工汇总，让项目、工作项、成员容量和迭代执行形成关联。

但如果团队只有几个人、项目单一且沟通半径很小，先用结构清晰的共享表格和固定复盘机制也可以。工具的价值取决于组织复杂度，不是团队规模越小越需要复杂系统。

7. 如果员工不愿意记录实际工时怎么办？

先检查记录是否过于细碎，以及数据是否被用于惩罚性考核。把记录粒度控制在工作类型和任务层级，通常比要求每15分钟填报更容易坚持。

同时要让团队看到记录的回报：减少无效会议、保护深度工作时间、纠正不合理排期、解决重复沟通。如果记录只增加了管理工作，却没有改善计划，员工自然会把它视为负担。

九、最后的执行清单：用两周建立一套可用模型

1. 第一周：建立事实基线

第一周不要急着追求精确。先收集过去一个周期的项目、人员、会议、临时需求、线上问题和实际投入，得到一个未经修饰的工作结构。

1. 列出所有产品经理和当前项目。
2. 标记每个人的业务能力与关键依赖。
3. 统计固定会议和临时事务的时间。
4. 区分计划工时、实际工时和等待时间。
5. 找出被多个项目重复使用的关键人员。

这一步的目标不是证明谁做得不好，而是找到容量损耗的来源。若没有事实基线，后续所有比例都只是管理者的主观印象。

2. 第二周：建立容量规则

第二周开始制定规则，不要一开始就把所有复杂情况写进制度。先确定基础工作日、固定事务比例、风险缓冲、技能匹配和项目优先级。

可以先采用以下默认规则作为起点：

• 按周管理，按月汇总。
• 每人每周只承诺可计划容量的70%至80%。
• 同一关键产品经理原则上不超过两个核心项目。
• 探索性任务使用时间盒，不做虚假精确估算。
• 临时插入工作必须记录原因。
• 连续两个周期发生同类偏差后，必须调整基线或流程。

这些不是固定真理，而是为了帮助团队开始积累可比较的数据。运行四到六个周期后，再根据真实偏差调整比例。

3. 每个周期都问三个问题

第一，哪些工作消耗了计划外容量？第二，哪些能力是当前项目真正的瓶颈？第三，如果下个周期只能保留一半工作，哪些事项仍然值得承诺？

第三个问题很重要。真正成熟的人力资源计划，不是想办法把所有需求都塞进容量，而是让组织在容量有限时能够明确放弃什么。

我的最终判断是：可用工时管理的核心，不是把每个人切割成更多可计量的小时，而是让组织看清有限人力应该被谁、在什么时间、以什么能力、为哪个结果使用。如果你准备开始改进，下一步不要先购买工具，也不要先要求员工填更多表格。先拿过去一个周期的数据，算出名义工时与有效工时的差距；再选一个项目建立周度容量视图；最后用三到四个周期验证计划偏差和临时插入率是否下降。只有当规则、数据和决策真正连起来，可用工时才会从一张资源表变成产品团队的交付能力。