资源冲突管理指南：研发团队如何做好人力资源计划，流程优化全流程

研发团队最常见的资源冲突，不是“人不够”，而是同一个人同时被三个项目当作关键路径：产品认为他本周要完成新功能，交付团队认为他要处理客户问题，技术负责人又安排他修复架构缺陷。每个计划单独看都合理，合在一起却必然延期。资源冲突管理的关键因此不是把日历排满，而是让需求、能力、优先级和可用时间在同一套决策规则下对齐。

一、先讲核心结论：资源计划不是排人头，而是管理承诺

1. 计划的对象是有效产能，不是名义人数

假设一个研发小组有 10 人，不能直接得出“每周有 50 人天产能”。团队成员还要参加评审、处理线上问题、辅导新人、维护构建流水线，也会因休假或跨团队协作而无法投入项目。名义工时只是日历上的上限，真正能用于目标工作的时间才是可承诺产能。

我做资源规划时，会先把团队时间分成四类：路线图工作、运维与支持、组织协作、不可预见缓冲。前两类通常需要明确负责人，后两类则容易被计划忽略。若把所有时间都分配给项目，表面利用率很高，实际只是在把风险推迟到迭代中后段暴露。

核心判断是：资源计划的质量不看每个人是否排满，而看团队能否在承诺范围内完成最重要的工作，并且在变化发生时知道该牺牲什么。

2. 冲突要在承诺之前暴露，而不是在延期之后解释

资源冲突不是排期表上的红色重叠，而是多个工作同时要求同一项稀缺能力，且没有经过明确取舍。冲突可能发生在人员、技能、时间窗口、审批权限、测试环境、架构决策等多个层面。只看“谁空闲”，容易忽略“谁具备完成这项工作的能力”。

因此，成熟的计划流程至少要能回答四个问题：工作为什么要做、最晚什么时候完成、需要什么能力、如果资源不足要调整哪项承诺。若只有任务清单和负责人，没有这些信息，团队看到的只是忙碌程度，而不是可执行性。

3. 管理者要优化流动，而不是追求每个人满载

研发工作存在排队和切换成本。一个人同时做五项任务，不代表五项任务都会更快完成。工作越多，等待评审、补充上下文、重新进入问题的时间越长。与其让所有人都接近满负荷，不如限制并行工作，让关键工作更快流过设计、开发、测试和发布环节。

我更愿意把资源计划看成一个持续更新的承诺机制：先识别目标，再评估能力和约束，之后做取舍，执行期间根据实际吞吐调整。它不是一次排完、之后不许变化的静态表格。

二、背景和真实场景：冲突通常藏在跨项目依赖里

1. 为什么研发团队比普通排班更难规划

研发工作的估算存在不确定性。同样一个需求，前端页面可能两天完成，也可能因权限模型、接口兼容或历史数据问题扩大到两周。团队还会面对缺陷、线上告警、需求变化、合规检查和外部依赖。计划不是在已知工序上分配人手，而是在不完整信息下决定承诺边界。

另外，研发能力并非完全可互换。两名工程师人数相同，不代表可以互相替代：一个熟悉核心交易链路，另一个熟悉数据平台；一个有生产环境变更权限，另一个尚未完成授权。资源计划如果只看岗位和人数，就会把关键技能瓶颈误判成普通产能不足。

2. 一个典型的三项目争用场景

下面用一个明确标注为情景模拟的例子说明。某中大型企业有 120 人研发组织，平台团队中的两名资深工程师同时被三个项目申请：新业务上线需要身份认证改造，稳定性专项需要治理高频故障，数据项目则需要统一审计事件格式。

三个项目都把工作标为“高优先级”，并且各自给出了看似合理的时间要求。项目负责人只在项目内部排期，没有共享技能容量，也没有统一的优先级决策人。结果不是三项工作并行加速，而是评审、接口确认和代码合并都在等同一批人。

表中申请总量超过两名工程师的可用容量，而且三个项目都依赖资深技能。即便把工时加总后发现“总量差不多”，也不能说明计划可行，因为投入不是同质资源，且任务需要在特定顺序和时间窗口内完成。

3. 冲突常由三种隐性容量造成

• 专家容量：某类决策、代码审查或生产操作只能由少数人完成，形成单点瓶颈。
• 碎片容量：工程师每天被会议、临时咨询和故障处理切成小块，日历上有空档，实际难以完成连续性工作。
• 依赖容量：团队需要等待安全、数据、运维或外部供应方的响应，这些等待不一定体现在项目团队的人力表上。

只计算开发人员的投入，会低估这些约束。资源计划应把评审、测试、发布支持和跨团队依赖纳入工作流，否则项目看似有人，实际仍然堵在关键环节。

三、常见误区：看起来精细的计划，可能更容易失真

1. 把利用率当成团队效率

利用率回答的是“资源有多少时间被分配”，不是“价值交付得有多快”。若每个人都被安排到 100%，一项临时故障就会挤掉既定工作；一旦没有缓冲，任何估算偏差都会转化为加班或延期。

我不会把“每个人都有任务”当作排期质量指标。更值得追踪的是承诺完成率、交付周期、阻塞时间、返工比例和未计划工作占比。利用率可以帮助发现闲置或过载，却不能独立解释效率。

2. 用人数替代技能匹配

“这个项目还差两个人”往往是一个不完整的描述。真正需要确认的是：缺少哪类技能、需要投入多长时间、是否要求连续投入、能否拆分工作、是否可以通过辅导或自动化降低专家依赖。

把普通工程师临时加入一个高度依赖领域知识的项目，可能增加沟通和指导负担。此时名义人数增加了，关键专家反而要花更多时间解释背景，团队有效产能不一定上升。

3. 把所有高优先级都当成最高优先级

多个项目的负责人都有理由强调紧急，但“紧急”必须与业务影响、截止日期、延误成本和风险证据对应。如果每项都最高优先级，团队就失去了排序依据，最终只能由谁催得更频繁来决定资源。

我建议优先级由有权承担取舍的人统一确认，而不是让各项目自行标注。优先级不是标签，而是一个真实承诺：排在前面的工作得到稀缺资源，排在后面的工作接受相应的延期或范围调整。

4. 用固定比例假设每个人的可用时间

“开发时间占 80%”可以作为初步估计，不能当成普遍事实。支持团队、平台团队、业务迭代团队的中断模式不同；新员工、技术负责人、值班人员的时间结构也不同。使用固定比例而不校准，会让计划看起来一致，却持续偏离真实情况。

更稳妥的做法是用过去 6 至 12 周的数据观察团队容量：计划工作、未计划工作、支持投入、休假和等待时间分别是多少。不要用短期极端周代表长期基线，也不要把历史平均值直接等同于未来承诺。

5. 计划完成后不再更新

需求变化、人员缺勤、线上事故和依赖延迟都是研发常态。计划的价值不在于预测永远准确，而在于偏差出现时能尽早调整。若团队把排期视为不能修改的合同，实际变化会转入加班、隐性延期或质量债务。

一份有用的计划必须写明变更规则：什么情况可以由团队内部调整，什么情况需要项目负责人重新排序，什么情况需要管理层决定范围、成本或日期的取舍。

四、专业判断逻辑：先识别约束，再分配资源

1. 先定义工作边界和完成条件

资源规划的输入不应只有项目名称和期望日期。每项工作至少要有业务结果、范围边界、验收条件、关键依赖、风险等级和最晚决策时间。若范围尚未澄清，估算只能表达不确定性，不能包装成精确承诺。

我会把需求分成“可承诺”“待澄清”和“探索验证”三类。可承诺工作可以进入正式容量计划；待澄清工作只安排有限的分析投入；探索验证工作则要定义时间盒和退出条件，避免研究任务无限延展。

2. 建立技能供给与需求的匹配视图

团队层面的资源视图不需要变成复杂的人才档案，但要能看出关键能力是否只有一人掌握。可以按能力领域建立矩阵，例如熟悉、可独立承担、可审查、可培养等层级，并标注近期可用性和授权限制。

人数只是供给的一个切面。对关键能力还要判断需求是否可拆、是否必须由专家全程参与、能否通过标准化减少判断次数，以及培养替补需要多长时间。

3. 计算可承诺容量时显式处理缓冲

团队可以用一个简单的容量估算式建立讨论起点：可承诺工作量 = 团队可用工作时间 − 已知运营负担 − 组织协作负担 − 风险缓冲。这个公式不是精确预测器，而是防止把理论工时误当成项目产能的检查工具。

比如一个 8 人团队，未来两周共有 80 个工作日。若根据历史观察，支持和值班占 15%，固定会议和协作占 10%，休假占 5%，团队再保留 15% 的不确定性缓冲，计划中可承诺的工作就不应按 80 人天计算。实际比例要由团队数据校准，而不是照搬示例。

缓冲不等于闲置。它用于吸收波动，使关键承诺不必因每一次临时事件而全面失守。若连续多个周期都没有使用缓冲，可以再评估基线；若缓冲每次都被支持工作耗尽，则应治理支持负担，而不是直接取消缓冲。

4. 用工作流判断瓶颈，不只看个人负载

当工作在开发、评审、测试、发布之间排队时，瓶颈可能并不在编码人员。资源计划要记录工作进入每个阶段的数量、平均等待时间、阻塞原因和返工情况。否则管理者可能持续增加开发投入，却让测试或架构评审队列越来越长。

判断瓶颈时，我会连续观察几个迭代，而不是凭一次会议上的印象。若某阶段等待时间长期增长、在制品持续堆积，而前一阶段产出不减，优先动作应是疏通该阶段或降低上游并行量。

5. 把优先级变成可执行的取舍规则

当资源不足时，我会综合看业务价值、时间敏感性、延误成本、风险降低作用、依赖关系和完成概率。不能只按收入排序，也不能只看管理层关注度。某些稳定性或安全工作短期收入不明显，但延误会扩大事故风险；某些客户需求看起来紧急，却可能没有明确的使用承诺。

为了避免伪精确，可以用评分辅助比较，但评分不能替代讨论。若采用 1 至 5 分的尺度，应为每个分数写出证据和负责人，尤其要把“业务影响高”落到具体结果上。分数相近的事项，应由有决策权的人确认先后顺序。

6. 将依赖、风险和触发条件写入计划

只写“某功能两周完成”不足以支持管理。计划还要明确前置条件，例如接口协议确认、测试数据准备、合规评审完成，以及这些条件的责任人和最晚日期。依赖迟迟未满足时，团队才能及时启动替代方案，而不是在截止日前才发现工作无法推进。

风险要对应触发条件和行动。例如，若关键工程师连续三天被生产事件占用，则缩减某项范围或移动非关键里程碑；若外部接口在某日期前未确认，则启动模拟接口方案。没有触发条件的风险清单，往往只是会议纪要中的装饰。

五、流程优化全流程：从需求进入到复盘校准

1. 需求进入：建立统一入口与必要字段

资源计划失控，常常始于入口分散。电子邮件、即时消息、会议承诺和项目看板同时接收工作，导致团队无法判断真实需求量。先统一需求入口，再规定最少信息，比一开始采购复杂系统更重要。

建议每个资源申请至少包含：业务目标、期望日期、范围与验收标准、所需技能、预计投入区间、关键依赖、延误影响、申请人和决策人。信息不全的工作可以进入澄清队列，但不应自动占用正式承诺容量。

2. 需求分层：区分承诺、探索与维护

不同类型的工作不应混在一个优先级队列里。路线图功能、探索性验证、缺陷修复、稳定性治理和日常支持的风险与估算方式不同。分层后，团队能设置不同的容量规则，例如为支持工作建立轮值池，为探索工作设定时间盒，为高风险改造安排阶段评审。

分类不是为了增加行政负担，而是为了让不可预见工作有明确入口。没有分类的团队往往把支持工作称为“临时插单”，把技术债称为“有空再做”，最后所有工作都挤进同一条队列。

3. 容量评估：从团队历史而非理想状态出发

按角色和技能盘点未来周期的可用时间，扣除休假、值班、固定会议和已确认的运营任务。对于共享专家，要把评审、咨询和跨团队支持单独估算，否则这些工作会以碎片形式侵蚀项目计划。

团队可以用过去几个周期的实际完成量作为参考，但要先确认工作类型和团队组成具有可比性。若团队刚经历架构调整、人员更换或重大故障，仅用历史平均值可能会误导计划。此时应扩大估算区间，并降低承诺确定性。

4. 排序与分配：先保护关键路径，再安排并行量

资源分配的顺序应是先满足不可错过的时间窗口和关键路径，再安排业务价值高且依赖明确的工作，最后才填入低确定性、可延期的事项。每个阶段都要问：若这项工作进入计划，哪项工作会因此延后？如果没有答案，通常意味着团队尚未真正做出取舍。

对于专家资源，可以采用预约窗口或集中评审时段，减少随时打断。对于需要连续专注的工作，尽量安排成完整时间块，而不是每天分配一小时。日历上的碎片时间不应被简单相加成可用产能。

5. 执行监控：关注偏差原因，不只看红黄绿状态

每周检查工作状态时，至少区分范围变化、估算偏差、人员缺席、外部依赖、返工和未计划工作。若只问“进度是绿还是红”，团队可能把风险压到最后才报告。状态更新的目标是触发决策，而不是给项目贴颜色。

建议设置轻量级的偏差阈值。例如某关键工作预计完成时间变化超过一个周期，或未计划工作占用超过预留比例，就进入资源复核。阈值可以按团队历史校准，重点是让触发规则事先透明，而非出现问题后临时争论。

6. 复盘校准：把计划误差变成下周期输入

复盘不应只追问谁低估了工时。要把计划偏差拆成估算误差、范围变化、等待、返工、外部中断和能力不足等类别。不同原因对应不同改进：估算误差需要改善拆分和技术探索，等待需要治理依赖，反复返工则要检查验收标准和评审质量。

每个周期只选择少量最有影响的改进项，并明确负责人和验证指标。若每次复盘列出十几项行动却没有追踪，复盘就会变成情绪宣泄，而不是计划系统的校准机制。

六、工具与数据：让计划可见，但不要让工具替代决策

1. 先确定管理问题，再决定是否需要平台

如果团队只有少数项目，需求入口统一、容量表透明、每周复核稳定，用轻量表格也可能足够。若组织有多个事业部、共享专家、复杂审批和跨项目依赖，单靠个人维护表格很容易出现版本冲突、口径不一和权限边界不清。

工具能帮助集中记录工作、负责人、迭代、依赖和状态，也能减少重复汇总；但它无法替管理者决定哪个项目应该让路。若组织没有统一优先级机制，换用更复杂的软件，只会更快地产生一套更复杂的冲突报表。

2. 中大型组织可以怎样评估管理平台

对于 100 人以上的组织，评估平台时，我会优先看它能否支持组织结构、项目与团队视图、权限隔离、跨项目依赖、工作项流转、数据统计和历史追踪。更重要的是，资源数据能否基于一致定义更新，而不是依赖每个团队临时维护一套个人表格。

以 PingCode 为例，可以把它作为中大型研发组织评估工作管理与协作流程的平台候选，重点验证需求、项目、任务、协作和数据视图是否适配现有流程。不要因为功能清单完整就默认适合：应拿真实的跨项目争用场景做试点，检验共享人员、审批边界、历史数据迁移和管理口径。

试点时可以选择一个有明显共享依赖的团队，跑完需求进入、容量评估、优先级确认、执行复核和周期复盘。若平台只能展示任务，却无法回答“这个人为什么同时被三个项目占用”“谁有权调整承诺”“变更如何留痕”，则它尚未解决资源冲突的核心问题。

3. 建议跟踪的指标及其边界

• 承诺完成率：衡量计划项按约定范围完成的比例。不要把临时增加的工作偷偷计入原承诺。
• 未计划工作占比：反映支持、故障和插单对路线图容量的影响。必须统一工作分类口径。
• 阻塞等待时间：识别依赖和审批造成的排队。应按等待原因分层，而不是只看总平均值。
• 关键技能负载：识别专家集中度和单点风险。不能只用个人忙碌程度替代技能风险。
• 返工比例：帮助判断需求澄清、接口协同和质量门槛是否有效。
• 在制品数量：观察团队并行工作是否过多。数量上升通常需要结合周期时间和阻塞情况解释。

指标要服务于决策，而不是成为个人排名工具。若把利用率或完成任务数直接用于绩效比较，团队会倾向于拆小任务、隐藏支持工作或回避高不确定性事项，最终数据更漂亮，管理判断却更差。

七、具体案例推演：如何拆解三个项目的冲突

1. 先把“都很重要”改写成可比较的业务条件

回到前面的情景模拟。身份认证改造有固定上线窗口，稳定性专项有持续事故风险，审计事件统一则存在跨系统口径依赖。第一步不是询问谁能加班，而是把三个项目的业务影响、延误后果和可调整范围写清楚。

假设评审发现：认证改造必须在特定客户上线前完成最小范围；稳定性专项的高频故障可以先处理两个最高风险路径；审计事件项目尚未完成数据口径确认。此时三项工作并非都需要完整投入，可以通过缩小范围和拆阶段降低并发需求。

2. 把不可替代的专家时间集中在判断点

两名资深工程师不必承担所有实现工作。可以由专家负责架构边界、关键评审、风险检查和疑难问题，将标准化实现交给团队其他成员。前提是设计文档、接口契约和测试条件足够清楚，否则“下放实现”可能转变为更多的反复咨询。

同时，为生产变更和认证评审设置固定窗口，减少三个项目随时打断专家。窗口之外的紧急请求必须说明影响和升级人，这样才能把真正紧急的事项与普通催办区分开。

3. 做出有代价的排序，而不是假装没有冲突

一种可行的模拟方案是：先保障认证改造的最小上线范围；稳定性专项优先处理已确认高频且影响面大的故障；审计事件统一先安排短周期口径验证，暂不承诺全面改造日期。这样不是放弃后两项工作，而是让投入与当前确定性、风险和业务窗口相匹配。

这个方案仍有代价：审计项目整体完成日期后移，稳定性专项不会一次性治理所有风险。决策记录必须把代价、责任人和重新评估日期写清楚。管理透明的取舍，胜过用虚假的并行承诺掩盖容量缺口。

4. 用一个周期验证，而不是一次性重建全组织计划

方案实施后，先用一个迭代或一个月观察专家被打断次数、评审等待时间、项目阻塞天数和高风险故障变化。如果专家咨询时间下降，但返工上升，说明知识转移不足；如果项目承诺改善而生产风险恶化，说明稳定性容量保护不够。

资源优化不是把人从一个项目机械移到另一个项目，而是验证新的分配方式有没有改善整体结果。必要时重新调整范围、培养备份人员或增加自动化投入。

八、不同情况下的行动建议：不要用同一套方案处理所有团队

1. 小团队、项目数量少但经常插单

先建立统一入口和简单的工作分类，不必立即引入复杂的容量管理模型。每周固定一次需求排序，明确哪些工作可以中断当前计划，哪些只能进入下一周期。若插单持续增加，应设值班或支持轮值，避免整个团队同时被打断。

小团队的核心风险通常是单点技能和上下文切换。与其精确计算每个人的小时数，不如减少并行项目、给关键工作安排连续时间，并制定核心模块的备份培养计划。

2. 中大型、多项目共享人员的组织

建立跨项目的优先级决策机制和共享技能视图，明确团队负责人、项目负责人和业务决策人的权限边界。涉及跨部门资源调整时，要求提出方说明影响、所需能力、投入区间和可接受的延期后果。

当多个团队共同依赖同一平台能力时，按月或按季度做组合层面的容量复核，并在周期内进行轻量滚动更新。对组织级共享专家，应减少临时点名式分配，优先通过明确服务窗口、标准接口和平台化能力降低依赖。

3. 正处于快速增长或需求剧烈变化的团队

不要把季度路线图误当成固定合同。可以把计划拆成近期承诺、下一阶段候选和远期假设：近期细化到可执行工作，后续阶段保留范围和日期弹性。需求不确定越高，越需要短周期验证和阶段性决策。

此类团队还应增加探索容量，但要设置明确的时间盒和验证问题。探索工作若没有退出条件，很容易长期占用资深人员，却无法为后续资源决策提供证据。

4. 生产支持负担高、计划反复被事故打断的团队

先将支持工作从项目工作中识别出来，统计事故类型、处理时长、重复发生率和影响范围。建立轮值安排和升级流程，让非值班人员尽量保持专注。若支持需求长期超过缓冲，问题不是计划排得不够好，而是服务稳定性或支持容量需要治理。

还要区别偶发事件与系统性故障。偶发事件可由缓冲吸收；重复故障应进入治理计划，不能永久归为临时工作。若只增加值班人数而不降低故障复发，资源冲突会以更大的支持团队形式持续存在。

5. 团队技能结构不均、少数专家过载

短期可以通过专家集中评审、工作拆分和明确接口减少重复咨询；中期要安排结对、文档化和授权培训；长期则要把关键能力纳入架构和人员发展计划。培养替补需要真实投入，不能只在个人发展计划里写一句“提升能力”。

若业务时限不允许等待培养，应坦诚比较外部引入、内部借调、缩小范围和延期的成本。不同选择都要有代价说明，不能默认专家通过加班解决组织设计问题。

九、不同情况下的取舍：每一种优化都有边界

1. 提高利用率与保留缓冲的取舍

提高利用率能让短期排程看起来更饱满，适合工作稳定、任务重复且波动较小的场景。但在研发团队中，过度压缩缓冲会放大突发事件的影响。若计划工作重要性高、变更频率高，保留容量通常比追求满载更能保护交付。

缓冲也不是越多越好。若团队长期有大量未使用容量，同时需求队列清晰、工作持续流入，就应重新校准容量或补充高价值工作。判断关键是实际波动和等待，而不是把“留白”本身当成目标。

2. 专家集中处理与能力下放的取舍

集中专家处理短期复杂问题，决策速度通常更快，但会加剧单点依赖和排队。能力下放能提高组织韧性，却需要文档、辅导、审查和允许学习的时间。紧急关键路径可以短期集中，稳定性治理和长期平台工作则应持续降低专家瓶颈。

如果专家参与每个小决策，应检查是否可以通过标准、自动化测试、设计模板或明确授权减少参与次数。真正有效的能力建设，不只是让更多人“知道怎么做”，而是让更多人能在风险可控的边界内独立完成。

3. 固定计划与滚动计划的取舍

固定计划有利于外部协作和时间窗口管理，适用于范围明确、依赖稳定的工作；滚动计划更适合需求变化快、探索性强的工作。两者并不冲突：可以对近期承诺保持稳定，对远期范围定期重估。

过度频繁地重排，会让团队失去专注并削弱承诺可信度；长期不调整，又会让计划脱离现实。建议设定调整节奏和例外机制：一般事项在固定评审点重排，重大风险或关键机会则走明确的例外决策流程。

4. 购买管理平台与先优化流程的取舍

平台适用于跨团队可见性不足、数据重复、权限复杂、审计要求高或依赖关系难以追踪的组织；流程尚未统一时，先做最小流程定义通常更经济。工具的价值取决于数据能否持续更新、角色是否愿意使用，以及管理层是否根据数据做取舍。

试点应设清晰的成功条件，例如减少资源汇总时间、提高跨项目依赖可见性、降低重复录入或缩短阻塞发现周期。不要只比较功能清单，也不要把平台上线率当作流程改进的证明。

十、下一步怎么做：用四周建立可校准的资源机制

1. 第一周：看清需求和真实工作构成

整理当前所有已承诺、待澄清和未计划工作，补齐业务目标、负责人、所需技能和依赖。抽样查看过去几周时间投入，把支持、会议、评审和项目工作分开。此阶段不急于重排所有项目，先确认冲突在哪里。

2. 第二周：确认关键能力与容量边界

与团队负责人一起标记稀缺技能、单点授权和共享专家，按实际可用时间估算下一周期容量。对数据不确定的部分给出区间和假设，不要为了表格整齐而填入看似精确的数字。

3. 第三周：做一次有代价的优先级决策

选出最影响交付的几项冲突，由有决策权的人确认先后顺序、缩减范围或调整日期。会议结束时要能说清楚：本周期承诺什么、明确不承诺什么、风险触发后由谁决定下一步。

4. 第四周：复核结果并调整规则

观察计划完成率、未计划工作、阻塞时间、返工和专家打断情况，重点解释偏差原因。只保留能够指导动作的指标，并为下一周期调整容量基线、支持轮值或依赖流程。

如果组织准备使用管理平台，可以在这四周中选择一个共享资源明显的团队做试点。先验证流程是否跑通，再扩大范围；先统一字段和决策责任，再迁移复杂历史数据。

十一、结语：资源冲突管理的本质，是让组织为优先级负责

资源冲突不可能靠一张更精细的排期表彻底消失。研发工作有不确定性，关键技能有稀缺性，业务需求也会变化。真正能改善结果的，是让冲突提前可见，让优先级可以比较，让资源不足时的代价有人明确承担。

我最看重的不是某个周期预测得多准确，而是团队能否在变化出现后迅速回答三件事：现在的瓶颈是什么，哪些承诺需要调整，谁有权做这个取舍。做到这一步，资源计划才从“谁更忙”的统计，变成“组织如何更快交付重要结果”的管理机制。

下一步可以从一个共享技能最紧张的团队开始：盘点需求、核对真实容量、挑出一项必须延期或缩小范围的工作，再用一个周期验证调整是否降低等待和打断。先让冲突显性化，再谈扩编、平台化或组织重构。