Capacity怎么做？产品经理最佳实践：资源负载从0到1

Capacity 做不起来，通常不是因为团队不会算工时，而是因为大家把“有多少人”误当成“有多少可交付能力”。一个 8 人团队看上去有 40 人日周容量，扣掉会议、支持、休假、跨项目协作和技能错配后，真正能用于某项产品工作的时间可能不到一半。产品经理从 0 到 1 建立资源负载管理，重点不是画一张看起来精确的甘特图，而是先统一容量口径，再把需求、技能、时间和风险放进同一个决策框架里。

一、先讲核心结论：Capacity 管理不是“把人排满”

1. Capacity 的核心是承诺能力，而不是日历空档

我把 Capacity 理解为：在明确的时间范围内，团队在现有人员、技能、工作制度和依赖条件下，能够稳定承诺的工作量。它不是名册人数，也不是所有人的理论工时总和，更不是把每个人的日历空白加起来。

如果一个 6 人团队每周理论上有 30 人日，产品经理不能因此承诺 30 人日的交付。团队还要参加评审、处理线上问题、回复跨部门咨询、完成代码审查和测试准备。若没有把这些“看不见的工作”纳入计算，计划从第一天起就已经超载。

我建议把 Capacity 拆成四层：理论容量、可用容量、可承诺容量和已分配容量。理论容量是工作制度提供的上限；可用容量扣除了休假、固定会议和已知支持任务；可承诺容量再扣掉风险缓冲；已分配容量则是已经承诺给项目、产品需求或运营工作的工作量。

这四层之间的差值，比单独一个“利用率”更有管理价值。比如可用容量和可承诺容量差距较大，往往说明工作不确定性高；可承诺容量与已分配容量差距为负，则说明承诺已经超过团队能稳定交付的范围。

2. 先统一容量单位，再讨论排期

跨职能团队常见的争论，表面上是“谁估得准”，实质上是单位不统一。研发用人日，设计用任务数，测试用用例量，产品用需求点数，管理层又要求按百分比汇报。没有统一口径，汇总出来的总量只是看起来整齐，并不具备决策意义。

早期可以用人日或人时，但要标明它表示的是“投入时间”而不是“产出价值”。成熟一些的团队可以同时保留工作量估算和交付历史，用历史完成量校准未来预测。不要把不同团队的故事点直接相加：不同团队的估算尺度并不天然可比。

3. 容量管理应该支持取舍，而不是制造精确感

Capacity 的最终产物不是一个精确到小数点的数字，而是更好的产品决策：本周期能承诺哪些工作，哪些需求要延期，哪些技能是瓶颈，需要临时借调还是调整范围，以及出现突发事项时先牺牲什么。

如果一张容量表不能帮助团队做取舍，它就只是报表。我更关注三件事：承诺是否有依据、瓶颈是否可见、变化是否留下记录。比起把估算从 80 人时修正到 78 人时，及时发现某个关键测试人员被三个项目同时占用，通常更有价值。

二、背景和真实场景：为什么产品经理需要从 0 到 1 做 Capacity

1. 需求池增长后，问题从“做什么”变成“谁能做、何时能做”

产品早期的团队往往人数少、沟通直接，大家靠口头协调就能解决排期。随着产品线增多，需求池里同时出现新功能、客户定制、稳定性改造、合规事项和技术债，单靠产品优先级已经无法回答交付时间问题。

这时常见的现象是：路线图上每项工作都有优先级，项目负责人也都认为自己的事情必须本季度完成；但工程师、设计师、测试人员和数据分析人员并没有随需求同步增加。冲突最终会以延期、频繁切换、质量回退或关键人员加班的形式暴露出来。

我会把资源负载管理的起点放在“工作与能力之间的关系”，而不是先从组织架构图开始。团队里有多少人只是入口数据；某一周期需要什么技能、哪些人可以承担、工作之间依赖什么，才决定了真实容量。

2. 典型场景：中大型组织里，项目总量不超载，关键角色却超载

以一个 100 人以上组织中的产品交付团队为例，管理者看到三个项目各分配了 30%、30% 和 25% 的团队容量，合计 85%，似乎还有 15% 余量。但实际安排中，只有一位资深测试工程师需要参与三个项目的发布验证；一个数据分析师还要承担临时经营分析；产品设计资源则集中在某个版本窗口。

此时用团队总容量平均分配，会掩盖角色级瓶颈。总盘子还有空余，不代表关键岗位有空余。项目 A 可能因为测试资源延误，项目 B 因为数据埋点无人校验而无法验收，项目 C 即使开发完成也不能按期上线。

在这类场景下，PingCode 可以作为中大型组织梳理项目、需求、任务与资源安排的协作平台示例：重点不是依赖某个功能自动给出“正确答案”，而是让计划、工作项、负责人、周期和实际进度能在同一套信息结构中被查看和复盘。具体字段和流程仍要根据团队治理方式配置。

3. 从 0 到 1 的合理边界：先管一个周期，不要先造全公司模型

第一次做 Capacity，最容易掉进“先把全部部门、全部项目、全部岗位建模”的陷阱。信息收集会拖很久，人员也会把它理解为新的填表任务。等模型完成时，业务优先级可能已经变了，大家对数据的信任也下降了。

我建议从一个稳定团队、一个 4 到 8 周的滚动周期和一组高频工作类型开始。先覆盖正在发生的项目与固定运营工作，验证容量口径是否能解释排期偏差，再决定是否扩展到其他团队。

三、常见误区：看起来在做容量管理，实际在制造偏差

1. 把每个人的工作日全部算成可交付时间

每周五个工作日，不等于五天都能投入项目。固定会议、代码评审、跨团队同步、故障轮值、招聘面试、文档维护以及帮助同事解决问题，都会占用注意力。对资深成员而言，答疑和决策本身可能就是主要工作，不应被当作“无产出时间”。

如果团队目前没有时间记录，不必为了做容量管理突然要求所有人按分钟填工时。可以先用访谈和两到四周的粗粒度抽样，识别固定占用的大类，再逐步修正。记录的目标是理解系统，不是评估个人忙碌程度。

2. 把利用率越高等同于效率越高

利用率接近 100% 看上去很“饱满”，但团队没有缓冲时，任何线上故障、需求澄清或依赖延迟都会打断原计划。工作切换、等待和返工会让名义投入上升，实际完成量反而下降。

容量管理不应鼓励把每个人排满。对变更频繁、外部依赖多的团队，保留缓冲不是浪费，而是对不确定性的定价。缓冲比例不应照搬行业口号，而应根据本团队过去的中断、返工和预测偏差来校准。

3. 用团队平均数掩盖技能瓶颈

“我们还有两个人日”不够完整。还要追问：剩下的是哪种能力？能否承担当前任务？任务是否依赖特定权限、系统知识或业务背景？团队里有空闲的后端开发，并不能自动替代缺席的安全评审或测试负责人。

我会用“角色容量”和“关键技能容量”两层检查。角色层用于看研发、测试、设计、产品等大类；技能层只对少数关键能力建模，例如发布审批、数据建模、特定系统维护。技能维度过细会让维护成本暴涨，因此只记录会影响决策的约束。

4. 用工时预测去承诺价值和交付日期

人时是投入，不是价值。需求估算为 40 人时，并不代表它比 20 人时的需求更重要，也不代表它一定在两天后上线。还要考虑优先级、依赖、评审、验收、发布窗口和完成定义。

对于重复性较高的团队工作，可以把历史完成量作为预测参考；对于探索型工作，容量表更适合表达“投入上限”和“决策检查点”，不宜承诺精确产出。探索任务应设置时间盒与退出条件，比如两周内完成技术验证，之后决定继续、缩小范围或停止。

5. 每月更新一次，遇到变化仍沿用旧计划

Capacity 是滚动管理，不是年度预算的附属表格。人员请假、优先级变化、线上故障、需求返工都会改变可用容量。若计划只在月初刷新，团队很可能在月中已经偏离，却还在用旧数字追责。

更新频率不必过度。多数产品团队可以在周期规划时完整校准，每周轻量检查变化，每次重大优先级调整时重新计算受影响的角色和工作项。关键是明确谁负责更新、什么情况触发更新、更新后哪些承诺需要重新确认。

四、专业判断逻辑：如何建立一套能用于决策的容量模型

1. 先定义工作范围和时间窗口

建模前先确定“算什么”和“看多远”。工作范围至少应区分产品交付、维护支持、客户事项、内部治理和探索验证；时间窗口则建议采用团队现有的迭代或项目规划周期。

如果产品需求已经按两周迭代管理，就先按两周建立容量视图，不必同时做周、月、季度三套互相冲突的口径。较长周期可以用于方向性预测，短周期用于具体承诺，二者的精度应当有区别。

2. 建立可用容量：把固定占用与不确定占用分开

一个实用的基础公式是：可用容量等于理论容量减去已确认缺勤、固定会议、已知运营支持和已承诺的其他工作。风险缓冲不要混在这些扣减项里，因为它代表的是未知变化的保护空间，应该单独展示。

比如某工程师在两周内有 10 个工作日，按每天 6 小时有效专注时间估算，理论容量为 60 小时；已知休假 6 小时、固定会议 8 小时、轮值支持 10 小时，可用容量为 36 小时。若团队为不确定性保留 20% 缓冲，可承诺容量约为 29 小时，而不是 60 小时。

“每天 6 小时有效专注时间”只是示意口径，不应被当成普遍事实。不同组织的会议密度、工作性质和支持负担差异很大，应通过团队自己的观察修正。

3. 以角色和技能检查瓶颈，而不只看总容量

建立容量表时，至少按角色汇总可用与已分配工作量。遇到明显瓶颈，再增加关键技能视角。不要一开始就把所有人员标签细分到几十种，否则每次调动、请假或任务变更都要维护复杂矩阵。

我通常用三类问题决定是否增加技能维度：这个能力是否只能由少数人承担？它是否会直接限制交付路径？它的缺口能否通过培训、流程标准化或外部支持缓解？若三项都不成立，就不必单独建模。

4. 用依赖关系修正“纸面上可并行”的计划

两个任务即使分配给不同人，也不一定真正并行。它们可能依赖同一个业务决策、同一套测试环境、同一位审批人，或同一批客户反馈。容量模型应能标出关键依赖及其等待风险，否则排期只是在计算投入，不是在预测交付。

当依赖无法消除时，计划应明确前置条件和检查日期。例如“研发完成”不是发布条件，真正条件可能是接口冻结、数据迁移验证通过、客服话术确认和灰度观察指标就绪。产品经理要把这些条件纳入工作范围，而不是事后当作意外。

5. 用历史数据校准，不把一次估算当成事实

每个周期结束后，比较计划工作量、实际完成量、延期原因和突发工作占比。目的不是寻找谁估算错误，而是识别系统性偏差：是否持续低估测试、是否高估并行能力、是否忽略发布准备、是否把支持工作留在账外。

建议至少跟踪以下指标：容量预测偏差、承诺完成率、突发工作占比、关键角色负载、任务切换次数和延期原因分布。指标不要太多，先选能触发行动的三到五项。

6. 把不确定性写进计划，而不是藏在估算里

需求不确定时，不要用一个看似确定的工时掩盖风险。把任务拆成探索、实现和验证阶段，并为每阶段设置进入条件与退出条件。若探索结论会改变范围，先承诺探索时间，不要提前承诺完整功能的上线日期。

对外沟通可以采用区间和条件表达：在关键依赖按期完成、范围不变的前提下，预计需要两个到三个迭代；如果某项验证未通过，则优先交付核心路径，次要能力进入后续周期。这样的表达比给出一个缺少假设的日期更诚实，也更方便管理预期。

五、具体案例与数据观察：用一个产品团队演示从 0 到 1

1. 案例背景：四类工作抢同一批关键资源

下面是一组情景模拟数据，用于演示计算方法，不代表某个企业的实际统计。设一个中大型组织的产品交付小组由 8 人组成：3 名研发、2 名测试、1 名设计、1 名产品经理和 1 名数据分析师，规划周期为两周。

团队当前有四类工作：核心功能迭代、客户问题修复、稳定性改造和数据分析需求。最初的排期方式是先把每个需求标成高、中、低优先级，再按总人日塞进迭代。结果是功能开发看似可并行，但测试和数据分析在周期末集中排队。

第一步不是重新估算所有需求，而是把已知固定占用列出来：计划休假、例会、发布轮值、线上支持、需求澄清和跨团队评审。按两周统计后，团队理论工作时间为 240 人时；扣除已确认占用后，剩余可用时间为 148 人时；再保留 18% 的风险缓冲，可承诺容量约为 121 人时。

2. 第二步：按角色核算，发现瓶颈不在研发总量

按角色拆分后，研发可承诺容量为 53 人时，测试为 27 人时，设计为 16 人时，产品为 13 人时，数据分析为 12 人时。四类工作初步需求分别为核心功能 55 人时、问题修复 18 人时、稳定性改造 23 人时、分析需求 15 人时，总需求 111 人时，低于 121 人时的团队总容量。

如果只看总量，计划似乎可行。但测试需求达到 34 人时，超过 27 人时可承诺容量；数据分析需求达到 15 人时，也超过 12 人时。总盘子有余量，关键岗位却超载，因此不能以“总需求小于总容量”为由通过计划。

这种拆分还暴露了一个优先级问题：问题修复里有一项会影响客户关键流程，必须尽早验证；某项稳定性改造则可以拆成监控补充与架构优化两部分，前者进入本周期，后者留待下一周期。产品优先级由“谁催得急”转向业务影响、风险和资源约束共同决定。

3. 第三步：做范围调整，而不是要求所有人加速

团队将核心功能保留主路径，把两个低使用频率的筛选选项移到后续版本；将稳定性改造拆成告警补齐和架构重构，先完成风险较高的告警部分；数据分析需求先交付关键漏斗指标，延后细分维度探索。调整后测试需求降到 25 人时，数据分析需求降到 10 人时，分别回到可承诺范围内。

这里的关键不是简单砍需求，而是识别“价值与资源的关系”。如果一个边缘功能占用了唯一测试人员大量时间，就要问它是否必须与主功能同批交付；如果某项分析只是为了验证一个假设，先用低成本数据回答核心问题，可能比一次性搭建完整看板更合适。

4. 第四步：周期中更新容量并记录变化原因

周期进行到第 2 天，线上出现一个高优先级问题，预计占用研发 8 人时、测试 5 人时。团队不应把这项工作当作“额外加班”悄悄塞进去，而应重新看受影响的承诺：优先保障客户关键流程修复，将低优先级筛选项明确移出本周期，并同步更新发布范围。

周期结束后，记录计划工作、实际完成、突发工作和延期原因。假如测试工作量连续三期高于计划，下一轮就不应只提高测试估算，而要检查需求拆分质量、验收标准是否过晚确认、环境准备是否反复等待。Capacity 复盘要改变下一轮决策，而不是只解释上一轮为什么没完成。

5. 案例中的判断结果：管理者应看到三种不同信号

第一种信号是总量余量：它说明团队整体还没有被所有工作填满，但不代表可以继续接需求。第二种信号是角色峰值：测试和数据分析超载，说明需要调整范围、错开发布窗口或补充专业能力。第三种信号是不确定性：线上支持变化较大时，固定容量承诺应更保守。

如果组织使用 PingCode 这类项目管理平台来呈现项目、需求、任务和负责人，建议把容量视图与工作项状态、计划周期和责任角色建立关联，而不是单独维护一份无人更新的电子表格。工具能帮助减少信息分散，但容量口径、优先级规则和例外处理仍需由团队共同约定。

六、从 0 到 1 的落地步骤：用四个周期形成可复用机制

1. 第一个周期：只收集最少必要信息

第一周期的目标不是追求准确，而是获得可解释的基线。先记录团队成员、角色、工作时间、已知休假、固定会议、运营支持、当前承诺工作和关键依赖。

信息字段控制在团队能持续维护的范围内。若一项字段无法改变排期、优先级或资源决策，就先不收集。避免要求每个人填写精确到小时的个人时间表，除非工作性质确实需要这种粒度。

2. 第二个周期：按角色检查负载和切换成本

第二周期开始用角色维度汇总容量，观察负载是否集中在少数岗位。与此同时，记录每个人同时参与的项目数量。多项目并行不仅是容量分配问题，还会带来上下文切换成本，尤其当团队成员每天都在不同项目之间切换时，名义上分配的百分比可能无法转化为连续交付。

如果团队发现成员同时参与四五个项目，不要立即用更精细的百分比分配来解决。优先尝试减少并行项目数、集中工作窗口、明确单一责任人，通常比把每个人的时间切成更多小块有效。

3. 第三个周期：用偏差复盘建立团队自己的缓冲率

缓冲率不应从别的团队照抄。收集连续周期中的突发工作量、延期原因和实际可用容量后，观察波动范围。若某团队每个周期都固定承担大量客户支持，就应把支持容量作为计划的一部分，而不是把它包装成意外。

若波动主要来自少量大事故，可以采用风险储备和触发机制；若波动来自日常零碎需求，应建立支持轮值、服务时段或工作入口。两种情况需要不同的管理手段，不能只用一个更大的缓冲百分比掩盖问题。

4. 第四个周期：把容量纳入需求评审和路线图决策

当团队对容量有了基本信任，产品经理可以在需求评审阶段就展示资源影响：需求涉及哪些角色、占用哪个周期、依赖谁、会挤出什么工作、风险缓冲是否被消耗。这样，优先级讨论就不再停留在需求价值排序，还能回答“为了做它，我们放弃什么”。

路线图上的日期也应标注置信程度。已完成技术验证、依赖明确的工作，可以给出较窄的交付窗口；需求仍在探索、外部审批未确认的事项，应标注假设和检查点。把不确定性显性化，比把所有事项都写成确定日期更能保护团队和业务关系。

七、不同情况下的行动建议：不要用同一种容量策略套所有团队

1. 初创或小型团队：用简单规则，避免精细排班

人员少、角色交叉多、需求变化快的小团队，不一定需要复杂的容量系统。可以按周期估算团队可投入范围，标出固定支持占用和关键依赖，再明确最多同时推进几项工作。

这类团队适合使用粗粒度工作量、短周期回顾和清晰的优先级规则。不要花大量时间维护个人利用率表，也不要让容量数据变成管理者追踪每个人是否“足够忙”的工具。

2. 中大型、多项目组织：重点治理跨项目争抢

当多个项目共享设计、测试、数据、安全或架构资源时，问题通常不是单个团队不会排期，而是跨项目优先级没有统一决策机制。此时要建立共同的规划窗口、资源冲突升级路径和变更记录。

组织可以先选择几类共享关键资源作为试点，明确容量负责人、工作分配规则和例外审批人。对于 100 人以上组织，PingCode 等项目管理平台可以作为信息汇总与协作载体，但不应被当成组织治理的替代品：如果项目负责人仍各自承诺、冲突无人裁决，换工具也不会自动消除争抢。

3. 维护和运营占比高的团队：把支持容量显式化

若团队经常处理线上故障、客户问题或合规请求，应把支持工作作为稳定工作类型规划，而不是每次都从项目计划里“临时挤”。可以采用轮值、专门服务窗口或按历史负担预留容量。

支持工作若高度不可预测，建议采用短周期计划并设置明确的升级规则。若连续多个周期支持负担超过预留范围，就需要讨论产品质量、自动化、客户沟通或运维资源，而不是长期依靠核心研发加班补洞。

4. 探索型产品团队：用时间盒管理容量，不用假精度承诺产出

创新探索、用户研究和技术验证的结果高度不确定。此时应承诺投入时间、学习目标和决策节点，而不是承诺尚未验证的完整功能清单。比如约定两周完成用户访谈与原型验证，之后根据证据决定扩大、调整或终止。

这种方法看似不如固定交付日期“确定”，却能避免团队在错误方向上持续投入。Capacity 的作用是限制探索成本并保障关键能力可用，而不是迫使探索任务伪装成成熟项目。

5. 交付节奏稳定的团队：利用历史完成量做区间预测

如果团队工作类型相对稳定、任务拆分方式一致，可以记录连续周期的完成量，用中位数或区间估计未来能力。不要仅依据表现最好的一期制定计划，也不要把平均值当成保证值。

可同时查看较保守、常态和乐观三种情景。例如把历史完成量的低位区间作为对外保守承诺，把中位水平用于常规规划，把高位水平用于内部机会评估。具体统计窗口应根据数据稳定性决定，工作方式刚变化时旧数据不宜直接沿用。

八、不同情况下的取舍：容量模型没有唯一正确答案

1. 统一口径与团队自治之间的取舍

跨部门协作需要统一的基本定义，否则总量无法比较；但不同团队的工作性质又不一样。我的建议是统一“字段和决策原则”，允许团队在估算方法上保留差异。

例如，所有团队都记录可用容量、已承诺工作、突发工作和风险缓冲，但探索团队用时间盒，运维团队用支持工单量，产品交付团队用历史工作量。统一的是管理语言，不是强行统一所有产出单位。

2. 估算精度与维护成本之间的取舍

估算越细，不代表决策越好。若每个任务都要经过多轮估算、每周更新大量百分比，维护成本可能超过收益。精度应该围绕决策风险投入：影响发布窗口、关键依赖和共享资源的工作值得细化；低风险、可逆的小任务可以粗估。

当团队对某项工作仍有大量未知时，继续细化数字没有意义。把未知项转成验证任务，往往比把 40 人时讨论成 36 或 44 人时更有效。

3. 高利用率与可靠交付之间的取舍

团队可以在短期冲刺中提高利用率，但需要明确代价：缓冲变少、应急能力变弱、任务切换更频繁，且恢复时间可能增加。若业务处于重大上线窗口，短期集中资源有时合理；若长期保持高负载，则应把它视为结构性风险，而非团队效率的证明。

判断是否该提高负载，要看交付波动、返工、缺陷和人员恢复情况，而不只是看是否按期上线。短期产出提升但质量和团队稳定性持续下降，说明组织正在透支未来容量。

4. 集中资源与多项目并行之间的取舍

多项目并行能让每个项目都“有人负责”，但可能增加切换和等待；集中资源能更快完成少数优先事项，却意味着其他项目暂时停滞。产品经理需要根据业务价值、依赖关系和机会成本作出明确选择。

如果所有项目都被标为最高优先级，说明组织没有完成优先级决策。容量模型无法替代决策，只能把资源冲突摆到桌面上。管理者要明确哪项工作先获得稀缺能力，以及被延后的项目何时重新评估。

5. 预测与承诺之间的取舍

预测描述基于当前信息最可能发生什么；承诺则意味着团队接受责任并配置资源。两者不应混为一谈。对外沟通时，可以先给预测区间和前提；只有在范围、依赖和容量得到确认后，再形成正式承诺。

如果业务方要求立即给出确定日期，产品经理应说明日期依赖的条件，并提供可选方案：缩小首发范围、调整发布窗口、补充资源，或接受更高风险。把选择权交给决策者，比用一个没有依据的日期换取短暂安心更专业。

九、衡量 Capacity 是否有效：看决策质量，不只看表格完整度

1. 有效机制会让延期更早被发现

Capacity 管理的首个成果，往往不是交付速度突然提升，而是冲突更早浮现。过去在发布前一周才发现测试排不过来，现在能在周期规划时发现角色容量不足；过去需求变更造成的影响无人记录，现在可以看到它挤占了哪项承诺。

如果管理机制运行一段时间后，延期仍然只在最后时刻暴露，说明容量数据没有和依赖、实际进度或变更流程连接起来。此时应检查信息更新机制，而不是继续增加更多容量字段。

2. 重点观察组合指标，避免单指标驱动错误行为

承诺完成率高，不一定代表团队健康。如果它是通过持续加班、降低质量或把难任务移出统计实现的，单看完成率会得出错误结论。容量复盘应结合突发工作占比、返工、缺陷、任务切换和延迟原因。

同样，利用率低也不必然代表资源浪费。某些关键角色需要为突发事件留出空间，探索团队需要时间处理未知，架构人员可能承担跨项目支持。只有结合业务结果和工作性质，指标才有解释力。

3. 建立一页式复盘，避免报表堆叠

每个周期结束后，用一页信息回答：计划容量与实际容量相差多少；哪些角色超载或闲置；突发工作占了多少；哪些承诺完成或未完成；下周期会采取什么改变。复盘必须落到具体动作，例如调整支持轮值、提前冻结验收标准或减少并行项目。

如果复盘内容连续几期都只是“需求变多、人员不足、加强沟通”，说明分类还不够具体。应继续追问需求增长来自哪里、哪些工作可延后、哪类依赖反复等待，以及资源补充是否真的比范围调整更划算。

十、结尾：从一张容量表开始，但不要止步于一张表

1. 最值得记住的判断

Capacity 管理最容易被误解成排班和填表，实际要解决的是有限能力如何被分配、承诺如何被校准、变化如何触发取舍。团队人数只能说明资源规模，角色能力、固定工作、依赖和不确定性才决定实际交付边界。

我的独特判断是：容量模型不必先追求预测准确，应该先追求偏差可解释。当团队能说清楚容量为什么变化、哪个岗位形成瓶颈、某项需求挤出了什么工作，模型才开始有用；之后才有条件用历史数据逐步提高预测质量。

2. 下一步怎么做

如果你准备从 0 到 1 开始，可以从下一个规划周期做三件事：先统一理论容量、可用容量、可承诺容量和已分配容量的定义；再按角色检查工作量，找出总量之外的瓶颈；最后在周期结束时记录预测偏差、突发工作和延期原因。

先选一个团队试运行，不急着推广全组织，也不急着购买更多报表。连续跑过几个周期后，依据真实偏差调整缓冲、估算粒度和资源规则。最终要形成的不是一张永远正确的容量表，而是一套能帮助产品经理更早发现冲突、让管理者做出明确取舍、让团队对承诺保持信任的工作机制。

常见问题解答（FAQ）