工作负载实操方法：PMO提升资源负载效率的制度设计方法与模板

工作负载看起来是一个“人够不够用”的问题，实际常常是“承诺了多少工作、工作何时真正发生、谁有权调整优先级”这三个问题叠在一起。某团队每个人的排期都显示接近满负荷，项目却仍然延期；复盘后发现，计划里没有扣除支持工作、评审等待和临时插单，所谓 100% 负载只是把尚未确认的需求也算成了确定任务。PMO要提升资源负载效率，关键不是把每个人的日历填满，而是用制度让需求、能力、优先级和调整动作形成闭环。

一、先讲核心结论：负载效率不是“人越忙越好”

1. 把负载管理从排期表升级为经营机制

我判断一套工作负载制度是否有效，不先看表格是否精细，而先看三个问题能不能被稳定回答：当前承诺了什么工作；关键资源在未来几个周期是否过载；发生冲突时，谁依据什么规则做取舍。三件事中任何一项没有明确答案，负载表就很容易沦为月末汇报材料。

负载效率的目标不是把可用时间全部填满，而是在可持续容量内完成最重要的承诺，并保留处理不确定性的空间。如果团队把每个人都排到 100%，一次客户问题、一次需求返工或一次关键评审延迟，就会把整条计划推向失控。名义利用率高，不等于交付能力强。

我建议将制度目标拆成四类：容量可解释、优先级可比较、变更可追溯、结果可复盘。容量可解释，意味着计划工时与实际可用能力有明确口径；优先级可比较，意味着项目之间不是靠谁声音大抢人；变更可追溯，意味着插单发生时同步记录被挤出的工作；结果可复盘，意味着预测误差能回到估算、依赖或审批规则上。

2. 先统一口径，再讨论利用率

“负载率”常被不同团队用不同分母计算。有的用合同工时，有的用扣除假期后的工作时间，有的把会议和支持工作算进任务，有的只统计项目工时。口径不同，百分比就不能直接横向比较。PMO应先发布统一定义，再把数据拆成可用于决策的维度。

一个可操作的基础口径是：计划负载率等于某周期内已承诺工作量除以该周期的有效容量。有效容量不是劳动合同里的总工时，而是扣除假期、固定例会、必要行政事务和组织预留后，团队可以合理投入交付的时间。支持任务与项目任务应分别记录，不能为了报表好看而悄悄藏进“其他”。

上述指标不能孤立解释。例如，实际投入率低可能意味着需求不足，也可能是审批等待、环境故障或工时记录缺失；计划负载率偏高可能是估算口径错误，也可能是组织把大量未确认事项提前算入承诺。PMO应要求指标与原因码、工作类型和周期一起呈现。

3. 用三层治理，而不是让 PMO 独自追工时

负载管理至少需要三个治理层级。项目层确认任务、估算和依赖；资源层协调跨项目冲突和技能稀缺；组合层决定哪些项目优先、哪些工作延后或停止。若只在项目层排任务，资源会被多个项目重复承诺；若只在组合层看总人数，关键技能和具体档期仍然无法落地。

PMO适合做制度设计、数据口径维护、冲突呈现和决策记录，不应替业务负责人承担全部排期责任。项目负责人要对工作拆分和计划可信度负责，职能负责人要对能力供给和技能发展负责，组合决策者要对优先级和资源取舍负责。责任不清时，常见结果是 PMO 催表格，管理层却不愿意取消任何一个承诺。

二、背景和真实场景：负载失真通常从哪里开始

1. 多项目并行时，资源被重复承诺

在产品研发、信息化建设、专业服务和运营改进团队中，一个人同时参与多个项目并不稀奇。问题在于，每个项目负责人通常只看到自己项目的需求，不一定知道其他项目已占用多少能力。计划汇总后，表面上每项工作都合理，合并后却出现同一位架构师在同一周承担三项关键评审的情况。

这类冲突不一定表现为显眼的“超负荷”。更常见的是任务反复切换、评审排队、决策等待，以及项目负责人各自把延迟归因于“资源响应慢”。实际根因可能是组合层没有为共享资源设置统一入口，也没有规定冲突升级的时间窗口。

2. 工时有记录，不代表产能被看见

团队可能记录了大量工时，但数据依然不能回答资源决策问题。例如，工时被记在项目编号下，却没有区分交付、支持、返工和等待；或者所有人每天都填报，填报粒度却细到难以长期维护。数据收集成本过高，会诱发补填、估填和统一填成整小时等行为，产生“看起来完整”的噪声。

我通常先问管理者下一步会依据这项数据做什么。如果答案只是“方便看人忙不忙”，就不应设计复杂记录规则；如果要判断某类支持工作是否需要单独配置容量，那么工作类型就必须能区分。数据字段不是越多越好，而是每个字段都要对应一个真实决策。

3. 支持工作与项目工作争抢同一批人

研发团队的线上问题、业务团队的临时分析、设计团队的零散改稿、职能团队的审计与合规任务，往往没有完整项目计划，却持续消耗关键人员。若制度只统计正式立项工作，这部分负载就会变成“隐形容量税”。项目看似延期，团队却说每天都很忙，双方都可能没有说谎。

改善办法不是把每个临时请求都变成大型项目，而是设置可见的工作类别和容量池。例如把计划交付、运行支持、管理协作、学习改进分别记录；对支持工作设置周期上限和升级规则；超出上限时由组合决策者判断是否扩容、降级服务或调整项目承诺。

4. 负载数据需要按周期匹配决策节奏

日级数据看起来精细，但多数资源决策并不需要每天重新分配。对跨团队项目组合而言，月度或双周滚动计划常常更可执行；对高频运营支持，则需要更短周期的值守安排。制度应当按决策时效分层，而不是强迫所有工作使用同一种时间粒度。

一项工作如果尚未明确范围，不宜假装能精确到小时；可以先用能力区间、技能需求和最早开始时间表达。范围澄清后再逐步细化。越不确定的工作，越需要在计划中标示不确定性，而不是用更多小数位制造精确感。

三、常见误区：看起来像管理，实际会削弱效率

1. 把满载当成效率，把空档当成浪费

如果团队要求每个人每个周期都达到接近满载，短期内报表会很漂亮，长期却容易增加排队和延期。工作系统不只有执行时间，还有等待、交接和返工。一个资源在多个任务间被切分得越碎，任务切换成本越难被计划表显示，最终可能出现“每个人都忙，交付却没有变快”。

我会把缓冲看作风险控制，不是偷懒空间。对于变化频繁、依赖复杂或支持负担较高的团队，预留容量是为了应对波动；对于稳定重复、需求可预测的工作，缓冲可以更小。缓冲比例应依据历史波动和服务承诺逐步校准，而不是全公司一刀切。

2. 把工时记录当成个人绩效排名

当员工发现工时数据会直接用于横向排名，记录行为就会改变：难以量化的协作可能被少报，任务可能被拆得更细，投入也可能被向“容易证明价值”的工作倾斜。这不仅污染数据，还会损害跨团队协作。工时记录首先是容量和成本的管理信息，不天然等于贡献评价。

若组织需要评估绩效，应结合交付质量、目标达成、协作贡献、复杂度和岗位责任，不应把投入时长直接当作产出。负载指标可以帮助发现工作分配不均、关键角色过载或流程等待，却不能单独回答一个人是否表现优秀。

3. 把所有工作都换算成工时再相加

工程设计、客户支持、风险评审和创意探索的工作性质不同，估算精度也不同。把它们都换算成同样的小时数，容易让表格获得形式上的可比性，却丢掉了技能、风险和交付质量的差异。尤其是跨职能协作，单纯汇总人时无法揭示谁是瓶颈、哪个环节必须等待。

更稳妥的做法是两条线并行：一条用工时或人天做容量规划，一条用技能、角色和依赖表达资源约束。需要决策时，再结合工作价值、截止时间、风险暴露和替代能力，不用一个数字替代所有判断。

4. 把资源冲突交给会议现场临时裁决

没有事前规则的资源会议，很容易变成项目负责人争抢资源。谁准备得充分、表达得强势，谁就可能拿到更多支持；真正高价值但表达不擅长的工作则被延后。会议也会反复讨论同一冲突，因为没有记录“为何选择”和“被牺牲的承诺”。

会议的职责应是处理需要授权的例外，而不是从头收集所有人的工作。会前先生成冲突清单、影响范围、可替代方案和决策期限；会中只讨论跨项目取舍；会后记录责任人、调整项和复核日期。无法在既定权限内解决的问题，应有清楚的升级路径。

5. 把工具上线当作制度完成

工作管理平台能够帮助团队集中工作项、状态、依赖和报表，但工具不能自动决定哪些工作值得优先，也不能代替职能负责人承诺容量。若字段没有清晰定义、数据责任人不明确、管理会议仍靠临时口头信息，平台只会把原有混乱搬到线上。

我在设计落地路径时，会先验证规则和字段是否能支撑一次真实决策，再决定自动化范围。对中大型组织、尤其是百人以上团队，使用类似 PingCode 这样的工作管理平台，可以考虑将项目、需求、缺陷、迭代与资源视图关联；但具体能力、权限模型和数据集成情况需要结合组织实际评估，不能把产品选择当成治理方案本身。

四、专业判断逻辑：先识别约束，再决定怎么分配

1. 先分清容量、需求和约束

容量是组织能够提供的有效能力；需求是计划在周期内完成的工作；约束则包括技能、时间、地点、合规要求、依赖关系和不可替代角色。很多负载分析只比较需求总量与容量总量，却忽略约束。例如团队总计有 200 人天容量，并不代表能完成需要 20 人天稀缺安全评审的工作。

因此，资源计划至少要保留四种维度：人或角色、技能、时间窗口、工作类型。对共享关键角色，还应标注可替代人员和熟练程度。若技能只能由一人提供，负载风险不仅是“这个人太忙”，也包括请假、离职、突发支持或审批延迟造成的单点故障。

2. 给计划承诺设置成熟度等级

并非所有工作都处于同等确定程度。已批准、范围清晰、依赖确认的工作可以进入承诺计划；有明确目标但范围仍需澄清的工作适合进入预测池；只有想法、尚未排序的事项应留在候选池。把这几类工作混在同一张“已排期”表里，会让资源冲突看起来比实际更严重，也让管理者误以为所有事项都已做出承诺。

成熟度不是给工作贴标签，而是保护组织免于过早承诺。若管理层要求候选事项也提供精确日期，PMO应明确展示假设条件和置信范围，而不是为了满足报表而虚构精度。

3. 用优先级规则处理跨项目取舍

优先级不应仅由“紧急”决定。可采用分层判断：法规与安全类义务、已批准的战略承诺、明确的客户或运营风险、经比较后的增值工作、可延期的内部改进。具体顺序要由组织治理层确认，PMO负责把规则变成透明流程，而不是自行决定所有项目的价值。

当两项工作争抢同一资源时，我会要求负责人提供最小决策信息：不做的后果、最晚决策日期、替代资源、可拆分范围、延期影响和预计容量消耗。没有这些信息，会议只能比较立场；有了这些信息，管理者才有可能比较代价。

4. 把负载阈值做成预警，不做成硬性配额

阈值应触发检查，而不是机械判罚。举例来说，连续多个周期预测负载明显高于团队设定的安全区间，可以触发容量评审；某项稀缺技能的未来档期被多个已批准工作占用，可以触发组合层决策；实际投入长期偏离计划，则检查工作类型、等待和估算口径。

阈值设置需要经过历史数据校准。组织可以先用六至八个周期观察需求波动、延期原因和预测误差，再确定适合的预警区间。缺少历史数据时，采用“建议基准”进行试运行，并明确其为暂定规则，不应把示意比例包装成普适行业标准。

5. 把需求变更与资源变更联动

需求新增或范围扩大时，资源计划必须同步调整。可选动作通常只有几类：增加容量、延后其他工作、缩小范围、改变交付顺序、接受风险。若变更流程只记录需求本身，不记录它挤占了什么工作，组织就会形成“新增不取消”的隐性规则，负载过高会成为常态。

我建议设置一个简单的变更问题：这项工作进入后，原有计划中哪项工作因此变化？如果没有明确答案，变更尚未完成资源评估。对小型、低风险的变更可授权项目负责人在预设缓冲内处理；对跨项目或影响外部承诺的变更，则升级到资源或组合层。

五、制度与模板：让工作负载可以被执行和复盘

1. 制度设计的最小闭环

制度文件不必一开始写成几十页。最小闭环应覆盖：适用范围、工作分类、容量口径、计划周期、优先级权限、冲突处理、变更记录、复盘指标和数据责任。缺少其中任一环节，都可能导致计划无法执行或问题无法追责。

下面的模板可以作为 PMO 的起点。字段应按照真实决策删减，不建议不加判断地全部搬进系统。尤其是“实际工时”是否需要细粒度填报，应先评估管理用途、团队成本和数据质量，再确定频率。

2. 模板一：资源需求登记表

3. 模板二：周期容量与负载视图

周期视图建议至少按团队、角色和技能进行汇总，同时保留到具体工作项的下钻路径。不要只给管理者看一个红黄绿格子；每个预警都应能追溯到哪些承诺、估算假设、依赖和变更造成了占用。

表中数字是制度设计的模拟示例，不代表任何组织的真实经营数据。示例中的负载率包含支持与运营预留，组织应在模板说明中写清计算方式，否则不同团队即使使用同一张表，仍可能得出不可比较的结果。

4. 模板三：资源冲突决策记录

资源冲突记录的重点不是“谁赢了”，而是记录决策依据和被影响的承诺。建议保留以下字段：冲突编号、涉及工作、冲突角色与时间、备选方案、价值与风险说明、决策结论、责任人、被调整工作、通知对象和复核日期。未来复盘时，才能判断当时的取舍是否合理。

一条合格记录可以这样写：由于同一位安全评审人员在第六周被两个已批准交付占用，组合负责人决定优先支持法规截止期更近的事项；另一项工作拆分为准备阶段与正式评审阶段，正式评审顺延一周；项目负责人需在本周确认范围变化，PMO在下次滚动计划中复核影响。它比“已协调，请相关方配合”更可执行。

5. 模板四：月度负载复盘

复盘不应只看实际投入比计划多或少。建议围绕四个问题开展：预测偏差来自估算、范围、依赖还是临时工作；哪些角色反复成为瓶颈；哪些工作进入后没有明确挤出项；哪些容量预留被用掉、哪些长期闲置。每个问题都要落到一项规则调整或验证任务，而不是停在“加强沟通”。

为避免复盘变成追责会，可以将指标按团队和工作类型聚合，优先讨论系统性模式。只有在确认数据完整、工作复杂度可比较、影响因素已区分之后，才进一步讨论个人或项目层面的特殊情况。

六、案例推演：从“每个人都很忙”到可解释的资源决策

1. 案例背景与数据边界

以下案例为匿名化的情景推演，用于演示制度如何运作，不代表真实客户或任何特定组织的业绩数据。设想一家具备研发、测试、产品和业务支持团队的企业，约 180 名员工，四个项目并行推进。业务负责人普遍认为团队“人手不足”，但过去没有统一记录临时支持、跨项目评审和需求变更。

试运行前的容量表把所有已提出需求都算作计划工作，未区分候选与承诺；同一名架构师被两个项目各自排入关键路径；线上支持占用没有独立类别。结果是计划表显示接近满载，项目经理仍不断提交“紧急资源申请”，管理层无法判断应新增人员还是减少承诺。

2. 先不增编，先做四周基线观察

PMO没有先给每个人增加填报义务，而是抽取四周现有任务与支持记录，将工作归并为交付、运行支持、协作管理、返工等待四类。对缺少记录的时间不做强行推算，而是单独标记为数据缺口。与此同时，负责人确认哪些事项已批准、哪些只是候选，避免把所有需求都压到正式容量上。

模拟基线结果显示：表面计划负载率为 97%；把候选需求移出承诺池后，承诺负载率降到 84%；另有约 14% 的已记录投入属于支持与运行工作。关键岗位冲突集中在架构评审和测试验收，而不是所有角色都普遍短缺。数字均为案例推演值，作用是展示如何从总量判断转向结构判断。

3. 再按关键角色和时间窗解决冲突

基线之后，团队没有把剩余容量简单平均分给四个项目，而是按法规时限、客户影响、战略目标和可替代性进行排序。架构评审拆成预审与正式评审两个阶段，预审由备份人员承担；测试团队把可并行的验证任务提前，避免所有工作挤在同一个发布周；运行支持则按值守轮换预留容量。

这类调整的价值不在于把一个人“压榨得更满”，而在于减少不可替代角色的排队，并把可以提前或拆分的工作从瓶颈档期移开。若替代人员缺乏必要能力，不能为了让表格变绿就强行分配，应通过结对、审查清单或阶段性培训降低单点风险。

4. 用结果指标验证制度，而不是只报负载下降

试运行八周后，案例团队比较了承诺兑现、冲突处理时长、临时插单占比和关键技能备份情况。模拟观察结果为：承诺兑现率由 68% 提升到 82%；跨项目冲突从平均每周 9 起降到 4 起；资源冲突从提出到决策的中位时间由 6 个工作日缩短到 2 个工作日；支持工作仍占有效投入约 13%，但已纳入计划。

这些数字不能证明制度本身是唯一原因。期间若项目范围、人员结构或交付周期同时改变，结果也会受到影响。因此复盘应保留比较口径和同期变化，并将成效表述为“与制度试运行同时观察到的变化”，而不是未经验证地声称某规则直接带来全部提升。

5. 案例中的关键判断

这个推演最值得借鉴的结论不是“把负载降到某个比例”，而是先把候选需求、正式承诺和持续支持分开。若直接根据 97% 的表面负载申请增员，组织可能误判短缺范围；若仅将数字压到较低水平，又可能把真实支持工作隐藏起来。拆分之后，管理者才能判断是总容量不足、技能分布不匹配，还是计划成熟度和优先级治理有问题。

七、工具、数据与落地：让系统支持规则，而不是替代规则

1. 先做决策地图，再配置工具字段

工具实施前，我会把常见决策列成清单：谁确认工作成熟度，谁维护有效容量，谁审批跨项目优先级，谁能接受范围变更，谁处理异常负载。随后为每项决策确认所需信息、数据来源和更新责任。这样做可以避免先创建几十个字段，最后却没有任何管理动作与字段对应。

对已经使用工作管理平台的组织，可以先检查是否能够关联工作项、负责人、团队、时间窗口、优先级、估算、依赖和状态。若容量计划需要与工时或财务系统衔接，还要明确主数据来源及同步频率。系统间数据不同步时，应先处理身份、组织架构和工作编号的映射问题，不要用人工反复复制来掩盖集成缺口。

2. 选择自动化的边界

适合自动化的通常是重复、规则明确的工作：容量汇总、重复冲突提示、逾期提醒、变更记录、周期趋势和权限控制。需要人做判断的通常是价值取舍、风险接受、技能替代、范围缩减和策略优先级。把前一类工作自动化，能减少 PMO 汇总成本；把后一类强行交给算法，容易制造无法解释的“系统分配结果”。

对于百人以上、跨项目协作较多的组织，平台化管理往往比多份独立表格更有利于维持数据关联和审计轨迹。以 PingCode 这类面向中大型团队的工作管理平台为例，评估时应重点验证：工作项与项目组合视图能否衔接、角色权限是否适配组织层级、数据能否导出或集成、不同团队的流程是否支持必要差异，以及维护成本是否可接受。是否适合，仍要以实际演示和试点结果为准。

3. 先做小范围试点，再扩展到全组织

试点对象宜选一组跨项目协作明显、负责人愿意参与、工作类型相对可识别的团队。试点周期建议覆盖至少数个完整计划周期，确保能看到计划、执行、变更和复盘，而不是只看到一次启动会议。试点前要明确成功标准，例如冲突决策时间、承诺兑现率、临时工作可见性和数据维护成本。

扩展前要检查三个条件：字段是否过多、规则是否被不同团队误解、例外是否需要更高层授权。如果试点中大量工作都靠 PMO 手动修正，说明数据责任或系统集成有问题；如果管理者不依据报告做取舍，说明治理权力没有落实。此时扩大部署只会扩大摩擦。

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

1. 组织规模较小、项目数量有限

小团队可以先用轻量表格和固定周会，不必马上引入复杂的资源管理系统。优先统一工作分类、人员可用时间、承诺成熟度和插单记录。若负责人彼此沟通顺畅，且冲突能在短时间内解决，制度应保持简单，避免为了“规范”增加大量填报成本。

取舍是可视化和审计能力较弱，跨部门扩张时容易出现版本不一致。建议保留唯一数据源、明确表格维护人，并每月抽查一轮计划与实际差异。一旦工作项、团队或项目数量增长到人工汇总难以稳定维护，再评估平台化。

2. 中大型组织、多个项目共享关键角色

这类组织应优先建立组合层容量视图、技能目录、跨项目冲突规则和授权矩阵。计划不能只按部门报总人天，还要展示稀缺技能在周期内的实际占用。对无法替代的角色，制定备份培养、评审轮值或外部支持方案；对长期出现的冲突，评估是否应调整项目组合，而不是不断临时加班。

取舍是治理成本更高，统一口径也可能与业务差异发生摩擦。不要为了完全一致而抹平团队的工作特点，可以统一定义和决策边界，同时允许不同团队采用适合的估算粒度。系统权限和流程配置要服务治理，而不是让所有团队都被迫走同一条僵硬路径。

3. 需求高度不确定、探索工作占比高

探索型工作不适合过早承诺精确工时和日期。可以使用容量区间、阶段性目标和假设清单，将资源分配到探索阶段、验证阶段和正式交付阶段。每个阶段结束后再根据证据决定继续、调整或停止。这样既保留探索空间，也避免未验证的想法长期占用确定性交付容量。

取舍是短期预测精度较低，管理层可能不习惯区间表达。PMO应展示不同情景下的容量影响，而不是伪造单一日期。例如说明“若外部接口按时提供，预计在某窗口完成；若延迟超过一周，则需要顺延验收或缩小范围”，让不确定性成为可讨论的条件。

4. 支持与运维工作频繁

对支持工作不应要求每一条小问题都走完整立项流程。可建立支持池、值守计划、优先级分级和升级阈值。低风险请求按服务规则处理；高影响事件触发快速响应；当支持池持续超出预留容量时，必须由业务和技术负责人共同判断是否降低服务承诺、增加轮值或改善根因。

取舍是支持池可能成为“看不见的黑箱”。应保留足够的分类信息，例如故障、咨询、权限、数据修复和重复问题；定期识别重复来源。若只记录总支持工时，无法发现哪些产品缺陷或流程问题持续消耗团队容量。

5. 资源确实不足，且短缺持续存在

增员应建立在持续性证据上，而不是某个高峰期的抱怨。至少检查几个周期的需求趋势、承诺兑现情况、加班与外包成本、关键技能利用情况、可替代性和项目组合优先级。如果需求长期超过有效容量，且范围优化、排期调整和流程改进都不足以覆盖，才有较充分的增员依据。

取舍是招聘有周期和固定成本，新增人员也需要培训、管理和协作容量。若短缺只集中在一种稀缺技能，招聘、外部顾问、培训备份人员或重新设计工作包可能比普遍扩编更合适。反过来，如果团队持续靠加班维持承诺，延迟增员也会积累质量和人员流失风险。

6. 管理层要求快速提升“资源利用率”

遇到这种要求，我会先追问目标指向的是成本、交付速度、人员闲置、客户响应，还是项目组合价值。不同目标对应不同动作。若只是提高工时填报率，可能改善数据完整性，却不一定改善效率；若追求交付周期缩短，减少并行工作和瓶颈排队可能比增加每个人任务数量更有效。

取舍是任何一项效率改善都可能改变其他指标。压缩缓冲可能提高短期排期密度，却增加延期风险；减少支持容量可能释放项目人天，却降低服务质量；增加并行项目可能提高表面资源利用，却延长每项工作的完成时间。PMO应把这些副作用明确摆出来，让管理层选择愿意承担的风险。

九、结尾：下一步先做一次负载口径体检

1. 用四周观察找到制度的第一处断点

资源负载制度最容易失败的地方，通常不是计算公式，而是组织不愿意把取舍写清楚：新增工作进来了，旧承诺没有被取消；关键角色被重复占用，却没人拥有最终裁决权；支持工作持续发生，却没有容量位置。只要这些问题还在，报表越精细，管理者可能越容易被错误的确定感误导。

我建议 PMO 下一步先做一轮四周口径体检：抽取一组跨项目团队，明确有效容量，区分候选、预测与承诺工作，单独呈现支持投入，并记录一次真实资源冲突的处理过程。随后只选一个制度改进点试运行，例如统一插单的“挤出项”记录，或为关键技能建立跨项目冲突升级机制。

负载效率的本质，是让组织在有限容量下持续兑现最重要的承诺，而不是让每个人看起来始终很忙。当容量、优先级、变更和责任能够被解释，PMO才真正从排表者转变为资源决策机制的设计者；而一张好用的负载表，应该让管理者更容易做取舍，而不是让团队更难说“不”。