资源负载工作负载全流程：跨部门团队实操方法与一文讲清

去年 11 月，我陪一家约 400 人的软硬件混合团队做年度交付复盘。项目经理把资源视图投到屏幕上：六条泳道几乎全是浅绿色，人均承诺负载 74%，看上去是教科书级的健康。可就在同一周，三位部门主管在群里为同一个固件工程师吵了起来，硬件要他补板级测试，平台要他做驱动联调，交付要他驻场支持。视图里的 74%，和现实里的抢人，说的是两件完全不同的事。

这件事后来成了我讲资源负载管理时最爱用的开场。因为它一次性暴露了三个真相：负载数字可以是准的，但它算的是错的东西；跨部门协作的卡点不在表格，而在谁有权说“这个先不做”；以及最难的部分从来不是把负载图画出来，而是让“排期承诺”这件事变得可被追溯、可被推翻、可被重排。

这篇文章我想把“资源负载 / 工作负载全流程”这件事从概念到落地完整讲一遍：先给结论，再讲为什么跨部门一到旺季就崩，然后拆掉几个流传很广的误区，给出我实际在用的折算逻辑和阈值，用一个 300 人量级组织的落地过程做样本，最后按不同规模、不同组织形态给出行动建议和取舍。文中出现的具体数值，除明确标注理论来源的以外，均为脱敏样本推演与经验基准，用于说明量级和判断方向，不作为行业统计引用。

一、核心结论：负载管理解决的不是“看得见”，而是“排得下、改得动、说得清”

先把结论摆出来，后面所有内容都是围绕这四句话展开的。

1. 资源负载、工作负载、产能利用率是三个不同的东西

大多数团队在这三个词上就开始混用，导致后面所有报表都不可信。我的定义很简单，也很刻意地区分它们的用途。

这三者的关系是：工作负载是输入，资源负载是预测，产能利用率是回看。用回看的数字去指导预测，就像看着后视镜开车，平时没事，一到路口就撞。

2. 全流程只有五步，但每一步都必须落到唯一数据源

我把跨部门资源负载的全流程压缩成五步。步骤本身不复杂，复杂的是每一步都有人想用自己的 Excel 版本。

1. 口径统一：确定“一个月有多少可承诺工时”“跨部门支持算不算负载”“返工算谁的成本”，写成一页纸的口径说明，谁都不许私自改。
2. 需求入池：所有要占用产能的事项，无论来自哪个部门，先进同一个池子，带优先级、期望交付时间、所需角色。
3. 产能折算：把名义工时逐层折成可承诺产能，按角色、按技能标签分别算，不能全局一个系数。
4. 匹配与承诺：把池子里的需求对到具体角色上，形成“谁在什么时候做什么”的承诺，承诺必须可追溯到需求条目。
5. 监控与再平衡：每周看超载、看插单、看缓冲消耗，只做三件事，挪期、拆包、砍范围。

这五步里，真正决定成败的是第 2 步和第 4 步。第 2 步决定你有没有资格谈负载（需求不收敛，产能永远不够）；第 4 步决定你的负载数据是不是“承诺级”的（没被承诺的排期只是意向）。

3. 跨部门的真正卡点不是表格，是仲裁权

我见过太多团队把精力花在把资源视图做得多漂亮，结果一到冲突还是靠“谁嗓门大”。资源负载管理本质是一个优先级仲裁系统，图只是它的输出。

仲裁权要回答三个问题：谁能往池子里加需求、谁能在冲突时决定顺序、谁能批准超载。这三个权力如果不落到具体的人和具体的会上，负载表就只是一张用来事后追责的清单。

我的经验是，跨部门团队里最有效的一招不是加报表，而是设立一个每周固定 45 分钟的“产能评审会”，参会者必须有权说“这个季度不做”。这个会一旦跑起来，负载数据的质量会自动提升，因为大家知道数字会被用来做决定。

4. 判断标准要换成“可预测性”，而不是“高利用率”

很多管理者心里有个隐含目标：让人均负载尽量接近 100%。这个目标在制造业流水线上成立，在知识型、跨部门协作的场景里是灾难。

原因不复杂：协作型工作的到达是随机的，处理时间也是随机的。当系统利用率逼近上限，排队长度不是线性增长，而是指数级爆炸。你省下的 10% 闲置产能，往往要用 2 倍的交付周期去换。

所以我看一个团队的资源负载体系是否成熟，第一眼不看负载率高低，而看两件事：承诺负载率的波动幅度，以及超载人数占比。前者代表可预测性，后者代表风险敞口。

二、背景与真实场景：一次旺季，负载是怎么被“偷偷”填满的

1. 三个结构性原因让跨部门负载必然失控

先讲清楚为什么这个问题在跨部门团队里格外严重。不是管理者不努力，而是结构上就有三个漏洞。

（1）需求侧没有单一入口

销售承诺客户一个定制需求，走的是销售线；客户成功提一个紧急修复，走的是服务线；技术负责人自己排技术债，走的是技术线。三条线各自看起来都合理，但落到同一个工程师身上，就变成了三份“都很重要”的排期。

这个漏洞的可怕之处在于它是隐性的。每条线单独看负载都不到 40%，合起来就超了 120%，而没有任何一个人在某个时刻看到过 120% 这个数字。

（2）供给侧产能口径不统一

财务按 21.75 天算人头成本，项目按 20 天排期，部门主管按“能干活的时间”算，工程师自己按“没被开会打断的时间”算。四个口径，四套数字，开会时各说各的，最后往往是嗓门最大的那个口径赢。

我一般会要求团队把口径写下来贴在 Wiki 首页，尤其是三个数：月可承诺工时、跨部门支持预留比例、返工计入方式。这三个数定了，后面 80% 的争论会自动消失。

（3）中间没有仲裁会议

需求进了池子，产能算出来了，但没人负责把这两者对齐。于是出现一种奇特现象：资源视图上红得发紫，会议纪要上依然是“按计划推进”。

没有仲裁，负载数据就只是报警器，不是方向盘。报警器响一万次，也不会让车拐弯。

2. 一个典型月份：负载被填满的四个时点

我把这类过程复盘过很多次，时间线惊人地相似，通常集中在四个时点。

• 月初第 1 周：排期按 100% 产能铺满，没有任何缓冲。此时负载率显示 85%，看起来还有余量，但余量其实是“会议和休假”还没来得及发生。
• 第 2 周：两个客户紧急需求插入，走的是“特批通道”，没有走池子，也没人把它记进负载。
• 第 3 周：关键角色（通常是某个中间件或底层驱动的人）同时被三个项目需要，部门主管开始私下协调，协调结果不回流到任何系统。
• 第 4 周：交付延期，复盘会上大家一致认为是“人手不够”，于是启动招聘，而实际原因是前两周的插单从未被计入。

这条时间线最值得警惕的地方是：每一次失衡都有一个“看起来合理”的临时决定。临时决定单独看都没错，累积起来就是系统性失控。

3. 为什么“人均 74%”是个危险数字

回到开头那个案例。74% 之所以危险，是因为它把三种完全不同的状态平均掉了：一部分人 40%（新入职、等待依赖），一部分人 85%（正常），一部分人 130%（关键角色）。平均值 74% 看起来温和，方差却大到足以让交付塌方。

更麻烦的是，那个 130% 的人往往正是最难替代的人。平均值掩盖方差，方差集中在瓶颈，瓶颈决定交付，这是资源负载管理里最经典的一条因果链。

三、拆解六个常见误区

1. 把工时填报当成负载管理

这是最普遍的一个。很多团队上线了工时填报，每周填、每月出报表，然后认为自己在做资源负载管理。实际上这是成本核算，不是产能调度。

区别在哪？填报是事后的，回答“昨天干了什么”；负载是事前的，回答“下周三他能不能接这个活”。两者的数据可以来自同一套系统，但用途、颗粒度、责任人完全不同。

我见过最典型的失败场景是：工时填报率 98%，报表做得很精致，但排期照样靠群里问。因为填报数据默认是“已经发生”的，它对未来的预测能力约等于零。

2. 把 100% 利用率当作目标

这个误区的来源是制造业思维。在流水线上，设备闲置就是浪费；在协作型知识工作里，闲置是吸收波动的唯一手段。

我在多个 100 到 500 人规模的组织里做过粗测：把承诺负载目标从 95% 下调到 85%，短期看“产能账面损失”约 10%，但按期交付率通常能提升 15 到 20 个百分点，加班工时下降 30% 左右。这笔账几乎总是划算的。

当然有例外。突发响应型团队（比如线上运维、客户支持）的合理目标反而更高，因为它们的任务颗粒小、切换成本低。判断依据是任务颗粒度与切换成本的乘积，而不是一个统一数字。

3. 用平均负载掩盖方差

“我们团队平均负载才 78%，还有空间。”这句话我一年能听到几十次。每次我都会追问：P90 是多少？超过 110% 的有几个人？

因为资源负载的约束是最大值约束，不是平均值约束。一个项目只要有一个关键角色超载，整个项目就会延期，其他人的余量并不会自动流过去。

我一般会看三个分布指标：P90 负载、超载人数占比（负载 > 110%）、以及负载基尼系数。P90 与中位数差距超过 1.4 倍时，说明这个团队的负载分配已经严重依赖少数人，属于结构性风险。

4. 只看人头，不看技能标签

“我们有 30 个工程师，只用了 24 个”，这句话在资源负载语境下几乎总是错的，因为能被替代的从来不是人，而是技能。

一个 300 人规模的团队里，通常有 3 到 5 个角色是真正的瓶颈：某个协议栈、某个老系统的维护者、某个只有一个人懂的数据模型。这些角色的负载率才决定交付，其他人的负载率只是背景噪音。

所以我做资源池划分时，第一步永远是打技能标签，第二步才是算负载。标签的粒度要能区分“能独立干”和“能看懂”，这两种人不能算同一份产能。

5. 靠周会口头协调跨部门

口头协调的问题不是效率低，而是不留痕。这次靠人情借了 3 天，下次这个人还在原部门排期表上，于是同一个冲突会重复出现，每次都要重新吵一遍。

我要求所有跨部门调剂必须落到三个字段：借出方、借入方、归还方式。归还方式可以是时间（下个月还 3 天），也可以是范围（这个需求由借入方承接一部分测试）。没有归还机制的借用，本质上是资源掠夺。

6. 颗粒度错配：用项目级分摊冒充任务级负载

项目级分摊是说“这个项目 3 个月，投入 5 个人，平均每人每月 80%”。这种算法在项目内部任务分布均匀时勉强可用，现实中几乎从不均匀。

真实的负载曲线往往呈现“前低后高”的尾部陡增：前两个月 50%，最后一个月 140%。如果按月均摊，你会在最关键的时候发现资源已经排给了下个项目。

我的建议是至少做到“角色 × 周”的颗粒度，对瓶颈角色做到“人 × 周”。再细就是过度管理，再粗就失去预警能力。

四、专业判断逻辑：四层折算、三条阈值、一个仲裁机制

1. 四层折算：从名义工时到可承诺产能

这是整套方法里最硬的一块。很多人算负载不准，根源就是分母用的是名义工时。我用的折算分四层，每层都有明确扣减依据。

可以看到，174 小时的名义工时，最后能用于计划内交付的只有 85 到 95 小时，折损接近一半。这就是为什么“人均 74%”实际已经很危险，如果分母是 174，74% 是 129 小时；而如果分母是 105，129 小时就是 123% 的超载。

下面是我写在团队 Wiki 上的计算脚本，用伪代码表达，任何人可以按自己团队的数字替换：

# 可承诺产能折算（单角色/单月，单位：小时）
名义工时 = 21.75 工作日 x 8h # 174h

不可用工时 = 会议 26 + 休假病假 9 + 行政培训 14 # 49h

可用工时 = 174 – 49 # 125h

跨部门支持预留 = 可用工时 x 0.12 # 15h

可承诺产能 = 125 – 15 # 110h

两条阈值（按工作类型取值）

承诺负载上限 = 可承诺产能 x 0.85 # 93.5h，可预测交付类

创新探索上限 = 可承诺产能 x 0.72 # 79.2h，含不确定性工作

负载率计算

负载率 = 已承诺工作负载 / 可承诺产能

超载判定 = 负载率 > 1.10 # 进入红色预警

这段脚本的价值不在于精确，而在于把“我们还能接多少活”变成一个可以算出来的数，而不是靠部门主管的感觉。

2. 稀缺度加权：同样的 1 小时不是同样的 1 小时

第二层判断是给角色加权。我的做法是给每个角色算一个稀缺度系数，范围 0.8 到 1.6，用三个因子相乘：可替代人数、上手周期、跨部门依赖度。

举个例子。一个可替代人数 8 人、上手 2 周的前端角色，系数大概 0.9；一个可替代人数 1 人、上手 6 个月的存储引擎角色，系数可以到 1.5。同样排了 80 小时，前者等效负载 72，后者等效 120。

这个加权最大的作用是让资源调剂有依据。没有加权，你只能在“谁闲谁上”这个层面协调；有了加权，你可以理直气壮地说“这个人不能再接了，他的等效负载已经是 130”。

3. 三条阈值：承诺负载上限、WIP 上限、缓冲比例

阈值是把判断变成规则的关键。我一般只设三条，多了没人记得住。

• 承诺负载上限：可预测交付类工作 85%，探索创新型 72%。超过就要触发重排，而不是靠加班消化。
• WIP 上限：单个角色同时进行的任务不超过 3 个，单个项目在制需求不超过团队人数的 1.5 倍。依据是利特尔法则，在制品越多，周期越长。
• 缓冲比例：关键角色预留 15%-20% 的资源缓冲，项目层面预留 15% 的时间缓冲。缓冲不是浪费，是应对不确定性的保险费。

这三条阈值我建议写进系统里做自动预警，而不是靠人盯。人盯的阈值，一周之后就会变成“大家都知道但没人管”。

4. 一个仲裁机制：把“抢人”变成“排序”

阈值解决的是“什么时候报警”，仲裁解决的是“报警之后怎么办”。我用的机制很朴素：一个池子、一个会、一张排序表。

（1）一个池子

所有占用产能的事项进同一个需求池，字段固定为：提出方、所需角色、工作量估算、期望交付、延迟代价。延迟代价这个字段最关键，它是排序的唯一客观依据。

（2）一个会

每周固定 45 分钟产能评审会，参会者必须包括各部门有权说“不做”的人。议程只有三项：上周超载复盘、本周新增需求排序、缓冲消耗情况。

（3）一张排序表

排序结果必须回流到排期系统，形成新的承诺。会议如果没有产生排期变更，就说明这个会白开了。

这套机制的核心不是流程，而是把“谁的优先级高”从人际关系问题变成数据问题。延迟代价一旦量化，争论会少掉一大半。

五、案例与数据观察：一个 300 人组织的 12 周落地过程

1. 样本背景与约束条件

下面这个案例来自我 2024 年参与的一次落地复盘，企业规模约 300 人，含硬件、平台、应用、测试、交付五个部门，跨部门协作占比高，季度末有明显的旺季波动。数据已做脱敏和区间化处理，用于说明趋势量级，不作为该企业或任何产品的官方统计。

约束条件有三个，值得先说清楚，因为它们决定了方法能不能照搬：第一，没有专职 PMO，资源协调由各部门主管兼管；第二，已有项目管理平台在用，但只用于任务流转，工时和负载模块基本空置；第三，管理层最关心的是按期交付率，而不是人均效率。

这三个约束非常有代表性。大部分 100 到 500 人的组织都是这个状态：工具已经有了，但只用了 30% 的能力；流程不是没有，而是没有仲裁环节。

2. 第 1-4 周：先立“一本账”，不谈优化

第一个月我只做一件事：把口径统一，把所有在跑的事项装进同一个池子。这一步听起来最无聊，但它是后面所有动作的基础。

具体做法是在 PingCode 里把项目、迭代、任务的层级先理顺，把工时字段和角色字段设为必填，然后用它的项目集视图把所有在建事项汇总到一张表上。这一步的价值不在于工具本身，而在于强制所有人用同一套字段描述同一件事。

这四周里我们踩的第一个坑是：一开始想把所有历史数据都补录进去，结果花了大量时间清洗脏数据，反而拖慢了进度。后来改成“只补最近 6 周，更早的一律归档”，两周就完成了。

3. 第 5-8 周：建资源池和技能标签

第二个月开始做供给侧。我们按角色建了 11 个资源池，给每个人打了 1 到 3 个技能标签，并区分“独立承担”和“可协作”两档。这个区分后来被证明是整套体系里性价比最高的一步。

有了标签之后，很多原本要靠开会解决的冲突自动消失了。因为当硬件部说“我们需要那个固件工程师”时，系统里能立刻看到只有 1 个人具备“独立承担”标签，另外 2 人只能协作，事实摆出来，讨论立刻从“要不要借”变成“怎么排优先级”。

这一步在 PingCode 里的落地方式是利用组织架构与角色权限做资源池隔离，再用度量模块把“人 × 周”的负载做成固定报表。我们没有做定制开发，全部用配置完成，这也是我建议大多数团队采取的方式：先用工具的标准能力跑通流程，再考虑定制。

4. 第 9-12 周：上仲裁会与缓冲

第三个月才引入仲裁会。顺序很重要，如果一上来就开会，大家手里没有数据，会变成互相指责；等数据齐了再开会，讨论就自然聚焦在排序上。

我们设了三条规则：延迟代价必须量化（用“每晚一周损失多少”表达，可以是金额也可以是客户影响等级）；每周最多批准 2 个插单；插单必须指定被置换的事项。第三条是最有效的，因为它让插单有了真实成本。

缓冲方面，我们只给 3 个瓶颈角色加了 15% 的资源缓冲，其他角色不动。原因是全员加缓冲等于没加缓冲，只会让账面产能虚高。有限的缓冲必须压在真正的瓶颈上。

5. 一个被低估的动作：需求收敛漏斗

整个落地过程中，效果最大的其实是需求收敛，而不是负载可视化。第三个月我们开始对入口做筛选，结果发现进入排期的需求只占提出量的三分之一。

这个比例一开始让业务方很不满，但两个月后就没人抱怨了，因为被砍掉的需求里，有相当一部分本来就是“提了但没人真的要用”。需求侧的每一次收敛，都相当于凭空多出一份产能。

6. 踩过的三个坑，以及我现在的做法

（1）一开始追求 100% 的数据完整度

我们花了三周清洗历史工时，结果发现对排期决策几乎没有帮助。现在的做法是先保证“未来 4 周的排期数据”完整，历史数据按归档处理，两周内就能跑起来。

（2）把负载率做成 KPI

第一个月我们把“负载率达标”放进部门考核，立刻出现了数字美化，大家把估算工时往低了报，负载率看上去很漂亮，实际该延期还是延期。第二个月就撤掉了，改成只考核按期交付率和插单率。

（3）缓冲加在了错误的位置

最初给全员加了 10% 缓冲，结果瓶颈角色依然超载，非瓶颈角色更闲。后来改成只给 3 个瓶颈角色加 15%，效果立刻显现。缓冲是稀缺资源，必须压在决定交付的那一环上。

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

1. 按组织规模：三种完全不同的起步方式

规模决定复杂度，不同规模的组织不应该用同一套方案。下面这张表是我在不同规模团队里实际用过的起步路径。

100 人以下的团队最容易犯的错是“工具先行”。我见过 60 人的公司买了平台，配了两个月，最后又回到 Excel。原因不是工具不好，而是这个规模下沟通成本低于流程成本，一张表加一个会就够。

100 到 500 人是方法收益最大的区间。这个规模已经跨过了“靠喊能协调”的临界点，但又没有富余到可以养专职 PMO。PingCode 这类面向中大型企业的平台在这个区间比较合适，主要原因是它的组织架构、角色权限、工时与度量能在一个系统里闭环，不需要额外做数据集成。

500 人以上必须分两级仲裁：部门内先自洽，跨部门再仲裁。如果所有冲突都上到公司级会议，会议本身就会成为瓶颈。

2. 按组织形态：三种典型场景的差异

（1）项目型组织

人是跟着项目走的，负载管理相对容易，重点在项目之间的资源交接。我建议在项目收尾前 3 周就锁定下一个项目的排期，避免出现“项目结束人才知道去哪”。

（2）运维支撑型组织

任务是随机到达的，无法按项目排期。这类组织的重点不是精确排期，而是设置固定的支撑额度：明确每周有 30% 产能用于临时支撑，超过就要走升级流程。把不确定性装进一个固定容器，比试图消除不确定性现实得多。

（3）矩阵型组织

最难的一种。员工有部门主管和项目经理两条汇报线，负载天然冲突。核心解法是明确资源归属方与使用权方：部门拥有产能，项目购买产能，购买必须走池子，不能私下借。

矩阵型组织还有一个隐性风险：员工的“实际老板”决定了他们的真实优先级。如果部门主管和项目经理的考核指标不一致，任何负载表都无法落地。这时候要先解决指标对齐，再谈工具。

3. 从零开始的 30 天路线

如果今天就要开始，我建议按下面这个节奏走，不要试图一次做全。

1. 第 1 周：写一页口径说明，定三个数，月可承诺工时、跨部门支持预留比例、返工计入方式。找 3 个部门主管签字。
2. 第 2 周：把未来 6 周所有在跑事项收进一个池子，字段只要 5 个。不要清洗历史数据。
3. 第 3 周：给瓶颈角色打技能标签，只打 5 到 8 个角色，不要全员铺开。
4. 第 4 周：开第一次产能评审会，只排下周，只解决一个冲突，形成一份可追溯的排期。
5. 第 5 周起：每周重复第 4 周的动作，第 8 周再考虑上报表和预警。

这个路线的关键设计是把工具和报表放在最后。因为流程没跑通之前上报表，只会得到一堆没人看的图。

七、不同情况下的取舍：没有最优解，只有代价可接受的选择

1. 精细度与维护成本

颗粒度越细，预警越准，但维护成本呈平方级上升。做到“人 × 日”的团队，通常需要专人维护，而且数据很快会失真，因为没人愿意每天更新。

我的经验分界线是：非瓶颈角色做到“角色 × 周”就够，瓶颈角色做到“人 × 周”。再细的收益不足以抵消维护成本。

2. 集中排期与部门自治

集中排期能提高整体效率，但会牺牲部门的响应速度；部门自治灵活，但容易出现资源割据。这个取舍没有标准答案，取决于业务的波动性。

波动大的业务（定制交付、客户项目）更适合集中排期，因为需要全局视角做置换；波动小的业务（平台研发、基础设施）更适合部门自治，因为局部最优就是全局最优。

3. 高利用率与交付弹性

这是最核心的一组取舍。把承诺负载从 85% 提到 95%，账面产能多出 10%，代价是交付周期可能翻倍、加班成本上升、关键人员流失风险增加。

我的判断标准是延迟代价与人力成本的比例。如果一次延期造成的损失远高于多养 10% 产能的成本，就应该选低利用率高弹性；反之则可以提高利用率。

4. 表格自建与平台化

100 人以下用表格完全够用，甚至更好，改字段不用等排期。但超过 150 人后，表格的三大问题会集中爆发：权限不可控、数据不能实时汇总、变更有历史但无追溯。

平台化的真正价值不是可视化，而是让承诺可追溯。当你能查到“这个排期是谁在什么时候改的、改之前是什么”，仲裁才有依据。这也是我在 100 人以上组织里倾向用 PingCode 这类平台的原因，它的价值在于需求、任务、工时、度量在一条链路上，而不是某个单独的负载视图做得多漂亮。

但要提醒一点：平台化不解决流程问题。我见过把平台用成高级 Excel 的团队，字段填得满满当当，仲裁会一次没开过，负载照样失控。工具能放大机制的效果，也能放大机制的缺失。

八、把“一文讲清”变成“一月跑通”

回到最开始那个 74% 的故事。那家团队后来做的第一件事不是买工具，也不是画更漂亮的资源视图，而是把三个部门主管拉到一个会上，让他们当着面把下个月的三份排期表合成一份，然后删掉其中 11 个事项。删完之后，那个固件工程师的负载从 128% 降到 96%，三个项目里有一个延期了两周，另外两个按期交付。

这就是我对资源负载管理最核心的独特判断：它不是一门关于测量的学问，而是一门关于放弃的学问。你能测得多准，取决于你有多大的权力去砍掉那些“都很重要”的事。所有把负载管理做成纯数据工程的尝试，最后都会退化成一份没人看的周报。

另外三个我想强调的观点，也是这篇文章和常见写法不太一样的地方。第一，填报完整度和交付能力无关，先建承诺机制再要求填报，顺序反了会白费半年。第二，缓冲只能加在瓶颈上，全员加缓冲等于没加，还会让账面产能虚高。第三，需求收敛的收益远大于负载可视化，一个季度能砍掉 40% 的无效需求，比任何排期算法都管用。

至于下一步，我建议你不要从工具开始，而是从下面三件事里挑一件，这周就做：

1. 找出你们团队负载最高的 5 个人，问他们“这周有几件事是别人塞给你的”。这个答案通常能立刻暴露需求入口的问题。
2. 用四层折算算一次真实的可承诺产能，跟自己团队现在用的分母比一比。差 30% 以上，说明你的所有负载数据都要重算。
3. 定下下周一个 45 分钟的会，参会者必须有权说“这个不做”。如果找不到这样的人，那才是真正的问题所在。

资源负载全流程说到底是三张表的事：一张说清“要做什么”，一张说清“能做多少”，一张说清“先做哪个”。三张表对齐的那天，你会发现资源管理其实不需要复杂的算法，它需要的是一群愿意在同一张纸上做取舍的人。