超负荷怎么做？研发团队流程优化：资源负载从0到1

去年十一月，我陪一家做企业服务的研发组织做季度复盘。他们 4 个研发小组、118 名工程师、9 个迭代，Sprint 承诺完成率连续三次停在 62% 附近，可每个人的日程表看起来都是满的。CTO 说了一句我记到现在的话："我们不缺努力，缺的是知道自己到底能装多少。"

这就是"超负荷"最典型的形态：不是有人闲着，也不是有人被压垮，而是整个系统对"自己能承接多少"没有共同答案。需求照常进来，承诺照常给，延期照常发生，复盘照常归因为"评估不准、执行不力"。

这篇文章讲的是把研发资源负载从 0 建到 1 的过程。它不是做一张漂亮的负载表，而是建立一条最小闭环：需求进入 → 产能折算 → 承诺判断 → 超载处置 → 下周修正。文中用到的方法、阈值和数据，来自我参与过的三次落地（60 人、120 人、400 人规模各一次）和二十多个研发团队的访谈观察。样本不大，所以凡是实测数据我都标了口径，凡是推演出来的数字我都会写明是示意。

一、先给结论：资源负载从 0 到 1，做的不是表，是承诺机制

如果只能记住一句话，那就是：资源负载的价值不在"看见谁忙"，而在"让承诺变得可以被讨价还价"。没有这个前提，负载表做得再细，最后也只是给加班找个证据。

1. 结论一：超负荷是"进入端"的问题，不是"执行端"的问题

我复盘过 7 个承诺完成率长期低于 70% 的团队，其中 6 个团队的单条需求平均工时估算偏差都在 ±25% 以内，也就是说，工程师估得并不离谱。真正的问题是同一周进入的需求工时是可用产能的 1.4 到 1.8 倍。执行端再优化，也消化不掉 60% 的超出量。

所以流程优化的第一刀应该切在需求进入的闸门上：谁有权把一个需求塞进本周，塞进来要扣掉谁的时间。这个问题不解决，任何排期工具都只是把混乱记录得更整齐。

2. 结论二：负载必须用"可用人周"计量，任务条数是无效口径

同一个团队、同一周，用不同口径算出来的负载率能差出 40 个百分点。任务条数把"改一个文案"和"重构一个鉴权模块"算成一样重；故事点只在团队内部可比，跨团队一比就失真；人天口径如果不扣除会议、支持、评审、休假和上下文切换，会系统性高估产能。

我的建议只有一个口径：可用人周（Available Person-Week）。它是把"名义人力"按周折算、扣掉一切非交付占用之后剩下的真实可承诺时间。一个 10 人的小组，名义上是 10 人周，可用往往只有 6.5 到 7.2 人周。

3. 结论三：0 到 1 阶段只需要盯住一个数字，承诺负载率

不要一上来就做十二个维度的人力报表。从 0 到 1 阶段，一个数字就够：本周承诺负载率 = 本周已承诺需求的折算工时 ÷ 本周可用人周 × 100%。它只回答一个问题：这次承诺，我们是不是又接多了。

我在 120 人那家公司的做法是，先只让 4 个小组连续记录 6 周的这一个数字，不做任何考核、不发任何通报。第 7 周把 6 条曲线摆在一起，组长们自己就看出了模式：有 2 个组长期在 130% 以上，而它们的需求来源都指向同一个业务方。共识不是我说服出来的，是数据摆出来的。

4. 结论四：没有缓冲的负载表，最后都会变成加班表

很多团队第一次做负载视图，把每个格子填到 100% 才算"排满"，结果表格看起来非常漂亮，实际一遇到线上问题就全线崩。原因很简单：100% 的排布等于 0 的容错。研发工作天然有不确定性，需求变更、依赖阻塞、线上故障都会吃掉计划时间。

我的经验值是给每个小组留 12% 到 18% 的缓冲，专门用来吸收三类事情：紧急缺陷、跨组支持、以及给下个迭代做技术准备。缓冲不是浪费，它是让承诺能被兑现的成本。

5. 结论五：可视化的第一用途是谈判，不是监控

这一点我在推行的第一年吃过亏。第一版负载看板做出来，我兴冲冲地放到大屏上，结果两周内数据全变成了"填得刚好 95%"。因为所有人都知道这东西会被上级看到，填满反而安全。

后来我们改了三条规则：看板只对"需求方 + 交付方"开放，不作为个人绩效输入，超载超过 120% 时组长有权直接把需求退回。数据质量立刻回来了。负载数据一旦和考核挂钩，它就从测量工具变成了表演工具，这是我在多个组织反复验证过的规律。

二、超负荷是怎么长出来的：一个 118 人研发组织的季度切片

抽象地谈超负荷没有意义，我把它拆成一条时间线看。下面这个案例来自 2023 年一家企业服务公司的真实季度，数据由他们的项目管理平台导出后我做了清洗，团队规模 118 人，业务是 B 端 SaaS 的中台与行业版本并行开发。

1. 四周时间线：一次超负荷的完整生长过程

第 1 周，季度规划会上定了 46 个需求，折算 1,180 人天；同期可用产能约 940 人天（已扣减）。会上没有人提出异议，因为"大家觉得努力一下能行"。这就是超负荷的第一个动作：在规划阶段就把 125% 当成 100%。

第 2 周，两个行业客户提出定制需求，商务侧直接答应"两周内给版本"。这类需求没有进入排期池，而是以"临时插单"的形式散落到 3 个小组，共 210 人天。管道里多出了 22% 的隐形负载，但看板上完全看不见。

第 3 周，中台组的一个核心依赖延期 5 天，导致下游 2 个小组共 9 个任务处于阻塞状态。阻塞期间人并没有闲着，而是被安排去做"顺手能做完"的小需求，于是任务并行度从平均 1.6 涨到 2.4，上下文切换成本开始显现。

第 4 周，为了赶季度节点，3 个小组开始集体加班，日均工时从 7.6 小时涨到 9.8 小时。与此同时，测试环境排队，缺陷积压从 43 个涨到 118 个，交付质量开始反向拖累进度。

到最后一周，46 个需求完成了 27 个，完成率 58.7%，与开季时承诺的 100% 相差 41 个百分点。但真正的代价不是这 41 个百分点，而是下个季度初有 31% 的产能被技术债和遗留缺陷占用了。

2. 数据观察：进入速率是交付速率的 1.6 倍

把这 13 周的数据按周聚合，会看到一条很直白的曲线：周均需求进入折算工时是 396 人天，周均实际交付折算工时是 248 人天。比值 1.6，稳定得可怕，它不随迭代、不随人员变动，几乎是一条水平线。

这意味着什么？这个组织的产能缺口不是执行问题，是结构性的。只要进入速率不变，无论怎么优化排期、怎么加人，积压都会以每周 148 人天的速度增长。加人更麻烦：新人上手期平均 6 到 10 周，期间还会占用老员工 20% 到 30% 的带人时间，短期内产能是负的。

3. 四个入口：水是从哪灌进来的

顺着数据往上追，需求进入被拆成了四个来源，占比和可控性完全不同：

• 季度规划需求（52%）：有评审、有排序，理论上可控，但实际评审时只比"优先级"，不比"产能"，所以照样超量。
• 业务方临时插单（23%）：没有闸门，一句"客户很急"就能进来，是最主要的隐形负载。
• 线上问题与缺陷修复（17%）：刚性占用，但从来没有在排期时预留，全部靠挤压计划内工作。
• 跨团队支持与联调（8%）：不可见，因为不计入任何人的任务列表，只体现在"某人这周好像没什么产出"。

值得注意的是，可控性最差的 48%（插单 + 缺陷 + 支持）从来不出现在任何排期会议上。团队按 100% 的产能做计划，实际上只有 52% 的时间是可规划的。这不是管理不努力，是账没算全。

4. 为什么"加人"解决不了这个问题

我第一次遇到这个案例时，管理层的第一个反应是"招人"。我算了一笔账：缺口是每周 148 人天，按每人每周 5 人天算，需要 30 人。但新人 8 周上手期、老员工带人成本 25%，前两个月净增产能大约是负 45 人天/周。

更关键的是，加人不会改变需求进入速率。在一个没有闸门的组织里，产能增加会被进入量立刻吸收，三个月后你会看到同样的 1.6 倍比值，只是绝对值更大了。这种情况我在两个团队都见过，业内一般叫它"产能黑洞"。

三、拆解六个误区：关于资源负载，大家最容易想错的地方

资源负载这件事的难点不在技术，在于它触碰了太多默认假设。下面六个误区，是我在访谈和落地里出现频率最高的，每一个都对应一次真实的返工。

1. 误区一：把"利用率高"当成管理目标

很多管理者的直觉是：人闲着就是浪费，利用率冲到 90% 以上才算健康。但研发工作和生产线不一样，它有大量隐性协作和不确定性，利用率超过某个点之后，交付周期会非线性上升。

我观察到的拐点大约在 80% 到 85% 之间（按可用人周口径）。低于这个区间，交付周期随负载缓慢上升；超过之后，排队时间开始主导周期，一个原本 3 天能排上的评审可能要等 8 天。同时并行任务数上升，返工率也跟着涨。

2. 误区二：用任务数或故事点当负载单位

任务数是所有口径里最容易操纵的一个。当团队知道负载按任务条数统计时，把一个大任务拆成五个小任务，"负载"立刻降下来，而实际工作量一点没变。我在一个团队见过极端案例：某小组平均任务颗粒度是其他组的 1/4，负载率永远显示 70%，实际是全场最忙的。

故事点的问题不同，它不是被操纵，而是不可比。同一个 5 点，在 A 组是"两天能搞定的接口联调"，在 B 组是"要跨三个系统的数据迁移"。用它做团队内部的相对估算没问题，用它做跨组的资源负载就是自欺欺人。

3. 误区三：先买工具，后定口径

这是我见过最贵的错误。有家公司先采购了项目管理平台，要求全员上线填工时，三个月后导出报表发现完全没法用，因为每个人的填写标准都不一样：有人填净工时，有人填含会议的总工时，有人一周只填一次凭记忆补。

正确的顺序是反过来：先定口径（什么叫可用人周、扣哪些项），再做一周的手工试算，验证口径能算得出来、算出来有人认，最后才上系统。工具解决的是采集效率和可视化，解决不了口径分歧。

4. 误区四：把负载表做成考核表

前面提过一次，这里单独说，因为它毁掉的系统比任何技术问题都多。一旦负载数据进入绩效，人的理性反应一定是"让数字好看"：任务拆细、工时填满、把难活推给别人、把简单活留在自己名下。

我给的原则是三条：负载数据只用于"承诺判断"，不进入个人评价；超载是组长的责任而不是个人的责任；退回需求不需要理由辩护，只需要引用负载数字。这三条一立，数据才敢真实。

5. 误区五：只算开发，不算测试、评审、支持和会议

只算开发的负载表，通常会高估 25% 到 35% 的产能。原因很具体：评审和联调的时间分散在每个人身上，线上支持的时间集中在少数几个人身上，会议时间全组平摊，三者加起来，一个 10 人小组一周大约被吃掉 28 到 34 人时。

我的做法不是精确统计每一项，而是用一个固定扣减系数起步：会议 10% 到 12%、线上支持 8% 到 10%、评审与联调 7% 到 9%，三项合计扣掉 25% 到 30%，先跑三个月，再用实测数据校准。精确到分钟的工时统计，成本远高于收益。

6. 误区六：0 到 1 阶段就想全自动

总有人问我能不能"自动识别负载、自动分配任务、自动预警"。技术上部分可以，但在 0 到 1 阶段做这个，通常结果是系统很聪明、没人信它。

因为自动化的前提是数据干净，而数据干净的提前是口径共识，口径共识的前提是有人手工算过一遍并且被现实打过脸。跳过手工阶段直接上自动化，等于把一个未经检验的假设固化成系统，后面推翻它的成本是前期的五倍。

四、专业判断逻辑：资源负载的四层模型

把上面这些经验收拢，我用的是一套四层结构：口径层决定"算什么"，采集层决定"数据从哪来"，判断层决定"多少算超载"，决策层决定"超载了怎么办"。四层缺一层，系统就会在某个环节漏气。

1. 第一层·口径层：可用人周怎么算

公式不复杂，难的是每一项的边界要写死：

可用人周 = 名义人力 × 周数 × (1 − 非交付占用率) × 在岗系数

其中非交付占用率包含会议、线上支持、评审联调、招聘面试、内部培训；在岗系数用来处理休假、病假、调休，一般取 0.92 到 0.95。以 10 人小组、单周为例：名义 10 人周 × (1 − 0.28) × 0.93 ≈ 6.7 人周。

请注意这个结果：名义 10 人周，可用只有 6.7 人周。这就是为什么"我们有 10 个人，怎么会做不完 10 人周的活"这个问题永远吵不出结果，双方用的根本不是同一个分母。

2. 第二层·采集层：三个数据源，填报成本必须可控

采集我一般只用三个来源，其余都靠推算：

1. 需求折算工时：需求进入时由交付方估算，允许 ±30% 误差，不为精度争吵，只保证量级正确。
2. 周度可用人力：由组长每周一更新一次，只填三个数：在岗人数、请假人天、本周特殊占用人天。
3. 承诺清单：本周承诺了哪些需求，这是唯一的"承诺"事实来源，与排期表必须一致。

三个数加起来，每个组长每周花 8 到 12 分钟。超过 20 分钟的采集方案，在第三周一定会烂尾，这是我在四个团队验证过的经验值。

3. 第三层·判断层：85 / 100 / 120 三档阈值

阈值不要设太细，三档足够，而且每一档对应一个明确动作，不靠人临场判断：

这里有个容易被忽略的细节：阈值必须连带动作用"，否则就只是三个颜色。我见过太多团队做出了漂亮的红黄绿灯，但红了之后什么也不发生，三周后大家就学会忽略颜色了。

4. 第四层·决策层：超载时的四个动作

超载之后其实只有四个选项，没有第五个。把它们写下来，是为了避免每次都变成一场情绪谈判：

• 削：砍掉范围。把需求拆成"必须这次上"和"可以下次上"，通常能砍掉 15% 到 25%。
• 缓：推迟时间。明确说出"最早什么时候能给"，比含糊地说"尽快"更有用。
• 换：换资源。从负载低于 85% 的小组调人，或把非核心模块外包，注意交接成本。
• 加：追加投入。加班、加人、加预算，必须承认它是有代价的，且代价会延后一期出现。

我要求每个团队在超载时必须从这四选一，并且写进记录。半年下来，最常见的选择是"削"（约 46%）和"缓"（约 31%），"加"只占 12% 左右。这个分布本身就是最好的管理成果：大多数超载被吸收在范围和时间上，而不是转成加班。

5. 一个可以直接用的计算脚本

手工算两周之后就该脚本化，但不要急着接系统。下面这段是我实际用过的口径计算脚本，输入是组长的三个数字，输出是可承诺产能与负载率，可以直接跑在表格或内部小工具里。

# 可用人周与承诺负载率计算（口径版本 v1.2）
输入：组长每周一填写的三个数字

HEADCOUNT = 10 # 在岗人数

LEAVE_DAYS = 2 # 本周请假总人天（含调休）

SPECIAL_DAYS = 1.5 # 本周特殊占用人天（面试、培训、外部支持）

固定扣减系数（首版经验值，三个月后用实测校准）

MEETING_RATE = 0.11 # 会议占用

SUPPORT_RATE = 0.09 # 线上支持

REVIEW_RATE = 0.08 # 评审与跨组联调

BUFFER_RATE = 0.12 # 预留缓冲

def available_person_weeks(headcount, leave_days, special_days):

nominal = headcount * 5 – leave_days – special_days # 名义人天

net = nominal * (1 – MEETING_RATE – SUPPORT_RATE – REVIEW_RATE)

return round(net * (1 – BUFFER_RATE) / 5, 2) # 折回人周

def load_rate(committed_person_days, apw):

return round(committed_person_days / (apw * 5) * 100, 1)
APW = available_person_weeks(HEADCOUNT, LEAVE_DAYS, SPECIAL_DAYS)
print("本周可承诺产能（人周）:", APW)          # 约 5.9 人周
print("承诺 32 人天的负载率:", load_rate(32, APW), "%")   # 约 108.5%

跑出来的数字第一次会让人不太舒服：10 个人的组，可承诺产能只有 5.9 人周。但就是这个数字，让后面所有关于"能不能再接一个需求"的讨论变得有据可依。

五、案例与数据观察：三种规模，三条不同的从 0 到 1 路径

同样是从 0 到 1，60 人、120 人、400 人的组织需要的做法完全不同。下面三个案例我都深度参与过，数据来自各自团队的迭代记录和我的回访，涉及具体经营数据做了模糊化处理。

1. 案例 A：120 人 SaaS 团队，先改口径再谈工具

这家就是我前面反复提到的企业服务公司。他们的第一版负载表是"每个小组的红色格子数量"，运行两周后彻底失效，因为没人知道红色代表什么。第二版我们只做了一件事：把口径从"任务数"换成"可用人周"，并强制所有排期会议用这个单位说话。

改变发生得比想象中快。第 5 周的规划会上，一个组长第一次说出"我们组这周只有 6.2 人周，你这三个需求是 9 人天，接不了"。这句话以前从没出现过，因为以前没有共同的度量单位。到第 12 周，季度承诺完成率从 58.7% 升到 79.4%。

2. 案例 B：400 人软硬混合团队，难点在共享资源池

这家做智能硬件，研发由软件、固件、硬件、测试四条线组成，400 多人。他们的特殊之处在于共享资源：测试设备、实验室、结构工程师、以及一个 9 人的平台架构组，四条线都要用。

前两版负载方案都失败在同一个地方：只算了人，没算稀缺设备和共享角色。软件线显示负载 82% 很健康，但实际卡在测试设备排队上，平均等 4.5 天。第三版我们加了"资源负载"和"人力负载"两条并行曲线，稀缺资源单独建池，用预约制而不是分配制，排队时间降到 1.8 天。

3. 案例 C：60 人团队，不上系统先上表

这家是个 60 人的创业公司，我建议他们前三个月完全不要采购任何系统。用一张共享表格，五列：小组、在岗人数、本周请假人天、承诺工时、负载率。每周一上午填，每周五复盘时看一眼。

三个月后他们才把这张表搬进项目管理平台。为什么值得等？因为三个月的表格过程让他们自己发现了口径问题：一开始大家填的"承诺工时"里包含了会议，导致负载率普遍虚高，两个月后才统一成净工时。如果一开始就上系统，这个错误会被固化成字段，改起来要动数据模型。

4. 中大型组织怎么把负载视图落进系统里

团队过百人之后，手工表格的维护成本会陡增：口径漂移、版本混乱、跨组汇总靠人肉。这个阶段才需要系统承接。以我在几家 100 人以上组织看到的落地方式为例，PingCode 这类面向中大型企业的研发管理平台，通常是这样承接负载视图的：

• 把"可用人周"变成字段而不是口头约定：在团队/迭代配置里固化在岗人数、请假人天、扣减系数，让它成为可复算的属性，而不是每个组长自己算一遍。
• 需求进入必须挂工时估算：需求工作项上设必填的折算工时字段，未填不能进入迭代，这是把闸门做进流程里。
• 用迭代容量与已承诺工时做实时比对：规划时直接看到"本迭代容量 34.5 人天 / 已承诺 41 人天"，超载在会议当场就暴露，而不是两周后才发现。
• 跨项目的资源视图：共享角色（架构、测试、DBA）可以按人看跨项目占用，避免"每个人都 80%、合起来 160%"的经典错配。
• 超载触发流转而不是只变色：负载超过阈值时推动需求进入"待裁决"状态，把决策动作固化到流程节点上。

需要说明的是，系统能解决的是采集效率和跨团队一致性，解决不了"愿不愿意把真实数字填进去"。后者只能靠前面说的三条规则：不进绩效、超载是组长责任、退回需求不需要辩护。

5. 三个案例的前后对比

三个案例有个共同点值得强调：真正起作用的动作都很小。案例 A 是换了一个计量单位，案例 B 是多建了一个资源池，案例 C 是推迟了三个月上系统。资源负载从 0 到 1 从来不是一套大工程，而是几个关键决定的组合。

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

下面按起点分类给建议。判断自己属于哪一类，比照搬任何一套方案都重要，我见过最失败的落地，就是把 400 人团队的做法照搬到 40 人团队。

1. 情况一：完全没数据，连工时有几个人在做什么都不知道

这是最典型的 0 阶段。不要做报表，不要买工具，先做一件事：连续 4 周，只记录"本周承诺工时"和"本周交付工时"两个数。用共享表格，每周一填、每周五更新。4 周后你会得到一张粗糙但真实的曲线。

判断标准很简单：如果连续 4 周交付工时都没超过承诺工时的 75%，说明问题不在产能，在于需求被反复打断或者优先级混乱，先别碰负载模型。

2. 情况二：有数据，但没人相信

通常是口径不统一导致的。建议做一次"口径对账"：让三个组长各自说出自己理解的"满载"是什么，把答案写在白板上。你会看到三种完全不同的定义，这本身就是最好的破冰材料。

对账之后只做一件事：把口径写成一段不超过 200 字的文字，贴在排期会的会议室里。能被一句话说清的口径，才有可能被真正使用；写成一页纸的规范，通常没人看。

3. 情况三：数据可信，但没人用它做决定

这是最常见的卡点，本质是"数据没有连到动作上"。解法是给阈值配动作：负载超 100% 必须削减一项需求，超 120% 需求方可以直接退回。规则一旦生效，数据立刻有了存在感。

另一个有效手段是改变会议顺序：先看负载，再看需求。以前是需求讲完了才看人力，那时候所有人都已经投入情绪，砍需求变成了"否定别人"。反过来，先看这周只剩 6.2 人周，再讨论需求，讨论的性质就变了。

4. 情况四：负载已经失控，正在救火

这种时候不能做长期模型，先做止血。三步走：第一步，把当前所有在途需求按"不做会怎样"排序，砍掉后 30%；第二步，冻结所有新增进入两周，只处理存量；第三步，用这两周腾出的时间建立最小口径。

要特别提醒：救火期最忌讳同时启动流程改革。人在高压下对任何新流程的容忍度都极低，这时候推负载模型，会得到一个"这玩意没用"的长期标签，后面再推要花三倍力气。

5. 情况五：多团队、跨部门、共享资源

这类组织的关键是区分"人力负载"和"资源负载"，两条线分开算。人力按人周，资源按占用时段（设备小时、环境时段、专家人时）。共享资源用预约制而不是分配制，让等待时间可见，很多时候超载不是因为人不够，是因为等待不可预期。

1. 先画出共享资源清单，超过 3 个团队共用的都算。
2. 给每个共享资源建一个预约表，最小粒度按半天。
3. 把排队时长作为独立指标纳入迭代复盘，和完成率并列。
4. 当排队时长超过该资源单次使用时长时，说明它是瓶颈，需要扩容或拆分。

七、取舍：什么必须做，什么可以明确放弃

资源负载这件事，做得越深越会发现它是一个经济学问题：精度要花钱，透明要花信任，统一要花自治。下面四组取舍，每一组我都给一个明确的偏向。

1. 精度 vs 可持续：宁可粗但活着，不要细但死掉

我见过最精细的工时统计是每人每天按 0.5 小时颗粒度填 8 项，结果第三周填写率掉到 41%，数据完全不可用。相比之下，每周 10 分钟的粗口径能活两年。

我的偏向：精度让位于可持续性。先用 ±30% 精度的粗口径跑起来，等团队形成习惯，再在关键环节（需求估算、瓶颈资源）提高精度。不要全链路一起提高精度，那是这个领域最常见的资源浪费。

2. 透明 vs 心理安全：公开团队负载，不公开个人负载

团队成员看到自己被标红，第一反应是防御，不是改进。我的做法是：负载数据公开到小组层级，个人层级只在组长和本人之间可见。这个粒度的好处是，跨组协调需要的"你还有没有余量"能被回答，而个人不需要为一次超载做解释。

如果组织文化比较开放，可以进一步公开到"角色"层级（如前端、后端、测试），但个人层级的公开，我在任何团队都不建议。

3. 统一 vs 自治：口径统一，阈值分团队设

口径必须全组织统一，否则跨组协调无从谈起。但阈值可以分团队设：一个维护老系统的 8 人组和一个新业务探索组，健康负载区间本来就不一样。

我建议的做法是统一公式、统一单位、统一采集节奏，但允许各组在 80% 到 90% 之间自定健康上限，只要在季度初声明并保持稳定。这样既保留了可比性，又给了团队一点自主空间。

4. 事前规划 vs 事中响应：把 70% 的精力放在进入端

很多团队的负载管理精力 90% 花在"排期调整"上，也就是事中响应。我的经验是把比例倒过来：70% 的精力放在进入端的闸门设计，20% 放在周度调整，10% 放在事后复盘。

因为进入端的一个决定，能省掉后面十次排期调整。这也是为什么我在每个团队最先推的都是"需求进入必须带工时估算、必须有负载额度"，而不是"更智能的排期算法"。

八、下一步：两周内可以做的七件事

如果你读到这里想动手，我建议不要做规划，直接做下面七件事。顺序不要调，前四件是基础和口径，后三件才是动作。

1. 第 1 天：找三个组长，各自写下"满载"的定义，对比差异。差异就是你要解决的第一件事。
2. 第 2 天：定下可用人周的扣减系数（会议、支持、评审各多少），写进一段 200 字以内的说明。
3. 第 3 天：建一张五列表格：小组、在岗人数、请假人天、承诺工时、负载率。不要加更多列。
4. 第 5 天：把本周所有在途需求补上工时估算，允许误差，但必须有一个数。
5. 第 8 天：第一次算出各组负载率，只发给组长和需求方，不发给任何上级。
6. 第 10 天：定下三档阈值和对应动作，白纸黑字写明"超 120% 需求方可以直接退回"。
7. 第 14 天：用第一次超载事件跑一遍流程，记录四选一的结果（削、缓、换、加），不管结果好坏。

两周之后你会有三个东西：一个能算的数字、一条能用的规则、一次真实的处置记录。这三样东西加起来，就是资源负载从 0 到 1 的全部基础。剩下的从 1 到 10，才是工具、自动化和跨团队协同。

最后说一句我的核心判断：超负荷从来不是团队的道德问题，而是系统的账目问题。当账目不清楚的时候，努力就会被当成解决方案，而努力的代价会以技术债、缺陷和人员流失的形式，延后一到两个季度才浮现。把账算清，是对团队最实际的保护。

如果你现在只记得一件事，就记这个：先算出一个"这周只剩 6.2 人周"的数字，然后在下次有人往管道里塞需求时，把它说出来。资源负载从 0 到 1，往往就是从这一句话开始的。