产能怎么做？跨部门团队入门指南：资源负载从0到1

去年冬天，一家 300 人规模的公司请我去看他们的“产能表”。表是 PMO 做的，Excel，37 个 sheet，每个部门一个，汇总页上写着一行大字：Q1 整体负载率 91%。研发总监拿着这张表说，产能已经打满，再接需求只能延期。销售负责人当场翻出另一张表，那是他让助理统计的“上周在岗人数”，说有三个组明明有一半人在等评审。同一家公司，同一周，两张表，两个结论。问题不在谁撒谎，而在于他们从来没有定义过“产能”这个词到底指什么。

这篇文章讲的就是从这种局面里走出去的过程：一个跨部门团队，怎么在 0 到 1 的阶段，把资源负载从“谁都说不清”做到“可以拿来吵架并且吵得出结果”。我会给出结论、拆解误区、给出判断逻辑，也会把我在几个团队里量到的数据摆出来，包括哪些做法有效、哪些纯属折腾。

一、核心结论：0 到 1 阶段，产能的目标是“可见”，不是“精确”

1. 先把一句话结论放在前面

如果你所在的跨部门团队还处在“没有统一产能口径”的阶段，那么第一个季度的目标不应该是算准产能，而应该是让产能这件事变得可见、可讨论、可复盘。精确是第三年的事，可见是第一个月的事。

我见过太多团队一上来就追求“精确到人天”的产能模型，做了三个月，做出一张没人维护、没人相信、开会时谁也不看的表。原因很简单：精确的产能模型对数据质量的要求极高，而跨部门团队恰恰是数据质量最差的地方，人员借调、兼职、临时支持、跨部门评审，每一项都在撕扯你的分母。

所以我把 0 到 1 拆成三个里程碑：可见（能不能看到谁被压满了）→ 可比（不同团队之间能不能用同一把尺子）→ 可承诺（能不能对外给出有依据的交付日期）。跳过第一个直接做第三个，几乎必然失败。

2. 反常识：90% 负载的项目组，交付周期通常是 70% 负载组的 2 到 3 倍

大多数管理者默认“负载率越高越好”，把 100% 当成理想状态。但在跨部门协作场景里，这条直觉是错的，而且错得很贵。

原因不是玄学，是排队。只要工作到达是随机的、任务耗时是波动的，系统里就一定会出现排队。排队论里有个非常朴素的结论：当利用率接近 100% 时，等待时间不是线性增长，而是指数级爆炸。M/M/1 模型下，平均等待时间约为服务时间的 ρ/(1−ρ) 倍，ρ 是负载率。ρ=0.7 时是 2.3 倍，ρ=0.9 时是 9 倍。

跨部门团队比单一职能团队更容易撞上这堵墙，因为它的任务天然更不均匀：一个需求从提出到上线，要经过产品、设计、开发、测试、运维、合规，每一段都有自己的队列。任何一段饱和，整条链路的周期就会被拉长，而且是乘数级地拉长。

3. 产能公式的真实写法

教科书上的产能公式是“人数 × 可用天数 × 每日工时”。这个公式没错，但它算出来的是名义产能，不是你能承诺的产能。我在实际项目里用的版本是四段相乘：

可承诺产能 = 名义工时 × 出勤系数 × 专注系数 × 可用系数

这四个系数的典型取值，在我复盘的样本里分别是 0.90-0.94（扣除年假、病假、法定假期）、0.75-0.85（扣除会议、培训、审批、管理事务）、0.60-0.75（扣除支持类工单、线上救火、临时借调）。三段乘下来，名义工时的 40%-55% 才是真正可以排给计划内交付的部分。

这个数字第一次算出来的时候，几乎每个管理者都会说“不可能，我们没那么闲”。但当你把工时记录按类别摊开给他看，争论通常会在十分钟内结束。争议从来不是因为数据不够，而是因为从来没人把数据摊开过。

4. 0 到 1 的三个里程碑

第一个里程碑是可见。标准很低：随便挑一周，能回答“哪五个人被压得最满、他们手上压的是哪三个需求”。做不到这一条，后面所有讨论都是空谈。

第二个里程碑是可比较。标准是不同团队之间能用同一套口径对比。这里最常见的坑是有的团队用“人天”报负载，有的团队用“需求个数”报负载，到了汇总层面对不上，最后只能靠拍脑袋。

第三个里程碑是可承诺。标准是当业务方问“这个需求什么时候能上”，你能给出一个带区间的答案，并且事后复盘时偏差在可接受范围内。这一步通常要到第 2 到第 3 个季度才稳定。

二、为什么跨部门团队的产能特别难算

1. 一个真实的季度评审现场：三张对不上的表

回到开头那家公司。我把三张表都调出来看了一遍：PMO 的产能表、销售的在岗表、以及研发自己维护的排期表。三张表的口径完全不同。

PMO 的表用的是“编制人数”，包含两个还在招聘中的 HC 和一个已经转岗但系统里没删的人；销售的表用的是“上周提交过代码的人”，把兼职支持的人也算了进去；研发的排期表用的是“迭代内已承诺的需求”，完全不包含支持类工单和线上问题处理。

三张表放在一起，结论必然打架。这不是数据质量问题，是定义质量问题。而定义质量问题，靠买工具是解决不了的。

2. 第一重失真：分母虚高

跨部门团队的分母有几个固定的虚高来源：未到岗的 HC、已转岗未清理的账号、兼职与借调人员的全额计入、以及把“能干活的人”当成“能按计划干这件事的人”。

最后一条最隐蔽。一个前端工程师在编制上是一个完整的人力，但如果他这周有三天在支持另一个产品线的线上问题，他对于我们这个项目的有效分母只有两天。而绝大多数产能表会把他记成五天。

我的一般处理原则是：资源台账里只放“本周真实可用”的人，招聘中的 HC 单独列一栏，永远不进负载计算。这一条看起来很小，但能一下子把很多团队的“负载率”从 91% 拉回到 78% 附近。

3. 第二重失真：分子漏项

分子端的漏项比分母端更普遍。绝大多数团队的负载统计只算“已排进迭代的需求”，而真实占用远不止这些。

我做过一次比较细的工时拆解，把某个 60 人跨部门项目群三个月的工时记录按类别归拢。结果是这样的：

这个结构我后来在多个团队重复验证过，比例会有波动，但“计划内执行只占一半左右”这个量级相当稳定。也就是说，如果你的产能表只统计排期占用，你对负载的低估通常在 40% 以上。

4. 第三重失真：时间粒度错配

第三个问题不那么直观：需求侧的粒度和供给侧的粒度对不上。需求是按“项目”或“季度”提的，产能是按“月”或“周”算的，中间没有桥。

结果就是每个月都在做一次“总量对总量”的粗算：这个季度有 40 个需求，我们有 12 个人 3 个月，平均每人每月 1.1 个需求，好像差不多。这种算法把所有的结构性矛盾都抹平了，它永远告诉你“总体还行”，而真实情况往往是某两个角色爆满、其余角色半空。

5. 为什么跨部门比单团队更难：协调成本是超线性的

单一职能团队里，人多一倍，协调成本大致翻一倍多一点。跨部门团队不是这样。当参与方从 3 个变成 6 个，需要对齐的接口从 3 条变成 15 条，协调成本涨了 5 倍；参与方变成 10 个，接口变成 45 条。

这就是为什么跨部门团队的“健康负载率”要比单团队低 5 到 10 个百分点。你省下来的那部分产能，本质上是被协调吃掉的，不是被浪费掉的。承认这一点，比想办法“提高效率”有用得多。

三、六个常见误区，以及它们为什么必然失败

1. 误区一：人数 × 日历天数 = 产能

这是最普遍的一个，也是最容易在第一次评审会上被推翻的一个。它的失败不是因为算错了，而是因为它算的是一个物理量，而管理需要的是一个可承诺量。

物理量的意思是：如果一切顺利、没有会议、没有支持、没有等待，我们能产出多少。可承诺量的意思是：考虑到过去 12 周的实际损耗，我们敢答应多少。前者用来做预算，后者用来做排期，混用就会出事。

2. 误区二：用平均值掩盖结构性瓶颈

“我们团队负载率 82%，还好。”这句话在跨部门场景里几乎总是误导性的。因为 82% 是一个平均值，而瓶颈从来不看平均值。

我见过一个典型结构：一个 24 人的跨部门项目组，整体负载 79%，看起来很健康。但拆开看，后端两个核心服务的负责人负载分别是 118% 和 124%，前端 61%，测试 55%。整体数字漂亮，实际交付被两个人卡住。

所以产能视图的第一个要求不是“准”，而是“拆得够细”。至少要拆到角色，最好拆到关键人。凡是只给一个总数的地方，都藏着瓶颈。

3. 误区三：只统计“已排期”，不统计“隐性占用”

这一条前面已经用数据说过了。这里补一个操作层面的观察：隐性占用之所以长期不被统计，不是因为它难统计，而是因为统计它会让人不舒服。

一旦把支持类工单算进负载，很多团队会立刻“超载”，然后就要面对“为什么我们人不够”这个需要向上解释的问题。相比之下，不统计它，一切看起来都很正常。这是一种组织性的回避，不是技术问题。

4. 误区四：用故事点承诺，用人天复盘

这个误区的破坏力被严重低估。承诺的时候说“这个迭代我们能做 40 个点”，复盘的时候说“这个迭代我们花了 320 人天”。两个单位之间没有换算关系，于是复盘永远得不出可用于下次预测的结论。

我的一般要求是：承诺、跟踪、复盘三个阶段必须使用同一套单位。要么全用人天（粗略但可比），要么全用吞吐量（以“过去 12 周平均每周完成多少个需求”为基准）。混用等于放弃了学习能力。

5. 误区五：做一次性大盘点，指望一劳永逸

很多团队在年初做一次轰轰烈烈的“资源盘点”，拉了三周的会，做出一张非常精美的产能表，然后就没有然后了。三个月后再看，表上的人有一半换了项目。

产能是流动的，不是存量。任何一次性盘点，保鲜期不超过 6 周。这件事的正确形态不是“项目”，而是“节律”，每周花 15 分钟更新，比每年花三周盘点有用得多。

6. 误区六：把负载率做成考核指标

这是我见过后果最严重的一个。一旦负载率进入考核，它会立刻失去作为观测指标的价值，因为被观测者会开始优化这个数字本身。

典型的表现是“工时注水”和“任务拆碎”：把一个两小时的任务拆成八个十五分钟的子任务，让系统里的“已排期工时”看起来饱满；或者干脆不填工时，让负载率永远显示在安全区间。两种行为都让数据彻底失真。

我的建议很明确：负载率是观测指标，不是考核指标。它可以用来触发讨论、调整排期、申请资源，但绝不与个人绩效挂钩。这条边界如果没有守住，整套体系会在一到两个季度内腐烂。

四、我的判断逻辑：三层台账加一座换算桥

1. 第一层：资源台账，先回答“谁能干什么”

资源台账不是人员花名册。花名册回答“我们有哪些人”，资源台账回答“这些人这周能干什么、能投入多少”。两者的差别在于可用性和技能标签。

我在建台账时至少要五个字段：角色、技能标签（不超过 3 个，多了等于没有）、本周可用比例（0.2 到 1.0，支持兼职和借调）、当前参与的项目数、以及一个“不可用原因”备注（休假、借调、招聘中）。

这五个字段看起来朴素，但它解决了一个非常实际的问题：当业务方说“你们不是有 30 个人吗”，你能立刻回答“这 30 个人里，这周真正能投到这个项目上的只有 11.5 个当量”。把“人数”换成“当量”，是产能管理真正的起点。

2. 第二层：负载视图，周粒度，且只做周粒度

周粒度是个关键选择。日粒度维护成本太高，没人坚持得过一个月；月粒度太粗，插单和救火完全看不见。周是唯一能同时满足“可维护”和“有信息量”的粒度。

负载视图要展示的核心不是“一个人有多忙”，而是“一个角色在下周、下下周、下下下周分别有多忙”。所以它天然是一个时间 × 角色的矩阵，而不是一个排行榜。

我一般会在这个矩阵上加两条辅助线：一条是所有角色的平均负载，另一条是“超载阈值”（通常是 0.85）。前者用来看趋势，后者用来触发行动。凡是越过阈值超过两周的格子，必须在周会上被点名讨论。

3. 第三层：产能预测，滚动 13 周

不做年度产能规划，做滚动 13 周。原因是跨部门团队的需求到达太不稳定，年度规划在发布的那一刻就已经过期了。

13 周大约是一个季度，正好覆盖“已经确定的、基本确定的、可能有的”三类需求。我在实践中把它分成三段：前 4 周锁定、5 到 8 周粗排、9 到 13 周只做容量提示不做承诺。

这个分段的好处是，它把“承诺”和“预测”分开了。前 4 周是可以写进合同的，中间 4 周是可以给业务方看的，最后 5 周只用来判断“要不要提前招人或者砍需求”。不同确定性的东西，用不同强度的承诺，这是产能管理里最省力的一条原则。

4. 换算桥：用历史吞吐率打通需求与供给

需求和供给之间必须有一座桥，否则永远是两套语言。这座桥就是历史吞吐率：过去 12 周，这个团队平均每周完成多少个“标准需求”。

标准需求的定义要固定，通常按“交付物类型 × 复杂度档位”划分，比如“一个中等复杂度的后端接口改造 = 1 个标准需求”。这个定义粗糙，但它稳定、可比、不需要每次都重新拆解。

有了吞吐率，需求侧的“我们想做 40 个需求”和供给侧的“我们每周能做 6 个”就能直接对上：40 ÷ 6 ≈ 7 周。这个数字比任何精细估算都更容易被业务方接受，因为它来自历史事实，而不是来自承诺。

5. 阈值设计：绿黄红三段，谁触发谁负责

阈值不设，负载视图就只是一张好看的图。我的做法是三段：

• 绿色（低于 75%）：正常，允许业务方自由插单，不需要走审批。
• 黄色（75% 到 85%）：预警，插单需要排优先级，由项目负责人决定挤掉哪一项。
• 红色（高于 85%）：超载，插单必须由跨部门决策会裁决，并明确写出“挤掉了什么”。

关键在最后半句：每次插单都必须显式记录它挤掉了什么。这条规则看起来只是记账，实际上它改变了整个组织的对话方式，从“能不能加个需求”变成“加了这个，哪个先不做”。前者是请求，后者是决策。

6. 一段可以直接用的计算逻辑

如果你现在就想在现有数据上算一遍周粒度负载，这段 SQL 可以直接改成你库里的表名。核心逻辑是：可用人天按周汇总，已排期人天按周汇总，两者相除得到负载率。

-- 周粒度资源负载：可用人天 vs 已排期人天
SELECT

t.team_name,

w.week_start,

SUM(r.available_days)                                   AS available_days,

SUM(COALESCE(a.assigned_days, 0))                       AS assigned_days,

ROUND(SUM(COALESCE(a.assigned_days, 0))

/ NULLIF(SUM(r.available_days), 0), 3)            AS load_rate

FROM dim_team t

JOIN dim_week w

ON w.week_start BETWEEN '2025-01-06' AND '2025-03-30'

JOIN fact_resource_availability r

ON r.team_id = t.team_id

AND r.week_start = w.week_start

LEFT JOIN fact_assignment a

ON a.team_id = t.team_id

AND a.week_start = w.week_start

AND a.status <> 'cancelled'

GROUP BY t.team_name, w.week_start

ORDER BY t.team_name, w.week_start;

两个注意点。第一，available_days 要用“当量”而不是人数，兼职 0.5 就当 0.5。第二，assigned_days 必须包含支持类工单，否则你会重蹈前面那个低估 40% 的覆辙。

五、案例与数据观察：一家 300 人研发组织的 90 天

1. 起点：三张互相对不上的表

就是开头提到的那家公司。研发 300 人左右，横跨 4 条产品线、9 个职能团队，做的是软硬件一体的产品，跨部门协作密度很高。他们的核心矛盾是：每个季度的需求排期会都要开两天，开完还是有人不满意。

我进去的第一件事不是建模，是把三张表放在一张纸上做对照。结果发现，光是“在岗人数”这一项，三张表的差异就有 17 人。这 17 人里，4 个是招聘中的 HC，6 个是已转岗，7 个是兼职按全额计算。先把这 17 人的口径统一，负载率就从 91% 降到了 76%。没有优化任何流程，只是把分母修对了。

2. 第一个 30 天：只统一口径，不上工具

这 30 天里我们没有引入任何新系统，只用了一张在线表格。目标是三件事：定义“标准需求”、定义“可用当量”、定义“负载率的计算方式”。

其中最难的是“标准需求”的定义。业务方希望按“功能模块”算，研发希望按“技术复杂度”算，两边谈了三次没谈拢。最后我们退了一步，用“历史交付周期分档”来定义：过去半年交付周期在 3 天以内的算 S，3 到 8 天算 M，8 天以上算 L。这个定义谁都不完全满意，但它有一个巨大优势，可验证。

“可验证”这件事在 0 到 1 阶段的价值，远高于“合理”。一个合理但无法验证的定义，会在第一次争议中被推翻；一个不完美但可验证的定义，能活下来并逐步迭代。

3. 第二个 30 天：把负载视图塞进已有的节律

第二个 30 天，我们开始做周粒度的负载视图。这里踩了一个坑：一开始我们新建了一个“产能周会”，结果第二周就有一半人请假。

后来改成把负载视图塞进他们本来就有的迭代计划会，只占 15 分钟，议程固定为三条：上周负载超 85% 的角色是谁、本周有哪些计划外占用需要补录、下周有没有需要提前干预的红色格子。不加会，只加议程，这一条让参与率从 55% 提到了 95%。

这也是我给所有跨部门团队的建议：不要为产能管理新建任何会议。新增会议的边际成本极高，而寄生在既有节律里的边际成本接近于零。

4. 第三个 30 天：从“看负载”到“调负载”

前两个月解决的是“看见”，第三个月才开始“调整”。这个阶段我们做了三件事：建立插单的显式记账规则、给关键角色设置 85% 的硬阈值、以及把历史吞吐率写进季度排期会的第一页。

硬阈值这一条阻力最大。有两个后端负责人明确反对，理由是“我们的工作性质就是会被打断”。我们没有硬推，而是退让成“超阈值需要写一行原因”，把强制变成了留痕。

结果很有意思：第一个月有 23 条超阈值记录，第二个月降到 11 条，第三个月只有 4 条。没有人被考核，但光是“要写一行原因”这个摩擦，就改变了行为。

5. 90 天后的四个数字

90 天结束时，我们跟踪了四个指标。它们不是全部变好，有两个改善明显，一个几乎没动，一个反而变差了，我把真实的都写出来。

没怎么动的是“人均产出”，原因是前两个月有相当一部分时间花在了口径对齐和数据补录上，属于一次性投入。反而变差的是“工时填报完整率”，因为支持类工单的补录规则改过一次，有一段时间大家不知道该填哪个字段。

我把这些不完美的部分写出来，是因为大部分讲产能的文章只讲改善后的结果，不讲过程中的反复。实际上，产能 0 到 1 的过程中，指标反复是最正常的现象，判断体系是否成立的标准不是“一路向上”，而是“问题能被定位”。

6. PingCode 在这里承担了什么，没承担什么

这家公司在第 60 天左右开始评估工具。他们规模在 300 人，跨 4 条产品线，靠在线表格维护负载视图已经开始吃力：表越来越多，权限越来越乱，跨项目看一个人的总负载需要手工合并三张表。这是我建议他们看专业平台的典型信号，不是表格不好用，是表格撑不住跨项目的聚合。

他们最终选了 PingCode。以我的观察，中大型企业、100 人以上、多产品线并行的组织，属于这类平台比较典型的适用区间；更小的团队用表格加纪律通常更划算，这一点我在下一节会展开说。

PingCode 在这个案例里真正解决问题的部分是三块。

第一块是工时与排期在同一套数据里。之前他们的支持类工单在工单系统、需求在项目系统、工时在 Excel，三处对不上。把工时填报挂到需求和工作项上之后，那 19% 的“支持与救火”第一次被结构化了，负载视图的分母终于接近真实。

第二块是跨项目的资源视图。一个人同时参与三个项目时，能在一个视图里看到他三块占用之和，而不是在三个项目里分别看他“还有余量”。这一点在共享资源池的组织里价值最大，也是表格最难做到的地方。

第三块是效能度量报表的持续输出。历史吞吐率、迭代完成情况、需求平均周期这些东西，如果能自动出，团队的复盘就会从“凭印象”变成“看数据”；如果每次都要人工整理，绝大多数团队撑不过三个月。

但它没承担的部分同样重要，我必须说清楚。

工具解决不了口径问题。“标准需求”怎么定义、“可用当量”怎么折算、“超阈值”怎么处理，这些全部是管理决策，工具只能承载你定好的规则。我见过不少团队买了系统之后，把字段填满，然后负载率照样不准，原因就是口径从来没定过。

工具也解决不了意愿问题。如果团队认为填工时是负担、是监控，数据质量就会持续下降。PingCode 这类平台能做的是降低填报摩擦（比如和工作项绑定、支持批量、有默认值），但“为什么要填”这件事必须由管理者回答。在那个案例里，我们给团队的回答很直接：填了，插单才有依据拒绝；不填，就只能靠加班。

还有一点：不要指望工具自动算出产能。任何平台的资源负载视图都是“你给它多少输入，它还你多少输出”。它能做的是聚合、可视化、提醒，判断仍然要人来做。我在项目里反复强调的一句话是：工具负责让事实可见，人负责让取舍发生。

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

1. 情况一：30 到 100 人，还停留在表格阶段

这个规模我建议先不要上系统。用一张在线表格加一套明确的规则，两周就能跑起来，成本几乎为零，而且能快速验证你的口径是否站得住。

具体做法：一张资源台账（人 × 周 × 可用当量），一张需求清单（需求 × 预估档位 × 目标周次），一张汇总视图（角色 × 周 × 负载率）。三张表用同一个“周次”字段关联，每周更新 15 分钟。

这个阶段最重要的不是工具，是让团队先经历一次“原来我们真的超载了”的认知冲击。有了这次冲击，后面推任何规则都会容易得多。

2. 情况二：已经有台账，但没人信

没人信通常有三个原因：数据明显不准、数据不准但没人承认、或者数据准但没人用。前者是技术问题，后两者是政治问题。

我的处理顺序是：先做一次“对账”，随便挑三个团队，把系统里的负载数据和团队负责人的主观感受做对比。如果差异超过 20%，说明数据源有问题；如果差异很小但团队仍然不信，说明问题在沟通而非数据。

对账这个动作有个额外好处：它把“你信不信”变成了“我们看同一份东西”。多数争议在这一步就会消解一半。

3. 情况三：多项目共享资源池，抢人打架

这是最难的一种。资源池共享意味着同一个人被多个项目主张，而每个项目经理都认为自己的需求优先级最高。

我的建议是把问题从“抢人”转成“排队”。做法是给资源池设一个统一的排队规则：按承诺日期倒排、按业务影响加权、按切换成本惩罚。规则公开，排队结果公开，项目经理之间就不再需要互相说服，只需要对着规则争。

另一个关键动作是显式记录切换成本。一个人在两个项目之间来回切换，每次切换平均损失半天到一天。这个成本以前是隐性的，现在写进负载视图，很多“反正他还有空”的说法就自动消失了。

4. 情况四：100 人以上、多产品线，需要系统承载

到这个规模，表格的边际成本会快速上升。跨项目聚合、权限隔离、历史数据留存、报表自动生成，这几件事靠人工维护迟早崩掉。

这个阶段的选型逻辑，我的建议是按顺序看四件事：能不能把工时和需求挂在同一个工作项上、能不能跨项目看一个人的总占用、能不能自动出历史吞吐率、能不能按角色做负载视图。前两条是刚需，后两条决定你三个月后还要不要人工整理报表。

PingCode 在前两条上比较扎实，第三条的报表能力也够用；如果组织的权限结构特别复杂（比如大量外部供应商参与），实施阶段要留出额外时间做权限设计。这是我在这类项目里反复踩到的一个点。

5. 一个通用的 4 周启动清单

1. 第 1 周：定义口径。确定“标准需求”的分档规则、“可用当量”的折算方式、“负载率”的计算公式。三件事写在一页纸上，全员可见。
2. 第 2 周：建台账。收集角色、技能标签、本周可用比例、参与项目数。不要追求完整，先覆盖 80% 的人。
3. 第 3 周：出第一版负载视图。只做角色 × 周次的矩阵，不做任何美化。目标是在周会上被真实使用一次。
4. 第 4 周：设阈值和规则。确定绿黄红三段、插单留痕规则、超阈值的处理流程。规则要少，最好不超过三条。

这四周结束时，你不一定有一个准确的模型，但一定有一个可以开始讨论的东西。这就够了。

七、不同情况下的取舍

1. 精确度 vs 维护成本

这是所有取舍里最根本的一个。产能模型的精确度和它的维护成本是平方关系：精度提高一倍，维护成本大约涨四倍。

我的判断标准是：如果这个模型每周的维护时间超过团队总工时的 1%，它就已经不划算了。一个 50 人的团队，每周 20 小时用于维护产能数据，意味着每年损失约 1000 小时，这些时间足够做完一个中型项目。

所以在 0 到 1 阶段，我倾向于选择“粗但持续”而不是“细但短命”。一个每周更新、精度 ±20% 的模型，价值远高于一个精度 ±5%、三个月后就没人维护的模型。

2. 集中管控 vs 团队自治

集中管控的好处是口径统一、跨团队可比；坏处是响应慢、数据失真（因为填报者不拥有数据）。团队自治正好相反。

我的经验是分层：口径集中，数据自治。也就是“负载率怎么算”由中央定义，“谁被排到哪个项目”由团队自己定。这样既保证了横向可比，又不至于让团队觉得被监控。

如果组织已经有过“数据被用来追责”的历史，那第一年应该更偏自治一些，先把数据质量养起来，再谈管控。顺序搞反，会直接导致数据造假。

3. 人天口径 vs 吞吐量口径

人天口径适合做资源规划（要几个人、要几个月），吞吐量口径适合做交付预测（这个需求什么时候能上）。两者不是替代关系，是分工关系。

常见的错误是用人天口径做交付承诺。人天告诉你“能做多少活”，吞吐量告诉你“多久能交付”，这两件事在跨部门团队里差别很大，因为中间横着一堆等待和协调。

我的建议是两个都留：人天口径放在资源台账里，吞吐量口径放在排期承诺里，中间用“标准需求”的换算关系连起来。

4. 工具先行 vs 规则先行

规则先行。这条我态度很坚决。先上工具再定规则的团队，最后往往得到一个字段填得很满、但没人相信的系统。

正确的顺序是：用表格把口径跑到能自洽（通常 2 到 4 周），确认这套规则在真实会议上能被用起来，再考虑迁到系统。迁的时候你会发现，很多在表格里模糊的地方，到了系统里必须明确，这恰恰是系统真正的价值：它逼你把规则说清楚。

反过来说，如果规则还没跑通就上系统，那些模糊的地方会被字段掩盖，看起来一切都规范了，实际上什么都没解决。

5. 提前锁产能 vs 保留缓冲

提前锁定产能让计划更稳定，但会牺牲响应能力；保留缓冲提高响应速度，但会让利用率看起来偏低，容易在预算评审中被质疑。

我的做法是把缓冲显式化：在负载视图里单独列一列“预留产能”，通常占总产能的 10% 到 15%，并明确写清楚它用来吸收什么（线上问题、临时需求、人员缺勤）。

显式化的好处是，它不再是“看不见的浪费”，而是“有名字的投资”。当有人问为什么负载率只有 82% 时，你不需要辩解，直接指那一列。

八、总结：产能管理的本质是承诺管理

1. 三个我反复验证过的判断

第一，产能不是算出来的，是暴露出来的。你不需要一个更聪明的公式，你需要一张让所有人都能看见同一件事的表。多数团队的产能问题，在数据被摆上桌面的那一刻就已经解决了一半。

第二，跨部门团队的瓶颈从来不在总量，在结构和时间。总量看起来够，是因为平均值把超载和空闲抹平了；时间看起来够，是因为你算的是月而不是周。把粒度降到周、把维度拆到角色，80% 的“人手不够”会现出原形。

第三，负载率的目标不是 100%，是 80% 左右。剩下的那 20% 不是浪费，是系统用来吸收波动的缓冲。一个负载率常年 95% 的团队，看似高效，实际上把所有的确定性都换成了加班和延期。

2. 下周就能做的三件事

如果你读到这里想立刻动手，我建议只做三件，不要贪多。

第一件：修分母。把招聘中的 HC、已转岗未清理的人、兼职按全额计算的人从产能计算里拿掉。这一步通常能在一天内完成，而且往往立刻能让负载率下降 10 个百分点以上，是全套动作里性价比最高的一步。

第二件：补分子。把支持类工单、线上问题处理、跨部门临时需求这三类占用，按周汇总进负载视图。不需要精确到小时，按“人天当量”粗估即可。这一步做完，你会第一次看到真实的负载形状。

第三件：定一条规则。只定一条：负载率超过 85% 的角色，任何新插单必须显式写出挤掉了什么。不要定十条，十条规则没人记得住；一条被真正执行的规则，比十条写在文档里的规则有用得多。

这三件事做完，你大概会用掉两到三周，成本不到一个人两周的工时。而它带来的最大变化不是数字变准了，是团队终于可以在同一张纸上讨论“我们到底能不能接”这个问题。

产能管理做到最后，你会发现它管的不是工时，是承诺。一个组织能不能可靠地兑现它说出的话，取决于它对自己能力的认知有多诚实。而诚实，是从把那张表摊开在桌面上开始的。