Capacity管理指南：项目成员如何做好资源负载，制度设计全流程

Capacity 管理最常见的失误，不是团队不知道谁很忙，而是把“看起来有空”误当成“能够接活”。一个成员本周排了 40 小时工作，日历上却仍有空白；如果其中包含会议、支持请求、评审和临时故障，这些空白并不等于可承诺产能。做好资源负载管理，关键不是把每个人的时间填满，而是让团队用一致口径回答三个问题：实际可投入多少、需求何时发生冲突、冲突出现后由谁决定取舍。

一、先讲结论：Capacity 管理不是排满日历，而是管理承诺边界

1. 先把“可用时间”和“可承诺产能”分开

我判断一套 Capacity 管理是否有效，首先不看排期表是否整齐，而看团队能不能解释“为什么这个人还能接新任务”。可用时间是扣除休假、节假日、固定会议等之后的理论工时；可承诺产能还要进一步扣除支持工作、协作开销、风险缓冲和无法提前预测的工作。

例如，一名成员每周名义工作 40 小时，扣除 4 小时固定会议、4 小时跨团队沟通和 4 小时轮值支持，理论上还剩 28 小时。但如果团队长期存在需求澄清、代码评审和线上问题处理，这 28 小时仍不能全部承诺给项目。对知识型工作，我更倾向于把可计划工时设为剩余时间的 70%，85%，并用团队自身数据校准，而不是直接照搬固定比例。

核心原则是：Capacity 管理要管“承诺可信度”，不追求利用率最大化。当计划利用率长期接近 100%，少量变更就会引发延期、加班和质量回退；保留缓冲不是浪费，而是为现实中的波动购买韧性。

2. 用三层口径判断负载，而不是只看一个百分比

团队可以把负载拆成三层：个人层看任务和角色分布，团队层看关键技能是否形成瓶颈，项目组合层看多个项目是否争抢同一批人。只看个人利用率，容易把“一个人很忙、另一个人有空”误判为资源充足；实际上，空闲成员未必具备当前任务所需技能，也未必能在交付节点前完成交接。

实际管理中，我会先看团队层的关键技能瓶颈，再看个人超载。原因很简单：如果架构评审只有一名成员能做，给其他成员减负并不会自动消除评审队列。管理者需要同时看“工时够不够”和“能力是否可替代”。

3. 让 Capacity 结果能触发决策

一张负载表如果只用于汇报，通常很快变成维护负担。它应当能触发具体动作：需求延后、范围缩减、资源调配、交付日期调整，或者由负责人明确接受风险。没有决策动作的容量数字，只是另一种更精细的忙碌展示。

我建议先约定超载阈值和处置责任。例如，未来两周计划负载超过可承诺产能 110%，项目负责人必须提交取舍方案；关键技能仅有一名可用人员时，项目组合负责人确认是否接受单点风险。阈值不是“自动判错”的红线，而是让组织及时讨论的触发器。

二、背景与真实场景：负载失真通常发生在项目交界处

1. 每个项目都合理，组合起来却不可执行

在中大型企业里，项目经常由不同业务负责人分别承诺。产品团队承诺版本日期，销售团队承诺客户交付，技术团队承诺平台升级，运营团队还要承担日常需求。每个项目单独看都像有资源，放在同一张日历上，才会发现它们依赖同一位架构师、测试负责人或数据分析人员。

这种冲突不一定表现为某个人被安排了 60 小时。更隐蔽的情况是：同一周内三项工作都要求某位专家参加关键评审，每项只占 2 小时，但评审前的准备、上下文切换和会后决策会把整段时间切碎。负载表如果只记录“任务工时”，很容易低估实际占用。

2. 多团队协作会放大局部排期的误差

一个团队可以通过加班暂时消化延期，但跨团队依赖会把局部波动传递到整个交付链。上游接口晚两天，可能让下游测试等待；测试窗口被挤占后，发布审批和客户验收也可能顺延。Capacity 管理因此不只是人力计算，更是对关键路径、依赖关系和可替代方案的管理。

在资源评审会上，我会追问“这个工时估算包括什么”。如果答案只包括编码，不包括需求澄清、联调、评审、缺陷修复和交付准备，那么数字可能适合做工作量估算，却不适合直接当作排期承诺。两种口径混用，是计划不断偏离的重要原因。

3. 100 人以上组织需要统一口径，但不能抹平团队差异

对于超过 100 人的组织，管理者常需要跨部门观察资源冲突、项目优先级和交付风险。以 PingCode 为例，中大型企业可以围绕项目、需求、任务和协作流程建立统一的工作视图，再由不同团队维护各自的估算单位、迭代节奏和审批规则。工具能提供汇总与追踪能力，但它不会自动替组织定义“什么算有效产能”。

我更看重工具是否能把数据来源和责任人说清楚：任务由谁更新，休假从哪里同步，项目优先级由谁确认，估算单位是否统一，历史变更是否留痕。若这些制度缺失，平台呈现得越完整，错误信息反而越容易被误当成事实。

4. 三类工作混在一起，最容易造成容量误判

项目工作、持续运营和突发工作应当分开观察。项目工作通常有明确范围和里程碑；持续运营包括维护、支持和周期性流程；突发工作则难以准确预测。将三者都塞进“项目任务”会让项目看似总是延期，也会让运营工作长期隐形。

• 项目工作：按交付目标和阶段估算，适合进入项目计划。
• 持续运营：按历史均值或轮值比例预留容量，定期检查工作量变化。
• 突发工作：用缓冲、应急轮值或快速分流机制管理，不应假设其为零。

三、常见误区：数字看起来精确，不代表管理更准确

1. 把 100% 利用率当作优秀目标

利用率越高，不等于交付越好。对于存在不确定性的工作，计划利用率到顶会使团队没有能力吸收需求变化、故障和估算偏差。某个成员连续几周都被排到满负荷，短期可能看起来产出很高；随后出现延期、缺陷或离职风险时，成本往往被转移到返工和恢复期。

我会区分“已分配负载”和“有效产出”。前者回答时间被安排到哪里，后者回答工作是否完成并产生可验收结果。仅用前者评价个人，容易鼓励拆分任务、虚报工时或减少协作；仅用后者又可能忽视过载带来的隐性风险。两者应结合周期趋势和工作类型判断。

2. 用工时精度掩盖估算误差

把一个月后的工作估成 17.5 小时，通常只是小数点带来的虚假确定感。工作范围、依赖和验收标准尚未明确时，精确到小时不一定更科学。早期计划可以使用人日、相对规模或区间估算；临近执行且任务清晰后，再转为更细的工时计划。

我建议把估算记录为区间或带置信度的预测。例如，“大概率 3，5 人日，存在外部接口风险”，比“4.2 人日”更适合用于早期资源决策。误差不是管理失败，拒绝承认误差才会让团队把不确定性藏进加班里。

3. 把人员视为可以互换的资源单位

“还有两个人有空”并不能证明团队有能力接新工作。人员的经验、权限、领域知识和协作关系会影响实际交付速度。若关键任务依赖单一专家，安排一个没有相关背景的成员，并不等于容量增加；反而可能增加培训、复核和返工成本。

资源规划要同时标注角色、技能和熟练度。对关键任务，至少确认执行人、评审人和可替补人选。即使没有成熟的技能矩阵，也可以从依赖记录、评审等待时间和任务返工原因开始建立，不必一开始就给每个人打复杂分数。

4. 只在项目启动时算一次容量

Capacity 会随范围、人员、优先级、休假和故障负担变化。启动时做过一次排期，不能代表后续几个月仍成立。若团队每周新增需求不断，却只在季度末复盘资源，积压问题会在交付前集中爆发。

我通常建议采用滚动窗口：近期一至两周看任务级承诺，中期四至八周看角色和项目组合冲突，更远周期只做范围和能力假设。离执行越近，数据越细；离执行越远，越应表达为区间和风险，而不是确定日期。

5. 让报表代替协商和优先级决策

资源冲突不是公式能独自解决的。两个项目都标记为“最高优先级”，容量表只能证明它们发生冲突，不能决定哪个项目应该让路。优先级需要有明确的业务授权者，并接受范围、日期、成本和风险之间的取舍。

如果管理层只要求团队“想办法都完成”，就等于把决策成本下放给执行者。结果往往是私下加班、质量让步和计划失真。好的制度应要求提出冲突的人同时提供至少一个可执行的取舍方案。

四、专业判断逻辑：从需求到容量，建立可追溯的计算链

1. 先定义统计周期和计量单位

负载数字必须有时间范围。按周适合迭代团队和短周期交付，按月适合运营工作和部门组合观察，按季度适合投资优先级与能力建设。把周级任务、月度支持量和季度人员规划混在同一张表里，却不说明转换口径，比较结果就没有意义。

计量单位也要与工作性质匹配。成熟、重复的工作可用工时或人日；探索性工作可用相对规模和区间；持续支持可按历史工单量、轮值时间和服务等级观察。管理者不应强迫所有团队使用同一种估算方式，但必须明确哪些指标可以跨团队比较，哪些只能在团队内部看趋势。

2. 计算净可用容量，并明确扣减项

可用容量可以从排班工时开始，扣除已知缺勤、固定职责和团队约定的预留时间。一个可操作的表达式是：净可计划容量＝名义工作时间－休假与节假日－固定会议与职责－运营支持预留－风险缓冲。每一项都要说明数据来源，避免不同经理按不同口径扣减。

风险缓冲不要用来掩盖估算质量差，也不应被视为可随意取消的空闲。团队可根据过去数个周期的计划外工作占比调整缓冲：如果连续多期临时工作明显高于预留，就应重新估计支持容量或改变工作流程，而不是只要求成员“提高效率”。

3. 把需求映射到角色和时间窗口

每项工作至少需要说明负责人、参与角色、预计周期、依赖和优先级。负责人承担交付责任，不代表所有工时都由负责人完成；参与角色则帮助识别架构评审、测试验证、设计支持等容易被漏算的负载。

时间窗口要反映任务真正需要资源的阶段。一个开发任务可能持续两周，但并非每天都需要同一名专家；如果只按任务起止日期平均摊工时，会误判冲突。对关键角色，应标出需要参与的具体节点，如方案评审、接口冻结、发布验证和客户验收。

4. 同时检查负载率、峰值和瓶颈

负载率可以用“已承诺工作量÷净可计划容量”表达，但必须和峰值、技能瓶颈一起看。平均负载率不高，可能掩盖某一周的严重冲突；团队总容量充足，也可能因单一角色短缺而无法推进。

我会重点检查三个问题：第一，未来两周是否有人持续超出个人容量；第二，某个关键角色是否同时出现在多个关键路径上；第三，计划外工作是否不断挤占计划任务。如果三项中的两项同时出现，就应优先调整承诺，而不是继续微调工时数字。

5. 把容量冲突转成有选项的决策

发现超载后，不要只发出“资源不足”的通知。应把决策拆成可比较的选项：缩小范围、推迟日期、增加具备能力的人员、降低并行项目数量，或明确接受风险。每个选项都要说明影响对象和代价，避免把成本藏在执行团队的加班里。

6. 建立数据反馈闭环，而不只追踪偏差

每个周期结束后，比较计划与实际时，不要把所有差异归因于个人执行效率。需要区分范围变化、依赖等待、估算偏差、突发支持、返工和缺勤。不同原因对应不同改进措施：估算误差靠校准，依赖等待靠流程设计，支持负荷靠轮值和容量预留，范围变化则要加强变更决策。

最小可行的复盘记录可以包含：原计划容量、实际用于项目的时间、计划外工作量、关键任务等待时间、未完成原因和下周期调整。连续观察几个周期后，团队才能知道缓冲设得是否合理、会议负担是否过高，以及哪些技能值得培养替补。

五、案例与数据观察：用一个情景推演看清容量制度如何落地

1. 案例边界：这是一组用于说明方法的情景数据

下面以一个 120 人左右的产品与技术组织为例，说明如何处理资源负载。数据是情景模拟，不是某家企业的真实经营数据，也不是对任何平台效果的实测结论。设组织有产品、研发、测试、设计和运营支持团队，三个项目在同一季度进入交付高峰。

项目甲要完成客户侧关键能力，项目乙需要升级公共服务，项目丙承担合规改造。三个项目各自有负责人和计划，但都需要同一位资深架构师参与评审，也都需要测试团队在月底集中验收。单项目计划看似可行，组合后却出现资源重叠。

2. 先看总量，再看关键角色

情景中，测试团队有 8 人，每人每周可计划工时按 24 小时估算，理论可计划容量为 192 小时。三个项目在高峰周分别需要 70、64 和 54 小时，总需求 188 小时，表面上没有超出总容量。但其中 118 小时集中在同一周后半段，且 4 人需要承担项目丙的特殊验证，真实瓶颈出现在角色和时段，不是团队总工时。

架构师的情况更明显：未来两周的净可计划容量为 32 小时，三个项目分别安排 12、14、10 小时评审与方案工作，总计 36 小时，尚未计入临时支持和决策准备。若只看项目总工时，冲突看不见；按角色与时间窗口查看，超载就很清楚。

3. 先改变顺序和范围，不急着追加人手

面对冲突，团队提出三种方案。方案一增加两名测试人员，但需要约一周熟悉业务，且不能解决架构师评审超载；方案二把项目乙的一项非核心能力推迟到下个迭代，并将验收拆成两批；方案三维持全部范围和日期，要求关键成员加班。

从成本和风险看，方案二更可控。它把测试峰值摊开，释放架构师时间，并保留项目甲和合规改造的关键路径。方案一只有在工作可独立拆分、人员具备基本背景且交接成本可接受时才有效；方案三不是“无成本方案”，而是把成本转为疲劳、缺陷和后续恢复时间。

4. 用前后指标验证制度是否有效

情景推演中，团队在调整后观察四项指标：高峰周超载时数、关键评审等待时间、计划外工时和按期完成率。重点不是宣称某个工具能把指标提升到特定数值，而是建立可验证的比较口径：同一团队、相近工作类型、相同统计周期，比较制度调整前后的变化，并记录范围变更等干扰因素。

这些数据只能说明怎样设计验证，不能当作普遍结果。实践中，若调整后按期率上升但返工也上升，不能简单判定制度成功；若超载时数下降，却是通过把运营支持转嫁给另一团队，也只是把问题移位。至少要同时看交付、质量、计划外工作和关键角色风险。

5. 工具应承载流程，不能替代制度

组织可以用协作平台管理项目、任务、负责人、计划时间和变更记录。例如，采用 PingCode 的团队可以将需求、项目计划、任务状态和协作记录关联起来，减少信息散落在表格、群聊和个人日历中的情况。是否适合某个组织，应结合权限模型、部署方式、集成需求、数据治理和团队采用成本评估。

工具实施时，我会先挑一个项目组合试运行，而不是一次性要求所有部门填报更多字段。先确认同一任务是否有唯一负责人，估算口径是否有说明，缺勤和支持工作是否能纳入观察，冲突是否有明确升级路径。字段越多不代表管理越成熟；只有能改变决策的信息才值得长期维护。

六、制度设计全流程：从试点到稳定运行

1. 第一步：明确管理目标和适用范围

制度启动前，先说清楚要解决什么问题。是项目延期频繁、关键人员冲突、跨部门争抢资源，还是支持工作长期被低估？不同目标需要不同数据。若核心问题是项目组合冲突，就不能只做个人工时填报；若问题是支持负荷失控，必须记录工作类型和服务来源。

同时划定边界：哪些团队参与、哪些工作纳入、观察周期多长、哪些数据仅用于规划而不用于个人绩效评价。若没有边界，成员会担心时间数据被用于排名，导致填报质量下降。制度应明确数据的用途、访问范围和保存规则。

2. 第二步：定义统一术语与最小数据集

先建立跨团队最小口径，不要一上来设计复杂的资源管理模型。建议至少包括人员或角色、时间周期、任务类型、估算工作量、优先级、负责人、依赖、状态和实际消耗。休假、固定职责、支持轮值等数据也要有明确来源。

术语要避免歧义。例如，“可用”究竟指没有排任务，还是已经扣除固定会议和运营工作后的净容量？“已承诺”是已经批准的项目计划，还是个人正在做的全部工作？最好用例子写入团队规范，并在试点复盘中修订。

3. 第三步：建立需求入口和优先级责任

没有统一需求入口，容量表就会永远落后于现实。团队要规定新增工作如何登记、谁负责确认优先级、紧急事项由谁判断、原计划被挤占后如何调整。紧急工作可以走快速通道，但必须记录它替代了什么工作，而不是直接塞进成员的剩余时间。

优先级责任通常不能由单个执行者承担。项目负责人可提出排序和影响，产品或业务负责人确认价值，项目组合层在冲突时做跨项目取舍。制度的价值不是阻止变化，而是让变化的代价可见、可追溯。

4. 第四步：设计容量评审节奏

建议采用分层节奏：团队每周检查近期负载和依赖，项目组合每两到四周检查关键角色冲突，管理层每月或每季度回顾优先级和能力缺口。具体频率取决于业务变化速度，不必为了形式增加会议。

每次评审应有固定输出：确认的容量假设、发现的冲突、拟定的取舍、决策人、完成日期和下一次检查点。会议不应逐条朗读任务，而应聚焦异常、变化和需要决策的事项。若没有异常，可以异步更新并保留例外升级机制。

5. 第五步：试点并校准估算与缓冲

选择工作类型相对稳定、负责人愿意参与复盘的团队进行试点。连续观察数个周期，比较计划和实际，找出系统性偏差：会议时间是否漏算、支持工作是否低估、需求是否经常变更、某类任务是否总被高估或低估。

不要用试点阶段的单一结果给团队排名。样本少、项目类型不同、人员构成变化，都会影响结果。试点首先验证流程是否可理解、数据是否能维护、冲突是否能被发现和解决；在此基础上，再谈跨团队对标。

6. 第六步：设置冲突升级和变更留痕

当计划负载超过阈值，团队需要明确升级顺序：项目负责人先给出范围或日期选项；涉及跨项目资源时交由项目组合负责人；涉及业务优先级时由有授权的业务决策者定夺。每一步都应规定响应时限，避免冲突长期悬而未决。

调整后要记录旧计划、新计划、变更原因和批准人。没有变更历史，团队无法解释预测为何偏离，也无法判断是执行问题还是决策变化。留痕不等于追责，而是让未来估算和组织决策建立在真实变化上。

7. 第七步：定期审视制度副作用

任何制度都有可能被指标反向塑造。若过度强调利用率，成员可能把工作拆得更细以填满容量；若只看按期率，团队可能缩小验收范围或延后暴露风险；若要求每件事都填工时，维护成本可能超过数据价值。

每季度至少检查一次制度副作用：填报耗时是否增加，计划外工作是否被隐瞒，跨团队协作是否变慢，成员是否因指标压力减少帮助行为。出现副作用时，应调整指标用途或流程，而不是继续堆叠报表。

七、不同情况下的行动建议：按组织成熟度选择起步方式

1. 小团队或单项目：先做轻量容量板

团队人数不多、项目关系简单时，不必搭建复杂模型。用一张共享视图记录未来两周的任务、负责人、估算区间、支持工作和休假，重点是每周识别谁会超载、哪些任务依赖同一人。每次只要求更新变化项，减少维护负担。

如果团队无法稳定估算工时，可以先用低、中、高复杂度或人日区间。关键是记录预测与实际偏差，观察数个周期后再调整。没有历史数据时，不要假装拥有精确预测能力。

2. 多项目并行：建立项目组合视角

多个项目共享人员时，个人排期表不足以解决冲突。组织需要一张组合层视图，至少显示项目优先级、里程碑、关键角色需求和计划峰值。管理层应定期决定哪些项目优先，哪些项目延后，避免每个负责人都把自己的事项标为最高优先级。

资源调配时优先检查可拆分工作、阶段顺序和验收窗口，再考虑跨项目借人。借人要估算交接成本、原团队受影响程度和回归条件，不能把人员当作无摩擦流动的单位。

3. 支持与故障较多：先把非计划工作显性化

如果团队经常被线上问题、客户咨询和临时修复打断，首要动作不是提高估算精度，而是记录这些工作从哪里来、由谁处理、占用多少时间。可以采用轮值、工单分流、固定响应窗口或明确服务等级，减少整个团队随时被打断。

若计划外工作持续超过预留，应讨论根因：系统稳定性、需求质量、客户承诺、支持入口还是责任边界。仅仅提高缓冲比例可以暂时改善计划，但无法替代对根因的治理。

4. 关键技能集中：投资替补能力，而不是只加人

某个角色长期成为瓶颈时，短期可以调节评审节奏和范围，长期则要建立替补能力。让第二人参与方案评审、编写运行手册、共享关键背景，逐步降低单点依赖。培养替补需要真实时间，必须纳入容量规划，不能指望成员在满负荷之外完成知识传递。

外部招聘或借调适合工作可拆分、技能要求清楚且交接期可接受的情况。如果任务高度依赖领域经验，新增人员在短期内可能增加核心专家的辅导负担。应先判断瓶颈是“人数不足”还是“知识集中”。

5. 远程或跨时区团队：容量之外还要看协作窗口

跨时区团队的名义工时相加，不代表可以顺畅协作。关键审批、设计评审和联调可能受共同在线时间限制。规划时应记录需要同步完成的节点和可异步完成的工作，避免把所有需求都安排到短暂重叠时段。

对异步协作，任务描述、决策记录和交接要求更重要。Capacity 计划应把响应时延和等待时间纳入交付预测，否则即使人员工时充足，任务仍可能在依赖队列里停滞。

6. 使用管理平台：先验证数据闭环，再扩大范围

当项目数量、参与部门和依赖关系增加到表格难以维护时，可以评估项目管理平台。选型时不要只比较功能清单，应该用真实流程演示：新增需求如何进入计划，资源冲突如何识别，优先级变更如何留痕，报表能否按角色和项目组合查看。

以 PingCode 这类面向中大型企业及 100 人以上组织的项目管理平台为例，评估重点可以放在需求与项目关联、权限控制、团队协作、数据汇总和现有系统集成上。是否采用，应通过小范围试点比较数据维护成本、决策速度和使用者体验，而不是仅凭演示界面作判断。

八、不同情况下的取舍：没有一种负载模型适合所有团队

1. 追求细粒度与降低维护成本之间的取舍

细到小时的数据有助于近期排班和成本核算，却增加填报与校验负担，也可能诱发虚假精确。粗粒度数据便于团队维护，但对短期冲突的识别能力较弱。常见做法是近两周使用较细单位，远期使用区间或角色需求，按预测距离逐步降低精度。

如果数据不会改变任何决策，就不应要求团队长期维护。可以先问：这项字段将触发什么动作？谁会使用？多久更新一次？如果三问都没有清晰答案，通常意味着字段设计需要简化。

2. 个人利用率与团队流动效率之间的取舍

把每个人都排满，看上去提高了个人利用率，却可能让任务在等待评审、测试或决策时形成长队。团队应观察工作从开始到完成的流动时间、在制品数量和等待原因，而不是只追求每个人始终有事做。

当团队在制品过多时，限制并行工作可能短期降低表面利用率，却提高完成率和反馈速度。是否采用，应看交付目标和工作类型：紧急响应团队需要保留待命能力，稳定的项目团队则可以更严格地控制并行任务。

3. 集中资源与分散资源之间的取舍

集中专家可以提高技术决策质量，代价是形成瓶颈和单点依赖；把专家分散到各项目，可以缩短局部等待，却可能降低全局一致性并增加重复工作。对高风险、强依赖的能力，集中评审或平台化治理可能更合适；对相对独立的交付，则可赋予团队更多自治权。

组织不必在集中和分散之间二选一。可以让专家维护标准、处理高风险决策，同时培养各团队的日常执行能力。关键在于定义“哪些问题必须集中评审，哪些问题可以由团队自行决策”。

4. 固定缓冲与动态缓冲之间的取舍

固定缓冲易于理解和排期，适合工作波动相对稳定的团队；动态缓冲根据历史支持量、项目风险和人员变化调整，适合工作类型差异明显的组织。固定比例简单，却可能对稳定团队过度保守、对高波动团队过于乐观。

实践中可以从固定缓冲起步，再按每个周期的计划外工作、延期原因和缺陷返工校准。调整缓冲时应公开依据，避免管理者为了满足日期而单方面削减缓冲，却仍要求团队维持原有交付承诺。

5. 跨团队统一指标与本地自治之间的取舍

统一指标便于高层观察项目组合，但不同工作类型之间未必可比。产品探索、基础设施维护和客户支持的产出形态不同，用同一套利用率排名会鼓励错误行为。组织应统一基本定义和治理流程，把具体估算方法留给团队选择。

适合统一的通常是工作状态、优先级定义、时间周期、变更记录和关键风险口径；不一定适合统一的是每个任务的估算单位、团队缓冲比例和个人绩效衡量方式。统一是为了看见冲突，不是为了把差异抹平。

九、下一步怎么做：用四周建立可运行的最小制度

1. 第一周：选定试点与基线

选择一个存在明确资源冲突、但负责人愿意协作的项目团队或项目组合。记录当前的计划负载、计划外工作、关键角色等待时间和主要延期原因，并说明数据缺口。基线不必完美，重要的是口径清楚、后续可以重复观察。

2. 第二周：统一定义并建立容量视图

确认名义工时、净可计划容量、任务类型、估算单位、优先级和责任人。只保留能支持决策的字段，把固定会议、支持轮值、休假和缓冲纳入可见范围。若团队之间口径不同，先标明差异，不要用一个未经验证的数字强行覆盖。

3. 第三周：进行第一次冲突评审

用滚动窗口检查个人峰值、技能瓶颈和项目组合重叠。每项冲突都要求负责人给出范围、日期、人员或风险接受等选项，并明确谁有权决定。评审结束后记录决策，不把“再想办法”当作结果。

4. 第四周：复盘数据质量和制度成本

检查预测与实际的差异来自哪里，填报耗时是否可接受，数据是否促成了决策，是否出现工作转移或指标行为。决定保留、删除或修改哪些字段，再确定下一轮观察周期。四周能验证流程是否可运行，但不能据此宣称组织产能已经提高。

Capacity 管理最值得坚持的，不是某个利用率目标或一张漂亮的资源热力图，而是把承诺建立在真实约束上。团队有权说明容量不足，管理者有责任做出优先级取舍，组织则应为不确定性预留空间。下一步，可以从一个真实项目组合开始，列出未来四周的关键角色需求、已知缺勤和计划外工作，再约定超载后由谁在多长时间内作出决策。只要这条链路能跑通，容量数据才真正从“看见忙碌”变成“改善交付”。