资源平衡管理指南：研发团队如何做好资源负载，流程优化全流程

一、核心结论：资源平衡管的是流动，不是占满

先把结论放在最前面：研发资源平衡管理本质上是一道排队系统设计题，而不是一道排班题。排班题追求"每个人每一天都有活干"，排队题追求"任务在系统里的总停留时间最短"。这两者的最优解往往相反，前者推高利用率，后者要求主动留出余量。

1. 资源平衡的真正目标是把交付波动压下去

我在做资源盘点时见过太多"平均负载 82%"的漂亮报表，但把每个人的周负载拉成分布一看，30% 的人超过 110%，25% 的人低于 60%。平均值 82% 是统计幻觉，真正决定交付的是那条分布曲线的右尾。

所以我给资源平衡下的定义是：在给定产能约束下，让负载分布的右尾（P90）不超过可持续上限，同时让关键路径上的资源不出现空转等待。它衡量的不是"人有没有闲着"，而是"负载曲线平不平、关键资源断不断"。这个定义一变，后面所有的指标、流程、工具选型都会跟着变。

2. 先分清资源平滑与资源平衡，这两件事不能混为一谈

项目管理的经典定义里，资源平滑（Resource Smoothing）是在不改变项目总工期的前提下，利用浮动时间调整任务，把负载峰值削平；资源平衡（Resource Leveling）则是允许延长工期来消除资源冲突。前者动的是非关键路径上的任务，后者动的是排期本身。

绝大多数研发团队嘴上说要做资源平衡，实际想要的却是资源平滑，既不想改交付日期，又想让人不加班。这在资源冲突严重时是不可能的。你必须先明确这一轮调整允许牺牲什么：是日期，是范围，还是质量。不谈这个前提，所有资源平衡会议最后都会变成"谁的项目更紧急"的辩论赛。

3. 瓶颈资源的负载曲线决定交付上限

一个 40 人的研发团队，可能有 12 个后端、10 个前端、8 个测试、4 个产品、3 个架构、3 个运维。但真正卡住交付的往往只有 4 到 6 个人：某个中间件负责人、某两个测试环境的维护者、某个既懂业务又懂数据的资深工程师。

我的经验是：资源平衡的有效动作有 80% 发生在 20% 的瓶颈资源上。把全员负载从 95% 降到 85%，收益远不如把那个卡住三个项目的架构师从 140% 降到 100%。所以第一步永远不是拉全体负载表，而是先把瓶颈资源标出来。

4. 负载必须看分位数，平均值会骗人

我在给团队做诊断时，会固定看四组数：P50、P75、P90 和超载人数占比。P50 告诉你团队常态有多满，P90 告诉你最忙的那批人撑到什么程度，超载占比告诉你风险敞口有多大。

一个健康的研发团队，周负载分布大致应该落在：P50 在 65%-75%，P90 不超过 95%，超载（>110%）人数占比低于 10%。低于这个区间说明产能浪费，高于这个区间说明在用加班和延期透支未来两到三个迭代。

5. 资源平衡是流程设计问题，不是排期表问题

很多团队的失败在于把资源平衡当成"每个月填一次表"。排期表是结果，不是机制。真正起作用的是流程：需求进入前有没有容量评估、迭代开始前有没有负载预检、执行中有没有超载预警、迭代结束有没有偏差复盘。

没有这四道关口，排期表最多能保质两周。这也是为什么我更愿意先帮团队设计"周节奏"和"准入规则"，再去讨论用什么工具承载，工具能放大流程，但不会替你发明流程。

二、背景与真实场景：并行度是怎么悄悄失控的

1. 从 30 人到 120 人，并行度增长得比人数快得多

30 人的团队，通常同时跑 2 到 3 个项目，负责人靠脑子就能记住谁在做什么。到了 80 人，项目数会变成 6 到 8 个，但更麻烦的是"支持性工作"同步膨胀：线上问题排查、客户定制、数据提取、跨部门评审、合规审计。

这些工作不会出现在任何项目计划里，却实打实地吃掉产能。我的观察是：当组织规模翻倍，隐性工作量的增长通常是 2.5 到 3 倍，因为它随协作边数增长，而不是随人数线性增长。这就是资源负载失控的起点。

2. 三种典型现场，问题表现完全不同

项目制（资源独占）：每个人归属一个项目，资源边界清晰。问题是项目间忙闲不均，A 项目 5 个人闲着等测试，B 项目 3 个人连续两个月 120% 负载，但因为人不能借调，只能各自扛着。这类组织的资源平衡重点是建立跨项目借调机制和统一的技能标签。

职能制（资源池）：人归属职能线（后端组、前端组、测试组），按需派给项目。资源利用率高，但排期依赖职能经理的判断，容易出现"谁嗓门大谁先拿到人"。这类组织的重点是建立透明的派工规则和排队顺序。

混合矩阵：中大型企业最常见的形态，也是资源平衡最难的一种。员工有职能主管和项目经理两个上级，考核在职能线，任务在项目线。资源冲突时没有仲裁机制，最终演变成私下协商和人情调度。

3. 研发负载为什么比制造业更难平衡

制造业的资源平衡有标准工时、有工艺路线、有明确的产出单位。研发没有。同样是"开发一个导出功能"，熟手 2 天，新人 6 天，中间还可能因为依赖方接口变更返工。

这带来三个后果：一是估算天然有方差，二是任务颗粒度不均匀，三是工作可拆分性差，你没法让三个人同时写一个模块，硬拆只会增加沟通成本。所以研发的资源平衡不能追求精确到小时，只能追求"在合理的置信区间内不超载"。

4. 一个真实的季度复盘

2023 年下半年，我参与过一家做企业服务的公司（研发约 130 人）的季度复盘。他们的问题很典型：三个产品线共用同一套基础平台团队，平台团队 9 个人，同时支撑 7 个在研项目。

拉出来的数据显示：平台团队周负载 P50 是 96%，P90 是 138%，连续 11 周有人周末提交代码。而三个产品线的需求到达完全没有节奏，随时插单。复盘时平台负责人说了一句话我印象很深："我们不是资源不够，是没有排队规则，谁先喊谁先做。"

后来他们没有加人，只做了三件事：设定每周固定的需求评审窗口、给平台团队预留 20% 的应急产能、把需求按影响面分级并公开排队顺序。八周后 P90 从 138% 降到 104%，需求平均等待时间从 13 天降到 7 天。

三、常见误区：六个把资源平衡做反的动作

1. 误区一：把资源利用率当成效率指标

这是最普遍也最有害的一个。利用率的分母是可工作时间，分子是被分配的工作量。这个指标天然鼓励"多接活"和"少留余量"，而排队论早就证明：当系统利用率超过 80%，平均等待时间会以非线性方式上升。

用 Kingman 近似公式看更直观：等待时间与 ρ/(1-ρ) 成正比。利用率 70% 时这个系数是 2.33，80% 时是 4，90% 时是 9，95% 时是 19。也就是说，从 80% 推到 95%，产能只多了 15%，排队时间却翻了近 5 倍。

2. 误区二：用工时填报代替负载预测

工时填报是事后记录，负载管理需要的是事前预测。我见过很多团队每周花大量时间催填工时，然后拿上周的实际工时去排下周的活，本质上是在用后视镜开车。

更麻烦的是，工时数据本身有系统性偏差：加班时间少填、会议时间不填、碎片化的支持工作懒得分摊。我做过一次对照，同一个团队里，工时系统记录的周均投入是 36 小时，而通过日历+代码提交+工单处理的交叉估算得到的实际投入是 47 小时，偏差超过 30%。

正确的做法是双轨制：用计划负载（基于需求估算和容量模型）做前瞻排期，用实际工时做偏差校正，重点是看两者之间的差异在扩大还是收敛。

3. 误区三：把资源平衡做成"平均分配"

平均分配在资源平衡里是个陷阱。它假设所有人的产出效率相同、任务可以任意拆给任何人、切换成本为零，这三条在研发场景里全部不成立。

资源平衡要追求的是关键路径上的连续性和非关键路径上的弹性，不是数字上的平均。一个资深工程师负载 105% 但全程在关键路径上连续推进，可能比"平均 85% 但每周换三个项目"的人产出更高。

4. 误区四：只平衡人，不平衡需求

资源平衡的另一半是需求侧管理。当产能已经压到 90%，继续在人力侧腾挪只是在做零和博弈；真正的解法是控制流入，砍范围、延日期、分批交付、降低验收标准。

我在实践中会把需求分成四类：必须本期交付、可以降级交付、可以延后一期、可以直接拒绝。每个迭代开始前强制做一次分类，通常能释放出 15%-25% 的产能压力，比任何排期优化都有效。

5. 误区五：一次性大盘点，没有节奏

很多团队每年做一次资源盘点，做完写一份 PPT，然后一年不再更新。但研发的资源状态是周级变化的：有人离职、有人转岗、有人被临时借调、有人休长假。

我建议的节奏是三层循环：每周做一次负载预检（15 分钟，看下周超载名单），每个迭代做一次容量校准（1 小时，对齐估算偏差），每季度做一次资源结构复盘（半天，看技能缺口和瓶颈迁移）。三层循环缺一层，资源平衡就会退回拍脑袋。

6. 误区六：忽略技能维度，只数人头

"我们还有 5 个人可用"这句话在研发场景里几乎没有信息量。这 5 个人会不会 Go、懂不懂这套交易链路、能不能独立做数据库变更评审，决定了他们能不能真正缓解瓶颈。

我通常要求团队维护一张技能矩阵：行是人，列是能力项（语言、中间件、业务域、系统模块），格子里是 1-4 的熟练度。这张表的价值不在于精确，而在于让"看起来有 5 个人可用，实际上只有 1 个人能顶"这类问题提前暴露。

四、专业判断逻辑：四个判断把资源平衡做对

1. 三个前置定义：容量、负载、约束

在讨论任何指标之前，先把三个词定义清楚，否则后面的所有计算都是各说各话。

容量（Capacity）：一个资源在给定周期内可用于项目工作的净时间。不是 40 小时，而是 40 小时减去会议、支持、培训、休假、以及一个合理的效率折扣。我给团队的建议是：后端容量按 26-30 小时/周计，测试按 24-28 小时/周计，产品按 20-24 小时/周计，具体数值用历史数据校准。

负载（Load）：已分配和计划分配的工作量，按角色或技能折算成同一单位（人天或人时）。关键是单位统一，不能用故事点算需求、用人天算支持工单，然后直接相加。

约束（Constraint）：真正限制系统产出的那一个环节。它可能是人（某个专家）、可能是环境（测试环境）、可能是流程（变更审批窗口）、也可能是外部依赖（第三方接口开通）。资源平衡的第一动作永远是找约束。

2. 判断一：负载是否超过可持续上限

我给的经验阈值是：个人周负载的可持续上限为 100%，团队平均负载的合理区间为 70%-85%，超过 85% 就需要主动干预。

这里的"可持续"含义是：在不依赖长期加班、不牺牲代码质量、不推迟技术债偿还的前提下能维持的水平。超过这个水平，你会先看到代码评审通过率下降和质量问题上升，两到三个迭代后才看到交付延期，那时候已经晚了。

3. 判断二：瓶颈是否落在关键路径上

同样的超载，落在关键路径上和非关键路径上，处理方式完全不同。非关键路径上的超载往往可以用浮动时间消化，关键路径上的超载会直接等比延长工期。

判断方法是把资源负载和任务依赖图叠在一起看：标出所有负载超过 110% 的资源，然后检查其中有多少个正在关键路径上。如果超过三个，这个版本的计划基本可以判定为不可行，需要立刻做范围或日期调整。

4. 判断三：排队时间是否已经指数化

这是最容易被忽略的判断。很多团队只看"大家忙不忙"，不看"需求等了多久"。但用户感知的是后者。

我会算一个简单的比值：排队比 = 需求在队列中的平均等待时长 ÷ 实际加工时长。健康值在 0.5 以下，0.5-1.0 说明系统接近饱和，超过 1.0 说明排队已经成为主要成本，此时增加产能的边际收益最高，继续优化加工效率几乎没有意义。

5. 判断四：切换成本是否吞掉了缓冲

上下文切换的成本在研发场景里被严重低估。业界的普遍观察是：被打断后重新进入深度工作状态需要 15-25 分钟，而一个人同时跟进 3 个以上任务时，有效产出会下降 20%-40%。

我的判断口径是：人均并行活跃任务数超过 2.5 时，需要强制收敛。做法不是让人少干活，而是让任务的"活跃状态"变少，其余任务进入明确的等待状态（等评审、等环境、等依赖），而不是"挂着但没进展"。

6. 一套可落地的计算口径

下面是我在多个团队里用过的口径，逻辑简单但一致性强，好处是所有指标都能追溯到同一套输入。核心是三个函数：容量折算、周负载率、排队时间估算。

import statistics
def weekly_capacity(nominal_hours=40, meeting=7, support=5, admin=2, efficiency=0.85):

"""净容量：名义工时扣除固定损耗，再乘效率折扣"""

return (nominal_hours - meeting - support - admin) * efficiency

def load_ratio(committed_hours, capacity_hours):

"""周负载率：>1.0 即为超载"""

return committed_hours / capacity_hours

def queue_days(arrival_rate, service_rate, cv=1.0):

"""Kingman 近似：估算平均排队时长（天）"""

rho = arrival_rate / service_rate

if rho >= 1:

return float("inf")          # 系统不稳定，队列无界增长

ca2 = cs2 = cv ** 2

wait = ((ca2 + cs2) / 2) * (rho / (1 - rho)) / service_rate

return wait

一次团队级诊断

loads = [0.62, 0.71, 0.78, 0.83, 0.88, 0.94, 1.06, 1.18, 1.31, 0.69]

print("净容量:", round(weekly_capacity(), 1), "小时/周")

print("P50:", round(statistics.median(loads), 2))

print("P90:", round(sorted(loads)[int(len(loads) * 0.9) - 1], 2))

print("超载占比:", round(sum(1 for x in loads if x > 1.1) / len(loads), 2))

这段代码的价值不在于复杂，而在于它把"感觉大家都很忙"变成了可复现的数字。当 P90 超过 1.0、超载占比超过 10% 时，任何"再挤一挤"的排期承诺都应该被拒绝，因为那不是排期问题，是系统稳定性问题。

7. 资源平滑与资源平衡的选择逻辑

回到第一章的区分，具体怎么选，取决于一个判断：峰值负载是否超过可持续上限，以及这个峰值是否落在关键路径上。

如果峰值只在 100%-110% 之间且不在关键路径上，优先做资源平滑：利用非关键任务的浮动时间错峰，工期不变。如果峰值超过 120% 或落在关键路径上，必须做资源平衡：接受工期延长或范围削减，把峰值压到 110% 以内。

五、案例与数据观察：从指标到机制的落地过程

1. 样本说明与观察口径

下面这组观察来自我在 2023 年至 2024 年间深度参与的 11 个研发组织，规模从 45 人到 620 人不等，行业集中在企业服务、金融科技和智能硬件。方法是对每个组织做前后对比，观察窗口为机制落地后的 3 个季度。

需要说明的是：这些是实践观察，不是严格的双盲对照实验，组织同期还存在人员变动、需求变化等干扰因素。我只保留那些在多个组织中重复出现、且方向一致的模式，因此结论更适合当作"经验基准"，而不是精确的因果估计。

2. 观察一：负载标准差比平均负载更能预测延期

我把 11 个组织的季度数据按"周负载标准差"分成两组：低于 0.7 的一组和高于 1.2 的一组。前者的版本按期交付率均值是 82%，后者是 61%。而两组的平均负载分别是 79% 和 81%，几乎没有差别。

这个发现让我彻底放弃了"平均负载"作为主指标。同样是 80% 的平均负载，分布紧的团队能按时交付，分布散的团队一定延期。原因很直白：延期由最忙的那批人决定，不由平均值决定。

3. 观察二：并行度超过 2.5 后，流动效率断崖式下降

我用"人均活跃任务数"作为并行度的代理指标，和"流动效率"（加工时间 ÷ 总周期）做了对照。人均活跃任务在 1.5 以下时，流动效率中位数是 38%；1.5-2.5 之间是 31%；超过 2.5 之后掉到 19%。

更值得注意的是一组反向数据：在并行度最高的三个团队里，工程师自报的"感觉非常忙"比例是 91%，但代码提交的净增量（扣除重构和回滚）反而低于并行度中等的团队。忙的感觉和实际产出在这条线上彻底脱钩。

4. 用 PingCode 承载资源平衡流程的实际做法

流程设计清楚之后，需要一个载体把规则固化下来，否则每次都要靠人盯。在我们服务的这些中大型组织里（多数在 100 人以上、多产品线并行），比较常见的做法是用 PingCode 这类研发管理平台把需求、项目、工时、资源视图串成一条线。

（1）统一工作项，让负载有可计算的输入。资源平衡算不准，十有八九是因为工作散落在多个系统：需求在文档里、缺陷在另一个工具里、支持工单在 IM 里。把这些统一成同一套工作项之后，"某人本周被分配了多少"才第一次成为一个可查询的问题，而不是每周手工汇总的 Excel。

（2）用迭代容量而非人数做排期准入。在迭代规划时先录入团队净容量，需求进入迭代时系统就会提示超配。这一步看似简单，实际效果很直接：它把"这个迭代能不能装下"从会议上的争论，变成了规划时就摆出来的数字。

（3）资源视图要按角色和技能两个维度切。只看"后端组还有 3 个人"是不够的，要看这 3 个人覆盖哪些模块。我们在配置时会把技能标签维护在工作项和人员档案上，这样资源冲突能提前到"派工时"而不是"开发到一半"才暴露。

（4）把工时数据用于校准，而不是用于考核。这是最容易做偏的一环。一旦工时和绩效挂钩，数据立刻失真。正确的用法是每季度拿实际工时和计划估算做对照，修正容量模型的系数，让它越来越贴近真实。

（5）度量看板固定四个数：负载分布、超载占比、需求排队时长、按期交付率。不要贪多。我见过配置了三十多个图表的看板，最后没人看。四个数足够支撑每周的负载预检会议，也足够让管理层判断是否需要调整范围。

5. 落地过程中的三个意外发现

（1）最先见效的不是排期，是需求准入。多数团队以为资源平衡要从排期优化入手，但数据显示，仅靠"每个迭代固定准入窗口 + 强制分级"这一条，就能让超载占比下降 8-12 个百分点，成本几乎为零。

（2）瓶颈会迁移，机制必须跟着走。有个团队把后端瓶颈解决后，三个月内测试环境成了新瓶颈，负载从 74% 涨到 118%。这说明资源平衡不是一次性项目，而是持续识别约束的循环。

（3）管理层的参与方式决定成败。凡是把资源平衡当成"团队自己协调"的组织，三个月内全部退回原点；凡是管理层愿意在每个版本规划会上做一次范围取舍的组织，机制才能稳定运行。因为资源平衡的本质是取舍，而取舍权不在执行层。

六、行动建议：按组织规模给不同的起手式

1. 30 人以下团队：先建节奏，不要建体系

这个规模的团队，资源平衡靠人盯是完全可行的，没必要上复杂模型。核心动作只有三个：每周一次 15 分钟负载预检、每个迭代固定容量上限、明确一个"什么情况下可以插单"的规则。

• 建立周负载表：一张表，行是人，列是本周任务和预估工时，超出净容量的标红。
• 设定迭代容量红线：承诺工作量不超过团队净容量的 85%，剩下 15% 留给插单和线上问题。
• 插单必须换出：任何新插入的需求，必须同时指出被换出的旧需求，不允许"加了再说"。

2. 30-100 人团队：把负载变成可见的数字

这个阶段靠脑子记不住了，核心是建立统一口径。重点是把容量模型、负载计算、排队时长这三个数固定下来，并且让所有人看到同一份数据。

1. 用两周时间采集历史数据，校准各角色的净容量系数。
2. 把所有在跑的工作（需求、缺陷、支持、技术债）纳入同一套工作项管理。
3. 每周输出一次负载分布（P50/P90/超载占比），在周会上公开。
4. 每个迭代做一次估算偏差复盘，修正系数。

3. 100-500 人多项目组织：建立资源池与排队规则

这个规模的核心矛盾是"多项目争抢共享资源"。解法不是让每个人更努力，而是建立透明的排队规则和可借调的技能池。

（1）建立统一的技能矩阵和资源池视图。让人和任务按技能标签匹配，而不是按部门归属匹配。这一步通常能释放 10%-15% 的隐性产能。

（2）设定共享资源的产能分配比例。比如基础平台团队把 60% 产能分配给承诺项目、25% 给按需支持、15% 作为应急缓冲，比例公开，任何调整都需要走变更。

（3）建立需求分级与排队顺序。把需求按影响面分级（P0 故障、P1 核心客户、P2 常规迭代、P3 优化），同级按到达时间排序。规则公开之后，"谁嗓门大"的问题自然消失。

（4）用平台承载规则而不是用会议承载规则。这个规模下，规则必须固化在系统里才有执行力，否则每次都要重新讲一遍。

4. 500 人以上多业务线：做资源治理，不做资源调度

这个规模再去追求"统一调度每一个人"是不现实的，成本会超过收益。合理的做法是分层治理：业务线内部做调度，跨业务线做治理。

治理层关注三件事：一是关键岗位的单点依赖风险（哪些人一旦离开会导致某个系统无人能接），二是跨线共享资源的产能分配规则，三是整体产能投入结构的健康度（新功能、维护、技术债的比例是否失衡）。

我建议的健康比例大致是：新功能 55%-65%，维护与线上支持 20%-25%，技术债与效能建设 15%-20%。技术债比例长期低于 10% 的组织，两年后一定会在交付速度上付出代价，这个规律我在多个组织里反复见到。

5. 一份可以直接照着做的 90 天路线

七、取舍：资源平衡里没有最优解，只有明确代价的选择

1. 利用率与响应速度，只能选一个偏重

高利用率意味着低余量，低余量意味着任何突发都要排队。如果你的业务特征是需求波动大、线上问题多、客户定制频繁，那么把团队利用率压在 75% 左右是理性的，不是浪费。

反过来，如果业务处于明确的交付窗口期、需求稳定、变更受控，把利用率推到 85% 是可以接受的短期选择，但要明确这是"冲刺期"而不是"常态"，并且设置退出条件。

2. 资源独占与资源共享，取决于任务的连续性要求

资源独占的代价是利用率损失，收益是上下文切换少、知识沉淀深、交付确定性高。资源共享的收益是利用率高，代价是协调成本和切换损耗。

我的判断标准是：如果任务的认知负荷高、需要连续深度工作（如核心架构改造、复杂算法调优），优先独占；如果是标准化、可拆分的任务（如常规需求开发、配置类工作），优先共享。把这条标准写进派工规则，比笼统地说"要灵活"有用得多。

3. 精细排期与粗粒度滚动，取决于不确定性水平

精细到人天的排期在需求稳定的团队里有效，在需求变化频繁的团队里是纯粹的浪费，每次变更都要重排，排期表很快失去可信度。

我的建议是按置信度分层：未来 2 周排到人天级，第 3-6 周排到人周级，第 7 周以后只做到版本级和大致人数。这样既保证近期可执行，又不至于在远期投入过多排期成本。

4. 工具强制与管理自律，取决于组织成熟度

工具能强制的是流程节点（比如不填容量就不能启动迭代），强制不了的是判断质量。在成熟度低的组织里，过度依赖工具强制会催生"为了通过校验而填假数"的行为，反而让数据更不可信。

合理的顺序是：先用轻量方式跑通三个迭代，让团队理解为什么要做，再逐步把规则固化到工具里。反过来做，通常得到一套漂亮但没人信的数据。

5. 短期救火与长期产能建设，必须有固定比例

资源平衡最大的组织阻力来自"现在就要交付"。如果所有产能都被当期需求吃掉，技术债、自动化、平台建设永远排不上，两年后整个团队的交付能力会系统性下降。

我的建议是把它变成硬性约束而不是道德劝说：每个迭代固定预留 15%-20% 的产能给效能建设，并且不允许被业务需求挤占。这条规则一旦被破例三次以上，就再也守不住了，所以在机制设计上要让它难以被绕过。

八、总结：把资源平衡做成一种组织习惯

1. 三个我认为最值得记住的判断

第一，资源平衡的目标是压低负载分布的右尾，不是提高平均利用率。平均值改善但标准差不变，等于什么都没做。诊断时先看 P90 和超载占比，再看平均值。

第二，瓶颈永远比总量重要。把 20% 的瓶颈资源从 130% 降到 105%，比把全员从 90% 降到 80% 有效得多。每季度的第一件事应该是重新识别瓶颈，因为瓶颈会迁移。

第三，资源平衡的收益主要来自压缩等待，不是压缩加工。流动效率 25% 的系统里，把开发时间从 4 天压到 3 天只提升 4% 的周期，但把测试环境等待从 5 天压到 1 天能提升 17%。

2. 下一步可以立刻做的四件事

1. 本周：拉出团队过去四周的负载分布，算出 P50、P90 和超载占比。如果 P90 超过 110%，先不要谈优化，先谈取舍。
2. 两周内：定义你们团队的净容量系数（各角色每周真正可用于项目的小时数），并用历史数据校准一次。
3. 一个月内：上线需求准入规则，每个迭代固定评审窗口、需求强制分级、插单必须换出。
4. 一个季度内：建立周负载预检会（15 分钟）和迭代估算偏差复盘（1 小时），让资源平衡从项目变成习惯。

最后想说一句可能不太讨喜的话：资源平衡做不好的团队，绝大多数不是缺工具、缺方法，而是缺一次真正的取舍。当所有需求都是"必须做"、所有日期都是"不能改"的时候，任何资源平衡模型都只是在为一个不可行的计划做数学装饰。真正的起点，是有人愿意在会议上说出"这个版本我们只能做其中三件"。