Capacity怎么做？产品经理流程优化：资源负载从0到1

Capacity（容量规划）不是把每个人的工时填进表格，再用红色标出超载的人。真正让产品经理头疼的，通常是这样的场景：路线图上有三个“本季度必须完成”的项目，团队名义上有十几个人，可关键后端工程师同时被四个项目预订；每个负责人都认为自己的需求只占一点时间，最后却没有一个项目按计划交付。要从0到1做好资源负载，关键不是先买工具，而是先统一“可用容量、需求占用和决策规则”，再让数据进入排期与取舍。

一、先讲核心结论：Capacity首先是一套决策机制

1. Capacity不等于工时登记

我判断一套Capacity做法有没有价值，不看表格有多少列，而看它能不能回答三个问题：团队在某个时间段内实际能交付多少工作；当前承诺占用了多少容量；发生冲突时，谁依据什么规则做取舍。只记录员工每天做了什么，通常得到的是事后统计，不是可用于排期的容量管理。

容量管理关注的是未来某个周期内的可用能力。它要把假期、会议、支持任务、值班、技术债和不确定性放进同一个视图，再与已承诺的需求对照。这里的“能力”也不是人的价值或绩效分数，而是团队在特定技能、协作条件和时间边界下完成工作的能力。

2. 从0到1，先形成可执行的最小闭环

我建议先建立一个小而完整的闭环：确定规划周期，估算团队可用容量，拆分项目需求，识别技能瓶颈，做一次优先级取舍，执行中定期更新，周期结束后复盘预测偏差。闭环可以先用表格完成，重点是让每个数字都能追溯到输入条件和责任人。

第一个月的目标不是预测得很准，而是让团队用同一套口径讨论负载。如果各部门对“一个人有多少可用工时”“一个需求算不算已承诺”都没有共识，再精致的系统也只会把口径冲突可视化。

3. 先管团队和技能，再细到个人

Capacity管理经常被误做成个人日历管理。我的判断是，早期应该先看团队总量、角色分布和关键技能，不要急着追踪每个人每天的小时数。产品交付依赖跨职能协作，某个团队总容量看似充足，也可能因为缺少测试、数据或特定领域经验而无法完成关键路径上的工作。

因此，第一版至少要能区分团队、角色或技能组。个人层面的分配只在存在明确的关键资源约束时展开，并且要与人员沟通、工作约定和隐私边界保持一致。

二、背景和真实场景：为什么“人不少”仍然会持续延期

1. 多项目并行时，容量会被重复承诺

在中大型组织里，资源通常不是整齐地归属于单个项目。产品经理、研发、测试、数据分析、设计和运营可能同时支持多个业务线。每个项目的排期看起来都合理，问题出在局部承诺没有汇总：A项目预订某位工程师每周两天，B项目也预订两天，临时支持再占一天，实际却没有人为这五天的冲突负责。

这类冲突往往不是谁故意超额安排，而是组织缺少一个共同的容量视图。项目负责人掌握自己的需求，职能负责人掌握人员情况，高层只看到里程碑。信息分散时，最容易出现的结果就是“所有项目都重要”，而执行团队承担了把不可能的计划变成现实的压力。

2. 产品经理的工作负载常被低估

产品经理的排期容易只记录需求分析、原型和评审，却漏掉用户访谈、数据核验、跨团队对齐、上线验收、客服反馈和临时决策。结果是计划表上看起来还剩两天，真实工作却早已排满。相同问题也发生在测试、架构和运维角色上：交付需求容易被估算，维持交付系统运转的工作却经常被当成“顺手处理”。

我会把工作分成两类：一类是可以明确对应项目和交付物的计划工作；另一类是持续发生但难以逐项提前列出的运营工作，例如线上问题、支持请求和例行协调。后者不应该被当作偶发噪声，应该用历史观察或明确预留容量处理。

3. 工具能提供视图，不能代替资源决策

在100人以上、多个团队并行的组织中，项目、迭代、任务、角色和成员分布在不同层级，单靠个人日历通常无法还原组织级负载。以PingCode为例，产品团队可以借助项目与需求管理相关信息建立跨项目视图，把需求计划、任务状态和资源安排放在同一套协作流程中讨论。但工具是否适用，仍取决于组织能否维护数据、定义容量口径并授权决策。

如果团队还没有稳定的需求拆分方式，成员经常临时变更，项目负责人也没有权力调整优先级，那么先把流程和责任讲清楚，比先配置复杂资源报表更重要。工具可以降低汇总成本，却无法替代管理层对“哪些工作可以延期”的回答。

4. 先确认组织究竟在优化什么

有的团队想提高交付预测能力，有的团队要减少关键岗位过载，有的组织希望识别项目组合中的资源冲突，还有的团队只是想让跨部门排期不再靠反复开会。目标不同，容量模型的颗粒度就不同。若没有清晰目标，团队很容易把收集更多工时数据误认为管理能力提升。

我通常会先问：过去一个季度，最贵的容量问题是什么？是上线延期、需求频繁插队、关键人员加班，还是管理者看不到项目冲突？先选一个主要问题，第一版模型才不会膨胀成一套无人维护的全面填报机制。

三、常见误区：这些做法会让容量数据失真

1. 把名义工时当成可交付工时

“每人每周40小时”只是劳动时间口径，不是可用于项目交付的容量。法定假期、休假、会议、团队例会、培训、值班与支持都会减少项目可用时间。不同组织的实际比例差异很大，直接套用某个固定折扣率，容易制造虚假的精确感。

更稳妥的做法是从本团队的实际日历和历史记录出发。可以先估算一个周期的净可用时间，再分别列出稳定性较高的固定占用和波动较大的运行负担。连续观察几个周期后，再修正假设，而不是把一个拍脑袋的“有效工时比例”长期当成事实。

2. 把所有工作压成一个人天数字

不同类型的工作并不能简单互换。一个工程师有两天空档，并不意味着他能替代两天的用户研究、特定系统排障或数据建模。若只比较总人天，团队会得到“人数足够”的结论，却忽略技能、领域知识、权限和依赖关系。

第一版不必建立非常细的技能矩阵，但要识别关键岗位和单点依赖。对于确实有技能瓶颈的工作，至少要在需求计划中标注所需角色、关键人员或团队，并明确是否存在替代人选、知识交接或外部依赖。

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

把每个人的计划排到接近100%，看起来像是最大化资源使用，实际常会削弱团队应对变化的能力。工作之间存在切换成本，需求也会发生返工、等待和紧急插入。排满日历的团队，一旦遇到一个关键问题，就可能让多个承诺一起延期。

利用率更适合用来发现长期异常，而不是作为个人表现目标。对知识工作而言，容量计划中留出缓冲并非浪费，而是为变化和协作支付的现实成本。缓冲多少，应由业务波动、工作类型和历史偏差决定，不宜要求所有团队统一使用同一个比例。

4. 把“已排期”误当成“已承诺”

计划里出现一个需求，不代表它已经具备交付条件。需求范围不清、验收标准缺失、上游依赖未确认、关键决策人未到位时，估算往往只是早期假设。如果把这类需求当成确定工作，容量图表会显得完整，执行阶段却不断出现返工和重排。

我会把需求状态至少区分为待澄清、候选、已承诺和执行中。只有经过必要的范围确认、依赖检查和优先级决策，才进入承诺容量。这样可以避免把“有人提过”与“团队已经答应”混为一谈。

5. 用精确工时制造精确幻觉

对长周期、探索性或依赖较多的项目，精确到小时的估算通常不代表真实掌握程度。团队可能填出“17.5小时”，但需求边界和技术风险仍然未知。数字的小数位越多，不确定性并不会自动变少。

初期应优先使用团队能够稳定理解的单位，例如人天、工作量档位或区间估算，并标注置信程度。复杂度高、信息不足的任务要先拆解或试验，而不是通过更细的数字格式掩盖信息缺口。

6. 把容量报表做成个人绩效监控

如果成员认为填报数据会被直接用于比较谁更忙、谁更有效率，数据质量通常会快速下降。人们会回避记录临时支持、把时间填得更接近预期，或者不愿意暴露估算偏差。容量信息的首要用途应该是项目组合和团队排期，而不是用工时数字代替绩效判断。

组织需要明确数据用途、查看范围和维护责任。个人层面的信息只在确有排期需要时使用，趋势分析以团队和工作类型为主，并将记录过程控制在合理负担内。

四、专业判断逻辑：建立一套能持续修正的容量模型

1. 先定义时间窗口和管理对象

时间窗口需要与组织实际决策节奏一致。团队按周滚动安排任务，管理层按月审视项目组合，年度路线图则适合观察方向和依赖。若用年度计划直接精确到个人周工时，误差会迅速积累；若只看本周，又可能错过跨项目的中期冲突。

我通常建议采用分层视角：近端两到六周关注团队交付与技能负载；季度层面关注项目组合和关键依赖；更远期只做能力情景推演，不做个人级承诺。具体周期应由团队的变更频率决定，而不是追求统一格式。

2. 计算净容量，而不是简单数人头

容量计算可以从一个容易解释的式子开始：周期净容量＝可工作时间－已知固定占用－运行支持预留－其他明确承诺。这里的重点不是公式多复杂，而是每一项都可以说明来源。团队成员的工作日、请假、固定会议与角色责任，应当在相同周期中核算。

例如，一个五人团队在两周内有十个工作日，名义上是50人天。如果其中有人休假、承担值班、参加专项培训，净容量就会低于50人天。团队再把这部分净容量按角色或技能拆开，才能判断某个项目是否有可用的研发、测试和产品工作量。

对于计划性较弱的支持工作，不要假装能够精确预测每一个工单。可以先用过去几个周期的中位数或范围做预留，并在复盘时记录实际发生量。若历史数据不足，应明确标注为初始假设，逐周期校准。

3. 把需求换算成可比较的容量需求

需求侧不能只写一个项目名称。至少要拆出范围、交付周期、主要角色、外部依赖和估算区间。产品经理可以把需求分解成可讨论的交付单元，例如调研与方案、开发、测试、发布准备和上线观察。这样才能识别工作是集中在某个角色，还是均匀分布在团队中。

估算可以使用区间表达。比如某功能预计需要8至12人天，其中研发5至7人天、测试2至3人天、产品与设计1至2人天。区间不是偷懒，而是承认需求阶段的认知不确定性。进入执行后再用实际结果修正类似工作的估算参考。

4. 在总量之外，判断约束是否落在关键位置

如果团队总共还有20人天容量，却只缺某个关键角色的5人天，项目仍可能无法按时交付。判断负载时，我会同时看三个层级：总容量是否够，角色容量是否够，关键人员或依赖是否可用。只有三个层级都没有明显冲突，计划才具备初步可执行性。

关键资源不一定是职级最高的人。它可能是唯一熟悉某个老系统的工程师、能完成特定合规评审的人，或必须参与多个决策的领域专家。把这类依赖显性化，才能讨论知识转移、替代方案和排期优先级。

5. 用负载率做预警，不用作个人排名

一个便于讨论的团队负载率定义是：已承诺工作量÷净可用容量。它可以帮助识别明显超载和空闲，但不能单独说明交付能力。因为已承诺工作量可能尚未成熟，容量估算也有误差，工作之间还存在并行和依赖关系。

可以为团队内部设定自己的观察区间，例如低于某个范围时检查需求准备是否充分，接近容量上限时检查风险和缓冲，超过容量时必须作出优先级决策。区间应由历史偏差和业务节奏校准，不应被包装成适用于所有公司的硬性行业标准。

6. 把不确定性纳入计划，而不是藏在备注里

容量表中至少需要区分三类工作：确定性较高、依赖待确认、探索性或高风险。对于依赖未确认的工作，可以保留候选容量而不做正式承诺；对于探索性工作，可先安排短周期验证，再依据结果更新范围。

一个有效的计划不是声称所有事情都确定，而是清楚标出哪些假设可能改变排期。产品经理的价值，往往体现在及时把不确定性转化成可执行的验证任务，而不是把未解决的问题留给开发阶段。

五、具体案例：一个季度路线图如何从“都能做”变成可交付计划

1. 案例背景与假设边界

下面用一个情景模拟说明判断过程。某数字产品团队有12名成员，包含产品、设计、研发、测试和数据角色，季度内同时面对三个目标：优化新用户转化、迁移一段基础服务、补齐数据质量问题。各项目负责人最初都认为自己的方案可以在本季度完成。

这个案例中的数字是为了演示容量判断方法而构造的样本推演，不代表某家企业的真实经营数据，也不构成行业基准。实际应用时，应以团队人员日历、历史支持量、已完成需求的工作量和项目依赖替换这些数值。

2. 先找出总量背后的角色瓶颈

团队按一个12周季度计算，理论工作时间约为720人天。扣除已知假期、例会、支持工作和固定运营安排后，得到约490人天的计划交付容量。乍看之下，三个项目的估算总量约440人天，似乎还留有50人天空间。

但按角色拆分后，问题出现了：研发需求约260人天，研发净容量约250人天；测试需求约82人天，测试容量约68人天；产品与设计总需求接近容量上限。整体总量没有超出很多，测试和特定研发能力却已经成为明确瓶颈。

这一类结果很常见：总量数字容易让管理者产生“只差一点就够”的错觉，角色层面的缺口却会沿着关键路径放大。此时继续要求每个人加快，并不能自动补足测试环境、领域知识或研发技能。

3. 把每个项目拆成容量剖面

团队进一步把三个项目按角色拆分，并标出估算区间、依赖和价值假设。转化优化需要较多产品研究、研发和实验分析；基础服务迁移集中消耗研发与测试；数据质量项目依赖数据工程能力，并且迁移项目完成后才能取得完整收益。

拆分之后，项目讨论从“哪个项目更重要”转为“在当前容量约束下，哪些交付范围最值得保留”。这一步非常关键，因为如果只比较项目总人天，通常无法看出某个工作包是否可以延后、缩小或先验证。

4. 做一次有依据的范围取舍

团队没有把三个项目全部判定为必须完成，而是先保护具有时间敏感性的转化实验和必要的基础迁移，数据质量项目则分成两阶段：本季度先完成高风险数据源的修复与监控，低优先级历史数据清理移到下一周期。这样既保留了主要业务结果，也降低了测试角色的集中负载。

在取舍过程中，产品经理需要把代价讲清楚：延期的功能是什么，影响哪些用户或运营场景；缩小范围会损失什么验证能力；若坚持原计划，需要增加何种资源、付出多大协调成本。不能只说“资源不够”，也不能把所有代价都转嫁给执行团队。

5. 用执行中的偏差校准下一轮

季度执行中，团队每两周更新剩余工作量、支持任务和依赖状态。若一个需求的实际工作量连续超出估算，不立即指责估算者，而是判断偏差来自范围变化、技术未知、返工、等待还是支持任务侵入。不同原因需要不同措施：范围变化要加强变更决策，技术未知要安排验证，等待则要处理依赖。

假设本季度预留的支持工作为42人天，实际发生58人天，多出的16人天可能解释部分延期。团队应进一步检查突发工作集中在哪些系统、是否有重复故障、是否存在没有被正式分配的运维责任。否则，下一季度仍会使用同一套过于乐观的容量假设。

六、从0到1的落地步骤：先把数据管起来，再逐步自动化

1. 第一步：选定一个业务范围做试点

试点范围最好具备明确负责人、相对稳定的团队边界和真实的项目冲突。可以选择一个产品线、一个跨职能团队或一个季度项目组合，不建议一开始把全公司所有人员和项目都纳入。范围越大，数据维护和口径协调成本越高，问题也越难定位。

试点开始前，先写清楚这次Capacity实践要解决什么。例如，减少关键角色超载、提高季度承诺可信度，或让项目优先级讨论有共同依据。目标应对应可观察的行为或结果，而不是“建立资源管理体系”这类难以验收的口号。

2. 第二步：建立最小数据字典

最少要统一以下概念：规划周期、人员或技能组、净容量、固定占用、运行支持、候选需求、已承诺需求、实际工作量和估算置信度。每个字段都要说明由谁维护、何时更新、什么状态算完成。

如果同一个“已承诺容量”在一个团队里表示已经审批，在另一个团队里却只是初步意向，汇总结果就没有可比性。数据字典不需要写成厚重制度，但关键术语应当有简短、可执行的解释。

3. 第三步：采集低成本且足够的输入

第一版不需要追踪每个人每天每小时的活动。优先收集日历、假期、团队固定职责、项目需求估算和已知依赖。对于运行支持，如果当前没有工单分类数据，可以先按周记录团队总量与工作类别，不要把填报负担设计得比问题本身还重。

估算最好由实际执行角色参与，而不是由项目负责人单方面分配。产品经理提供范围和验收条件，研发与测试补充技术工作量和风险，负责人确认优先级及承诺边界。Capacity不是给工作贴一个数字，而是让相关角色共同确认计划假设。

4. 第四步：开一次以冲突为中心的规划会

规划会的重点不是逐个项目朗读进度，而是找出冲突、讨论替代方案和作出决策。可以按以下顺序进行：

1. 确认周期内的净容量与已知缺勤。
2. 查看已承诺需求的角色分布和关键依赖。
3. 标出超出容量、接近上限或置信度偏低的项目。
4. 比较延期、缩小范围、增加资源、调整顺序等方案。
5. 记录最终取舍、责任人、影响范围和复查时间。

会议的输出不应只有一张红黄绿图，而应包括明确的决策：哪些工作进入承诺，哪些仍是候选，谁有权批准插入新工作，发生变化时需要重新评估哪一部分容量。

5. 第五步：周期内滚动更新，不要等到月底算总账

容量计划是滚动视图，不是一次性预算。团队可以按周或双周检查实际工作量、剩余工作、突发支持和依赖状态。更新时要优先处理影响承诺的变化，不必为了追求整齐而重复录入没有变化的信息。

当新增工作进入时，必须同时回答它挤掉了什么。若组织允许紧急需求无条件插入，容量计划会变成事后解释工具。负责人要明确例外机制：什么情况可以插队，谁能批准，影响如何同步给相关项目。

6. 第六步：复盘预测偏差，形成团队自己的参考值

每个周期结束后，对比计划与实际，但不要只比较总工时。可以按角色、工作类型和偏差原因复盘：估算偏差、需求变更、支持任务、等待依赖、返工或人员变化。连续几个周期后，团队会逐渐知道哪些类型的工作容易被低估，哪些支持量需要单独预留。

一项实用做法是记录“预测偏差分布”，而不是只记平均值。平均数可能被少数大项目拉动，区间更能说明计划风险。若某类需求经常落在估算上界之外，应先查拆分质量和范围稳定性，再决定是否调整估算规则。

7. 第七步：根据规模决定是否接入管理平台

当项目数量、团队数量和角色交叉关系增加后，手工汇总的成本会快速上升。此时可以考虑使用项目管理平台，把项目计划、任务、负责人、进度和跨团队视图连接起来。PingCode可作为中大型企业及100人以上组织评估项目协作与资源信息整合时的候选方案之一，实际是否适用仍应通过业务流程匹配、权限模型、数据迁移和试点验证来判断。

选择工具时，我会重点验证四件事：能否表达团队与角色层级，是否支持计划与实际状态协同，能否保留变更和决策记录，管理者与执行者是否愿意持续维护。若工具只能显示分配量，却不能说明估算来源和承诺状态，组织仍需依靠线下表格补充关键决策。

七、指标与图表：怎样判断容量管理真的有用

1. 关注预测质量，而不是追求看板漂亮

容量管理的结果应体现在计划质量上。可以观察承诺完成率、计划变更率、估算偏差、临时插入工作比例、关键角色负载峰值和支持工作预留准确性。指标不必一次全部上线，建议先选两到四项与试点目标直接相关的指标。

承诺完成率需要谨慎解释。如果团队为了提高数字而减少承诺，完成率会变好，却不一定创造更多业务价值。因此最好同时看交付范围、用户结果或业务目标是否实现，避免单指标驱动行为。

2. 用负载区间发现讨论对象

团队负载率适合用作预警信号：明显偏高时检查过载和范围取舍，明显偏低时检查需求准备与依赖等待，接近满载时检查变更空间。这里的重点是触发问题，而不是把某个数值当作自动判定绩效好坏的红线。

不同工作类型的波动差异很大。探索型团队可能需要更多试验和方向调整，运维密集型团队的支持负担可能变化明显，版本交付型团队则更需要关注测试与发布窗口。跨团队对标前，先确认口径是否一致，否则数字差异可能只是业务类型不同。

3. 设计能促成行动的图表

团队图表应当直接指向行动。例如，按角色展示需求与容量，用于调整范围；按周期展示预测与实际，用于校准模型；按工作类型展示支持时间，用于查找运营负担；按项目展示需求集中度，用于识别组合风险。若图表无法引出一个可以由责任人执行的动作，它很可能只是装饰。

图表需要同时呈现数据口径和边界。比如“实际工作量”是否包含会议，“承诺完成”是否按原始范围计算，“容量”是否扣除休假。没有这些说明，不同团队之间的可视化对比会造成错误结论。

八、不同情况下的行动建议与取舍

1. 团队规模较小、项目较少时

如果团队只有一个主要产品方向，且跨项目冲突不明显，先用共享表格或简单看板即可。把周期、成员、角色、可用时间、已承诺工作和不确定性记录清楚，再每周短会检查变化。此阶段的收益来自口径统一，不来自复杂建模。

小团队不宜过早追求人员级利用率报表。团队成员通常可以直接沟通，维护一套细颗粒度工时系统的成本可能高于减少的协调成本。出现重复冲突后，再增加技能分组或项目组合视图。

2. 中大型组织、多项目并行时

当多个业务线共用关键角色、项目负责人数量增加、管理层无法看见冲突时，应该建立跨项目的容量治理机制。明确谁负责各类数据，谁批准优先级，资源冲突如何升级，哪些承诺不能被项目负责人单独改变。

对于100人以上的组织，平台化通常更有价值，但前提是统一项目结构、角色口径和状态定义。工具上线前，应先选取一条跨团队流程试点，验证从需求进入、容量评估、冲突决策到周期复盘的完整链路，而不是只迁移旧表格。

3. 工作高度不确定、处于探索阶段时

探索型工作不适合用确定性很高的长周期容量承诺。可以把计划拆成短周期验证：先安排少量研究或技术试验，明确要验证的假设、所需角色和停止条件，再根据证据决定是否扩大投入。

此时需要管理的是探索预算和决策节点，而不是假装项目范围已经稳定。若验证失败，及时停止或转向也是有效产出；Capacity应帮助组织看见投入边界，而不是把所有初始设想都推向开发。

4. 支持和运维工作占比高时

如果线上问题、客户请求或内部支持经常打断计划，先建立工作分类和发生量观察。按系统、问题类型、紧急程度和处理角色记录一段时间，找出高频来源，再决定是否设轮值、增加预留、改善产品质量或调整服务边界。

不要把支持工作一概归为“不可控”。其中一部分确实随机，另一部分可能来自重复故障、低质量需求、缺少文档或职责不清。Capacity视图能暴露容量被占用的事实，但要释放容量，还需要解决占用背后的业务原因。

5. 高层要求所有团队满载时

这类要求表面上追求效率，实际上可能把风险转化为更高的等待成本和延期概率。我的建议是用历史交付偏差、临时工作比例、关键角色排队和项目延期情况说明：计划容量之外的工作并没有消失，只是被隐藏到加班、返工或后续延期里。

如果组织仍决定提高负载，至少应限定试行范围和周期，观察加班、缺陷、承诺变更和交付稳定性。出现负面信号时，应允许调整。容量利用率不能脱离质量、流动效率和人员可持续性单独优化。

九、取舍与边界：什么时候不值得做得太细

1. 数据精度和维护成本必须平衡

越细的数据并不一定越有决策价值。按小时填报看起来精确，却可能增加填报时间、制造监控感并诱发数据修饰。如果决策只需要判断某个团队在未来六周能否承接一个需求，按人天或工作量区间通常已经足够。

我会用一个简单标准判断是否值得增加字段：这个字段是否会改变排期、范围或资源决策？如果不会，就先不采集。容量模型的目标是支持真实选择，而不是收集可以被统计的数据。

2. 集中管理和团队自主之间需要边界

组织级视图能够减少资源重复承诺，但过度集中也可能让每个排期都等待一个中央审批者。可以统一项目组合和关键资源的冲突决策，同时让团队保留对日常任务安排的自主权。

哪些事项需要集中协调，应以跨团队影响和机会成本为依据。涉及共享关键技能、多个业务线的重大冲突或明确的战略取舍，通常需要更高层决策；团队内部的小范围顺序调整，则应尽量在执行团队内完成。

3. 共享资源的弹性与上下文切换存在矛盾

把一位专家切成多个项目的零碎时间，可能提高账面利用率，却降低实际效率。知识工作需要理解上下文，频繁切换会带来重新进入问题、等待反馈和沟通协调的成本。因此，共享资源应尽量按连续时间块安排，而不是把每周每一天切成多个小段。

当共享资源长期成为排队瓶颈，通常有三种选择：降低同时进行的项目数，培养替代能力，或增加稳定投入。选择哪一种，要结合需求持续时间和专业能力稀缺程度。临时加人不一定能马上降低负载，特别是需要较长领域熟悉周期的岗位。

4. 不能把Capacity变成隐性承诺工具

计划表中的空白不意味着团队随时可以接新需求。空白可能用于处理不确定性、维护质量或等待外部条件。组织需要把“未分配容量”与“可立即接单容量”区分开，并由相关负责人决定是否释放。

同样，项目被标记为已承诺后，也不意味着范围不可调整。实际情况变化时，应该通过明确的变更决策重新评估目标、时间和容量。让承诺可被修订，不等于降低责任；真正的责任是及时说明变化及其影响。

十、结尾：从容量表回到真正的业务取舍

1. 让数字服务于选择，而不是替代选择

Capacity从0到1，最重要的不是得到一个看起来准确的负载百分比，而是让组织第一次能在同一张图上看见需求、容量、技能瓶颈和不确定性。数字的价值在于暴露冲突，让管理者决定做什么、不做什么，以及改变计划要付出什么代价。

我更愿意把容量管理看成一套持续修正的预测机制：先用可解释的假设做计划，执行时记录真实变化，周期结束后检查误差，再调整下一轮。预测会有偏差，但只要偏差被看见、能被解释并且能改变下一次决策，模型就在变得有用。

2. 下一步从一个周期、一个团队、一次决策开始

如果你现在准备启动Capacity，不必先设计全公司的完整框架。选一个真实存在冲突的团队，拉出未来四到六周的净容量，按角色拆分需求，标记候选与已承诺工作，开一次只讨论冲突和取舍的规划会。

周期结束后，复盘实际支持量、估算偏差和临时变更，删除没有帮助的字段，补上真正改变决策的信息。一张能推动取舍、并在下一轮变得更准确的简单表，比一套无人维护的复杂模型更有价值。