资源负载如何做好产能？产品经理协同管理与操作步骤

上个月，一个做企业服务的产品负责人拿着他们的迭代看板来问我：“我们 14 个研发，负载率常年 80% 以上，为什么每个版本还是要延期三到五天？”我翻了一眼他们的看板，14 个人身上挂了 47 个进行中的任务，平均每人 3.4 条并行线，其中 9 个任务已经超过 5 天没有状态变更。这不是产能不足，这是产能被切碎了。这件事让我确定了一个判断：大多数团队算不清产能，不是因为不会算，而是因为算的是“人有多忙”，而不是“活能不能流出去”。

这篇文章我想把资源负载到真实产能的换算讲透，包括产品经理在中间到底该抓哪几个动作、哪些做法看起来专业其实有害、以及在 PingCode 这类平台里落到操作层面具体怎么做。

一、先给结论：产能不是算出来的，是被协同“让”出来的

如果只允许我留一句话给正在做资源规划的产品经理，那就是：产能不是把所有人力加总，而是把人力在一段时间里真正能变成“可交付物”的那一部分提取出来。这两者之间的差额，通常占名义工时的 35% 到 50%，而且这个差额里绝大部分不是“摸鱼”，是协同损耗，等待、切换、返工、对齐、上下文重建。

1. 负载率回答“忙不忙”，产能回答“能不能交”

这两个指标在会议桌上经常被混用，但它们的数学含义完全不同。负载率的分母是可用工时，分子是被分配的工时，它是一个“占用度”指标；产能的分母是时间窗口，分子是这段时间内真正完成并交接出去的可交付物数量，它是一个“吞吐”指标。

一个团队完全可以做到负载率 90%、产能只有理论值的 55%。因为负载率只看“有没有被分配活”，不看“这些活之间是否互相打架”。我在做诊断时习惯问一个问题：你们这周有多少人，是因为在等一个评审、等一个接口、等一句确认而停在那里的？大部分团队答不上来，因为他们的工具里根本没有“阻塞时长”这个字段。

2. 有效产能的四个乘数

我把有效产能拆成四个连续的折扣项，这也是我后面所有判断逻辑的基础：

有效产能（人天）＝ 名义工时 × 可用率 × 协同效率 × 交接完整率

• 可用率：名义工作日里，真正能投入主线工作的时间比例。要扣掉假期、会议、线上支持、面试、培训、行政事务。
• 协同效率：并行和协作带来的效率折损。一个人同时挂 1 条线时接近 1.0，挂 3 条线时普遍掉到 0.65 到 0.7。
• 交接完整率：需求、设计、接口、验收标准交接时信息缺失导致的返工比例。这个乘数最容易被忽略，却常常是最大的漏口。

举个具体数字：一个 12 人的研发小组，4 周名义工时 240 人天。扣掉假期与会议后可用 187 人天（可用率 78%），扣掉并行切换损耗后 153 人天（协同效率 82%），扣掉返工与等待后只剩 135 人天（交接完整率 88%）。名义 240 人天，有效产能 135 人天，占比 56%。这就是为什么“14 个人干 4 周”排出来的计划总是完不成，排计划的人用的是 240，干活的人手里只有 135。

3. 产品经理真正能撬动的三根杠杆

资源负载这件事，表面上是研发经理的排班问题，实际上是产品经理的输入管理问题。因为负载的“形状”是产品经理决定的：需求以什么节奏进来、同时开几条线、每条线的验收标准写得多清楚。

我把它归成三根杠杆，按干预收益从高到低排：

1. 需求进入节奏：是把 15 个需求一次性塞进迭代，还是分成 3 批、每批 5 个。前者会造成前期过载、后期空转。
2. 并行度：一个后端同时支撑 4 条业务线，和同时支撑 2 条，产出差距不是 2 倍，可能是 1.4 倍。
3. 交接颗粒度：验收标准写到“支持导出”还是写到“导出字段、格式、条数上限、异常提示文案”，直接决定返工率。

这三根杠杆的共同点是：它们都不增加人力，但都能改变有效产能。这也是我一直认为产品经理应该深度参与产能管理的原因，不是因为要管人，而是因为你是需求侧唯一的调速阀。

4. 产能管理的最小闭环：可视、限额、承诺、复盘

很多团队一上来就想做“资源负载均衡”，做得很复杂，最后没人看。我建议从最小闭环开始，四步，缺一不可：

• 可视：每个人手上现在有几条在制任务、每条卡了多久，一眼能看到。
• 限额：给并行度设上限，超了就排队，不允许“先接着再说”。
• 承诺：迭代承诺量不超过有效产能的 80%，剩下的做缓冲。
• 复盘：每个迭代结束对比“承诺 vs 交付”，校准下一轮的人天口径。

这四步的价值在于形成校准回路。没有复盘的人天估算，本质上是一次性的猜测；有复盘的人天估算，才会逐渐变成团队的私有基准。我见过做得最好的团队，他们的“1 人天”是有明确内部定义的，6 小时有效编码时间，不含评审和自测，这个定义写在新人手册第一页。

二、真实场景：产能是怎么一步步塌掉的

抽象地讲产能公式意义不大，我更想还原三个我实际参与过的场景。这三个场景来自不同规模的组织，但塌方路径惊人地相似：先是不觉得有问题，然后是局部过载，最后是系统性排队。

1. 场景一：需求池看起来很空，交付总在第 8 周爆掉

第一个是一个 120 人规模的研发组织，做的是行业解决方案。他们的需求池常年保持 60 到 80 个“待排期”需求，产品经理每周评审一次，评审通过就往下派。

问题出在节奏上。需求进入是脉冲式的，交付是线性的。每个季度初，销售和客户成功会集中提一批需求，产品经理为了“响应业务”，一周内能通过 20 多个需求进入开发；然后接下来两三周进入“消化期”，团队拼命赶；到第 8 周左右，早期需求的技术债和返工集中爆发，同时销售又提了新一批，团队彻底排队。

我用他们 12 周的数据做了一次还原：需求进入量在第 1 周和第 9 周各有一个峰值，分别是 23 个和 19 个，而在制品数从第 3 周开始就超过 40，平均周期从 11 天涨到 26 天。吞吐量并没有提升，只是把东西堆在了管道里。这是典型的利特尔法则在起作用：在制品越多，平均周期越长，而吞吐只取决于出口能力。

2. 场景二：负载率 85%，有效产能只有 52%

第二个场景是一家做 SaaS 的公司，60 人研发，分了 5 条产品线。他们的资源表非常“漂亮”，每个人负载率都在 80% 到 90% 之间，看起来饱和得很健康。

但我让他们做了一个实验：连续两周，每人每天下班前记录“今天有多少小时是花在主线任务上的”。结果平均值是 4.1 小时/天，占 8 小时工作制的 51%。剩下的时间去了哪里？跨线协作的会议、给别的线答疑、被临时拉去救火、以及最耗人的，切换后重新进入状态的时间。

注意，这些人不是不忙。他们非常忙，只是忙的内容无法沉淀成可交付物。这就是我前面说的“负载率 90%、产能 55%”的真实版本。而且这种状态有个恶性循环：负载率越高，切换越频繁，切换越频繁，有效产能越低，于是团队觉得“人不够”，要求加人，加人后又增加沟通成本。

3. 场景三：产品经理变成人肉调度台

第三个场景是我见过最典型的组织病。一家 300 人规模的公司，没有统一的资源视图，各条线的排期在自己的表格里。于是每天上午，产品经理的工位会排队：测试问“这个需求什么时候能提测”，销售问“客户那个功能排到哪了”，研发问“我手上的 A 和 B 哪个优先”。

产品经理成了唯一的调度中心，而这个调度中心的带宽是有限的。当一个人的日程里有 40% 用于回答“现在什么情况”，他就不再是产品经理，而是人肉看板。更麻烦的是，这种模式下所有决策都依赖他的记忆，一旦他休假，整个组织的优先级判断就失序。

4. 为什么产能问题最后会落到产品经理头上

很多产品经理觉得委屈：产能是研发经理的事，为什么追到我这里？我的判断是，这不是责任转移，而是因为产品经理掌握着唯一能改变产能形状的输入。

研发经理能优化的是“怎么干得更快”，这有物理上限；产品经理能优化的是“干什么、什么时候干、一次干几件”，这个空间大得多。前面三个场景的解法，没有一个是靠加人解决的，全是靠改输入节奏、压并行度、提高交接颗粒度解决的，这三件事的主导权都在产品侧。

三、五个常见误区：看起来很专业，其实在制造假产能

下面这五个误区，我在不同公司反复见到。它们的共同特征是：做的时候很有安全感，做完了数据很好看，但实际交付没有任何改善。

1. 误区一：把人天加起来就是产能

这是最普遍的一个。做法是把团队人数乘以工作日，得到一个数字，然后往里塞需求，塞满为止。这个算法的问题不是不精确，而是方向错了，它假设人是同质的、时间是连续的、切换是免费的，这三个假设在知识型工作里全都不成立。

更隐蔽的问题是，一旦用了这个算法，团队就会开始“保护”这个数字。因为账面产能是满的，任何一个人请假都成了“产能缺口”，于是实际交付延期时，理由永远是“有人休假”“有人被借调”。用一个错误的基准去解释偏差，永远解释得通，也永远学不到东西。

2. 误区二：负载率越高越好

很多管理者把负载率当成效率指标，看到 70% 就焦虑，看到 95% 就满意。但如果把负载率和交付准时率画在一张散点图上，你会看到一条明显的倒 U 型曲线。

我整理了手上 6 个团队、共 38 个迭代的数据（示意性样本，用于说明趋势而非统计结论）：负载率在 65% 到 80% 区间时，迭代准时率最高，中位数 86%；负载率超过 90% 后，准时率跌到 62%，同时缺陷密度上升约 40%。因为高负载吃掉的正是应对意外的那部分缓冲，而知识型工作里意外是常态，不是例外。

3. 误区三：用甘特图排产能

甘特图是表达依赖关系的优秀工具，但它是时间轴工具，不是容量工具。它告诉你看得见“A 要在 B 之后”，但看不见“小张这周已经被排了 6.5 天”。

我见过太多团队用甘特图排满 8 周，图上每个条形都严丝合缝，一执行就崩。原因是甘特图默认资源无限，它不会在你把第 4 个任务拖到同一个人身上时提醒你“这个人已经超载了”。用甘特图做产能规划，等于用地图导航但不看路况。

正确的分工是：依赖关系用甘特图或时间线表达，容量约束用负载表或资源视图表达，两者必须互相校验。这也是为什么一体化平台在这件事上有天然优势，同一份任务数据，既能出时间线，也能出负载视图，不需要人工同步两份表。

4. 误区四：产能不足就加人

加人是所有方案里最贵、见效最慢、副作用最大的一个，但往往是最先被想起来的。原因很简单：它不需要改变任何现有流程，只需要增加预算，而预算审批的痛苦远小于流程变革的痛苦。

但是新人加入的产能曲线不是从 1 开始的，而是从负数开始。前 2 到 4 周是纯消耗（环境搭建、业务学习、代码规范熟悉），第 5 到 10 周才是缓慢转正，通常到第 3 个月才能达到团队平均产出的 60% 到 70%。而且这段时间老员工要分出 15% 到 25% 的时间带人，所以加人后的第一个月，团队总产能往往是下降的。

把它做成一张曲线更直观：一个 10 人团队在第 0 周加入 3 人，第 1 到 4 周团队有效产能从 10 降到 9.4 左右，第 8 周回到 11，第 16 周才到 12.2。也就是说，如果你需要的是 6 周内交付，加人解决不了问题；如果你需要的是半年后的产能，加人才是对的答案。

5. 误区五：把“排期”当成“承诺”

这个误区最伤产品经理的信誉。排期是一个基于当前信息的最好估计，承诺是一个对外保证。两者的差别在于：估计可以随信息更新而调整，承诺不行。

很多团队的做法是，把排期表直接发给业务方，于是排期自动变成了承诺。一旦后续有任何变动，产品经理就要花大量时间解释，久而久之大家学会了一个坏习惯，排期时故意留冗余，反正会被追问，不如先报松一点。这样做的结果是，整个组织的排期数据都失真了，产能管理失去了基准。

我的做法是把两者显式分开：内部排期按有效产能的 100% 排，对外承诺只报 80%，剩下的 20% 用来吸收插单和意外。并且明确告诉业务方那是承诺值，不是估计值。承诺值做到率 90% 以上，比估计值精确到天更有价值。

四、专业判断逻辑：从资源负载到有效产能的四层换算

这一节是方法论的核心。我把它设计成四层递减的换算，每一层都有一个明确的扣除项和一个可观测的指标。你不用一次做到完美，但四层都要走一遍，因为漏掉任何一层，算出来的数都会系统性偏高。

1. 第一层：名义工时 → 可用工时

名义工时是最容易算也最容易骗人的。一个人一个月 21 个工作日，就是 21 人天，这一步没什么好讨论的。真正要动手的是从名义工时里扣掉刚性占用。

我把刚性占用分成四类，建议按季度校准一次：

• 制度性占用：法定假期、年假、调休，按历史使用率折算，不要按额度折算。
• 例行性占用：周会、站会、评审会、汇报，通常占 10% 到 18%。
• 支持性占用：线上问题处理、客户答疑、内部咨询，通常占 8% 到 15%，波动最大。
• 组织性占用：面试、培训、团建、行政，通常占 3% 到 6%。

这四项加起来，用 8 小时工作制折算的话，可用率通常在 72% 到 82% 之间。如果你算出来的可用率高于 85%，基本可以确定有一类占用被漏掉了，最常见的是支持性占用，因为它不在任何日历上。

2. 第二层：可用工时 → 可分配工时（扣协同税）

第二层扣的是“协同税”，也就是为了让协作发生而必须付出的成本：需求对齐、接口联调、方案讨论、代码评审、跨团队同步。这些时间不是浪费，它们是复杂工作的必要开销，但它们不能用来产出可交付物。

协同税的大小和团队结构强相关。一个 5 人全栈小队，协同税可能在 10% 左右；一个 100 人、跨 4 个职能的组织，协同税轻松到 25%。这里有个容易被忽略的规律：协同成本随人数近似平方增长，而产出是线性增长。这就是为什么大组织的“人均产能”天然低于小团队，这不是管理不善，是结构成本。

我在做诊断时常用的一个观测口径是“会议密度”：每人每周花在会议上的小时数除以总工作小时数。超过 25% 的团队，协同税一定偏高，而且他们的产能问题往往不是排期问题，是组织设计问题。

3. 第三层：可分配工时 → 有效产能（乘并行效率系数）

第三层是并行效率。这是整个换算里最被低估的一环，也是最容易通过管理动作改善的一环。

我用的经验系数（基于多个团队的观察，属于经验基准而非精确统计）：

注意这张表的用法：它不是让你去精算，而是让你有一个说服工具。当一个业务方要求“这个人顺便支持一下”时，你可以给出具体数字：从 2 条线加到 3 条线，这个人的有效产出会掉 20%，等于凭空拿走 0.2 个人。把并行成本显性化，比讲道理有效得多。

4. 第四层：有效产能 → 可承诺产能（留缓冲）

最后一层是留缓冲。很多人觉得留缓冲是“不自信”，我的看法相反：不留缓冲的承诺才是对交付不负责任，因为它把所有的意外都转嫁给了执行者。

我建议的缓冲结构是三层：

1. 迭代缓冲（15%）：吸收迭代内的插单和小范围返工。
2. 版本缓冲（10%）：吸收跨迭代的依赖延迟和联调问题。
3. 战略缓冲（5%）：留给突发的客户问题或竞争响应。

三层加起来，可承诺产能大约是有效产能的 70% 到 75%。这个数字看起来偏保守，但实测下来，能做到这个承诺率的团队，业务方的满意度远高于那些承诺 95% 但经常延期的团队。产能管理的目标不是把数字用满，而是让承诺可信。

如果要把这套换算固化成可执行的口径，可以写成一份简单的配置：

capacity:
nominal_days: 21 # 每人每月名义工作日

availability_rate: 0.78 # 可用率（扣制度/例行/支持/组织占用）

collaboration_tax: 0.18 # 协同税（会议、评审、联调、对齐）

parallel_factor: 0.70 # 并行效率（当前平均 3 条线）

handover_integrity: 0.88 # 交接完整率（返工折算）

iteration_buffer: 0.15 # 迭代缓冲

release_buffer: 0.10 # 版本缓冲

strategic_buffer: 0.05 # 战略缓冲

可承诺人天 = nominal_days × availability × (1-tax) × parallel × handover × (1-buffers)

按这组参数，一个 10 人团队每月的可承诺产能是 10 × 21 × 0.78 × 0.82 × 0.70 × 0.88 × 0.70 ≈ 57.9 人天。而按名义工时算是 210 人天，两者差了 3.6 倍。这个差距就是为什么“账面上人很多，实际什么都排不进去”。

5. 三个预警阈值和一条不可越过的红线

换算之外，还需要一组可以每天看的阈值。我的建议是三个预警加一条红线：

• 黄色预警：个人负载率超过 85%。触发动作不是立刻减活，而是检查这个人的在制任务数是否超过 2 条。
• 橙色预警：平均并行度达到 3 条线。触发动作是冻结新需求进入，先把在制清到 2 条以下。
• 红色预警：单个任务阻塞超过 48 小时。触发动作是当日升级到产品经理和研发负责人，阻塞必须有人负责解除。
• 红线：任何一个关键模块只有一个人能改。这是产能的隐性单点，一旦这个人请假或离职，整条线的产能归零。红线的处理方式不是预警，是必须在季度内消除。

这套阈值的好处是可操作。“负载率 85%”这种数字，团队看一眼负载表就知道要不要动作；“产能不足”这种判断，只会引发争论。

五、案例与数据观察：一个 300 人研发组织的产能改造

这一节我用一个真实的改造过程来说明前面的方法怎么落地。出于保密要求，客户名称隐去，规模和数据做了区间化处理，但路径和关键动作是原样的。这个组织的背景是：约 300 人研发，分 4 条产品线，使用 PingCode 作为研发协作平台，已经运行了一年多，但主要用需求管理和缺陷管理，工时和负载视图基本没人看。

1. 改造前的基线：数据齐全，但没人相信

他们最初的问题不是没有数据，而是数据不可信。同一个需求，产品经理估 5 人天，开发估 12 人天，实际做了 9 人天，三个数字都记在不同地方。工时填报率只有 43%，而且集中在迭代末期补填。

我让他们先做了一次基线测量，用 4 周时间，不改变任何流程，只记录三个数：在制任务数、任务平均阻塞时长、迭代承诺兑现率。结果是这样的：

这组数字说明了问题所在：并行度 3.4 条、阻塞 3.8 天、返工 23%，三个指标互相喂养。并行导致阻塞，阻塞导致上下文丢失，上下文丢失导致返工，返工又加剧并行。这不是产能不足，是产能内耗。

2. 第一步：把“人天”的口径统一到一个定义上

改造的第一个动作不是上工具，是定口径。我们开了一次两小时的会，只做一件事：确定“1 人天”等于多少有效工作时间。最后定的是 6 小时，不含会议、不含答疑、不含自测。

然后我把这个口径写进了他们的估算模板，并且规定所有估算必须用“人天 + 不确定性”两个字段，不确定性分三档：确定（误差 ±20%）、一般（±50%）、探索（无法估计，需要先做技术预研）。

这一步看起来琐碎，但它解决了一个根本问题：在此之前，他们所有的产能讨论都建立在不同的度量单位上，争论的本质是单位不一致，而不是判断不一致。口径统一后，很多争论自动消失了。

3. 第二步：用负载视图把并行度压到 2 条以内

口径统一后，才轮到工具。他们在 PingCode 里把工时估算、迭代规划和负载视图串起来用：需求估算的人天直接进入迭代容量计算，负载视图按人聚合当期的在制任务和剩余工时，超载会以颜色标出。

关键动作是设 WIP 限额：每人同时进行的任务不超过 2 条，超出部分必须回到待办，不允许“先接着”。这条规则在推行的前两周引发了大量冲突，因为业务方习惯了“先答应下来”。产品负责人的做法很聪明：他没有强推，而是把负载视图投在周会上，让所有人看到，当某人挂到第 4 条任务时，他前两条任务的剩余工时在一周内几乎没动。

数据比规定有说服力。三周后，团队自己接受了限额，因为大家发现并行度降下来后，每周真正完成的任务数反而上升了。

4. 第三步：把产能写进迭代承诺，而不是写进排期表

第三步是把可承诺产能这个概念落到迭代里。他们的做法是：每个迭代开始前，先算有效产能，再乘 0.8 得到可承诺量，然后只按这个量接需求，多出来的进候选池。

这里有个细节值得说。他们一开始用的是 0.9 的系数，结果第一个迭代就溢出了，因为缓冲不够吸收插单。改成 0.8 之后稳定了三个迭代，再逐步提到 0.82。这个过程本身就是校准：承诺系数不是拍出来的，是用两三个迭代的实际兑现率反推出来的。

同时他们做了需求分档，把产能按比例分配：

• A 类（核心功能与收入直接相关）：占 60% 产能，必须完成，不允许被挤占。
• B 类（体验优化与效率提升）：占 25% 产能，可延后一个迭代。
• C 类（技术债与架构治理）：占 10% 产能，不可挪用，这是长期产能的投入。
• D 类（临时插单与客户救火）：占 5% 产能，超出部分从 B 类扣。

这个分配最有价值的地方是 C 类的 10% 固定配额。在此之前，技术债永远排在最后，永远被业务需求挤掉，导致返工率居高不下。把技术债做成有预算的产能项，而不是“有空再做”，是唯一有效的治理方式。

5. 第四步：用数据反哺需求排序

最后一层是让产能数据反向影响需求决策。改造进行到第 10 周左右，产品负责人发现了一个规律：在 4 条产品线里，B 线的需求平均人天是 A 线的 2.3 倍，但带来的收入贡献只有 A 线的 0.6 倍。这个发现直接导致 B 线的一个大版本被砍掉，产能重新分配到 A 线。

这件事的意义在于：产能管理最终不是一个效率问题，而是一个资源分配问题。当你能准确知道每条线消耗多少产能、产生多少价值时，砍需求就从“政治博弈”变成了“数据讨论”。这也是为什么我一直认为产品经理必须啃下产能这块硬骨头，它是你做优先级决策时唯一的硬约束。

6. 12 周后的结果，以及被隐藏的代价

12 周后的数据对比：

最后一行是我特意加上的，因为几乎所有讲产能改善的文章都会略过这个代价。吞吐量下降 8%，原因是 WIP 限额让一些小需求不再“顺手做掉”，而是必须排队。这就是真实的取舍：你换来了准时率和质量，代价是绝对数量的略微下降。

这个代价值不值？我认为值，而且要提前跟业务方讲清楚。因为交付周期缩短 37% 带来的业务价值（更早拿到反馈、更少的需求过期）通常远大于吞吐量下降 8% 的损失。但如果不说清楚，第 13 周就会有人拿着“需求完成数量下降”的报表来质疑整个改造。主动暴露代价，是产能改造能活下去的前提。

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

同一套方法，在 20 人团队和 300 人组织里的落法完全不同。下面按规模和结构分五种情况给建议，你可以直接对号入座。

1. 20 人以下小团队：一张表就够了，别上系统

这个规模最大的风险是过度管理。上平台、建流程、设角色，成本比收益高。我的建议是：

• 用一张表管理，字段只要六个：任务、负责人、人天估算、状态、开始日期、阻塞原因。
• 每周一次 30 分钟的产能会，只看两件事：谁手上超过 2 条任务、哪些任务卡了超过 2 天。
• 承诺系数先用 0.8，跑三个迭代再校准。
• 不要求工时填报，只要求任务状态更新，因为在这个规模下，填工时的成本高于它带来的信息价值。

这个阶段的关键是建立“先看负载再派活”的肌肉记忆，而不是建立一套精密的体系。

2. 100 到 300 人单产品线：需要平台，但更需要模板

到了这个规模，表格会失效，因为信息分散在多个人手里，无法聚合。这时候需要平台承载，比如用 PingCode 把需求、迭代、工时、负载打通，让同一份数据既能出排期也能出负载视图。

但平台不是重点，模板才是。我建议在这个阶段把三样东西模板化：

1. 需求模板：强制包含验收标准、边界条件、依赖说明，缺一不许进入评审。
2. 估算模板：人天 + 不确定性档位 + 估算依据。
3. 迭代复盘模板：承诺量、交付量、阻塞时长、返工占比四项，固定对比。

模板的作用是降低协同税。100 人以上的组织，最大的产能杀手不是人不够，是每次都要重新对齐“这件事该给什么信息”。

3. 300 人以上多产品线：必须做组合管理

这个规模下，单条线的产能优化已经没有意义了，因为瓶颈在跨线调度。你需要的是组合层面的容量评审：

• 建立统一的产能池，而不是每条线各自算。
• 每季度做一次产能分配评审，把产能当作预算分给各条线，分完就锁定。
• 设一个跨线的调度角色（通常是产品负责人或 PMO），只有他能调整分配。
• 共享资源（架构、前端基建、测试平台）单独设配额，不参与各线竞争，否则永远被抢。

这个阶段最常见的失败模式是“名义上统一，实际上各线自己抢人”。判断标准很简单：如果两条线能在同一周各自把一个共享资源排满，你就没有真正的容量管理。

4. 外包与自有混合团队：产能要契约化

混合团队的产能管理难点在于：外包的产能不可观测，自有团队的产能被协调工作吃掉。我的建议是把产能写成契约：

• 外包按“可交付物 + 验收标准”计，不按人天计，避免人天注水。
• 自有团队预留 15% 到 20% 的产能用于需求澄清和验收，这部分不进交付承诺。
• 接口和边界在合同或协议里写清楚，减少返工型对接。
• 每周做一次交付物验收，不要攒到月底，否则问题会集中爆发。

5. 已经在用平台但数据不靠谱：先治口径，别换工具

这是最常见的情况。很多团队发现问题后的第一反应是换工具，但换了之后数据还是烂，因为问题不在工具，在口径和习惯。

治理顺序我建议这样：

1. 先定口径：1 人天等于多少小时、任务完成的标准是什么、什么算阻塞。
2. 再减字段：把必填字段砍到 5 个以内，字段越多填报率越低。
3. 然后建反馈：每周把负载视图和数据质量投在同一个会上，让填得准的人被看见。
4. 最后才谈分析：数据准确率到 85% 之前，不要做任何预测和报表。

数据治理的本质是让人愿意填，而不是让人不得不填。前者靠价值反馈，后者只能得到应付式的假数据。

七、不同情况下的取舍：没有全都要，只有换什么

产能管理的每一个决定都是交换。这一节我把五组最常见的取舍摊开讲，每组都给出适用条件，因为“哪个更好”这个问题本身没有答案。

1. 精度 vs 维护成本

你可以把产能算到 0.5 人天的精度，代价是每天要花 20 分钟维护数据；你也可以只算到“人周”级别，代价是排期误差大。这个取舍的判断标准是变更成本：

• 如果需求变更频繁（每周超过 20% 的排期会被调整），高精度的投入是浪费，因为算得再准也会被推翻。这时候选粗粒度。
• 如果交付承诺涉及合同违约金或对外发布节奏，必须高精度，因为误差的代价远高于维护成本。

我个人的经验阈值是：团队规模超过 50 人，或者单次交付涉及对外承诺，才值得做到人天级精度；否则人周级足够。

2. 缓冲 vs 承诺

缓冲留得多，承诺可信度高，但账面产能利用率低，容易被质疑“人效不足”；缓冲留得少，利用率好看，但承诺频繁失守，信任成本高。

这里有个容易被忽略的事实：缓冲的代价是可量化的，承诺失守的代价是不可量化的。缓冲 20% 意味着账面少 20% 的产出，这是能算出来的；而承诺失守导致业务方不敢规划、销售不敢报价、客户不敢续约，这些损失算不出来，但通常更大。

所以我的倾向是：对外承诺相关的一律留足缓冲（20% 到 25%），内部探索型项目可以压到 10%。

3. 集中调度 vs 团队自治

集中调度能让资源在全局最优分配，但响应慢、容易成为瓶颈；团队自治响应快、责任感强，但容易出现资源孤岛和重复建设。

我的实践判断是：300 人以下优先自治，300 人以上必须有一部分集中调度，但集中调度的范围应该限定在共享资源和跨线冲突上，不要把所有排期都收上来。

4. 平台化 vs 表格化

平台化的价值在于数据自动聚合，代价是流程刚性和学习成本；表格化的价值在于灵活，代价是无法聚合、无法追溯。

判断标准不是团队规模，而是信息是否需要跨人聚合。如果产能决策需要综合 5 个以上人的实时状态，表格一定会失效，因为更新永远滞后；如果决策只涉及 3 个人，表格反而更快。

5. 短期吞吐 vs 长期产能

这是最重要的一组取舍。把技术债治理、自动化测试、文档建设的产能砍掉，短期吞吐会立刻上升 10% 到 20%，但这些缺口会在 2 到 3 个季度后以返工、故障、交付变慢的形式还回来。

我在前面的案例里提到 C 类需求固定占 10% 产能，就是为了对抗这个倾向。这个 10% 看起来是“损失”，实际上是为未来产能付的保险费。一个可以自测的判断标准是：如果你的返工工时占比超过 20%，说明你已经借了太多未来的产能，现在必须开始还。

八、把方法变成习惯：接下来两周你可以做什么

写到这里，我想回到最开始那个问题：14 个人、负载率 80%、版本还是延期。如果那位产品负责人只带走一件事，我希望是，先把“每个人手上有几条任务、每条卡了多久”变成每周必看的两个数字。这件事不需要预算、不需要工具、不需要审批，一张表加一次 30 分钟的会就能做到。

我的独特判断可以浓缩成三句：

• 产能是流出来的，不是堆出来的。管住入口和并行度，比催进度有效十倍。
• 产能管理的产物不是计划，是承诺的可信度。一个兑现率 90% 的保守计划，价值远高于一个兑现率 60% 的激进计划。
• 产品经理是需求侧唯一的调速阀。你不做产能管理，产能就会以“延期”的形式替你做出决定。

接下来两周的具体动作，我建议按这个顺序：第一周做基线测量，只记三个数，人均在制任务数、任务平均阻塞时长、上三个迭代的承诺兑现率，不要改任何流程；第二周做一次口径会，把“1 人天等于多少小时”“什么算完成”“什么算阻塞”三个定义定下来并写进模板。

两周之后再谈 WIP 限额和承诺系数，因为在没有基线的情况下推限额，你无法证明它有效，也就无法在第一次冲突中守住它。这是我踩过的最深的一个坑：方法是对的，推进顺序错了，最后全组回到原点。

如果你已经在用某个项目管理平台，比如 PingCode 这类覆盖需求、迭代、工时和负载视图的工具，那么第二周之后可以直接进入第三步，把负载视图投到周会上，让数据替你说话。工具能做的只是让数据可见，判断和取舍始终在人这边。