Capacity怎么做？项目成员落地方案：资源负载从0到1

项目里最常见的 Capacity 问题，不是“大家到底有多少工时”，而是计划表显示团队还有余量，关键任务却连续延期：有人同时挂着三个项目，有人被会议切碎，有人的技能恰好不匹配。做成员容量管理，不能只把每人每周的工作小时填进表格；要把可用时间、已有承诺、工作类型和不确定性放进同一套判断逻辑。本文给出一套从零开始的落地方法，并用明确标注的情景模拟数据说明，怎样让资源负载从“看起来有人”变成“知道谁能在什么时候承担什么工作”。

一、先讲结论：Capacity不是工时表，而是承诺管理

1. 先分清容量、负载和可交付能力

Capacity通常被翻译成“容量”或“产能”，在项目管理里至少有三层含义。第一层是日历容量，即成员在某一周期内理论上可工作的时间；第二层是可分配容量，即扣除休假、会议、支持值班和固定职责后，真正能投入项目的时间；第三层是可交付能力，即结合技能、任务依赖、切换成本和风险缓冲后，团队能够可信承诺的产出。

这三层不能混为一谈。一个成员日历上每周有40小时，不代表项目可以安排40小时任务；即使扣除会议后有30小时，也不代表这30小时都能用于同一个项目。若工作内容需要连续专注，而成员每天被多个项目切换，理论上的30小时可能只能形成18至22小时的有效交付时间。容量管理要做的，是把这种落差显性化。

我的判断是：Capacity的核心单位不是“人”，而是“成员在特定周期、特定技能、特定工作类型下可以兑现的承诺”。只统计人数，会把技能差异抹平；只统计工时，会把并行和切换成本抹平；只统计项目百分比，则容易把“分配了时间”误当成“工作能完成”。

2. 从可用时间推导可承诺时间

落地时可以先用一个简单公式建立共同语言：可分配时间 = 日历工作时间 − 固定职责时间 − 休假与不可用时间；可承诺时间 = 可分配时间 × 专注系数 × 技能匹配系数 − 风险缓冲。这里的系数不是精确物理常数，而是帮助团队解释计划为什么要保守的管理参数。

例如，一名工程师一周日历工时为40小时，固定会议与轮值支持占8小时，休假和内部事务预留2小时，可分配时间为30小时。如果团队近期跨项目切换较多，专注系数按0.8估算；任务技能匹配较好，匹配系数按0.95估算；另留15%的风险缓冲，则可承诺时间约为19小时，而不是30小时。

这个估算不应被误解为对个人进行精确计量。它的作用是识别计划中的隐性乐观：如果项目负责人持续把每个人的全部可分配时间填满，任何一个小故障、评审返工或临时支持都会把计划推入延期。

3. 先做到可讨论，再追求精确

很多团队一开始就希望得到精确的成员负载数字，但数据不完整时，精确到小数点的数字只会制造虚假的确定性。初期可以用半天或一天作为最小容量颗粒度，以周为主计划周期；对于变化频繁的支持工作，可采用“容量预留区间”而不是逐条预测。

容量管理的第一阶段，不必马上回答“某人下周还能做几个故事点”，先回答三个可执行的问题：谁在什么时间段不可用？哪些人已经有超过一个主要工作流的并行承诺？关键技能是否只有一个人能够承担？能够稳定回答这三个问题，往往比建立复杂模型更有价值。

二、背景和真实场景：资源表看似透明，承诺却不可信

1. 一个典型的百人规模团队场景

以一家约150人的软件组织为例，产品、研发、测试和交付团队同时服务多个业务项目。项目负责人各自维护计划，有人用表格记录成员投入比例，有人按迭代分配任务，也有人只在周会上口头协调。每个项目单独看都像有明确人手，合在一起却没人能说清某位核心工程师下月究竟有多少可用时间。

以下案例是用于说明方法的情景模拟，不代表某家企业的实测结果。团队共有42名研发与测试成员，4个重点项目，另有约15%的工作时间用于线上问题处理、技术支持和平台维护。项目经理最初按人员总数分配工作，启动两个月后出现三个现象：核心成员在多个项目计划中重复出现；测试工作集中到版本末尾；临时支持没有进入排期，却持续打断原计划。

问题不在于团队没人做事。相反，所有人都很忙，计划表也几乎排满。真正缺失的是跨项目的容量视图，以及“谁有权改变承诺”的规则。没有这两者，项目计划就是一组互相竞争的愿望。

2. 容量数据应回答的四类问题

我通常把容量会议的目标限定为四类，而不是逐条审问成员每天做了什么。第一，未来两至六周内，团队可以接受多少新工作？第二，哪些岗位或技能已经成为瓶颈？第三，新增工作会挤掉哪项既有承诺？第四，出现变化时，谁负责调整范围、顺序或日期？

如果一张表只能显示“成员A分配到项目甲60%、项目乙40%”，却不能说明这两个百分比对应什么工作、在哪些周发生、遇到突发任务时怎么处理，那么它只是分配记录，不是容量管理。有效视图必须让团队看见时间窗口和冲突，而不是只看一份静态名单。

3. 为什么中大型组织更需要统一视图

百人以上组织的难点通常不是没有项目管理工具，而是项目边界、汇报关系和计划口径不一致。一个团队按迭代排期，另一个团队按里程碑估工，交付团队按客户现场排班；即便每个小组内部都做得不错，也可能因为共享专家、环境资源或测试窗口发生冲突。

以PingCode为例，面向中大型企业及100人以上组织时，容量规划的价值不应停留在“把人员放进项目”。更重要的是让产品、研发、测试、交付等角色围绕同一套工作项和时间范围协作，并把计划、执行状态、风险与变更关联起来。工具可以帮助呈现冲突，但容量口径、优先级和承诺规则仍然需要组织自己制定。

若组织尚未建立跨团队优先级机制，先上容量仪表盘通常解决不了争抢问题。系统能让冲突更明显，却不能替管理者决定哪个项目延期、哪个范围缩减。先统一决策规则，再统一数据视图，通常比先堆功能更有效。

三、常见误区：数字齐全不等于容量真实

1. 把日历工时当成可承诺工时

最常见的错误，是把工作日乘以每天标准工时，直接当作项目容量。这个算法忽略了会议、代码评审、故障响应、辅导新人、发布协同和上下文切换。对于管理岗位、技术负责人、客户支持人员和共享服务团队，名义工时与项目交付时间的差异尤其大。

修正办法不是给每个人统一打折，而是先识别工作类型。固定会议可以用日历统计；轮值支持可看近八至十二周的实际工单时间；评审和协作则可以按岗位做区间估计。若一个团队的历史数据还不足以支撑细分，先用团队级预留比例，并在每个迭代后复盘偏差。

2. 把分配百分比当成工作计划

“成员A本月投入项目甲50%、项目乙50%”听起来公平，但若两项工作每天都要求响应，两边实际都会被延迟。分配比例没有表达连续时间块、优先级、交付节点和冲突处理方式。容量管理要进一步落实到周期和承诺：哪一周投入多少，交付什么，发生冲突时由谁调整。

对于需要深度工作的任务，把同一人的时间切成多个零散百分比尤其危险。一个上午处理项目甲，午后参加项目乙会议，晚上再补项目丙任务，账面时间可能没有超载，注意力却已经被切碎。团队应关注并行工作流数量，而不只是投入比例。

3. 把历史估算当成固定产能

过去某个迭代完成了40个故事点，不意味着下一个迭代也能稳定完成40个。故事点是团队内部的相对估算，不同团队之间不可直接比较；成员变化、技术债、需求清晰度和工作中断都会改变吞吐量。

历史数据适合用来形成范围，而不是制造承诺。建议至少观察六个迭代的完成量，计算中位数和波动范围，再结合已知的休假、发布任务和支持窗口调整。若某团队每个迭代的完成量上下波动很大，先改善工作拆分和中断管理，往往比提高预测模型精度更实际。

4. 把“忙碌”当成“高利用率”

利用率不是越高越好。若计划把团队容量长期排到100%，任何突发支持、缺陷修复或需求澄清都会挤占原承诺。表面上成员没有空闲，结果可能是更长的交付周期、更频繁的延期和更多任务同时处于进行中。

我更关注的是“可预期的有效利用”与“恢复空间”。团队需要留出处理变化的余量，尤其是在产品探索期、交付高峰期和线上服务压力较大的阶段。空闲容量不是浪费，它也是吸收不确定性的保险。

5. 用个人排名代替系统诊断

如果容量数据被用于给成员排名，成员自然会把估算做得更保守，或把隐性工作藏起来。数据一旦成为个人绩效的直接依据，团队就难以如实记录协助、评审和问题排查等难以量化的贡献。

容量数据首先应该用于项目组合决策和团队级预测，而非比较个人“产出效率”。个人层面的信息只在具体协调需要时使用，例如识别某位专家被多个项目重复依赖，而不是用工时高低评价价值。

6. 只统计项目任务，漏掉维护与协作

不少计划把产品功能列得很细，却没有记录升级依赖、环境维护、技术债、客户问题、合规检查和新成员带教。未进入计划的工作不会消失，只会以“临时插入”的形式出现，最后被误认为团队估算不准。

每个团队至少应建立三类容量桶：承诺项目工作、持续运营工作、变化与风险预留。这样做不代表所有工作都要拆成同样细的任务，而是让管理者知道容量正在被什么占用。

四、专业判断逻辑：先看瓶颈，再看平均值

1. 容量要按技能池拆分

全团队有40名成员，不代表团队拥有40份可互换的能力。容量应至少按关键技能池拆分，例如后端服务、客户端、测试自动化、数据工程、设计、安全评审和交付实施。岗位名称不够精确时，可以进一步区分熟练度或独立承担范围，但不必一开始就设计复杂能力矩阵。

如果项目的关键工作要求一名具备特定系统经验的工程师，而团队只有一人满足条件，那么即使其他岗位有大量空余，项目仍然存在容量瓶颈。团队总容量看起来充足，并不能消除单点依赖。

2. 用“瓶颈容量”而非“平均容量”决定关键节点

对跨职能项目来说，最终交付速度往往由最紧缺环节决定。需求开发有余量、测试窗口不足，整体还是无法按期发布；后端资源充足、数据治理专家被其他项目占用，关键路径同样会延迟。因此，计划评审时要看关键路径上的技能池和时间窗口，而不是只看团队平均利用率。

实操中，我会先列出未来六周的关键交付节点，再反向标记必须参与的技能和人员。若某个节点依赖的专家在同一周同时出现在两个关键项目中，应把它视为显式冲突，而不是寄希望于个人加班化解。

3. 把不确定性分成可管理的类型

风险缓冲不应该是随手加一个“安全系数”。我会区分三类不确定性：需求不确定性，通常通过探索、拆分和阶段承诺管理；执行不确定性，通常通过历史完成率、技术验证和测试策略管理；外部中断不确定性，通常通过运营预留、值班机制和优先级规则管理。

三类风险的处理方式不同。需求尚未澄清时，多加人不一定更快；技术方案未经验证时，承诺日期的置信度应降低；支持工作频繁且不可预测时，团队应把支持容量单独留出，而不是每周重新假装它不会发生。

4. 使用区间承诺，避免单点精确的错觉

对变化较大的工作，我建议用容量区间表达。例如某技能池未来两周可投入18至24人天，其中基础承诺按18人天安排，额外6人天作为条件性容量，只有在风险解除或优先级确认后才进入正式计划。这样可以把“最可能”“有条件”和“不能承诺”分开。

区间承诺并不意味着计划含糊。恰恰相反，它要求团队清楚说明区间上下限由什么驱动：成员是否休假、需求是否冻结、外部接口是否按时提供、故障支持是否超过历史范围。无法解释上下限的区间只是模糊表达；能够说明触发条件的区间才有管理价值。

5. 设定在制工作限制，保护有效容量

容量不只是“能接多少工作”，还要关注“同时开多少工作”。一个成员同时负责六个任务，即使每项预计投入很少，等待、切换和重新进入上下文的成本也会很高。限制并行工作流，通常比把所有人排到满负荷更能改善交付节奏。

可以先按团队经验设置简单规则：每人同时承担一个主要任务和一个轻量支持项；跨项目角色需要由负责人确认优先级；未完成的任务不自动叠加新承诺。规则不是为了限制成员，而是为了让管理者在新增需求时必须明确“加什么，就移除什么”。

五、具体案例与数据观察：用六周试运行校准容量

1. 先建立最小可用数据集

情景模拟中的42人团队没有一开始就采集每个人每小时做了什么，而是先收集六类数据：成员所在技能池、每周可用日历、已知休假、固定运营职责、已承诺工作和实际完成工作。数据按周汇总，支持任务只记录类别与投入区间，不追求分钟级追踪。

为了避免容量表变成新的行政负担，团队规定只有会影响未来两周承诺的变化才需要更新。例如新增一个临时支持事项，如果只占半小时且不影响节点，不必逐条登记；如果某位专家预计要花两天排查线上问题，就必须同步更新其所在项目的容量。

2. 第一个周期：暴露“计划内”和“计划外”的差距

试运行第一周，团队按名义工作日计算容量，计划总量为168人天；扣除休假、例会、轮值和固定支持后，可分配容量约为129人天。实际完成的计划工作为103人天，另有17人天投入临时问题处理和返工。

这些数据是模拟样例，目的是展示核算过程，不应被当成行业平均值。重要发现不是“完成率只有多少”，而是计划内工作与计划外工作合计达到120人天，已经接近可分配容量；若再按名义容量追加工作，团队就会把剩余缓冲误认为可用产能。

3. 第三至第六周：修正支持预留与项目切换

团队接下来把临时支持作为独立容量桶，并将其按技能池分配。近四周的支持投入显示，平台与后端角色的波动明显高于设计和客户端团队。于是管理者不再给所有团队统一预留15%，而是对高波动技能池设置更高预留，对相对稳定的技能池按较低比例安排。

同时，两个项目把部分工作从“每周持续占用”调整为“集中投入窗口”。工程师连续两天处理一个项目，再切换到另一个项目，减少了每天来回切换的次数。调整后，团队没有增加总工时，却更容易完成计划内工作。这个案例说明，容量改进有时来自减少碎片化，而不是增加人手。

4. 不只看完成量，还要看系统是否变健康

试运行复盘时，团队同时观察四项结果：承诺完成率、计划外工作占比、关键技能缺口、任务在制时间。模拟数据中，承诺完成率从六周前的68%上升到第六周的82%；计划外工作占总投入的比例从约18%降到约12%；但测试自动化缺口仍然存在，任务从开发完成到测试开始的等待时间没有明显改善。

这说明容量改善不是单一数字变好，而是要看约束是否迁移。团队修复了计划口径和部分切换成本后，瓶颈从跨项目争抢转向测试排队。此时继续提高研发任务投入并不会加快整体交付，合理动作应是调整测试顺序、提前验证关键路径，或评估增加测试自动化能力。

5. 用偏差复盘校准，而不是责怪估算

每周复盘容量偏差时，我会把偏差归入几种可行动的原因：工作范围变化、估算假设错误、技能不匹配、外部依赖等待、临时支持、质量返工、成员不可用和任务切换。若只记“估算偏差”，团队就无法判断下一次应该改预留、拆任务、补技能还是调整依赖。

例如，同样是任务延迟三天，若原因是需求验收标准改变，修正方式是冻结范围或补充澄清；若原因是接口团队交付延迟，修正方式是调整依赖和缓冲；若原因是某专家并行承担多个项目，修正方式是重新分配承诺。容量数据的价值，在于把延期原因从情绪判断转成可处理的系统变量。

六、从0到1的落地方案：四周做出可用的容量机制

1. 第一步：明确管理对象与时间颗粒度

先确定这次要管理的是哪些团队、哪些工作，以及计划要看多远。多数项目团队可以从未来六周开始：前两周做较具体的承诺，第三至第六周做容量区间和主要依赖观察。若工作周期极短，可按周滚动；若项目是大型交付，则可按月规划、每周更新关键窗口。

时间颗粒度要与决策速度匹配。按季度看，无法解决下周的测试冲突；按小时排一整季，则更新成本过高。常见有效做法是近处细、远处粗：近期按任务和周管理，远期按技能池和工作量范围管理。

2. 第二步：盘点固定职责和不可用时间

容量盘点从团队可用日历开始，而不是从项目需求开始。收集团队成员的工作日、休假、固定会议、轮值职责、长期支持和阶段性职责。个人不需要提交大量解释，负责人只需确保会影响承诺的不可用时间进入计划。

对共享角色，可以先用岗位负责人确认技能池容量，再按项目窗口分配。若一个人长期在多个团队间协作，不要让每个项目各自报一个百分比就结束；需要有一个能解决冲突的资源协调人，或者建立跨项目优先级评审机制。

3. 第三步：把工作分成三类容量桶

建议先把工作分为承诺型、运营型和变化型。承诺型包括已经确认范围与时间的项目交付；运营型包括支持、维护、发布、值班和持续治理；变化型用于新需求、突发故障、探索性工作和未确定事项。

初期不必把变化型工作全部拆到任务级，但要给它一个容量边界。若组织过去每周平均投入大量时间处理支持，就应把历史范围反映在容量计划中，而不是继续将其标成“偶发”。数据积累后，再细分高频支持类别，识别是否能通过自动化或流程改造降低消耗。

4. 第四步：建立技能池与关键依赖地图

用轻量能力矩阵标记关键技能的可用人数、熟练程度和可替代性。矩阵的目的不是给员工打分，而是识别项目计划里哪些工作只能由少数人承担，哪些技能池的容量无法通过临时调人补齐。

对每个关键里程碑，标出必须使用的技能和依赖项。项目负责人应能回答：该项工作最晚何时开始？需要哪些角色连续投入？若关键人员不可用，替代方案是什么？若答案为空，容量计划就还没有覆盖关键路径。

5. 第五步：先做一轮人工校准，再配置系统

第一轮容量计划建议用团队熟悉的表格或已有管理平台完成，重点验证字段和会议流程，而不是急于定制复杂报表。可先采用以下字段：人员或技能池、周期、可用容量、固定职责、已承诺工作、运营预留、剩余区间、风险说明、决策人。

运行两到三周后，再判断哪些内容适合进入系统自动汇总。若组织用PingCode管理项目工作，可把项目工作项、负责人、迭代或里程碑、状态与团队计划关联起来，减少重复录入；同时要明确哪些数据由团队维护、哪些由系统计算、哪些需要人工判断。系统视图不应把估算数自动包装成事实。

6. 第六步：固定容量评审节奏和变更规则

建议建立两种会议。每周短会处理未来两周的冲突、成员不可用和新增紧急事项；每月组合评审处理项目优先级、跨团队资源和关键技能建设。两种会议不要重复读状态，而要解决决策权不同的问题。

每次新增工作，都要明确它属于哪种优先级，并说明会影响什么既有承诺。规则可以简化为：紧急事项可以插入，但必须指定被推迟的工作；普通新增需求进入候选池，等容量窗口或优先级评审；涉及共享专家的变更需要同步更新所有受影响项目。

7. 第七步：用复盘数据调整参数

每个周期复盘计划与实际的差异，优先校准三项参数：固定职责时间、运营预留比例、项目切换损耗。参数不要按单周极端情况频繁调整，可以使用滚动四至八周的数据观察趋势，并保留重大事件说明。

对于稳定团队，可以看中位数和波动范围；对于变化很大的团队，分开观察正常周和发布周、值班周或客户交付周。统一使用一个比例，容易把高波动岗位的风险低估，也可能让稳定团队长期保守过头。

1. 第1周：明确范围、周期、管理对象和决策人。
2. 第2周：盘点日历、固定职责、支持工作和技能池。
3. 第3周：建立未来六周的容量视图，标记重复承诺与瓶颈。
4. 第4周：进行第一次复盘，修订预留、优先级规则和更新责任。
5. 第5周起：按周更新近期承诺，按月处理跨项目资源和能力建设。

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

1. 小团队、单项目：先管理专注时间

十人以内、主要服务一个项目的团队，通常不需要复杂的跨项目资源模型。优先记录休假、支持值班、发布任务和关键依赖，再限制同时进行的工作数量。若成员很少，按“角色容量”规划可能比公开个人负载表更合适，既能暴露关键技能缺口，也能避免把团队管理变成个人工时追踪。

取舍是简单机制无法精确处理多人共享任务，但维护成本低，适合快速起步。只有当项目冲突、技能瓶颈或支持中断频繁出现时，再增加更细的技能池与周容量视图。

2. 百人以上、多项目并行：先统一口径和决策权

中大型组织应优先建立跨项目容量视图，至少覆盖共享专家、关键测试窗口、发布资源和交付人员。必须先确定谁能批准新增承诺、谁能调整优先级，以及冲突发生时如何升级处理。没有决策权的容量看板，只会让大家更清楚地看到冲突，却仍然无法解决冲突。

这类组织适合使用统一项目管理平台承载工作项、计划和状态，但不要把工具上线等同于机制上线。先选择一个项目群做试点，覆盖一至两个关键技能池，观察四至六周，再推广到其他团队。这样能尽早发现字段口径不一致、项目负责人重复维护和汇总责任不清等问题。

3. 支持工作多、需求波动大：采用预留区间而非满额承诺

线上服务、客户交付、平台维护和运维团队，外部中断往往无法完全预测。可按技能池建立运营容量桶，用历史滚动数据估算常态范围，并在高峰期调整预留。对临时工作设定分级机制：哪些事项可立即打断计划，哪些进入下一窗口，哪些必须由业务负责人确认优先级。

取舍是预留过高会让项目负责人感觉“有容量却不排活”；预留过低则会造成计划反复被打断。解决方法不是争论一个永久正确的比例，而是定期对比预留与实际消耗，并把差异追溯到工作类型和时段。

4. 需求尚未稳定：先规划探索容量，不承诺详细排期

探索性项目的主要不确定性在于问题定义、方案验证和范围变化。此时适合承诺阶段目标，例如完成用户访谈、技术验证或风险评估，而不是把后续数月的任务全部分配到个人。容量计划可按技能池与时间窗口表达，待关键假设被验证后再细化到工作项。

取舍是远期日期看起来不够确定，但它比给出精确到某日却依赖大量未验证假设的排期更诚实。管理者应把“还不能承诺”转成一组明确的验证任务和决策门槛，而不是让模糊范围长期占据团队容量。

5. 发布节点固定、合规要求高：优先保护关键路径和缓冲

固定发布窗口、客户合同和合规检查要求更严格的计划管理。需要提前锁定关键岗位和验证窗口，把外部审核、环境准备、部署演练和回归测试纳入容量，而不能只排开发工作。对关键节点应建立替代方案，例如功能降级、范围分批、备用审核人或可回退发布策略。

取舍是关键路径保护会降低临时调整的灵活性，因此必须设置变更门槛。不是所有需求都能进入已锁定窗口；若要插入，决策人需要接受相应范围、质量或日期风险，并把决策留痕。

6. 数据基础薄弱：先做团队级估算，不做个人级精细追踪

如果组织没有稳定的工作项、工时或支持记录，先从团队级容量桶开始。每周记录已承诺工作、运营投入、突发事项和完成情况，采用区间而不是小数点。坚持几个周期后，先确认数据定义是否一致，再判断是否值得细分到个人或技能级。

取舍是团队级数据不容易快速定位个人冲突，但它更容易被接受，也更适合建立真实记录习惯。等团队能够稳定解释偏差，再逐步增加颗粒度；不要从一开始就要求所有人精确填写每小时活动。

7. 是否采用某项目管理工具或平台：看工作流，而不是只看资源视图

选择工具时，我会先检查四件事：工作项是否能与迭代、里程碑或项目计划关联；跨项目共享成员是否能被识别；实际执行状态是否能回流到计划视图；权限和汇总方式是否适合团队规模。只有资源表而没有工作执行信息，容量视图很快会过期。

对于中大型组织，可将平台作为协作与数据汇总的基础设施，但不能期待平台自动决定优先级、判断技能匹配或识别所有隐性工作。工具的价值是降低维护成本、加快冲突发现和形成可追溯记录；管理者仍需为取舍负责。

8. 取舍总表：先解决什么，暂缓什么

八、结尾：容量管理的成果，是团队敢于说清楚“不能同时做什么”

1. 判断容量机制是否真正落地

一个团队有了容量机制，不是因为表格填得完整，也不是因为每个人都被分配到100%。更可靠的判断标准是：新增工作会不会触发对既有承诺的讨论；共享专家的冲突能否在延期前被发现；运营工作有没有进入计划；团队是否能解释容量偏差来自哪里。

如果管理者仍然可以在不调整任何计划的情况下不断塞入新任务，容量机制就还没有真正形成。它可能已经可视化，但尚未进入决策。容量管理最终要改变的是承诺方式，而不只是报表样式。

2. 下一步从一张六周视图开始

下一步不需要立刻建一套完美系统。选一个项目群，画出未来六周的技能池容量，先标记休假、固定职责、支持预留、已承诺工作和关键依赖。然后找出三类问题：重复承诺、瓶颈技能、没有明确归属的运营工作。

接着召开一次只做决策的评审会：确认哪些承诺可信，哪些需要延期或缩范围，哪些风险要通过预留处理。两周后复盘实际偏差，调整口径，再决定是否扩大范围或接入管理平台。这个小闭环比一次性做出复杂模型更容易形成组织习惯。

我对Capacity落地的独特判断是：容量不是用来证明每个人有多忙，而是用来迫使组织在资源有限时做出明确取舍。从0到1的关键，不是把所有时间算得更精细，而是让“新增什么、放弃什么、谁来决定、何时复盘”变得清楚。先把承诺做可信，资源负载才真正有管理价值。