Capacity实操方法：项目成员提升资源负载效率的协同管理方法与模板

去年冬天，我参与了一家智能硬件公司的研发复盘。他们的排期表做得非常漂亮：46 名研发，未来八周每个人的利用率都排到 95% 以上，几位骨干甚至超过 110%。但就在那个季度，三条产品线同时延期，最严重的一条晚了六周。复盘会上项目经理说了一句我印象很深的话：“表上没有一个人是闲的，可项目就是不往前走。”

这不是排期能力的问题，是 Capacity 定义的问题。排期表统计的是“人被安排了多少时间”，而项目真正需要的是“这些时间能不能在需要的时候、以需要的技能、连续地投入到同一个目标上”。两者之间的差额，就是资源负载效率的全部战场。

这篇内容我想把 Capacity 拆成可操作的东西：一个四层判断模型、五个可直接复制的模板、一套 30 分钟的协同节律，以及在 PingCode 这类研发管理平台上怎么把它跑成闭环。文中出现的实测数字，我会标注清楚是样本观察还是示意推演，方便你判断能不能直接搬到自己的团队。

一、先给结论：Capacity 管理的对象不是“人”，是“可承诺的确定性”

在展开方法之前，我先把最核心的判断摆在前面。这四条结论是我在多个 100 人到 800 人规模的组织里反复验证过的，它们决定了后面所有模板的设计逻辑。

1. Capacity 是一个区间，不是一个数字

绝大多数团队做容量规划时，会得出一个单一数字：这个迭代我们有 320 人天。这个数字看起来精确，实际上是把一个概率分布压缩成了一个点估计，而项目风险恰恰藏在分布的右尾里。

我习惯的做法是给每个容量结论配三个值：P50 容量（有一半概率能做到）、P80 容量（八成概率能做到）、P95 容量（几乎一定做到）。承诺对外交付时用 P80，做技术债和预研投入时用 P50 减 P80 的差额，只有 P95 才敢写进对外合同。这个动作看起来只是多写两个数字，但它把“赌一把”变成了“管理风险敞口”。

我做过一次回溯：在一个 130 人的研发组织里，把过去六个季度的实际完成人天和当初的单一估算值对比，实际完成量的中位数只有估算值的 76%，而波动区间在 58% 到 91% 之间。这就是为什么单一数字的承诺总是“看起来合理，结果总是差一点”。

2. 负载效率的上限由最窄的技能口决定

很多人把资源负载理解成一个加法问题：总需求 500 人天，总产能 600 人天，所以有 100 人天的余量。这是错的。Capacity 不是标量，是矩阵，行是人，列是技能，格子里才是可用产能。

一个团队可能有 100 人天的后端余量，同时前端缺口 40 人天。从总量看是健康的，从交付看是堵塞的。约束理论（TOC）讲了几十年：系统产出由瓶颈决定，非瓶颈上的富余产能不会转化成产出，只会转化成等待。所以 Capacity 的第一步永远不是算总量，而是找瓶颈口。

3. 真正消耗产能的是“未登记的负载”

我在做负载诊断时有一个固定动作：让每个成员回溯过去两周，把实际花掉的时间按“已排期任务 / 临时插入 / 会议协同 / 线上支持 / 流程事务”五类填一遍。几乎每次结果都类似，已排期任务通常只占实际工时的 45% 到 60%，剩下的部分在排期表上完全不存在。

这意味着大部分团队在拿 100% 的名义产能去做 55% 的规划，然后疑惑为什么总是差 40%。问题不在于估算不准，而在于分母用错了。

4. 协同的成本远低于加人

遇到产能不足，组织的第一反应通常是加人。但在软件和复杂产品研发里，加人的边际收益衰减得极快，因为新人需要语境、需要被指导、会占用老人的产能，而沟通路径按 n(n-1)/2 增长。

我算过一笔账：一个 10 人团队补充 2 名新人，前两个月老人的指导投入约 30 人天，新人有效产出约为老手的 35%，要 4 到 5 个月才追平。同样的 30 人天，如果用来做需求裁剪、减少并行、压缩在制品，通常能在 2 到 3 周内拿回 15% 到 25% 的有效产能。先做减法再考虑加法，几乎永远是更划算的顺序。

二、真实场景：为什么资源负载问题总在项目过半才爆发

资源冲突很少在项目启动时暴露，它通常在项目过半、第一个里程碑评审前后集中爆发。理解这个时间差，比记住任何模板都重要。

1. 一个 130 人研发组织的两周切片

我做过一次相对完整的样本观察：在一个 130 人的研发组织里，选取 6 个双周迭代，对 42 名核心成员做了工时分类统计。结论如下（样本推演，用于说明结构，不代表行业统计）。

• 名义可用工时为 100%（按每人每双周 10 个工作日 × 8 小时计）。
• 扣除会议、评审、跨部门对齐后，剩余 76%。
• 扣除临时插入的需求、答疑、线上问题处理后，剩余 58%。
• 扣除流程性事务（周报、合规、培训、面试）后，剩余 49%。
• 再扣除上下文切换造成的效率损失，真正可用的深度工作时间约为 38% 到 42%。

这个数字第一次摆在管理团队面前时，会议室安静了几秒。因为大家突然意识到，所有排期争论的其实是那 40%，而不是表上的 100%。

2. 三类负载从来没有被写进计划

看上面的折损结构，会发现流失最严重的不是会议，而是那三类“从来没有被写进计划”的负载。

1. 插单负载：销售承诺、客户投诉、老板临时想法。它不会出现在迭代计划里，但一定会占用工时。
2. 维持性负载（BAU）：线上问题、数据修复、权限审批、客户支持轮值。团队知道它存在，却默认它是“顺手做掉”。
3. 组织性负载：招聘面试、新人带教、内部分享、跨团队协调。这类负载对组织有益，但消耗的是同一个产能池。

这三类负载的共同特征是：不做计划，但必须做；不进报表，但一定发生。它们构成了一条隐性的“影子排期”，和明面上的迭代计划争夺同一批人。

3. 需求入口失控是产能流失的第一现场

如果只能改一个环节，我会选需求入口。因为插单负载的根源不是执行不力，而是准入没有成本。

在一个健康的产能体系里，任何一条新需求进入迭代，都应该显式地告诉提出者：它将挤掉哪一条已有需求，或者它将让交付日期推后几天。这个动作叫“置换声明”。没有置换声明，就等于组织默许了无限透支产能。

我见过效果最直接的一次改进，是在需求评审会上加了一块白板，写着“本迭代剩余可承诺容量：18 人天”。新需求进来就减，减到 0 就必须做置换决策。就这一个动作，两个迭代内插单量下降了约 40%，而且没有人觉得被冒犯，因为规则是透明的。

4. 交接与等待：看不见的 30%

还有一个被系统性低估的部分：等待。

用利特尔法则（Little's Law）看，周期时间 = 在制品数量 / 吞吐率。团队把在制品堆高，吞吐率又受瓶颈限制，结果就是周期时间线性膨胀。而在周期时间里，真正在加工的时间通常只占 15% 到 25%，其余是排队、等待评审、等待环境、等待别人回复。

所以当你问“这个人负载为什么这么高”，答案往往不是他在干活，而是他手里同时挂着 7 件事，每件都在等。等待不消耗工时，但消耗交付能力，这是资源负载效率里最反直觉的一条。

三、拆解四个常见误区

下面这四个误区，我在不同公司反复见到。它们的共同点是：看起来是在做资源管理，实际上是在制造资源问题。

1. 误区一：把“人均利用率”当成效率指标

利用率是一个财务语言，不是一个交付语言。财务关心设备折旧摊销，所以希望 100% 运转；但项目交付关心的是响应速度和周期时间，这两者在高利用率下会急剧恶化。

排队论给出的结论很明确：当系统利用率从 70% 升到 90%，平均等待时间不是增加 20%，而是增加数倍；接近 100% 时趋于无穷。因为需求到达本身是随机波动的，没有余量就没有吸收波动的能力。

我自己的经验线是：团队级利用率的目标区间应该在 70% 到 80%，瓶颈角色可以到 85%，任何角色长期超过 90% 就意味着交付周期会失控。这个数字不是拍脑袋，而是排队模型加上实际观察校准出来的。

2. 误区二：把所有成员当成可互换的工位

很多容量表长这样：后端 8 人 × 10 天 = 80 人天，前端 5 人 × 10 天 = 50 人天。这个算法隐含了一个假设：8 个后端是同质的。

现实中，同样是后端，一个人在支付链路上是不可替代的，另一个人在报表模块上独当一面，第三个人还在熟悉代码。把他们加总，等于把三个不同的分布平均成一个常数，然后拿这个常数去承诺交付。

我的做法是用技能维度 + 熟练度系数替代人头加法：核心专家系数 1.0，熟练 0.75，可独立 0.5，需协助 0.25。同一个人在不同技能维度上可以有不同的系数。这样算出来的容量虽然还是一个数字，但它是从矩阵聚合出来的，保留了瓶颈信息。

3. 误区三：用填满的排期表证明管理到位

这是最隐蔽的一个。很多管理者潜意识里把“有人闲着”视为管理失败，于是不断往排期表里塞东西，直到每个人都是 100%，然后感到安心。

但排期表排满，意味着零缓冲，也就是零抗风险能力。任何一次需求变更、任何一次评估失误、任何一个人请假，都会直接冲击交付日期，没有任何内部消化空间。

更麻烦的是，排满的排期表会激励一种行为：成员为了不被继续塞活，会刻意把任务估长，或者把已完成的工作藏着不报。这是典型的“局部优化导致系统劣化”，管理者越努力，信息越失真。

4. 误区四：把 Capacity 当成一次性动作，而不是节律

很多团队一年做一次“资源盘点”，然后把它当成年度预算的一部分锁进柜子。但需求在变、人在变、技能在变，一次盘点的有效期通常不超过六周。

Capacity 的本质是一个滚动更新的节律，而不是一份静态文档。它的价值不在那个数字有多准，而在于组织每周都会因为要更新它，而重新对齐一次“我们现在到底在做什么、还剩多少空间”。

我通常建议的最小节律是：双周迭代 + 六周滚动窗口 + 每周一次 30 分钟负载对齐。低于这个频率，容量数据就会失真到没有决策价值。

四、专业判断逻辑：Capacity 的四层模型

下面这套四层模型是我这几年用得最顺手的一个框架。它把“我们能做多少”这个模糊问题，拆成四个可以分别管理、分别优化、分别承诺的层次。

1. 第一层：名义产能（Nominal Capacity）

名义产能 = 人数 × 可用工作日 × 每日标准工时。它是一个会计概念，用途只有一个：作为后续折损的基准分母。

这一层的常见错误是直接拿它做承诺。名义产能永远不应该出现在对外的交付承诺里，因为它对应的假设是“人每天 8 小时不间断做同一件事”，这个假设在真实组织里从不成立。

计算公式很简单，但要注意口径一致：

名义产能（人天）
= Σ(成员人数 × 窗口内工作日 × 每日标准工时 / 8)

－ 法定节假日、年假、调休、培训、出差

示例：10 人团队，六周窗口内工作日 30 天

含 1 天法定假日、2 天平均年假

名义产能 = 10 × (30 – 3) = 270 人天

2. 第二层：有效产能（Effective Capacity）

有效产能 = 名义产能 × 专注系数。专注系数才是真正需要被管理和被改善的变量。

专注系数不是拍出来的，它必须来自观测。最可靠的方法是做两轮工时分类回溯（前面第二节那个动作），拿到本团队真实的折损结构，然后每季度校准一次。

我观察到的区间大致是：成熟团队 0.55 到 0.65，快速扩张团队 0.45 到 0.55，强支持属性的团队（含运维、客户支持）可能低到 0.40。如果你的团队算出来是 0.7 以上，先怀疑统计口径，而不是先庆祝。

3. 第三层：可承诺产能（Committable Capacity）

可承诺产能 = 有效产能 × 承诺系数。承诺系数通常取 0.7 到 0.8，它代表你愿意拿出来做确定性承诺的那部分，剩下的留作缓冲。

这里有一个关键判断：缓冲不是浪费，缓冲是购买确定性的价格。一个团队承诺 100% 有效产能，等于把交付日期变成了一场赌博；承诺 75%，看起来保守，但按期交付率会从 50% 上下跳到 80% 以上。

我一般建议把有效产能切成三段，而不是两段：

• 承诺段 70%：已排期、已估算、已确认的需求，对外承诺交付。
• 缓冲段 20%：吸收插单、评估误差、临时支持，不承诺但必须预留。
• 储备段 10%：技术债、工具改进、预研、团队学习，保护长期产能。

4. 第四层：弹性产能（Elastic Capacity）

弹性产能指的是在短期冲击下可以调动的额外供应：外包、跨团队借调、加班、范围裁剪、延期交付。它有成本，也有上限，但必须被提前识别出来，而不是等到出事再找。

我的经验是，每个团队都应该有一份写下来的弹性清单，标注每项的响应时间、成本量级和副作用。比如“借调一名后端”响应时间 2 周、成本是原团队 15% 产能的交接损耗；“削减 P2 需求”响应时间 1 天、成本是客户满意度；“周末加班”响应时间 0 天、成本是两周后的产能反噬。

把弹性产能显性化，最大的好处是：当风险真的发生时，组织是在做选择，而不是在慌乱。

5. 判断原则：先压缩波动，再谈扩容

这一节最后给一条我认为最重要的原则。

面对产能不足，绝大多数组织的动作顺序是：加班 → 加人 → 加流程。而正确的顺序应该是：压缩需求波动 → 减少并行与在制品 → 消除瓶颈 → 提升专注系数 → 最后才是扩容。

原因很直接：前四步的收益是即时的、免费的、可逆的，而扩容的收益延迟 3 到 6 个月、有成本、不可逆。在一个波动剧烈的系统里扩容，等于往一个漏水的桶里加水，你只是在为波动买单。

五、可落地的模板：五个工具就够

这一节是全文最“可用”的部分。下面五个模板，我建议按顺序引入，不要一次全上。每引入一个，至少跑两个迭代再评估。

1. 模板一：成员能力-可用度矩阵

这是所有 Capacity 工作的起点。它回答两个问题：每个人在哪些技能上可用？未来六周他在每个技能上能投入多少？

矩阵的行是成员，列是技能（不是职能，“后端”太粗，应该拆到“支付链路”“消息中间件”“性能调优”这种粒度），格子里是“熟练度系数 × 可用天数”。

看这张表就能得出结论：总量 114 人天，看起来很宽裕，但性能调优只有 47.5 加权人天，而“可独立承担”（系数 ≥ 0.5）的只有 C 一个人。这就是瓶颈口，不是缺人，是缺这个技能上的第二个人。

顺带说一句，这张表最有价值的副产品是：它把“某个模块只有一个人懂”这种口头共识，变成了一个可以排期解决的结构性缺口。

2. 模板二：六周滚动负载看板

为什么是六周而不是一个迭代或一个季度？因为一个迭代太短，看不到累积效应；一个季度太长，数据必然失真。六周大致是一个中型需求从设计到上线的典型跨度，也是大多数人能相对准确预判的时间窗。

看板的结构是：

• 第一列：需求/项目清单，标注优先级和所属产品线。
• 第二到第七列：六周，每周一列。
• 每行一个成员，格子里是当周负载百分比。
• 颜色规则：低于 60% 显示为蓝色（产能闲置），60% 到 85% 为绿色，85% 到 100% 为黄色，超过 100% 为红色。
• 底部一行：团队总负载率和本周瓶颈角色。

这张看板的价值不在颜色本身，而在于它让“两周后某人会超载”这件事，在两周前就被看见。资源管理的大部分失败，本质上是发现得太晚。

3. 模板三：70/20/10 三段式配比表

这是一个“预算制”的做法，把有效产能当成一笔钱来分配，而不是一件一件往里塞。

这张表最关键的一列是“谁有权动用”。没有授权边界的配比表，三天之内就会被业务方吃光。我见过太多团队做出了漂亮的 70/20/10，但因为没人守门，第一个 sprint 就变成了 95/5/0。

另一条经验：储备段必须由技术负责人而不是项目经理持有。因为项目经理的绩效天然绑定交付，而储备段的收益在三个季度之后，激励不匹配，制度就一定守不住。

4. 模板四：30 分钟负载对齐会议议程

这是整套方法里唯一的“协同动作”，也是最容易被搞砸的一个。搞砸的方式通常是把它开成了进度汇报会。

负载对齐会只讨论三件事：未来两周谁会超载、未来两周谁会闲置、需要做什么调整。进度不在这个会上讨论，因为进度有自己的同步机制。

1. （0-5 分钟）看板刷新：更新本周负载数据，标出红色和蓝色格子。
2. （5-15 分钟）逐条处理红色格子：每个超载点必须当场产出一个动作，置换、延期、借调、裁剪，四选一，不允许“再观察”。
3. （15-20 分钟）处理蓝色格子：把闲置产能分配给储备段任务，优先补技术债和瓶颈技能的第二人。
4. （20-25 分钟）确认瓶颈角色：本周最窄的技能口是谁，为它排一个保护动作。
5. （25-30 分钟）记录并公示：把决策写进系统，指定负责人和截止日，下周一自动复核。

这里有一条硬规则：红色格子不允许带着“再看一周”离开会议。因为红色格子的本质是决策拖延，而拖延的代价会在两周后以延期的方式结算。

5. 模板五：需求准入检查清单

最后这个模板管的是入口。前面四个都是“进来之后怎么排”，只有这个能减少“进来多少”。

任何新需求进入迭代前，必须回答五个问题，缺一项就退回：

1. 它挤掉的是哪一条已有需求？如果挤不掉，说明容量判断有误。
2. 它的估算区间是多少（P50 和 P80），谁估的，估算依据是什么？
3. 它需要哪些技能，这些技能的瓶颈角色当前负载是多少？
4. 如果延期，最坏的业务后果是什么？这个后果由谁承担？
5. 如果必须做，是否可以用更小的范围先验证？

这五个问题的作用不是设置官僚障碍，而是让需求方也参与容量决策。一旦提出需求的人知道“我这一条会挤掉谁”，插单就会自带优先级判断，而不是全部标成“最高”。

准入判定伪代码（可直接写成看板规则）
输入：新需求 N、当前承诺段剩余容量 R、瓶颈技能负载 L

若 N.估算_P80 大于 R：

触发置换声明，要求提出者指定被挤出的需求

若提出者无法指定，则将 N 放入候选池，不进入本迭代

若 N.所需技能 属于 瓶颈技能 且 L 大于 85%：

标记为高风险，需技术负责人确认第二人可用

若 N.范围 可拆分为 小于 3 人天 的验证单元：

允许以探索形式进入储备段，上限为储备段 30%

其余情况：正常进入承诺段，同步更新 R 与 L

六、案例与数据观察：在 PingCode 里把 Capacity 跑成一条闭环

模板如果只停留在表格里，两周后就会失效，因为表格不会自己更新，也不会主动提醒。这一节我用 PingCode 举例，说明在研发管理平台上怎么把上面五个模板变成一个自动运转的闭环。这里选择 PingCode 是因为它主要服务中大型企业及 100 人以上组织，而这个规模恰恰是表格管理最先崩溃的临界点。

1. 场景设定：一家 300 人规模的软硬件混合研发企业

这是我从旁观察过的一个相对典型的场景：300 人左右，研发占 180 人，分 5 条产品线，硬件、嵌入式、后端、前端、测试五个职能交叉协作，同时跑 9 到 12 个项目。他们的原始状态很有代表性：

• 排期用表格，分散在 5 个产品线负责人手里，口径互不相同。
• 工时靠回忆填，颗粒度是“人天”，而且是周末补填。
• 负载冲突靠周会上吵，谁嗓门大谁先拿资源。
• 插单没有入口控制，平均每个双周有 7 到 9 条临时需求。

这个状态在 50 人以下还能靠人盯，到 180 人就必然失效。原因不是管理者不努力，而是信息分散在 5 个 Excel 里时，全局瓶颈在物理上不可见。

2. 第一步：把可用工时算成人天，而不是“人头”

他们做的第一个动作，是在 PingCode 的迭代里为每个成员设定本迭代的可用工时，把年假、培训、出差、支持轮值先扣掉，再排任务。这一步看起来平淡，但它是所有后续数据的基准。

实际操作中有一个细节值得说：可用工时不要一次设定一个季度，而是每个迭代设一次。因为人的可用性本来就是迭代级变量，设成季度值，数据从第一天就开始失真。

这一步完成后，他们第一次发现：名义上 180 人的研发队伍，某个迭代的真实可用工时只相当于 148 人。差额来自 11 人出差、6 人年假、9 人的支持轮值，以及一批刚入职还在带教期的新人。

3. 第二步：用负载视图暴露冲突，而不是靠会议吵

第二个动作是把工时填报和任务进度绑在一起，让每个人的实际负载可以从任务工时和迭代看板自动聚合出来，而不是手工汇总。

这里的变化是质的变化：负载从“某人说的”变成了“系统算的”。当产品线负责人说“我们这条线人手不够”时，可以直接打开视图看是哪个技能口在超载、超载几周、由哪个需求造成。争论从立场之争变成了数据核对。

他们后来反馈，最有用的不是红色格子本身，而是能一眼看到某个骨干连续三周都在 110% 以上。在此之前，这种持续超载是隐形的，因为它每周都被“这周特殊”合理化掉了。

4. 第三步：把预警线写进规则

第三个动作是把判断变成规则，减少对个人经验的依赖。他们设了三条规则，都写进了日常的看板检查里：

1. 单人负载连续两周超过 100%，自动升级：不是提示本人，而是提示项目经理和技术负责人，因为本人往往是最不愿意报超载的那个。
2. 瓶颈技能负载超过 85%，新需求自动标记高风险：让准入检查在提交时发生，而不是在评审会上被否决。
3. 储备段被占用超过 50%，触发技术负责人复核：这条规则保护的是长期产能，防止技术债被无限推迟。

我特别想强调第一条的设计。很多系统把超载提醒发给本人，效果很差，因为它把压力转嫁给了一线。正确的做法是把超载信号发给有能力改变它的人，而不是发给承受它的人。

5. 六个双周后的数据观察

他们在推进这套方法六个双周后，做了一次前后对比。下面是示意性的对比数据，基于该场景的实际反馈整理，用于说明变化方向，不作为行业基准。

这些数字里我认为最有价值的是第三行：资源冲突决策耗时从 6.5 天缩短到 1.5 天。因为资源管理的真实成本，很大程度上不是“排错了”，而是“排错之后要花很久才纠正”。决策速度直接决定了纠错成本。

而储备段从 0% 到 6% 这一项，短期内看不到任何交付收益，但它决定了明年这个团队的产能是上升还是继续下滑。

6. 为什么中大型组织更需要系统而不是表格

有人会问：这些用 Excel 不能做吗？小团队确实可以，但到 100 人以上就会遇到三个硬约束。

第一是更新成本。5 个 Excel 汇总一次大概要 2 小时，每周一次就是 100 小时/年，而且每次汇总都会引入口径偏差。第二是一致性。多个负责人各自维护表格时，口径必然分叉，而口径分叉的容量数据比没有数据更危险。第三是可追溯性。三个月后想复盘“当时为什么做了这个决策”，Excel 给不出答案，而系统里的变更记录可以。

这也是为什么我倾向于在 100 人以上的组织里建议使用 PingCode 这类平台做承载：不是因为功能多，而是因为它能把工时、迭代、看板、度量放在同一个数据源里，让负载数据成为执行的副产品，而不是额外的一项管理工作。数据一旦需要专人维护，它的生命周期就不会超过两个季度。

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

方法论最怕被无差别套用。下面按团队规模和类型给出不同的起手式，请对号入座，不要贪多。

1. 20 人以下团队：先做一张表

这个规模不要上系统，一张共享表格加一个每周 15 分钟的对齐就够了。核心动作只有一个：把可用工时算成真实人天，然后在排期时不排满。

具体做法：表格列是未来六周，行是成员，格子填负载百分比；每周五更新一次；任何超过 90% 的格子必须在下周一之前处理掉。做到这一点，20 人团队的资源问题能解决七成。

2. 20 到 100 人团队：先做负载看板，再做容量模型

这个规模的关键矛盾是信息分散。所以顺序应该是：先统一负载视图，再建四层容量模型。

1. 统一工时口径：所有人用同一套分类（已排期 / 插单 / 协同 / 支持 / 流程）。
2. 建立六周滚动看板，先只做可视化和预警，不做复杂计算。
3. 跑两个迭代后，用实际数据校准专注系数，再引入四层模型。
4. 最后才引入 70/20/10 配比，因为配额需要可信的数据支撑才能守住。

顺序错了会怎样？如果先上 70/20/10 而没有可信数据，业务方会立刻质疑“凭什么只有 70%”，然后配额在第一周就被突破，方法从此失去信用。

3. 100 人以上组织：先做需求准入，再上系统

大组织的产能流失主要发生在入口，而不是在排期。所以优先级应该是：需求准入 → 统一数据源 → 负载可视化 → 容量模型 → 度量与复盘。

准入先行的原因很实际：在 180 人的组织里，把插单从每双周 8 条压到 4 条，等于凭空多出 6% 到 8% 的有效产能，而且成本为零。相比之下，优化排期算法能带来的提升通常不到 2%。

4. 交付型、研发型、运维型团队的不同起手式

三类团队的 Capacity 结构差异很大，不能用同一套模板开场。

• 交付型（项目制、客户定制）：起手式是“需求准入 + 人力调度池”。核心矛盾是项目之间抢人，所以要建立跨项目的资源池视图和优先级仲裁规则。
• 研发型（产品迭代）：起手式是“在制品收敛 + 三段式配比”。核心矛盾是并行过多和储备段被侵蚀，所以要限制 WIP 并保护技术投入。
• 运维型（含支持）：起手式是“隐性负载显性化 + 轮值排班”。核心矛盾是支持类工作从不进计划，所以要把轮值当成一等公民排进容量。

5. 已经严重超载时：先做减法，不做优化

如果团队当前利用率普遍在 100% 以上、连续三周没有缓解，那就不要谈优化，先做减法。顺序是：

1. 冻结所有新增需求，只允许做置换。
2. 把在制品数量砍到瓶颈资源的 2 倍以内。
3. 砍掉或推迟所有 P2 需求，明确告知影响方。
4. 为瓶颈角色配一个“不受打扰时段”，每天至少 3 小时。
5. 稳定两周后再重新引入配比与预警。

超载状态下引入新流程是无效的，因为团队没有余力执行流程。先恢复余量，再恢复秩序。

八、不同情况下的取舍

这一节讲的是“没有标准答案”的部分。每个取舍都有代价，关键是想清楚你愿意付哪一个。

1. 取舍一：透明度 vs 管理成本

负载数据越细，决策越准，但填报成本越高。我的经验分界线是以“天”为颗粒度：以天为单位填报，成本可接受，精度够用；以小时为单位，填报成本翻倍，精度提升却很小，因为估算本身的误差就超过小时级。

如果你的团队填报依从性一直很低，先降颗粒度而不是加强考核。考核能换来数字，但换不来准确。

2. 取舍二：粒度 vs 可持续性

技能维度拆得越细，瓶颈识别越准，但维护成本越高，而且成员会抵触被贴上细分标签。我一般建议技能维度控制在 8 到 12 个，并且每半年复核一次，允许成员自己申报变更。

技能标签的另一个风险是固化：一个人被标成“只做报表”，就再也接不到别的活。所以矩阵里应该保留“成长中技能”这一列，明确表达组织愿意在这些维度上投入培养。

3. 取舍三：集中调度 vs 团队自治

集中调度能最大化全局效率，但会牺牲团队的自主性和响应速度；团队自治响应快，但容易出现资源囤积（每个团队都想多留人）。

我的建议是“容量集中、分配自治”：容量数据统一口径、统一可见，但具体的任务分配由团队自己做。这样既保留了全局视野，又不至于让调度变成官僚。

唯一的例外是瓶颈角色。瓶颈资源必须集中调度，因为它决定了系统产出，交给局部优化一定会被滥用。

4. 取舍四：缓冲 vs 承诺

缓冲留得多，交付确定性高，但短期看起来“产能浪费”；缓冲留得少，短期数字好看，但交付风险高。

这个取舍的答案取决于你的业务属性：如果延期代价远高于产能闲置代价（如对外合同、硬件量产窗口），缓冲留到 25% 甚至 30% 都合理；如果需求波动小、延期代价低（如内部工具），缓冲可以压到 15%。

最怕的是不一致：对外承诺按 100% 排，内部考核按利用率算，两个指标互相拆台，团队永远在两头挨骂。

5. 取舍五：工具 vs 习惯

最后一个取舍是很多组织踩过的坑：以为买了工具就解决了问题。实际上，工具能放大习惯，但不能创造习惯。

一个每周认真做 30 分钟负载对齐的团队，用表格也能跑得不错；一个从不做对齐的团队，上了再好的平台，数据也会在两个月内变成摆设。所以顺序永远是：先建立节律，再引入工具去降低节律的执行成本。

判断标准很简单：如果在用表格的阶段，你们已经能连续四周按时更新，那就可以上系统了；如果做不到，先解决“为什么做不到”。

九、三个高频追问

最后回应三个我在分享这套方法时最常被问到的问题，它们的答案都有点反直觉。

1. 成员不愿意填工时怎么办

先假设他是对的。绝大多数抵触不是因为懒，而是因为填了没有用，甚至有害，填得准的人被塞更多活，填得虚的人反而轻松。这是激励设计问题，不是态度问题。

解法是让填报产生可见的正面结果：明确承诺“连续两周超过 100% 会自动触发支援”，并且真的执行。当成员发现填准了会得到保护，依从性通常在两三个迭代内自然提升到 85% 以上。

2. 需求波动太大，六周窗口根本看不准

波动大恰恰说明你需要滚动窗口，而不是不需要。看不准的部分，交给缓冲段去吸收，而不是试图预测得更准。

一个实用技巧是把窗口分成“确定区”和“观察区”：前两周是确定区，排到 90% 精度；后四周是观察区，只标资源占用趋势，不承诺具体需求。这样既保留了全局视野，又不制造虚假精度。

3. 老板直接插单，规则管不住怎么办

规则管不住的不是老板，是没有成本信息的决策。老板插单时通常不知道这一条会挤掉什么。所以不要用规则去拒绝，要用信息去呈现。

有效的话术是：“这条可以做，代价是 A 项目延期 5 天，或者 B 需求推到下个迭代，您希望选哪个？”把二选一的决策权交回去，绝大多数管理者会做出合理判断。真正的问题从来不是有人插单，而是插单不需要承担后果。

十、结语：把 Capacity 变成一种组织习惯

回到开头那家智能硬件公司。他们后来做的改变其实很朴素：把每个人的可用工时按迭代设一次，把插单做成需要置换声明的动作，每周花 30 分钟对齐一次负载。没有上新工具，没有加人，三个季度后按期交付率从 58% 升到 76%。

我想说的是，Capacity 管理的核心从来不是算得多准，而是让组织形成一个稳定的、可预期的“我们还能接多少”的表达能力。有了这个能力，承诺才可信，承诺可信，协同才有意义。

如果这篇内容只能带走一句话，我希望是这句：不要用 100% 的名义产能去做 100% 的承诺，那 40% 的差额不是执行力问题，是你从一开始就用错了分母。

下一步，我建议按这个顺序动手，一周内就能看到变化：

1. 今天就做：让团队回溯过去两周的工时，按五类分一遍，算出你们真实的专注系数。
2. 本周内做：把未来六周的负载做成一张表，标出所有超过 85% 的格子。
3. 下周一做：开第一次 30 分钟负载对齐会，只处理红色格子，每个格子必须产出一个动作。
4. 两周后做：引入 70/20/10 配比，先只守储备段那 10%。
5. 两个月后做：如果前四步都能稳定执行，再考虑用 PingCode 这类平台把节律自动化，让它从“靠人坚持”变成“系统默认”。

顺序比工具重要，习惯比模型重要。这两件事做对了，Capacity 就不再是一年一次的盘点表，而会成为团队每天都在用的判断依据。