Capacity落地方案：项目负责人开展资源负载的最佳实践案例解析

项目计划里写着“后端工程师投入 100%”，周会上却连续三周有人说“这周排不开”；项目负责人看板上还有 12 个空闲人天，交付日期仍然一再后移。做 Capacity（资源容量与负载）规划时，我最常见到的矛盾不是团队真的缺人，而是计划中的“可用”与现实中的“能交付”不是一回事。落地的关键，不是把每个人排满，而是用统一口径识别有效容量、需求冲突和风险缓冲，再把资源决策嵌入项目节奏。

本文案例数据为情景模拟，用于演示计算与判断方法，不代表特定企业的真实经营数据。

一、先讲结论：Capacity 管理不是排满日历

1. 资源负载的目标是提高承诺可信度

我判断一套 Capacity 方案是否有效，首先不看资源利用率有没有达到 100%，而看三个更贴近交付的结果：团队承诺是否稳定、关键角色是否有持续超载、需求变化时负责人能否及时做出取舍。把每个人的日历填满，可能只会让计划看起来精确，却不能保证工作能按期完成。

Capacity 管理的基本关系可以写成：可承诺容量 = 可用工作时间 − 固定占用 − 必要缓冲；资源负载率 = 已承诺工作量 ÷ 可承诺容量。这里的“已承诺工作量”应来自有范围、有负责人、有估算依据的工作项；“可承诺容量”则要扣除会议、支持、休假、运维和跨项目协作等现实占用。

若只拿名义工时做分母，团队看起来可能长期有余量；若把所有时间都视为可交付时间，项目负责人便会在每次临时需求到来时发现计划无法兑现。容量数字的价值不在于预测每个人每小时做什么，而在于提前揭示承诺的边界。

2. 先统一三个口径，再谈工具

启动前，我会要求项目负责人、职能经理和团队成员先对三个定义达成一致：统计周期是什么、工作量按什么单位估算、什么情况下才算资源已承诺。缺少这三项，系统里的负载图只会把口径分歧画得更漂亮。

• 周期：建议从两周或一个月开始。周期太短会被日常波动干扰，太长则无法捕捉需求变更。
• 工作量：可用人天、小时或团队点数，但同一张容量表中不要混用；团队点数适合迭代团队内部相对估算，不宜直接换算成跨团队人天。
• 承诺状态：区分已批准、候选和待评估工作。只有已批准且有明确负责人、范围与时间窗的工作，才进入正式负载。

我倾向于把容量规划分成“预测”和“承诺”两层：预测用于看趋势、寻找冲突；承诺用于对外说明在当前假设下能交付什么。两层数据可以相关，但不能混为一谈，否则一个尚未批准的需求就可能挤占正式项目的容量。

3. 首批目标应是减少意外，而非追求精确

Capacity 落地的第一阶段，建议把目标设为“提前发现关键岗位冲突”，而不是“精准预测每位成员每天的产出”。前者能够通过较少数据实现；后者不仅难以验证，还容易把管理变成个人时间监控。

若一项方案要等到每个人每天登记所有活动才能运行，它的维护成本通常已经超过早期价值。我更愿意先用角色、周或迭代作为粒度，在团队回顾中验证容量假设，再逐步细化到个人和任务。

二、背景与场景：为什么项目负责人会低估资源冲突

1. 一个看似有余量、实际上已超载的项目组合

以下案例是依据常见项目组合管理问题构造的情景模拟。我假设一家有 120 名员工的中型软件企业，产品、研发、测试和实施团队并行支持多个版本与客户项目。人数达到百人以上后，项目负责人通常不再只管理一个团队的任务，而要与产品线、职能部门、客户交付和运营支持共同协调。

项目组合中有三个重点工作：新版本功能开发、重点客户交付和既有系统稳定性治理。表面上，研发团队每周合计可投入 400 小时；扣除会议、休假、支持后，实际可承诺容量约为 280 小时。三个项目分别申报 120、110、75 小时，总需求为 305 小时，超出容量 25 小时。由于每个项目只看自己的计划，冲突最初没有在单项目排期中显现。

更麻烦的是，容量不是均匀分布的。三个项目都需要同一位资深架构师参与评审，另有两位测试工程师同时承担版本验证和客户验收。团队总量看起来只超出约 9%，但关键角色的局部负载已接近 140%。这就是“总体容量够用，关键路径仍然堵塞”的典型情形。

2. 多项目并行时，角色瓶颈比总人数更重要

总人力是粗粒度指标，角色容量才决定很多工作的实际排队时间。增加一位尚未熟悉业务的工程师，未必能立刻分担架构评审；把开发人员调去测试，也不一定能在当期提高验收产能。项目负责人若只看团队合计人天，很容易把技能差异、上下游依赖和熟悉度当成可互换的空白。

因此，我会至少分两层看负载：第一层是团队或职能的总量，用于判断整体需求是否超出供给；第二层是关键技能与关键角色，用于定位真正的约束点。若团队总容量充足、关键角色过载，方案往往是调整顺序、减少并行、设立替补或缩小范围，而不是笼统地要求“再多投入一些”。

3. 组织规模越大，容量信息越需要有治理边界

在 100 人以上组织里，项目负责人通常依赖多个团队提供资源信息。不同部门可能分别使用工时表、迭代计划、电子表格和项目管理平台；同一名成员可能同时被登记为“可用”“预留”和“已投入”。容量治理的难点因此不只是计算，还包括数据责任、更新节奏和跨部门协调规则。

以 PingCode 这类面向中大型企业及 100 人以上组织的项目管理平台为例，项目团队可将工作项、迭代、负责人和计划容量关联起来，帮助负责人在一个协作环境中查看需求与执行状态。工具能降低信息分散造成的核对成本，但不能替组织决定谁有优先权，也不能自动解决职能经理与项目负责人的授权边界。真正的落地仍要先约定规则，再配置字段和视图。

三、常见误区：负载表做得越细，不一定越能交付

1. 把 100% 利用率当成最佳目标

资源利用率达到 100%，听起来像是没有浪费，实际却意味着计划没有为变更、故障、评审返工和估算偏差留下空间。若每位关键成员都排满，任何一个临时问题都会把后续任务整体推迟。局部超载还会让团队在多任务之间频繁切换，表面上同时推进，真正完成的工作却减少。

我会把“高利用率”和“高流动效率”分开看。前者衡量资源是否被占用，后者关心工作从开始到完成的等待和阻塞。对于知识工作团队，持续满载可能提高可见的忙碌程度，却未必提升交付吞吐量。Capacity 应用于判断是否留有合理余量，而不是制造每个人都必须满负荷的压力。

2. 把成员工时等同于项目产出

同样投入 20 小时，结果可能是完成一个已拆解的常规任务，也可能只是澄清需求、排查依赖或等待决策。项目工作不是把工时相加就能预测交付日期；工作之间的依赖、返工概率、角色稀缺性和决策时延，都会改变结果。

因此，容量规划应与范围和交付状态相连。工时可以作为资源占用的估算单位，但不应被误解为价值、效率或个人绩效的直接指标。若一个团队被要求不断提高利用率，成员可能倾向于把工作估得更满、隐藏支持任务，最终降低数据可信度。

3. 把“已安排”当成“已确认”

计划表上写了负责人，不代表该负责人已确认可投入；负责人确认了，也不代表任务边界、依赖和验收标准都清楚。把候选工作提前计入正式承诺，会让容量表虚增负载；反过来，把口头承诺遗漏，又会制造虚假的空闲。

我建议至少区分“候选、待确认、已承诺、执行中、完成或取消”几个状态。容量报表需要明确哪些状态参与统计，并能追溯状态变更。尤其在客户项目或跨部门项目中，不能仅凭项目负责人的排期视图推断资源已得到职能部门确认。

4. 用个人平均值掩盖峰值和技能约束

以团队平均负载判断是否安全，常会掩盖关键岗位的峰值。平均每人负载 80%，可能意味着多数成员在 70% 左右，也可能意味着一半成员空闲、一半成员过载。两种分布对交付的含义完全不同。

我会同时观察平均值、中位数、超载人数、连续超载周期和关键技能负载。对短期紧急任务，单周超过基准可能可以接受；连续多个周期超载则是结构性问题，应调整范围、优先级或能力供给，而不是把一次高峰当成团队常态。

5. 把工具上线当作流程落地

系统可以集中任务、人员、迭代和容量信息，但它不会替团队选择估算口径，也不会自动判定临时需求应由哪个项目让路。若组织没有明确更新责任和决策机制，工具初期可能带来更多重复录入：成员填工时，项目负责人维护排期，职能经理又在表格里维护一份“可信版本”。

我通常先确定唯一的数据责任链：谁维护工作项范围，谁确认成员可用时间，谁批准跨项目优先级，谁负责处理超载告警。工具配置围绕这条链展开，而不是为了“看起来功能齐全”把所有字段一次性加满。

四、专业判断逻辑：从输入、容量、需求到决策

1. 先定义规划对象和时间粒度

Capacity 规划可以面向个人、角色、团队或项目组合。初次落地时，我倾向于从团队与关键角色切入，再逐步细化到个人。若一开始就做个人级日历预测，组织需要承担大量维护成本，而且容易引发“被监控”的感受；若只看项目总量，又无法找出具体瓶颈。

时间粒度取决于工作节奏。研发迭代常用一至两周作为短周期，季度计划则适合按月观察趋势。容量预测周期要与决策周期匹配：如果资源调整至少需要四周审批，按周看见超载也不够，负责人应向前看更长的窗口。

2. 计算名义容量、有效容量和可承诺容量

我把容量分成三个层次，避免“40 小时工作周”被直接拿来排项目。名义容量是标准工作时间；有效容量扣除固定会议、休假、培训、日常支持等可预见占用；可承诺容量再扣除交付所需的风险缓冲。缓冲不是偷懒，而是承认知识工作中的不确定性。

例如一名全职成员每周名义工时 40 小时，预计会议 6 小时、支持 4 小时、评审协作 3 小时，休假折算 2 小时，则有效容量为 25 小时。若当前项目需要保留 20% 缓冲，可承诺容量约为 20 小时。这个计算并非要求成员每周只工作 20 小时，而是提醒项目负责人，不应在预测中把全部有效时间都提前承诺出去。

（1）把固定占用分类，而非笼统打折

常见做法是统一把团队容量打八折，优点是简单，缺点是无法说明差异。运维岗位、客户实施和产品研发的支持占用并不相同；同一个团队在版本发布周与常规周的会议、缺陷处理和协作负担也可能不同。能分类就分类，暂时无法细分时才用统一折扣作为临时假设。

（2）把缓冲与不可预见工作分开

支持工单、发布值守等可预测工作应作为容量扣减项，而不是塞进“缓冲”。真正的缓冲用于估算误差、未决依赖和不可预见变化。若所有占用都归为缓冲，团队无法判断容量损失来自业务常态还是计划风险，也就无法提出针对性的改进。

3. 用负载率识别压力，但不要把阈值当成通用定律

负载率可以帮助排序风险：低于组织设定的舒适区，通常有机会接纳新需求；接近上限，需要核对假设和依赖；超过 100%，意味着计划工作量超过可承诺容量。但“80% 安全、100% 危险”并非跨行业通用标准。不同团队的工作波动、值班责任、发布节奏和技能结构都不一样。

我会把阈值设为试行规则，并用过去几个周期的数据校准。例如，某团队如果每个迭代都因支持工作损失约 15% 计划容量，则其规划基线应当显式反映这部分工作，而不是每次迭代后都将偏差归咎于执行不力。阈值的意义是触发讨论，不是替代判断。

4. 先识别瓶颈，再决定增加供给还是减少需求

发现负载超出容量后，项目负责人要区分这是总量问题、技能问题、时间窗口问题，还是优先级问题。总量问题可以考虑缩小范围或增加有效供给；技能问题可能需要专家支持、培训或替补；时间窗口问题应调整依赖与里程碑；优先级问题则需明确哪个项目让路。

我反对把“加人”作为超载后的默认方案。新人融入、知识传递和协作成本会消耗现有成员的时间，短期内甚至降低团队可用容量。只有任务能够拆分、知识可转移、培训成本可接受，而且新增人员的有效贡献能赶上关键日期时，加人方案才有意义。

5. 让数据触发决策，而不是只生成红黄绿状态

负载图表的作用是提出问题：谁的负载连续超标？哪个项目占用了共享技能？哪个假设与实际偏差最大？真正的治理动作要落实为决策记录：改了什么范围、由谁批准、从哪个周期开始、风险由谁承担。

如果一个告警没有负责人、处理期限和后续复查，它只是颜色变化。成熟的做法是把超载状态关联到可执行的选项，例如调整优先级、拆分交付、替换角色、延后低价值工作或保留当前计划并接受风险。

五、案例拆解：如何把 25 小时超额转成可执行取舍

1. 先验证需求估算和容量假设

回到前面的情景模拟，三个项目合计申报 305 小时，团队可承诺容量为 280 小时。我的第一步不是立刻削减 25 小时，而是检查需求是不是重复计算、固定占用有没有遗漏、任务估算是否包含必要评审，以及这些工作是否真的要在同一周完成。

检查后发现，稳定性治理项目中有 12 小时的分析工作与版本开发项目重复，项目负责人原先分别估算了同一组日志排查；另外，某项客户交付任务尚未拿到验收环境，预计有 8 小时会在等待期间无法有效推进。修正后，明确的并行需求从 305 小时降至 285 小时，但仍超过容量 5 小时。重复计算被消除，不代表团队已经有余量。

2. 用角色负载而非只看团队合计安排工作

接下来按角色切片。架构师可承诺时间为 20 小时，三个项目初始合计需要 27 小时；测试人员可承诺时间为 48 小时，项目申报需求为 56 小时。其他研发角色在总量上尚有空间，但由于部分任务依赖架构评审和验收，不可能简单地将未占用时间替代这些稀缺技能。

我们先把非关键路径上的架构评审拆为异步预审与一次集中决策会，减少重复沟通；再让一位熟悉模块的高级工程师负责常规设计检查，架构师只处理高风险方案。这样并不是把专业工作降格，而是把稀缺专家时间用在真正需要其判断的环节。

3. 通过范围、顺序和替补三种手段恢复可承诺计划

在案例中，我会要求三个项目负责人共同评估工作优先级，而不是分别争取资源。最终选择保留客户验收里程碑，将版本开发中的两个非关键增强项延后一个迭代；稳定性治理保留高风险修复，低风险优化转为候选工作。同时指定测试替补提前参与需求评审，减少后期返工。

调整后，本周期确认工作量为 266 小时，可承诺容量仍按 280 小时计算，留下 14 小时用于预计波动。这里的 14 小时不是“闲置配额”，而是有意识保留的容量空间；若本周没有突发事项，可用于提前验证下个周期的高风险工作，但不宜在周初立即承诺给另一项长期任务。

4. 连续观察偏差，决定是否调整基线

执行期间，项目负责人每周检查一次实际占用与计划偏差。若支持工单连续两个周期比假设多 20%，就要重新评估支持容量，而不是不断提高成员个人负载率。若偏差主要来自一次性发布故障，则应作为特殊事件记录，不必立即永久下调团队基线。

案例复盘时，我们不把“计划 266 小时、实际 280 小时”简单判为预测失败，而是拆解超出的 14 小时来自何处：多少是需求变化，多少是返工，多少是估算偏差，多少是组织等待。只有找到偏差来源，下一轮容量模型才会比上一轮更好。

六、落地步骤：用六周建立可复用的资源负载机制

1. 第一周：界定范围、角色和决策权限

第一周先选一个有代表性的项目组合，而不是全组织一次铺开。明确参与团队、关键角色、规划周期、工作量单位和决策会议。尤其要写清楚：项目负责人可以自行调整什么，跨项目优先级由谁批准，职能经理负责确认什么资源信息。

试点范围应足以暴露真实冲突，又不至于复杂到无法复盘。可以选两至四个依赖共享角色的项目，覆盖一支稳定团队和一项临时支持责任。若试点只包含一个独立团队，可能验证了容量表的可用性，却没有验证跨项目决策机制。

2. 第二周：建立最小可用的数据字段

容量数据先追求“够用且能维护”，而不是“字段齐全”。最小字段一般包括：成员或角色、可用时间、固定占用、已承诺工作量、工作状态、项目优先级、时间区间和估算来源。对关键工作再补充依赖、风险和替补安排。

可在 PingCode 等项目管理平台中，将项目工作项、迭代计划、负责人和时间区间关联起来，按团队或角色查看需求；若组织已有稳定的人事和考勤数据，也可以在符合权限与隐私规则的前提下复用必要信息。不要把考勤系统的在线时间直接当作项目容量，也不要在未明确目的和访问权限前汇入个人敏感信息。

3. 第三周：回看历史，设定临时基线

如果有过去 6 至 12 周的计划与实际记录，可以按角色或团队估算会议、支持、返工和休假造成的容量损失。历史数据不完整时，不必假装精确；先标注为“临时基线”，由团队成员和职能负责人共同确认，之后用实际偏差滚动修正。

基线中应标注统计口径。例如“支持占用每周约 4 小时”究竟包括线上故障、客户咨询还是内部答疑？如果口径不同，跨团队比较就没有意义。对外报告必须附上口径，避免某个团队因为记录更完整而看起来“产能更低”。

4. 第四周：进行首次需求负载匹配

先把已批准工作与可承诺容量做匹配，再把候选需求放在独立视图中。发现超载时，要求负责人给出至少两个可选方案：减少或延后范围、调整依赖顺序、替换或补充角色、增加协作成本后接受风险。单纯报告“需要更多人”不算完整方案。

这次匹配会议不应变成逐人逐任务的长时间排期会。我更推荐按“团队，关键角色，项目时间窗”三级展示，让讨论先聚焦影响交付的瓶颈，再对确有必要的成员任务进行细看。单次会议控制在可做决定的范围内，未决事项明确责任人和回访时间。

5. 第五周：运行预警和变更登记

在试点中，告警规则应少而明确。比如关键角色超出可承诺容量、同一成员被两个项目同时指定为唯一负责人、关键依赖没有确认、某工作在当前周期内反复变更估算。每类告警都应对应处置动作，不必为了系统显得智能而设置大量难以解释的颜色等级。

需求变化发生时，保留原计划与新计划的差异：什么发生了变化，谁提出，谁批准，影响了哪些工作。没有变更记录，月底看到的实际与计划差异就无法解释，团队会把流程问题误认为估算能力问题。

6. 第六周：回顾偏差，决定扩围还是修正

六周并不一定足以证明一套容量模型长期有效，但通常足以发现字段负担、角色冲突和决策延迟。回顾时重点问四个问题：团队是否提前看见风险？数据是否有人持续维护？预警是否产生了真实决策？维护成本是否值得？

若风险看见了却无人能拍板，先解决授权；若容量数据经常过时，先简化更新；若数据稳定但预测偏差持续较大，再改进估算和缓冲。不要把所有问题都归结为工具缺少一个报表或自动化规则。

七、监控与复盘：用结果指标验证容量方案有没有价值

1. 监控指标应覆盖预测、交付和维护成本

只看资源利用率容易诱导团队追求满载；只看按期率又可能忽略范围被压缩、返工增加或成员持续超负荷。Capacity 方案需要一组彼此制衡的指标，至少包括预测偏差、关键角色超载、承诺兑现、变更频率和数据维护成本。

我会把指标分成三类：领先指标用于提前发现风险，例如未来四周关键角色负载；过程指标用于判断执行是否按规则运行，例如超载事项的决策时长；结果指标用于检查交付质量，例如计划兑现率、延期原因和返工比例。这样既能看到风险，也能判断措施是否有效。

2. 让预测偏差变成可学习的信息

预测偏差不是天然的坏消息，它是调整模型的材料。比如项目预计需要 40 小时，实际用了 56 小时，单独看只能知道偏差为 16 小时；进一步分类后，才知道其中 8 小时是客户新增范围、5 小时是等待接口、3 小时是返工。三类原因分别对应范围控制、依赖治理和质量改进。

如果长期只汇总“超时百分比”，团队很容易把所有偏差都归到估算不准，进而不断扩大缓冲，导致计划失去可解释性。复盘记录应包含原因分类、影响时长、责任环节和下一步改变，而非简单要求个人“估得更准”。

3. 维护成本也是 Capacity 方案的产出指标

一套计划若使项目负责人每周花几个小时手工汇总多份表格，团队成员还要重复填写工时，表面上有了更细的数据，组织成本却可能上升。落地后应持续衡量数据获取、整理、核对和解释需要多少时间。

如果工具之间暂时无法集成，可以先把更新频率控制在每周一次，只对高风险角色和已承诺工作做重点核对。对不影响决策的信息，不必追求实时刷新。实时数据的价值取决于组织是否能实时做出资源决定；如果决策每两周才召开一次，分钟级同步通常不会带来同等收益。

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

1. 单团队、需求较稳定：先做轻量容量盘点

如果团队规模较小、主要服务一个产品或项目，需求变化有限，可以先用团队级容量表和两周滚动计划。记录成员可用比例、固定支持占用、已承诺工作和关键依赖即可，不必立即建立复杂的个人技能矩阵。

这种方案的优点是启动快、维护负担低；缺点是对跨项目冲突的预警能力有限。若未来出现多个负责人共享同一批成员，就应升级到按角色或项目组合查看，而不是不断给现有表格增加手工备注。

2. 多项目并行、共享专家紧张：优先做角色级规划

当多个项目同时依赖架构、测试、数据、安全或实施专家时，团队总容量不是首要视图。应先把稀缺技能的可用时间、项目窗口和任务依赖呈现出来，再由项目组合负责人决定优先顺序。

这类组织适合建立跨项目的容量评审节奏，例如每周或每两周处理未来四至八周的共享资源风险。优点是更早识别局部瓶颈；代价是需要跨团队授权和共同的数据定义。若缺乏统一决策人，角色级视图只会让冲突更清楚，却不一定能让冲突消失。

3. 客户支持和运维占比高：先建立需求类别基线

对支持工作波动较大的团队，我不建议把全部突发事项都塞入项目计划。先分类统计线上事件、客户咨询、常规维护和版本发布工作，观察几个周期的频率与耗时，再设定基础预留容量和升级机制。

如果重大故障发生频率低但影响高，可以设定应急容量和轮值安排；如果日常支持稳定占用较多时间，应把它作为正式工作流管理。两者不能都以“临时工作”名义处理：前者需要应急响应，后者需要长期容量配置和服务优先级。

4. 需求波动大、创新工作多：采用场景预测而非单一承诺

探索型项目很难在早期准确估算全部工作量，硬性承诺一个完整周期的个人计划并不现实。可以按基础、预期和高需求三种情景评估容量，例如明确最低可交付范围、常规预期范围和需求扩大时需要取消的工作。

这种方式的好处是把不确定性摆到台面上，避免假精确；代价是业务方必须接受条件式承诺，并参与范围取舍。场景预测不等于不做计划，而是明确计划依赖哪些假设、触发什么调整。

5. 个人工时数据敏感或抵触明显：从团队级视图开始

如果成员担心容量数据被用于个体绩效排名，应先明确用途边界、访问权限和保留期限。首期可以只展示团队或角色负载，不展示个人日历；只有在工作交接或关键依赖需要时，才开放必要的个人信息。

Capacity 数据适合支持承诺与资源协调，不适合简单比较谁“更忙”或谁“产出更高”。若管理者无法承诺不把粗糙工时数据用于个人排名，成员很可能减少真实报告，最终让模型失去可信度。

6. 组织刚开始做资源管理：不要一开始追求全公司统一模型

不同工作类型的节奏和产出方式并不相同，研发、实施、市场活动和运营支持未必适合用同一套估算单位。早期可以统一最基本的状态、周期、责任人和优先级定义；在团队内部保留合适的工作量口径，再通过可解释的角色容量做组合管理。

统一的价值是让决策可比较，不是要求所有岗位使用同一种产出模型。过早把所有工作压成同一个“小时数”，容易造成虚假的精确和不公平的横向比较。

九、结尾：先把冲突看见，再决定是否增加人手

我对 Capacity 落地的核心判断是：一张负载图不会自动提高产能，但一套可追溯的容量决策机制，能减少组织把超载误判成执行不力的概率。项目负责人真正需要的不是一份看起来精密的个人日历，而是知道哪些工作已经承诺、哪些角色构成瓶颈、哪些假设正在失效，以及谁有权决定取舍。

先从一个有共享资源冲突的项目组合试点，统一工作量单位和承诺状态；再扣除会议、支持、休假与必要缓冲，按团队和关键角色检查负载；发现超额时，依次核对重复需求、依赖窗口、范围优先级和替补能力；最后用预测偏差、兑现情况、超载持续时间与维护成本复盘。这个顺序通常比先买工具、先追求满载、再要求团队解释延期更有效。

下一步可以从本周的计划会议开始：选出未来四周最容易冲突的三个项目，列出共享的关键角色，估算其实际可承诺容量，并要求每个超载项带着至少两个取舍方案进入决策。先让“我们缺多少资源”变成可验证的问题，再讨论加人、延期或缩范围；这是 Capacity 从排表走向管理能力的起点。