工作负载管理指南：项目经理如何做好资源负载，流程优化全流程

项目资源负载看起来像一道排班题，真正让项目延期的却常常不是“人不够”，而是团队把同一批人的时间重复承诺了：产品经理同时参加三个项目的需求评审，架构师被多个团队列为关键路径上的“可用资源”，测试人员则在迭代末尾集中接收工作。工作负载管理的核心，不是把每个人填满，而是让承诺、能力、优先级和交付节奏彼此匹配，并在变化发生时及时重新决策。

一、先讲核心结论：负载管理不是排满日历

1. 管理的对象是可交付能力，不是工时总和

我判断一个团队是否做好资源负载管理，通常不会先看每个人每天排了多少小时，而是先问三个问题：当前有哪些明确承诺？完成这些承诺需要哪些关键技能？遇到变化时，团队有没有能力调整顺序，而不是继续往日历上叠任务？

工时只是输入，不是交付能力的完整表达。一个开发人员本周有 40 小时可工作，不代表 40 小时都能用于项目任务。会议、代码评审、线上支持、知识交接、沟通等待和临时故障都会占用时间。若计划把 40 小时全部分配给开发任务，计划从建立之初就隐含了“没有任何中断”的假设。

我的基本判断是：先确定团队真实可用容量，再根据技能和优先级安排工作，最后为变化保留缓冲。这比先把所有需求塞进计划、再要求成员自行加班更可靠。

2. 负载管理的目标是降低承诺失真

负载管理不是追求每个人的利用率越高越好。团队利用率升得很高时，表面上每个人都有事做，实际可能出现任务切换增多、协作等待变长、缺陷修复挤占新功能、关键人员成为瓶颈等问题。计划看似更饱满，交付反而更脆弱。

我更关注三个结果：承诺的工作是否与可用能力相符；工作是否在团队内部合理流动；发生变化后，项目是否能通过调整范围、顺序或资源来恢复可控。负载管理的价值不是消灭变化，而是避免变化只能通过加班来消化。

3. 用四层视角建立工作负载管理闭环

一套可执行的工作负载管理，至少包括需求入口、容量评估、执行监控和调整复盘四层。只有容量表、没有需求排序，团队无法决定做什么；只有计划、没有执行信号，管理者会在延期暴露后才发现问题；只有监控、没有调整权限，数据也只能证明团队很忙。

二、背景和真实场景：为什么“大家都很忙”仍然会延期

1. 多项目共享专家，造成隐性排队

中大型组织经常不是每个项目都拥有完整的专职团队。架构、数据、安全、用户研究、测试等角色，可能同时服务多个项目。项目计划里，这些人往往被写成“按需支持”，但“按需”并不意味着随叫随到。多个项目同时进入评审、联调或上线阶段时，实际上形成了一个没有显式排队规则的共享服务队列。

这类问题的危险之处在于，项目经理可能看到每个项目都只占用了专家的一小部分时间，于是认为负载合理；专家本人却需要在多个背景之间反复切换。任务看起来可以并行，实际交付却被依赖等待串联起来。一个评审迟到两天，后续开发、测试和上线窗口可能整体顺延。

2. 计划只统计项目任务，漏掉运营和协作工作

我见过不少团队的容量表只列需求开发和测试任务，却不列生产支持、客户问题、招聘面试、内部评审和跨团队协调。结果是计划容量永远显得够用，执行容量却总是不够。问题不是成员估算能力差，而是计划统计范围不完整。

在持续运营的团队里，支持工作不是偶发噪声，而是稳定存在的需求类别。它不一定能准确预估到具体事项，却可以按历史区间估算。若过去六周团队每周平均有 15% 的工时用于线上支持，就不宜在下一轮计划里把这部分容量当作可自由分配的项目时间。

3. 任务切换成本没有出现在工时表里

一名工程师上午处理紧急故障，午后参加产品方案会，接着切换到一个正在联调的项目，最后还要回复另一个团队的代码问题。每项活动单独看都合理，但每次切换都需要重新建立上下文。工作负载表通常记下任务工时，却不记录切换造成的注意力损失和重新进入状态的时间。

因此，我不会把“有空档”直接等同于“能接新任务”。如果工作被切成过多的小段，成员可能在所有事项上都有投入，却没有连续时间完成任何一项复杂工作。对需要深度思考的任务，连续工作窗口往往比零散空闲小时更有用。

4. 用 PingCode 场景理解跨团队负载协同

对于 100 人以上、存在多个产品团队和共享职能团队的组织，可以把 PingCode 作为项目与研发协作场景的分析例子：项目管理者需要把目标、需求、迭代、缺陷、依赖关系和团队容量联系起来，而不是分别维护互不相通的表格。具体功能和配置应以组织实际部署版本为准，不能因为工具里能看到任务，就假定资源冲突已经被解决。

在这类组织里，工具的作用首先是让承诺和执行状态可见，其次才是自动化提醒与汇总。资源决策仍然需要业务负责人、项目经理和职能负责人共同完成。例如，两个项目都要求同一位安全专家在本周评审，系统可以显示冲突，但不能替组织判断哪个目标更重要。

下图为情景模拟，用于说明遗漏非项目工作会怎样改变可排产容量，不代表任何企业的实测数据。它强调的是计算顺序：先扣除固定协作和支持工作，再安排项目任务。

三、常见误区：看起来精细，实际会制造更大偏差

1. 把 100% 利用率当作资源效率

把每个成员的日历排满，容易产生一种控制感：没有空闲，看起来就没有浪费。但系统没有缓冲，就没有能力吸收需求波动。只要出现一次紧急缺陷、需求澄清延迟或关键依赖未就绪，原计划就只能通过延长工时或挤压质量来维持。

对复杂知识工作来说，容量预留不是闲置，而是风险吸收能力。预留多少不能凭口号决定，应结合中断频率、交付稳定性和工作类型观察。支持类工作比例高、外部依赖多的团队，通常需要比需求相对稳定的团队保留更多机动容量。

2. 把任务小时数直接相加，忽略技能约束

总工时看似足够，不代表关键技能足够。一个项目可能总共需要 120 小时，团队拥有 150 小时的空余容量，但其中只有一名成员能完成数据迁移评审，且这名成员同期还承担生产值班。这个项目依然可能卡在关键技能上。

资源评估必须同时看“容量”和“能力”。容量回答有多少时间，能力回答这些时间能否完成特定工作。把两者混为一谈，会让管理者误以为通过调入任意成员就能解决瓶颈，进而增加沟通成本和返工风险。

3. 把估算差异归咎于成员不够努力

实际耗时超过估算，可能源于需求不清、依赖等待、技术风险、返工、支持工作被打断，当然也可能是估算偏差。若组织只用“计划工时对比实际工时”评价个人，成员会倾向于报高估算、隐藏阻塞或拆小任务以避免暴露风险，数据最终失去决策价值。

我更建议把估算差异作为团队预测能力的反馈，而非个人问责指标。重点追问：偏差集中在哪类工作？是输入条件不完整，还是任务等待时间被遗漏？哪些不确定性能够在下一轮提前验证？

4. 只看工作量，不看在制品数量和等待时间

团队接了很多任务，不代表任务推进得快。若每个人同时启动多项工作，所有任务都可能处于“进行中”，但关键步骤仍在排队等待。项目经理需要看任务从开始到完成的流动，而不只是工作量累计。

在制品过多常见于团队害怕成员“没有事做”，于是不断提前分派任务。我的建议是先让已启动工作完成或暴露阻塞，再启动更多工作。减少并行通常会让局部看起来没有那么忙，却更容易缩短端到端交付时间。

5. 把工具里的资源视图当成管理结论

任何工具都只能呈现输入数据和规则的结果。成员可用时间未更新，任务没有拆到可判断的粒度，优先级没有明确排序，视图再整齐也只是把旧假设可视化。管理者不能把“系统里显示绿色”理解为“承诺一定可靠”。

以 PingCode 这类项目协作平台为例，团队可以利用统一的项目、需求与执行记录减少信息分散，但资源模型、工时口径和跨项目优先级仍需组织自己约定。工具应帮助暴露冲突，不应成为冲突责任的替代品。

四、专业判断逻辑：怎样把容量、技能和优先级算到一起

1. 先划清工作口径，再做任何容量计算

第一步不是建表，而是明确哪些工作进入容量模型。建议至少区分承诺项目工作、运营支持、组织协作、学习与改进、休假及不可用时间。不同团队可以采用不同分类，但必须保持口径稳定，否则本月的“项目投入”与下月的“项目投入”无法比较。

还要明确统计单位。按人天管理适合较粗粒度的阶段规划；按小时管理适合短周期、明确工种和较稳定的工作；对需求变化频繁的团队，精细到小时往往制造虚假准确感。精度应服从决策需要，而不是服从表格的细致程度。

2. 用净容量代替名义容量

净容量可以按一个简单结构估算：团队可工作时间，减去已知不可用时间、固定运营工作和必要协作时间，再扣除根据历史波动确定的缓冲。它不需要一开始就精确到小数点，关键是将以前隐藏在个人日历里的工作显式化。

例如，一个 8 人小组名义上每人每周 40 小时，名义容量是 320 小时。若休假与培训折算 20 小时，例会与评审 48 小时，支持工作约 40 小时，再为临时波动保留 32 小时，则可承诺的项目容量约为 180 小时。这个结果远低于名义总量，却更接近可执行现实。

3. 建立技能矩阵，识别不可替代的单点

技能矩阵不用把人打成复杂的等级标签，可以用“可独立负责、可在指导下完成、尚不具备”三档，覆盖关键工作类型。矩阵的目的不是给成员排名，而是帮助项目经理发现：哪些工作只有一个人能做？哪些人需要提前参与知识交接？哪些任务可以通过培训降低瓶颈风险？

如果某个关键技能只有一名成员具备，即使此人看起来没有满载，仍可能形成组织级风险。此时要考虑降低并行项目数、提前完成评审、安排结对、培养备份，或调整交付顺序。把更多任务压给唯一专家，短期或许推进，长期却扩大单点故障。

4. 以优先级和依赖关系决定资源分配顺序

资源冲突时，不要依次满足声音最大的人。先明确业务价值、时限刚性、延误影响、依赖阻塞和替代方案，再作排序。一个截止日期很近的任务，若其结果对关键业务并不重要，也未必应压过一个价值更高、且被多个团队等待的工作。

我建议把优先级分成三个层次：必须按期完成且影响明确的承诺；对目标有价值但可以调整时间的工作；尚未完成验证、暂不进入承诺的候选需求。每次新增工作都要回答“它替代什么”，否则团队只会不断扩大承诺面。

5. 把预测拆成承诺、预测和候选三个层级

很多计划失真的根源，是把“希望做”写成“承诺做”。我会把工作分成已承诺、当前预测和候选事项：已承诺需要有负责人、验收条件和容量依据；预测事项表达当前判断，但允许根据实际流动调整；候选事项需要进一步澄清，不应提前占用关键人员的确定容量。

这三个层级能帮助管理者在沟通时说清楚确定性。对业务方而言，“本期一定交付”与“容量允许时争取纳入”是不同承诺。把这种差异写明，比用一个看似精准的日期掩盖不确定性更诚实。

6. 用流动指标补足工时指标

工时有助于规划投入，流动指标有助于发现交付过程中的等待和拥堵。建议至少关注周期时间、在制品数量、阻塞时间和承诺完成率。周期时间从工作开始到完成，阻塞时间揭示等待依赖的成本，在制品数量反映并行压力，承诺完成率则检验计划是否稳定。

这些指标要结合起来看。若周期时间变长、在制品增多、阻塞时间上升，通常不应继续增加任务，而应先查找瓶颈。若承诺完成率低但周期时间稳定，问题也可能是承诺范围过大，而非团队执行效率不足。

五、具体案例与数据观察：把负载问题从“感觉很忙”变成可调整的计划

1. 案例背景：同一名专家被三个项目同时依赖

以下案例为情景模拟，用于展示分析和决策方法，不指向某一家企业的实测结果。某组织有产品、研发、测试和安全职能，三个项目计划在同一阶段完成版本发布。安全评审由一位专家承担，三个项目都把评审安排在同一周；测试团队还要同时处理线上缺陷。

项目经理最初看到的计划是：研发任务总量在团队估算容量之内，安全评审每个项目只需半天，测试排期也留有若干空档。但把跨项目依赖、评审顺序和线上支持纳入后，问题显现出来：安全专家的有效时间不足以满足三个项目的并行安排，测试空档也被缺陷处理不稳定地占用。

2. 观察负载时，先找峰值而不是平均值

团队平均利用率可能只有 78%，但这并不能说明资源冲突轻微。若同一周的关键角色负载达到 130%，而其他岗位尚有余量，团队仍会在关键路径上排队。平均值会把局部峰值抹平，因此项目经理需要按角色、技能和时间窗口检查负载。

下表里的数据是情景模拟，用于说明汇总口径。角色负载按“需求工时÷该角色净容量”计算；高于 100% 表示计划需求超过该时间窗口的容量，不代表成员实际工作效率。

3. 用变化前后的计划比较检验决策效果

团队没有简单要求安全专家加班，而是先检查依赖：项目甲的评审是发布前置条件；项目乙的评审可以提前完成；项目丙仍有两项安全需求尚未澄清。团队于是调整评审顺序，将项目乙提前评审，先澄清项目丙需求，并把项目甲的发布窗口与评审完成时间绑定。

这类调整的收益不是让每个人的负载都变得平均，而是让最关键的依赖先得到处理。项目乙减少了等待，项目丙避免在信息不全时反复评审，项目甲则获得了明确的风险边界。负载平衡的目标是改善端到端流动，不是让表格里的百分比看起来整齐。

4. 观察计划命中率，判断容量假设是否可信

如果团队连续多个周期都只能完成承诺工作的六到七成，先不要急着要求成员加速。可以检查三类原因：计划是否纳入支持工作，需求是否在中途持续增加，任务是否因依赖或验收标准不清而停滞。相反，若团队经常提前完成且剩余容量稳定，也可能说明计划过于保守，或有工作未被纳入可见范围。

计划命中率应与工作类型、需求变化和质量结果一起看。为了提高命中率而把承诺压得很低，可能牺牲业务价值；为了追求高承诺量而持续加班，则可能把疲劳和质量风险推迟到后续周期。单一指标不能替代管理判断。

5. 复盘真实原因，而不是只记录“延期”

每次计划偏差都可以归入一类主要原因：需求变更、容量缺失、技能瓶颈、依赖等待、估算误差、返工或突发支持。原因分类不需要过度细碎，但要能指导动作。例如“依赖等待”可以推动提前预约评审，“支持工作”可以推动设置轮值容量，“返工”则需要检查验收标准和质量门禁。

复盘的输出应是可验证的改进假设，而非一句“加强沟通”。如果下周期提前冻结评审窗口，阻塞时间是否下降？如果把线上支持从项目容量中独立扣除，承诺完成率是否更稳定？让改进动作与观测指标对应，才能判断措施有没有作用。

六、流程优化全流程：从需求进入到复盘改进

1. 建立统一需求入口，避免工作绕过计划

工作负载管理从入口开始。若业务部门通过即时消息、会议口头安排和邮件直接派活，项目经理看到的计划永远不完整。统一入口不意味着每项小事都要走复杂审批，而是让新增工作至少具备提出人、预期结果、优先级、期望时间和影响范围。

对于紧急工作，可以设置快速通道，但快速通道也要记录“替代了什么”。如果紧急事项不需要替代任何工作，团队就必须确认它确实有额外容量；否则只是把成本隐藏在加班、延期或质量下降里。

2. 先澄清验收条件，再估算资源需求

未澄清的需求无法可靠估算。项目经理应先确认交付物、验收标准、依赖方、风险点和完成定义，再让执行角色参与估算。业务方只给出一句“尽快上线”，团队就报出一个看似精确的日期，通常是在用数字掩盖信息不足。

需求仍有较大不确定性时，可以先安排探索工作，例如原型验证、技术调研或小范围试验。探索的目标是降低不确定性，不应与完整交付的工作量混在一起。这样可以把“还不知道要做多少”转化为“先花有限容量回答关键问题”。

3. 按团队节奏建立容量基线

容量基线应从历史实际中校准。团队可以先选择 4 至 8 个连续周期，记录名义容量、非项目工作、临时中断、承诺工作和实际完成情况。观察的重点不是追求精确到每小时，而是发现稳定的扣减项和波动区间。

新团队缺少历史数据时，可以先使用保守估计，并把它标记为初始假设。经过几个周期后再更新。初始估计的价值在于让风险显性化，而不是假装它准确。

4. 按角色和依赖进行滚动排程

排程时先放入关键路径上的稀缺技能和外部依赖，再安排可替代性较高的工作。不要先把所有普通任务排满，再发现专家没有时间处理评审或设计。对于共享角色，应预留明确时间窗口，避免多个项目以“有空时支持”的方式抢占同一容量。

滚动排程意味着远期计划粒度更粗，近期计划更具体。距离交付较远的工作可以按阶段或工作包估算；进入近期窗口后，再细化到可执行任务。过早对远期每一天作承诺，会制造维护成本，并让任何变化都显得像计划失败。

5. 执行中限制并行，及时解除阻塞

执行阶段要同时看新工作进入和旧工作完成。团队如果持续启动新任务，却不推动已开始事项完成，任务池会越来越拥堵。项目经理可以与团队约定在制品上限，超过上限时先完成、协助或解除阻塞，再接收新工作。

阻塞问题应尽量具体化：等待谁的决策？缺少哪项输入？何时可以升级？“正在等待”不是可操作状态。把阻塞责任人与下一步动作写清楚，项目经理才能区分真正的外部等待与任务内部尚未推进。

6. 变化发生时执行影响评估，而非静默插入

新增需求或资源变化进入后，应评估范围、时间、质量和依赖的影响。常用的可选动作包括：替换低优先级事项、推迟交付时间、缩小本次范围、增加合适技能的资源、拆分交付批次。每种动作都有成本，不能只说“尽量兼顾”。

若项目经理没有权力决定优先级，应把冲突升级给有决策权限的人，并带上备选方案和影响。管理者的责任不是独自吸收所有变化，而是让组织看见变化的代价，由相应负责人明确选择。

7. 周期结束后更新基线和规则

每个迭代或阶段结束时，比较计划与实际，区分估算偏差、范围变化和流程等待。容量基线、缓冲比例、技能矩阵和在制品限制都可以按证据调整。不要为了让下周期看起来更顺利，简单把上周期所有未完成事项原封不动地搬过去。

复盘还要检查结构性风险：是否长期依赖某一位专家？是否有团队连续多个周期没有完成学习和改进工作？是否因为高利用率而无法处理技术债？这些问题不会在单个迭代里立刻造成事故，却可能逐步削弱未来交付能力。

七、不同情况下的行动建议：不要用同一套负载规则管理所有团队

1. 新团队或缺少历史数据时

不要一开始就追求复杂的工时模型。先建立基础记录：成员可用时间、固定会议、运营支持、已承诺工作、阻塞原因和完成结果。前几个周期的目标是形成可用基线，而不是证明某个精确利用率。

建议把远期承诺压低，把不确定工作拆成小规模验证，并明确说明容量数据属于初始估计。随着团队持续记录，再判断哪些扣减项稳定，哪些属于偶发波动。

2. 多项目共享专家资源时

建立跨项目的角色视图，至少看到专家在未来数周的评审、决策、设计和故障支持安排。由项目负责人共同确认共享角色的优先级和服务窗口，避免每个项目经理都单独争取“半天”。

若共享专家长期成为瓶颈，优先考虑减少同时启动的项目、提前预约关键节点、培养备份能力或调整交付顺序。临时追加人手未必有效，因为新人需要指导，短期可能增加专家负担。

3. 需求变化频繁或支持工作很多时

把运营支持视为正式工作类别，使用轮值、专人窗口或团队容量池吸收波动。短周期内可以降低固定承诺比例，待工作波动稳定后再逐步调整。若不承认这类工作存在，项目计划就会不断被“不可预测事件”打断。

需求变化频繁时，采用更短的承诺窗口和分批交付。项目经理要与业务方约定变更规则：什么情况可以插入，插入后替换什么，谁有权批准。规则的目的不是阻止业务变化，而是使变化成本可见。

4. 固定交付日期且不能轻易调整时

固定日期不等于范围固定。若日期具有合同、法规或市场窗口约束，应尽早评估关键路径和容量缺口，并优先保护最小可交付范围。对非关键功能设置明确的延期或降级选项，避免所有需求都被默认为必须按期完成。

如果日期、范围和质量底线同时完全不可调整，项目经理需要尽早升级风险，而不是等待最后一周通过加班补救。三者都刚性时，组织必须提供足够的合适资源并接受成本上升；否则承诺本身就不可行。

5. 分布式团队或跨时区协作时

容量计算不能只看工作日总时数，还要看协作窗口。一个成员虽然有 30 小时可用，但与依赖团队只有每天一小时重叠，澄清和反馈的等待时间可能明显增加。把跨时区交接、异步评审和决策延迟纳入排程，计划才更接近真实流动。

可以通过明确交接模板、异步决策时限和固定重叠时段减少等待。不要把会议数量减少误认为沟通成本自动下降；如果信息没有留下可追踪记录，异步协作可能只是把等待变得更隐蔽。

6. 使用项目管理平台或表格时

团队规模较小、项目较少、角色稳定时，表格可能足够。它的优势是轻便、易调整，适合快速建立容量假设；短板是多人同时维护、历史变更追踪和跨项目视图容易失控。

当组织有多个项目、共享职能和较多依赖时，可以评估 PingCode 等项目管理平台是否能把需求、计划和执行信息更连贯地呈现。评估重点应放在数据口径、权限、流程适配、报表维护成本和成员使用负担，而不是只比较功能清单。工具上线前应先统一管理规则，否则只是把分散的混乱迁移到新界面。

八、不同情况下的取舍：每种“优化”都要付出相应成本

1. 高利用率与交付韧性的取舍

提高利用率可以增加短期排产量，但会减少吸收突发事件的缓冲。对需求稳定、工作高度可预测的团队，容量利用可以相对积极；对线上支持多、依赖复杂、变化频繁的团队，则需要更多机动空间。没有适用于所有团队的统一利用率目标。

真正要比较的是新增排产带来的交付收益，与失去缓冲后产生的延期、质量和疲劳成本。若一个小幅增加利用率就让计划频繁失守，说明团队已接近系统边界，继续压缩空档可能得不偿失。

2. 专业化分工与技能冗余的取舍

高度专业化有利于提高单项工作质量和速度，但容易形成关键人员瓶颈。培养备份、结对和轮岗会消耗短期容量，却能降低单点风险。对低频、影响有限的技能，可以接受有限冗余；对发布、安全、数据迁移等关键能力，应评估没有备份的业务后果。

培养备份也不意味着让所有人都成为全能角色。更现实的目标是让关键任务至少有可接替的第二人，并通过文档和共同实践缩短交接时间。

3. 详细计划与快速响应的取舍

详细计划能提高近期协调效率，但维护成本会随变化增加。稳定项目可以把近期工作拆得更细；探索性项目应保留较粗计划，以阶段目标和验证结果管理。项目越不确定，越不宜把远期排程做成精细到每日的承诺。

如果计划每天都要大规模重写，就说明粒度与不确定性不匹配。可以把计划分为近期明确、中期预测、远期方向，让团队把精力放在当前可执行的决策上。

4. 集中式资源池与团队自治的取舍

集中资源池便于组织层面处理优先级冲突，适用于共享专家多、项目竞争明显的环境；缺点是决策链条可能变长，局部团队响应变慢。团队自治能提高日常速度，但如果跨项目依赖多，也可能让每个团队各自优化、全局互相阻塞。

一种折中方式是：日常任务由团队自行安排，稀缺技能和重大优先级冲突由跨项目机制协调。协调会议不必频繁冗长，但需要明确参与者、决策权限和冲突升级条件。

5. 工具自动化与人工判断的取舍

自动汇总、提醒和冲突提示适合重复规则明确的事项；涉及价值排序、风险容忍和战略取舍时，仍需要负责人判断。把自动化用于减少信息搜集和重复维护，把人的注意力留给解释原因、协商取舍和调整目标，通常比追求“系统自动排出最优资源”更现实。

工具投资也要考虑维护成本。若组织无法保证任务及时更新、角色信息准确和项目状态可信，复杂的自动排程会给出看似权威却建立在陈旧数据上的建议。

九、结尾：资源负载管理的真正起点，是敢于做选择

1. 先解决最重要的冲突，不要先追求完美模型

工作负载管理不需要从一套庞大的流程开始。先找出团队最常见的三种冲突：容量被谁占用、关键技能在哪里排队、哪些需求绕过了入口。把这三件事记录清楚，通常比一次性引入复杂指标更能改变执行结果。

2. 下一步按三个动作启动

接下来可以先做一个周期的轻量试运行：整理当前承诺与候选需求；按角色估算净容量并标出共享技能；每周检查在制品、阻塞和新增工作。周期结束后，用实际情况修正容量假设，并记录哪些工作需要被替换、延后或拆分。

我最看重的判断是：一个可信的资源计划，不是证明团队没有空闲，而是能够解释为什么这些工作值得占用容量、哪些风险仍未被消除，以及变化发生时由谁作出取舍。当项目经理能把这三件事说清楚，资源负载才从填表变成了真正的交付管理。