资源平衡怎么做？产品经理制度设计：资源负载从0到1

资源平衡最容易被误解成“把每个人的工时填满”。我在产品团队做资源盘点时，见过一种看似高效的排期：每个人未来六周的负载都接近 100%，但版本连续延期，线上问题无人处理，需求优先级每天都在变。问题不在于团队不够忙，而在于计划把“可用工时”误当成“可交付能力”。资源平衡真正要解决的，是在需求不确定、人员能力不同、突发工作持续出现的情况下，明确哪些事能做、谁来做、做到什么程度，以及什么情况下必须让步。

一、先讲结论：资源平衡不是把人排满

1. 先平衡承诺，再平衡负载

我判断一个团队有没有资源管理问题，不先看每个人的工时表，而先看承诺是否可信。一个团队如果总是把所有需求都标成“本季度完成”，那即使任务分配看起来平均，也只是把不确定性藏进了计划。

资源平衡要先回答三个问题：本周期真正可用的能力是多少；哪些工作必须做、哪些工作可以延后；当容量不够时，由谁、按照什么规则决定取舍。只有先定清承诺边界，才有讨论个人负载的意义。

我的核心判断是：资源负载不是人力利用率，而是“已承诺工作对有效能力的占用程度”。有效能力需要扣掉休假、会议、支持工作、跨团队协作、学习和突发事件。把这些因素忽略掉，再精细的排期也只是精确地算错。

2. 不追求人人相同，追求系统有余量

不同岗位的工作形态并不相同。产品经理的需求澄清、研发的编码与评审、测试的回归与验收、设计师的并行支持，无法用同一种工时刻度直接比较。所谓公平，不是每个人都排 80%，而是负载依据工作性质校准，关键瓶颈不被长期压满，风险有人承担。

若一个团队长期把每个人排到 95% 以上，任何一个需求变更、线上故障或人员请假都会挤压计划。留出余量并非浪费，而是为波动付费。容量越不稳定，计划中的缓冲越应明确；但缓冲不应成为随意塞需求的空白格。

3. 资源平衡的最小闭环

从零开始不需要先采购复杂系统，也不需要建立一套庞大的审批制度。最小可行闭环只有四步：核算有效容量，按优先级形成需求队列，识别瓶颈与依赖，按固定节奏滚动复盘。闭环运行起来后，再逐步补充技能矩阵、情景模拟和跨项目调度。

这张表刻意没有把“把每个人排满”列为目标。资源管理要产出的是可执行的承诺和可调整的机制，不是漂亮的利用率数字。

二、为什么资源平衡会成为产品经理的制度问题

1. 需求进入速度往往快于交付能力

多数团队并不是没有计划，而是计划不断被新事情打断：销售带来客户承诺，运营提出活动需求，管理层追加战略事项，线上系统又出现故障。每件事单独看都合理，合起来却超过团队容量。

当需求入口没有统一规则，产品经理就会被迫充当“人工缓冲区”：在多个群里接收任务，再以个人判断调整优先级。短期看似灵活，长期会形成两个后果：一是需求来源强弱决定顺序，二是团队无法解释为什么某项工作被推迟。

制度设计的重点不是让所有人都走一条冗长流程，而是让需求以相同格式进入判断：目标是什么、影响谁、截止日期是否真实、依赖什么能力、延后成本是什么。入口标准一致，才能在资源不够时比较。

2. 团队容量不是人数乘以工作日

一个十人团队不等于十个人都能持续投入项目。有人承担线上值班，有人要参加客户访谈，有人是某个系统的唯一维护者；新员工也不一定能在本周期独立完成同等复杂度的工作。

我会把容量分成三层来看。第一层是名义容量，即人数、工作日和标准工时；第二层是有效容量，即扣除假期、固定职责和协作成本后的可用时间；第三层是可承诺容量，即考虑风险、技能匹配和依赖之后可以对外承诺的范围。

三层容量不能混为一谈。名义容量适合做上限估算，有效容量适合安排工作，可承诺容量才适合对业务方给出承诺。把后两层混在一起，团队会在每次计划会上重复争论“为什么明明有十个人却做不完”。

3. 产品经理负责机制，不该独自背负所有取舍

资源平衡经常被推给产品经理，因为产品经理最接近需求，也最容易看到冲突。但产品经理不一定拥有人员调配权、预算权或客户承诺权。若组织只要求产品经理“排好计划”，却不给其调整范围和升级冲突的路径，最后往往变成产品经理个人承受压力。

合理的分工是：业务负责人说明目标和不可变约束；产品经理整理需求价值、范围与依赖；技术和交付负责人估算能力与风险；团队负责人对人员冲突作最终决策。产品经理的职责是让冲突可见、让选择可比较，而不是替所有部门吞下超载。

4. 中大型组织需要把资源问题放到跨项目层面看

当项目只有一个，团队可以在日常沟通中解决大部分冲突；当多个项目共享同一批架构师、测试负责人或数据工程师，局部排期就容易互相矛盾。一个项目看似有足够资源，可能只是把另一个项目的关键人重复计算了。

以 PingCode 这类面向中大型企业及百人以上组织的项目管理平台为例，价值不应被理解为“多了一张排期表”。真正需要验证的是，它能否把需求、项目、人员、依赖和交付状态放在同一套协作视图中，帮助管理者识别共享资源的冲突。平台只是承载机制的工具，若优先级规则和责任边界没有建立，系统只会更快地展示混乱。

三、常见误区：看起来在管理资源，实际在制造噪声

1. 把利用率当成效率

高利用率容易汇报，也容易误导。一个人日历上排满任务，不代表任务都能按预期完成；相反，排满可能意味着没有时间处理评审、沟通和返工。尤其是知识型工作，工作的完成路径通常不是连续、可切割的流水线。

利用率可以作为诊断信号，但不宜作为单一绩效目标。一旦团队被要求持续提高利用率，成员就会倾向于把更多事项登记为“工作”，隐藏协作时间，或把未完成任务拆小后持续滚动。指标看起来变好，交付可信度却下降。

我的判断方式是同时看三个结果：承诺完成率、未计划工作占比、关键工作等待时间。若利用率上升而等待时间也上升，问题不是人不够忙，而是工作在系统中排队；若完成率下降、未计划工作增加，就该检查需求入口和应急容量。

2. 把工时估算当成确定事实

估算是决策输入，不是承诺本身。需求还没澄清、依赖还没验证时，一个精确到小时的数字并不比“约三天”更可靠。过早追求精度，常会诱发谈判：业务方把估算当成可以压缩的报价，团队则用更多缓冲保护自己。

我会要求估算附带假设。例如：“后端改造约五人天，前提是接口兼容现有数据结构；如需迁移历史数据，需重新评估。”这种表达把未知条件显露出来，也让后续偏差能回到假设变化上分析，而不是简单归咎于执行不力。

3. 把每个人平均分配到多个项目

“每人支持两个项目”听上去公平，但频繁切换会带来上下文恢复成本。一个工程师上午处理项目甲，下午参加项目乙评审，晚上再修项目丙的线上问题，表面上三个项目都获得了资源，实际每个项目都在等待重新进入状态。

对深度工作占比高的角色，我更愿意使用连续时间块或稳定小队，而不是把日历切成碎片。确实需要共享的专家，可采用固定窗口集中评审、明确响应时限、预留紧急支持额度等方法，减少随叫随到造成的隐性损耗。

4. 只看人天，不看技能和依赖

六个人天的设计工作不能简单分给六个任意成员。若任务依赖特定领域经验，容量要按匹配能力计算。某个岗位总体有空，并不意味着关键技能有空；资源表若只有姓名、项目和工时，就会漏掉这种约束。

依赖也会改变有效负载。设计尚未评审通过，前端开发即使有空也无法有效开始；接口未确定，测试用例只能反复修改。此时真正的瓶颈可能在决策等待，而不是执行人手不足。

5. 把突发工作当成例外，不为它留空间

如果每个周期都出现线上故障、客户升级或紧急合规要求，那它们就不再是意外，而是系统的一部分。预算里完全不留应急能力，团队只好靠加班和挤压已承诺工作处理，最终计划总是“被突发事件打断”。

留白要基于历史观察，而不是凭感觉。团队可以记录过去六至八个周期中未计划工作占比，按工作类别区分缺陷、客户支持、技术债和临时决策。若数据稀疏，先以区间估计并持续校准，不要把一个月的异常当成稳定规律。

四、专业判断逻辑：从“谁有空”转向“系统能交付什么”

1. 先统一负载的统计口径

资源管理失败，常常不是因为没有数据，而是不同人说的“负载”不是一回事。有人统计日历工时，有人统计任务估算，有人只统计项目工作，有人把会议和支持也算进去。口径不统一，任何比较都会引发争执。

一个可操作的周期口径是：负载率等于周期内已承诺工作量除以有效容量。有效容量按岗位或个人分别核算；工作量可以用人天、故事点或其他团队已稳定使用的单位，但同一张图里不要混用。若工作量估算可信度较低，应同时呈现区间或置信等级。

公式本身不复杂，难点在“已承诺工作”和“有效容量”的边界。建议将计划内项目工作、固定职责、支持值班、管理协作、培训和假期分开记录。不是要求每人填到分钟，而是能解释容量为何变化。

2. 先看关键岗位，再看平均值

团队平均负载率会掩盖瓶颈。例如，团队平均为 72%，但唯一的数据工程师已经排到 115%，两个项目又都依赖他完成上线前的数据核验。总体看起来有余量，实际交付仍会被一个岗位卡住。

我会先按角色和关键技能检查峰值，再看团队整体。重点关注不可替代性高、排队时间长、被多个项目共享的角色。平均值适合观察趋势，峰值和等待时间更适合发现具体阻塞。

3. 把需求价值与容量成本放到同一张决策桌上

优先级不能只由业务价值决定，也不能只由交付容易程度决定。高价值需求可能占用稀缺专家，低价值但合规必需的工作也可能有不可延期的时间约束。要把价值、紧迫性、风险、工作量、依赖和机会成本同时摆出来。

我不建议把所有因素硬塞进一个看似客观的总分。评分适合帮助排序，不适合代替讨论。对分数相近的需求，真正有用的问题通常是：延期一个周期会失去什么？谁承担这个成本？是否存在缩小范围的办法？是否可以先验证关键假设，再决定完整投入？

4. 区分需求优先级和资源优先级

需求优先级说明“组织希望先解决什么”；资源优先级说明“稀缺能力先被哪个工作占用”。二者经常不同。一个战略项目可能价值最高，但核心团队尚未准备好；一个客户缺陷价值范围较窄，却必须在规定时间内修复。

如果只维护一张按优先级排序的需求清单，团队容易误以为排序第一的事项就可以马上启动。实际还要检查能力匹配、依赖就绪和工作窗口。把“优先做”与“现在能做”分开，才能降低开工后等待和返工。

5. 用稳定节奏调度，不要随时重排

资源计划需要动态调整，但动态不等于每天重新洗牌。频繁调度会让成员无法形成连续工作时间，也会让项目负责人不再相信计划。可以设定固定的资源复核节奏，例如每周短检视、每个迭代正式调整、月度处理跨项目冲突。

只有出现明确触发条件时才临时升级：线上重大故障、法规期限变化、关键依赖失效、核心人员不可用、重大客户风险。触发之后，不是直接把新工作塞进旧计划，而是明确移出什么、延期什么、谁批准变更。

五、具体案例：一个产品团队怎样从口头排期走向可校准的负载管理

1. 先说明案例边界

下面是我用来解释制度设计的模拟案例，不是某家公司的真实经营数据，也不代表行业平均水平。设想一个 24 人的产品研发团队：产品 4 人、设计 3 人、研发 12 人、测试 4 人、交付协调 1 人；团队同时维护现有产品，并承担两个新业务项目。

团队过去采用各项目负责人单独排期。每个项目都按全部成员的工作日估算容量，人员重复被分配，会议与支持工作没有入账。管理层看到的计划完成率约为 60% 至 70%，但团队无法区分是估算偏差、临时工作还是依赖造成的延迟。

2. 先花两个周期建立基线

我不会在第一周就拿历史数据定责。旧记录口径不一致，直接比较会制造虚假精确。团队先连续两个周期记录三类数据：已承诺工作量、实际投入类别、任务等待或阻塞时间。记录重点是校准机制，不是评价个人忙不忙。

第一次盘点发现，名义人天中约有一部分被固定会议、客户支持和线上维护占用。研发端的未计划工作显著高于设计端，而测试工作集中在版本末尾，形成交付峰值。产品团队原来把这些差异统称为“项目有风险”，没有进一步拆解。

这里的关键动作不是立刻优化某个岗位，而是先建立可解释的分类：哪些是稳定职责，哪些是项目工作，哪些是未计划事件。只要分类一致，团队就能在之后判断应当减少需求、调整职责，还是补充能力。

3. 重新核算容量并发现真正的瓶颈

按模拟案例计算，团队每个四周周期的名义容量是 480 人天。扣除假期、固定职责与协作后，有效容量约为 360 人天；团队又根据前两个周期观察到的应急波动，把可承诺容量暂定为 315 人天。这是团队自己的情景基线，不应被理解成普遍适用的折扣比例。

把任务按技能而非只按项目汇总后，团队发现研发整体仍有容量，但数据工程和测试回归是瓶颈。前者由少数成员承担，后者集中在版本尾部。原来管理者认为团队“缺两名研发”，但实际优先问题是数据工作排队与测试窗口不合理。

4. 把需求队列改成“可选择的组合”

容量下降后，团队没有简单地把每个项目等比例砍掉，而是把工作重新分成三类：必须保障的稳定性与合规工作、与当前目标强相关的交付项、可以通过缩小范围验证的探索项。每项需求补充延后成本和关键依赖，再由业务与交付负责人共同确定组合。

其中一个项目原计划在周期内完成完整工作台。拆解后发现，真正需要验证的是核心用户能否在一个流程里完成任务；其他报表和配置功能可以后置。团队先保留主流程，推迟低频配置能力，并明确若试点数据没有达到预设条件，不启动后续扩展。

这种调整不等于产品团队自行降级需求。产品经理需要清楚地呈现取舍：保留什么、放弃什么、影响什么用户、何时复核。业务负责人确认目标变化，技术负责人确认实现边界，团队才对新范围重新承诺。

5. 将测试能力前移，减少周期末排队

测试工作原先主要在开发完成后集中进入，导致前期资源利用率看起来不高，临近发布却拥堵。团队把验收条件、风险点和关键路径测试提前到需求澄清阶段，研发提交可测版本后分批验证，减少所有工作挤在最后几天的峰值。

这不是把测试人员简单分散给每个项目，而是让测试工作按风险尽早介入。对变化频繁、影响面大的功能提前定义回归范围；对低风险改动保持轻量检查。如此安排可以减少末期排队，但也会增加前期沟通成本，因此应在高风险和多依赖项目上先试点。

6. 两到三个周期后看结果，而非只看排期是否漂亮

这个模拟案例的目标不是宣称某个数字提升，而是说明应如何验证调整是否有效。团队可以观察承诺完成率、关键任务等待时间、未计划工作占比、返工量、并行项目数和加班时长。若完成率提高，但未计划工作被隐瞒、加班显著上升，就不能认为制度成功。

建议先设定基线，再看变化方向和原因。比如连续三周期观察到等待时间下降、临时工作占比趋稳、交付承诺更少变更，才有理由认为资源规则开始产生作用。单个周期的偶然波动不足以证明机制有效。

六、从零到一的制度设计：先把规则做小，再逐步扩展

1. 第一步：定义工作入口与最低信息

所有需要占用团队能力的工作都要进入可追踪的入口，不必全部走同一套重流程，但最低信息应足以判断价值、时限、范围和依赖。口头需求可以快速登记，未登记的事项不能直接视为已承诺工作。

• 业务目标：希望改善的用户或经营结果是什么。
• 范围边界：本次必须交付什么，明确不包含什么。
• 时间约束：截止日期来自合同、法规、活动窗口，还是内部偏好。
• 依赖条件：需要哪些团队、系统、数据或决策先就绪。
• 风险与替代：若容量不足，能否缩小范围、分阶段或延后。

入口信息的作用不是要求需求方写长文档，而是让资源冲突能够被比较。尤其要区分“必须在某日完成”和“希望在某日完成”。如果所有日期都被标成绝对期限，优先级就失去意义。

2. 第二步：建立团队自己的容量基线

从过去的工作记录开始，按周或迭代观察计划工作、固定职责和未计划工作。样本不足时，先用保守区间，不要急着发布一个组织通用系数。不同团队、岗位和业务阶段的波动并不相同。

基线至少要说明统计周期、人员范围、工作量单位、是否包含会议与支持、异常情况如何处理。下一周期容量变动时，记录具体原因，例如人员休假、线上专项或监管任务，而不是简单把计划容量改成一个新数字。

3. 第三步：建立负载视图，但不要制造排名

第一张负载视图可以只有四类信息：人员或角色、有效容量、已承诺工作、关键依赖与风险。若组织尚未具备稳定工时数据，可先用相对区间标记，如低、中、高，并在周期复盘中校准。

不建议把负载视图用于“最忙员工榜”。排名会诱导人们争取更多工时登记，而不是减少排队和切换。管理者应关注的是系统瓶颈、冲突持续时间和工作流动性，而不是谁的数字最大。

4. 第四步：规定容量不足时谁有权做决定

制度要写明冲突升级路径。产品经理可以提出优先级建议，项目负责人解释交付影响，部门负责人决定人员重配，业务负责人承担目标和范围取舍。涉及多个业务线时，应有一个能做组合决策的责任人或会议机制。

若规则只写“由相关方协商”，实际上没有确定责任。协商可以形成选项，但必须有人在期限内做决定。否则团队会通过同时启动多个项目来回避冲突，最后把决策成本转嫁给执行成员。

5. 第五步：建立变更控制，不把计划变成僵化承诺

计划需要调整，但每次新增工作都应该带着对应的容量变化进入系统。新增一个高优先级事项时，至少要说清它挤掉什么、延期什么，或新增了什么能力。没有容量代价的变更只是隐藏成本。

可以采用简单的变更记录：变更内容、提出方、原因、影响项目、移出事项、批准人、复核日期。这样做不是为了追责，而是让组织理解承诺为什么变化。几个月后，这些记录会成为预测应急负载和改善需求入口的依据。

6. 第六步：每个周期复盘规则，而不是只复盘个人

周期复盘应问：哪些假设错了？哪些工作被反复打断？瓶颈是技能不足还是决策等待？工作是否过早并行？未计划事项来自哪里？下周期应该调整哪个规则？如果会议只讨论“谁没完成”，组织就失去了改进系统的机会。

建议把复盘控制在能行动的范围内，每周期选一至两个机制问题试验。例如减少同时开工项目数、固定共享专家答疑窗口、将高风险测试前移。一次改动过多，会让团队无法判断什么真正有效。

七、不同场景下的行动建议

1. 小团队：先用简单台账，不急着上复杂工具

十人以内、项目数量较少的团队，可以用一张共享表维护周期容量、已承诺工作、阻塞和负责人。关键是统一口径并每周短暂更新，不是追求完整的系统集成。

小团队通常沟通成本低，但单点依赖更严重。应优先标记唯一维护者、关键客户支持人和只有一人掌握的技能。即便暂时不能培养备份，也要把这类风险显式放进计划，而不是等到人员请假才发现无法继续。

2. 多项目共享人员：先做组合视图，再做项目内优化

若团队同时服务多个项目，第一步不是让每个项目负责人把计划排得更细，而是把共享角色放进同一视图。至少要看未来几个周期的占用峰值、依赖时间窗和冲突事项。

对于共享专家，可以采用集中服务窗口、评审批次、明确服务等级和固定容量池。不要让专家被多个项目无限制地即时打断。若共享需求长期超过容量，管理层必须在延后、缩小范围、替代方案或扩充能力之间做选择。

3. 需求波动大：把应急能力作为正式容量类别

客服、交易、运营和快速迭代产品的团队，突发事项可能占比较高。可以将应急容量单独分配，而不是让它隐形挤压项目工作。应急池使用后，记录来源、处理时长和被挤出的事项，定期判断哪些事件可通过产品改进或流程改造减少。

应急池不能无限扩大。如果连续几个周期大部分容量都被突发工作占用，团队需要判断是否进入了异常经营状态，或是否应该专门安排轮值和稳定性工作。持续用“临时”命名的工作，其实已经是稳定职责。

4. 业务优先级经常变化：设定冻结窗口和明确触发条件

当优先级频繁变化时，完全冻结计划不现实，但没有任何稳定窗口也不可持续。可以约定周期内的核心交付范围，允许特定级别的事件触发调整，其余新增事项进入下一次排序。

冻结窗口的价值是保护连续工作，不是拒绝变化。执行前应明确哪些事件可以打破窗口、谁有权确认、打破后哪些事项退出。没有退出机制的“紧急插单”，本质上就是要求团队超载。

5. 新团队或新业务：先用短周期验证，不套用成熟团队历史

新业务的需求和技术风险都较高，成熟产品的历史吞吐量未必适用。可先以较短周期完成探索、验证关键依赖，再逐步形成容量基线。计划重点放在假设、风险和决策节点，而非过早承诺精确日期。

尤其要把探索工作与交付工作区分开。探索可能产出验证结果或决策建议，不一定产出可上线功能。若把两者都按相同完成标准追踪，团队会被迫把不确定性伪装成确定排期。

6. 组织规模大：工具先服务于统一口径和跨项目透明度

人数超过百人、项目线并行且岗位共享明显时，人工维护多份表格容易出现重复分配和口径漂移。此时可评估项目管理平台，但选型应从管理问题反推能力要求，而不是先追求功能清单最长。

我会优先检查四件事：需求与项目是否能关联；人员和角色容量能否按统一口径呈现；跨项目依赖与变更是否可追踪；权限和组织结构是否适合实际管理边界。若数据无法持续更新，平台图表再丰富也只是历史截图。

八、取舍原则：资源不够时，明确损失比假装都能做更负责

1. 延期还是缩小范围

若核心价值可以通过更小范围验证，缩范围往往比整体延期更有信息价值；若关键流程必须完整闭环，强行切片可能造成不可用体验，则应考虑延期或分阶段交付。判断依据不是“哪个听起来更积极”，而是缩小后的版本是否仍能验证目标。

每次缩范围都要说明用户影响和后续条件。否则所谓最小版本会不断累积欠账，最后变成长期无法收敛的半成品。产品经理需要为删减范围建立退出条件，而不是只把任务移到下一期。

2. 加人还是减少并行工作

增加人员有适用边界。任务可以拆分、知识可以传递、加入时间来得及，新增成员才可能提高产出。若瓶颈是决策等待、共享专家或频繁变更，继续加人可能增加协调成本。

当多项目都处于半完成状态时，先减少并行工作通常值得尝试。完成已启动任务、释放关键角色，再启动下一项，往往比把更多人分散到所有项目更容易恢复交付流动。

3. 提高利用率还是保留缓冲

业务稳定、工作可预测、依赖少的阶段，可以适当提高计划负载；探索期、发布窗口密集、线上波动大的阶段，应保留更多缓冲。缓冲比例不应照搬其他企业，应该由本团队未计划工作、等待时间和承诺偏差共同校准。

如果管理层要求每个周期都达到某个固定利用率，团队需要解释该指标与交付结果之间是否有因果关系。资源平衡不能把所有波动都转成加班，也不能把每个空余时段都视作可追加需求的容量。

4. 建立专职团队还是共享服务

任务连续、领域知识重、响应速度要求高的业务，专职团队能减少切换和沟通成本；需求偶发、专业技能稀缺、跨项目总量较小的工作，共享服务更经济。判断时要计入等待成本，而不仅是人员成本。

共享模式如果没有服务窗口和优先级规则，会退化成“谁找得急谁先得到帮助”。专职模式若没有清晰的目标与工作边界，也可能形成局部资源富余、组织整体缺人的问题。两种模式都需要透明的容量和决策机制。

5. 用制度解决，还是用工具解决

如果团队连谁能批准需求插入、什么叫有效容量都没有共识，换工具不会自动消除争议。先用短期试运行把规则做清楚，再把稳定的数据结构固化到系统里，成本通常更低。

当重复计算、跨项目可视性、权限协作和历史追溯已经成为主要成本时，工具能显著降低维护负担。选型时要求供应商用真实工作流演示关键场景，并确认数据能否导出、角色和权限是否可配置、计划变更是否留痕。不要只看仪表盘是否好看。

九、结尾：下一步从一次容量复盘开始

1. 先做一个周期的真实盘点

资源平衡不是为了证明团队满负荷，而是为了让组织在容量不足时做出有依据的选择。产品经理最重要的工作不是替所有人安排时间，而是把需求、能力、依赖、风险和取舍摆在同一张桌面上。

如果团队现在还没有资源制度，下一步可以从一个周期开始：统一工作入口，记录有效容量和未计划工作，标记关键技能与等待，周期结束后复盘承诺偏差。先让团队看见真实工作流，再决定需要增加什么规则或工具。

2. 记住三个判断

• 满载不等于高效。持续满载会放大等待、切换和突发风险。
• 平均负载不等于没有瓶颈。共享技能和单点依赖决定了真实交付能力。
• 计划变化必须有容量代价。新增事项要对应移出、延期、缩范围或增加能力。

我对资源平衡的最终判断很简单：一套好制度，不是让每个人看起来都很忙，而是让团队能解释为什么现在做这些事、为什么暂时不做另一些事，以及出现变化时谁来承担选择的责任。从一次诚实的容量复盘开始，比从一张看起来精确的排期表开始，更接近真正的从零到一。