Capacity流程与规范：项目成员资源负载数据分析关键指标

项目负载表里，每个人看起来都只分配了 80% 的时间，项目却仍然连续延期，这并不矛盾。常见原因是团队把“计划工时”当成“可用产能”，把忙碌当成有效投入，也没有区分已承诺工作、临时支持和不可打断的日常职责。Capacity 分析真正要回答的不是“谁还有空”，而是“在什么时间范围、哪些约束条件下，团队能可靠交付多少工作”。

一、先讲核心结论：Capacity 不是工时汇总，而是交付能力的约束模型

1. 先把三个问题分开

我在审视项目负载数据时，会先把问题拆成三个层次：成员在某段时间内有多少可投入时间；这些时间有多少已经被有效承诺；团队承诺的工作是否与技能、依赖和优先级相匹配。只看其中一个层次，往往会得出错误结论。

例如，一个工程师一周名义上有 40 小时，并不意味着可以安排 40 小时项目工作。会议、值班、代码评审、支持请求、休假和跨团队协作都会消耗时间；即使这些活动没有出现在项目计划里，它们也会真实地挤占交付能力。

我的基本判断是：Capacity 是有时间边界、人员边界、工作类型边界和置信度边界的供给估计。它不是一个永久不变的人力数字，也不是“人头数乘以标准工时”的简单乘法。

2. 负载数据至少要同时看供给、需求和风险

一张可用于决策的负载视图，至少要把可用产能、已承诺工作量、未计划工作和关键技能覆盖放在一起。仅展示“某成员排了多少小时”，不能说明这些小时是否可执行，也不能说明项目是否会因单点技能或外部依赖而停滞。

3. 指标的用途是触发动作，不是给人贴标签

负载指标如果只用于比较谁“忙”、谁“闲”，很快就会引导团队修饰数据。更有效的做法是让每个指标对应一种管理动作：负载超限时调整范围或时间；技能缺口时安排配对、培训或外部支持；未计划工作偏高时检查中断来源；预测偏差扩大时重新估算而不是要求成员加班填平差额。

我更愿意把 Capacity 报表看成资源决策的早期预警，而不是绩效排名表。它要帮助负责人尽早发现承诺与供给不匹配，而不是事后解释为什么没有按期完成。

二、背景与真实场景：为什么“看起来有空”仍然无法接新项目

1. 多项目并行让名义工时失去解释力

在中大型组织里，一个成员经常同时承担产品迭代、缺陷修复、内部支持、技术改造和临时专项。每个项目负责人都可能只拿走一小块时间，但这些碎片叠加后，成员的工作日被切成许多短时段。表面上每个项目分配都不高，实际却很难获得连续、可专注的工作时间。

例如，某位测试工程师每周被三个项目分别安排 8 小时、10 小时和 6 小时，另有 6 小时用于回归支持。总计 30 小时，看上去还剩 10 小时；但如果三个项目的会议和验证窗口分散在每天，剩余时间可能不足以完成一次连续的端到端测试。

因此，Capacity 既要看总量，也要看工作连续性和并行切换成本。某个成员有 4 小时空档，不等于能承接需要连续两天投入的复杂任务。

2. 计划里缺失的工作，往往不是小数目

运维支持、客户问题、代码评审、面试、内部咨询和紧急缺陷，常常没有进入项目计划，却会消耗团队的真实产能。如果计划只统计正式任务，实际负载就会被系统性低估。团队随后会把偏差归因于“执行不够努力”，而不是识别需求入口和工作结构的问题。

我通常先问两个问题：本周期临时工作占用了多少时间？这些工作是否有稳定的类别和入口？如果团队无法回答，第一步不是增加预测精度，而是先建立轻量级的工作分类和记录习惯。

3. 组织规模越大，口径不一致造成的误判越明显

当部门、项目和职能团队各自定义“投入”时，同一张报表里可能同时出现小时、人天、故事点和百分比。有人把 1 人天按 8 小时计算，有人按 7 小时；有人把会议计入项目，有人把会议当作非项目时间。数字汇总得越整齐，口径差异反而越容易被掩盖。

对 100 人以上的组织来说，问题通常不是没有工具，而是缺少共同规则：谁维护可用时间，谁确认工作估算，临时任务由谁登记，跨项目冲突由谁裁决。如果这些责任没有定义，使用某项目管理平台只能更快地汇总不一致的数据。

4. 把 Capacity 用在决策点，而不是只在月末复盘

容量分析最有价值的时点，是项目承诺之前、迭代规划时、关键依赖变化时，以及多个项目争用同一技能时。等到月底再看实际投入，当然可以解释发生了什么，却已经错过了调整范围、调换顺序或补足能力的窗口。

我建议将分析节奏分为三个层级：团队每周检查短期负载，项目组合每月检查资源冲突，季度规划检查能力结构和长期需求。三种节奏服务不同决策，不应强行用一张表解决所有问题。

三、常见误区：这些做法会让负载看板“有数字、没判断”

1. 用名义工时当作净可用产能

把每人每周 40 小时直接作为可排项目工时，是最常见的高估方式。会议、休假、固定职责和行政事务并不会因为没有进入项目系统就消失。更合理的做法是先计算净可用时间，再根据历史中断和团队工作类型设置缓冲。

缓冲不应被视为浪费。它是对不确定性的显式承认。没有缓冲的计划并不一定更高效，只是把风险藏在成员的加班、临时延期和质量返工里。

2. 把负载率当作生产率

负载率高，可能代表承诺过多，也可能代表需求估算偏大；负载率低，可能是资源闲置，也可能是任务依赖未就绪、技能不匹配或工作未被正确记录。它不是生产率指标，更不能直接用于个人绩效比较。

如果管理者看到 95% 负载就认定团队高效，容易忽略缺陷返工、交付延迟和创新工作被挤出的代价。短期满载不等于长期高产，稳定交付通常需要为风险和学习留出空间。

3. 把故事点和工时直接换算

故事点是团队内部对相对规模和复杂度的估计，工时是时间投入记录，两者的含义不同。若没有稳定的历史样本和明确的用途边界，建立固定换算关系会制造虚假的精确性。

我会把故事点用于团队迭代内的相对规划，把工时用于容量和成本观察。若组织必须做跨团队预测，应优先使用各团队自身的历史吞吐和交付周期，而不是把不同团队的故事点放到同一把尺子上。

4. 忽略技能约束和任务依赖

总量充足不代表资源匹配。团队可能有 100 小时可用时间，却只有一名成员能完成数据库迁移；也可能有开发能力，却缺少安全评审或业务验收资源。把不同技能的时间加总，会把关键岗位短缺隐藏起来。

容量规划需要至少区分关键角色、关键技能和关键依赖。对于高风险工作，还要明确替补人员和知识传递安排。没有备份的单点能力，即使本周负载率只有 50%，仍然可能是高风险。

5. 用过细的计划制造控制感

把未来数月的每个人每天排满，表面上很精细，实则容易随着需求变化迅速过期。远期规划适合采用角色、团队或能力池的粒度；近期开工时再细化到个人和具体任务。

我通常把时间范围分为近期承诺、中期预测和远期方向。距离越远，计划越应表达为区间和情景，而不是精确到小时的确定数字。精度应与信息质量相匹配。

四、专业判断逻辑：建立可复核的 Capacity 计算口径

1. 先定义统一时间单位和周期边界

团队可以用小时或人天，但必须说明换算规则和统计周期。例如，约定 1 人天按 7 小时净工作时间计算，周计划以工作日历为准，节假日和个人休假从供给中扣除。这里的 7 小时仅是示例口径，实际应由组织结合工作制度确定。

还要区分自然周、迭代周期和项目阶段。若迭代周期跨越假期，不能简单按固定天数估算；若成员在周期中途加入或离开，也应按实际在岗时间修正。

2. 用净产能而非名义产能做供给基线

一个便于团队复核的基础公式是：净可用工时等于计划工作时间，减去休假、固定职责、会议和其他已知不可用于项目任务的时间。之后再从净可用工时中扣除未计划工作预留，得到可承诺工时。

可承诺工时不是所有净可用工时的满额使用，而是团队愿意对外承诺的部分。预留多少，应该参考工作波动、紧急请求和历史预测偏差，而不是由一个脱离场景的统一百分比决定。

3. 负载率要说明分子、分母和时间窗口

负载率常见写法是已承诺工作量除以可承诺工时，但组织必须明确“已承诺”的定义。草稿任务、需求池和已经进入迭代的工作不能混为一谈；分母也不能一会儿用名义工时、一会儿用净可用工时。

建议在报表旁标注口径，例如：“本迭代负载率＝已确认任务估算工时 ÷ 扣除休假、固定职责及预留后的可承诺工时”。若分母为零、估算缺失或周期尚未完成，应显示“不可比较”或区间，而不是强行输出百分比。

4. 对预测结果加入置信度，而不是追求单点准确

计划数据并非都同样可靠。已确认的休假通常可信度较高；刚进入需求池的工作，范围和估算都可能变化；未计划支持则应依据历史观察区间推断。将数据按置信度分层，能避免把不确定需求伪装成确定承诺。

可以把工作分成“已确认”“预计发生”和“候选需求”三类。决策者分别查看基准情景、压力情景和机会情景：基准情景用于正常承诺，压力情景用于评估冲击，机会情景用于判断如果条件改善可提前完成什么。

5. 看团队流动指标，验证容量模型是否可信

负载模型不能只用投入数据校准，还要和交付结果对照。若长期负载率接近满载，但完成量波动很大、周期时间变长、未完成工作不断滚入下一周期，说明排程可能过度乐观或工作切换成本过高。

我会至少观察预测偏差、周期时间、未计划工作比例和返工率。它们不是为了把成员变成数字，而是为了识别容量模型中的系统性误差：估算是否偏乐观，需求入口是否失控，依赖是否频繁等待，质量问题是否制造了额外工作。

五、指标体系与计算方法：从单人负载扩展到团队能力

1. 基础容量指标：先把供给算清楚

负载率超过 100% 是需要调查的信号，不是自动等同于必然延期；低于某个阈值也不等于存在闲置。判断时应同时查看估算不确定性、技能匹配、依赖状态和团队的历史交付表现。

2. 计划稳定性指标：识别“边做边改”的消耗

迭代开始后新增工作越多，原始容量计划越容易失真。可以用未计划工作比例衡量突发需求影响：未计划工作工时除以周期总投入工时。还可以观察承诺变更率，即周期内新增或移出工作量相对于初始承诺的比例。

这两个指标需要按工作类型拆开。由生产故障带来的突发工作，与由范围定义不充分造成的反复变更，解决路径不同。前者可能需要值班轮换和容量预留，后者则需要改进需求澄清和决策流程。

3. 交付结果指标：容量是否转化为可靠交付

工作投入增加，不一定带来交付增加。用完成承诺比例观察计划兑现情况，用周期时间观察工作从开始到完成的时长，用返工比例观察交付质量成本。三者结合，能避免把高投入误认为高产出。

这里需要避免将团队之间的周期时间直接排名。团队承担的工作类型、审批路径、系统复杂度和外部依赖不同。更有效的用途，是看同一团队在口径一致情况下的趋势，以及重大变化前后的差异。

4. 技能覆盖指标：把稀缺能力从总量里拆出来

当任务必须由特定技能完成时，单纯的团队总容量会产生误导。可以按技能建立“具备独立完成能力的人数”“关键任务替补覆盖率”和“技能等待时间”等观察项。覆盖率低于组织的风险容忍度时，优先处理知识集中，而不是继续压缩计划。

技能矩阵不应变成静态标签。某成员被标记为“熟悉”某领域，不代表可以独立承担所有复杂工作。矩阵最好配合最近参与记录、可独立完成的任务类型和替补安排，以免把名义覆盖误当成真实韧性。

5. 让指标组合解释原因，而不是只发出警报

例如，负载率上升、未计划工作比例稳定、周期时间变长，可能意味着估算偏差或依赖等待；负载率中等、完成承诺比例下降、关键技能等待时间上升，则更像是能力结构不匹配；负载率偏高且承诺变更率同时上升，通常要先控制入口和范围。

我会避免把所有红色指标合成一个“资源风险分”。综合分数适合做初筛，不适合替代解释。真正的决策需要看到风险来自哪里、影响哪个里程碑，以及有哪些可调整的杠杆。

六、具体案例与数据观察：一个四人团队如何从“满载”改成可兑现

1. 案例口径：情景模拟，不代表行业基准

下面用一个产品研发团队做情景模拟，说明计算方法。团队有 4 名成员，一个两周周期共 10 个工作日，名义工时为 4 × 10 × 8＝320 小时。数据用于展示分析步骤，不代表任何企业的真实统计，也不应直接作为其他团队的目标值。

团队初始计划把 320 小时全部视为可用工时，并按个人分配任务。复盘后发现，周期内有 32 小时休假或不在岗时间，48 小时固定会议、值班和评审时间，另有 40 小时用于客户问题和紧急缺陷。若这些因素在计划前没有完整登记，名义上的高容量就会变成虚假供给。

2. 从名义产能重算可承诺产能

按模拟数据，先从 320 小时扣除 32 小时缺勤和 48 小时固定职责，得到 240 小时净可用工时。再依据团队近期突发工作的观察，为未计划工作留出 40 小时，形成 200 小时可承诺工时。若把突发工作重复扣除，结果会被低估；因此要先区分它是固定职责，还是波动性预留。

初始计划承诺 228 小时，按正确分母计算，负载率为 114%。这个数值说明计划存在明显压力，但不能直接断言一定延期。进一步检查发现，228 小时中有 28 小时任务尚未完成需求澄清，而且关键测试工作集中在一名成员身上，于是风险不仅是“超了 28 小时”，还包括需求不确定和技能单点。

3. 调整决策：先削减低优先级承诺，而不是平均摊薄

团队将工作拆成三个类别：必须守住的客户承诺、对本周期目标有直接贡献的迭代工作，以及可延后的内部改进。负责人将 20 小时低优先级改进移出本周期，将 8 小时需求不清晰的任务留在候选池，并为关键测试安排第二名成员参与配对。

调整后，已确认承诺为 200 小时，恰好匹配可承诺工时。这个结果并不意味着风险消失，而是让承诺与容量口径一致，同时通过配对减少单点风险。团队还需要在周期中跟踪突发工作，如果实际冲击超过预留，应重新协商范围，而不是默认为成员加班。

4. 复盘重点：产能预测误差比“谁不够努力”更有解释力

假设该团队连续三个周期的净可用工时预测偏差分别为 18%、11% 和 7%，而未计划工作占比从 22% 降至 13% 再降至 9%。这组模拟数据的意义不是证明某一管理动作必然带来改善，而是说明应追踪输入假设是否逐步接近现实。

如果预测偏差下降、完成承诺比例上升，而返工率没有恶化，才有理由认为容量规划更可靠。反过来，若完成率上升只是因为删掉了困难工作或降低验收标准，就不能把它当成有效改进。

5. 对使用某项目管理平台的组织，先配置责任再追求自动化

以 PingCode 为例，在 100 人以上的研发组织中，可以把团队、迭代、工作项、负责人、估算、状态和工作日志作为 Capacity 分析的基础数据，再通过统一字段和报表呈现不同团队的负载与交付情况。平台的价值在于减少信息分散、支持口径追踪和及时发现冲突；它不能替团队决定估算是否合理，也无法自动消除临时需求。

配置时，我会先明确数据责任：项目负责人确认承诺范围，团队负责人确认可用时间和固定职责，成员更新任务状态，资源协调角色处理跨项目冲突。若任务状态长期不更新、估算字段无人维护，再完善的仪表板也只是在展示过期信息。

对规模较大的组织，建议先用一个业务单元试运行两个到三个周期，验证字段定义、报表口径和决策流程，再扩展到其他团队。试点阶段重点记录误报、漏报、数据维护耗时和决策延迟，而不是单纯追求所有成员填报率达到某个数字。

七、Capacity 流程与规范：从数据进入到行动闭环

1. 规划前：统一日历、角色和工作分类

规划开始前，负责人需要确认周期边界、工作日历、成员休假、固定职责和任务分类。不同类别应足够少，能支持决策即可。例如，可分为项目交付、维护支持、协作职责和临时工作；分类过细会增加填报成本，分类过粗又无法识别资源消耗来源。

同时要约定估算的用途。工时估算服务于容量安排，不应被自动解释为个人表现；故事点用于团队相对估算，也不应被转换成统一的个人效率分。规则越清楚，成员越不需要靠猜测来填写数据。

2. 规划中：先确认工作，再分配成员

Capacity 规划不宜从“每个人还有多少时间”开始，而应先确定目标、范围和优先级，再检查关键角色是否具备足够容量。反过来从个人空档拼任务，很容易形成局部排满、整体交付路径仍然受阻的计划。

1. 确认目标和范围。区分本周期必须完成、可以延后和仍待澄清的工作。

2. 校准工作量。对高不确定任务标记区间或假设，不要用一个看似精确的数字掩盖风险。

3. 核对供给。扣除休假、固定职责和合理预留，得到可承诺工时。

4. 检查技能和依赖。确认关键任务有合适负责人、替补安排和前置条件。

5. 形成团队承诺。对超出容量的部分明确删减、延期或增援方案，不将缺口默认转化为加班。

3. 执行中：跟踪变化，而不是逐小时监控

执行期间需要关注影响承诺的变化：新增需求、关键成员不可用、外部依赖延误、缺陷集中爆发和估算明显偏差。每天追问成员每小时做了什么，通常会带来高维护成本，却不一定提高项目判断质量。

更实用的做法是设置触发条件。例如，新增工作超过预留、关键里程碑受到依赖阻塞、承诺范围变化超过约定阈值时，要求负责人重新评估容量和交付日期。阈值应根据团队波动和风险承受能力设定，不必跨团队一刀切。

4. 复盘时：把实际投入分类回写到预测模型

周期结束后，不要只比较计划与实际总工时。要区分计划工作、未计划支持、返工、等待和固定职责，确认偏差来自供给变化、需求变更、估算误差还是执行路径。这样才能知道下个周期应调整哪一个假设。

复盘应关注系统而非个人归责。若突发工作连续数周高于预留，应重新设计支持轮值或需求入口；若某类任务反复低估，应更新估算参考；若等待占用大量周期时间，应改善依赖响应和审批路径。

八、不同情况下的行动建议：不要让同一套阈值管理所有团队

1. 新团队或历史数据不足时

没有可靠历史数据时，不宜假装可以精确预测。先用较短周期、较粗粒度和更保守的承诺建立基线，同时记录计划工时、实际投入、未计划工作和完成结果。经过几个周期后再判断波动范围，逐步调整预留和估算口径。

在这个阶段，重点不是证明团队“能做到多少”，而是找到预测偏差来自哪里。若任务类型变化很大，应该按工作类型分层观察，避免用少量样本推导一个看似普适的团队参数。

2. 需求稳定、工作重复度较高时

工作类型稳定的团队可以使用历史吞吐量和周期时间辅助容量规划。例如，支持团队可按请求类别、复杂度和响应时限观察需求；维护团队可按缺陷、升级和例行变更的历史比例安排预留。

即使工作稳定，也不意味着应该把计划填满。需求峰值、休假集中和复杂故障仍会造成波动。可根据历史分布设计正常容量和压力容量，并在高峰阶段提前安排轮值、跨团队支援或服务范围调整。

3. 高创新、高不确定项目时

探索型项目的任务边界会变化，早期估算的不确定性也更高。此时更适合用阶段目标、假设验证和短周期反馈来管理，不宜过早细化到长期个人工时。Capacity 重点应放在关键能力是否到位、实验周期是否足够、依赖能否及时获得。

对于不确定性较高的工作，可以把估算表达为区间，并说明影响区间的关键假设。随着原型、技术验证或用户反馈出现，再逐步收敛范围。这样比不断修改一个精确到个位数的工时估算更诚实，也更便于决策。

4. 多项目争用少数专家时

当多个项目都依赖同一名专家，平均分配时间未必是最佳解。频繁切换可能拉长每个项目的周期，还会让其他成员等待。应先识别哪些任务必须由专家亲自完成，哪些可以通过评审、配对、模板或知识转移完成。

短期内可设置明确的支持窗口，减少即时打断；中期则应培养替补和扩大关键技能覆盖。若专家的任务无法拆分，应让项目组合负责人按战略优先级排序，而不是让每个项目分别争取“只占一点时间”。

5. 跨部门职责多、会议密集时

如果成员把大量时间用于协调、评审和决策会议，单纯缩短会议时长不一定解决问题。应先区分必要协作与重复汇报，查看会议是否存在决策人缺席、议题不清或同一信息多次同步。

把固定职责纳入容量口径，能让业务负责人看见协作成本。若会议是组织必须承担的工作，就不应在项目计划里假装它不存在；若会议重复且没有决策产出，则应从流程上删减。

九、不同情况下的取舍：精确度、透明度与维护成本如何平衡

1. 个人级计划与团队级计划

个人级计划有助于发现具体冲突，例如休假期间仍被分配关键任务，但维护成本高，也容易被误解为微观监控。团队级计划更适合早期容量判断，能够减少虚假精确，却可能掩盖稀缺技能和单点风险。

我的取舍是：远期规划以团队、角色或能力池为主；临近迭代时，对关键成员和关键任务做个人级校验。这样既保留早期灵活性，也能在真正需要的范围内发现冲突。

2. 工时数据与吞吐数据

工时数据适合分析容量投入和资源成本，吞吐数据适合观察团队交付趋势。若团队任务大小差异很大，仅看完成件数会失真；若只看工时，又可能把投入增加误当成交付改善。

二者可以互相补充，但不应混成一个指标。组织需要成本核算时保留工时口径；需要预测交付时优先使用团队历史交付数据，并结合工作类型和依赖情况解释差异。

3. 统一标准与团队自主口径

完全统一有利于跨部门汇总，但可能忽视不同职能的工作结构；完全自主又会让组合层面无法比较。可统一最小口径，例如周期、工作分类、可用时间定义和承诺状态，同时允许团队为专业场景增加局部字段。

跨团队比较时，应先比较定义是否一致，再比较数字。如果一个团队把支持工作计入项目，另一个团队将其排除，直接比较负载率没有意义。报表可以呈现差异，但不能替代口径说明。

4. 自动采集与人工确认

自动采集能减少重复填报，但数据来源不同会带来新的误差：日历不代表实际投入，任务状态不代表工作已经完成，日志时长也不一定能准确区分价值活动。自动化适合减轻录入负担，不应取消业务确认。

较稳妥的做法是自动汇总日历、休假和工作项状态，人工确认关键假设、未计划工作分类和计划承诺。若采集成本高于决策收益，应先缩小指标范围，而不是因为系统可以记录就要求记录所有事情。

5. 高利用率与交付缓冲

追求高利用率可以减少显性的空闲，却会降低团队应对突发事件和复杂问题的余地。尤其在工作高度互相依赖的环境中，单人满载可能让其他任务排队，整体交付时间反而变长。

缓冲不是无条件留白。要说明它保护的是什么风险、如何使用、周期结束后如何复盘。若缓冲持续闲置且需求稳定，可以重新校准；若缓冲总被突发工作耗尽，则应把需求波动纳入正式容量模型。

十、落地检查清单：让指标进入稳定运行

1. 数据口径检查

• 是否明确了统计周期、工作日历和时间单位？

• 是否区分名义工时、净可用工时和可承诺工时？

• 已承诺、候选和未计划工作的状态是否有清晰定义？

• 会议、值班、支持和休假是否避免漏记或重复扣减？

2. 风险判断检查

• 负载率是否按统一分子、分母和时间窗口计算？

• 关键技能、替补覆盖和依赖等待是否单独呈现？

• 未计划工作、承诺变更和预测误差是否有历史记录？

• 高负载时是否有范围、顺序、日期或增援的明确决策路径？

3. 治理与复盘检查

• 谁负责维护可用时间、工作估算和任务状态？

• 报表发现风险后，谁有权调整项目优先级？

• 平台数据多久更新一次，过期数据如何标识？

• 复盘是否能把偏差归因到需求、供给、依赖或质量，而非简单归责个人？

如果一套 Capacity 流程不能帮助负责人作出“做什么、先做什么、哪些不做”的决定，它就还停留在数据采集阶段。治理的完成标志不是报表上线，而是风险出现后有明确的协商和调整机制。

十一、结尾：先把承诺变得可信，再把预测做得精细

Capacity 分析最容易走偏的地方，是急着寻找一个通用利用率目标，再让所有团队朝着它填表。不同团队承担的支持工作、技能结构、依赖复杂度和需求波动都不一样，脱离场景的统一阈值会把真正的风险压平。

我更看重一条可复核的因果链：可用时间如何计算，工作为何被承诺，哪些因素会造成偏差，偏差出现后谁来调整。当这条链成立，指标才有解释力；当它不成立，再多小数位也只是装饰。

下一步可以从一个团队、一个迭代开始：统一工时口径，区分固定职责与临时工作，计算净可用工时和可承诺工时，再同步观察未计划工作比例、完成承诺比例和关键技能覆盖。运行两到三个周期后，用实际偏差校准预留与估算。先让承诺接近现实，再逐步扩大到项目组合层面的资源决策。