资源冲突落地方案：项目负责人开展人力资源计划的制度设计案例解析

项目资源冲突真正失控，往往不是因为团队里“人不够”，而是因为两个项目都把同一位关键工程师写进了计划，却没有任何制度规定谁有权决定优先级、谁承担延期后果。围绕《资源冲突落地方案：项目负责人开展人力资源计划的制度设计案例解析》，我更关注的不是怎样把资源表做得更漂亮，而是怎样把需求、承诺、冲突、裁决和复盘连成一套可执行的机制。下文的案例为匿名化情景推演，不对应某一家企业的真实经营数据；其中的数值用于解释制度设计方法，不能当作行业统计结论。

一、先讲核心结论：资源计划不是排人头，而是建立承诺机制

1. 把“谁来做”改写成“谁在什么时间承诺多少产能”

我设计人力资源计划时，首先会把“这个项目需要一名后端工程师”改写成可核验的资源需求：需要什么能力、在哪些周投入、每周需要多少可用工时、需求的置信度是多少，以及该投入是否已经得到资源负责人确认。只写岗位名称，无法判断同一个人是否被重复承诺；只写总人天，又容易掩盖工作集中在关键路径上的事实。

有效的资源计划至少需要同时回答五个问题：工作由谁负责，工作需要什么技能，需求发生在哪段时间，投入占个人可用容量的比例是多少，需求由谁确认。排期不是承诺，只有经过资源责任人确认、进入统一容量视图的排期，才可以作为团队承诺。

2. 冲突处理必须有明确的决策权和升级时限

当两个项目争同一名员工时，项目负责人可以提出业务优先级和交付影响，但不应在缺少规则时私下争抢。资源责任人负责核实团队容量，项目组合或业务决策人负责比较组织级优先级，项目负责人负责更新范围、里程碑和风险。制度需要规定冲突由谁裁决、在多长时间内完成裁决，以及裁决后谁负责通知相关团队。

我通常建议把“发现冲突，核实事实，比较方案，作出裁决，更新基线”设计成一个短闭环。若冲突当天被发现，却等到例会才处理，造成的往往不是一天延误，而是工作被拆开、测试窗口错过、上下游团队空等的连锁成本。

3. 制度先解决稀缺资源，再解决全员精细排班

多数组织没有必要一开始就逐小时管理所有员工。对大量工作内容相对可替代的岗位，按团队和周管理容量就足够；对架构师、关键测试人员、数据专家、安全评审人员等稀缺角色，则需要细化到具体周次和关键节点。计划粒度应由资源稀缺性和替代成本决定，而不是由表格能填多细决定。

这一判断可以避免两个极端：一端是没有可核验信息，另一端是花大量时间维护看似精确、实际频繁过期的个人日历。制度设计的目标不是让计划永远不变，而是让变更被及时发现、被授权处理，并且留下影响记录。

二、背景和场景：为什么资源冲突总在项目开始后集中爆发

1. 多项目组织的资源需求往往错位，而非平均不足

一个团队可能在总体上有足够的人力，却仍然出现严重冲突。原因是项目需求集中在相同时间段、相同技能上：两个项目都要在月底完成架构评审，都需要同一位领域专家；或者多个项目把测试资源安排在版本冻结前，形成短期峰值。按全年总人天做预算，无法直接看出这种周级别的拥堵。

我会把资源需求拆成“岗位能力，时间窗口，可用容量”三维数据。举例来说，团队有六名研发人员，不代表任意一周都能提供六人周的有效产能。休假、支持工作、代码评审、线上值守、跨团队协作和既有承诺都会消耗容量。若不扣除这些因素，计划表上的满负荷只是算术上的满负荷，不是可靠的交付能力。

2. 典型情景：三个项目争用两类稀缺能力

以下采用一个中大型产品组织的情景推演：团队约有120人，正在推进客户交付、平台改造和合规升级三个项目。客户交付需要一名资深后端工程师连续投入四周；平台改造希望同一工程师在其中两周参与架构迁移；合规升级则需要安全专家在版本冻结前完成两轮评审。

三个项目的计划都经过各自负责人审核，但团队没有统一的资源确认机制。资深工程师在项目甲的排期表中被安排了80%投入，在项目乙的排期表中又被安排了50%；安全专家则被三个项目各自预订了评审时间。单看任何一张项目计划，安排似乎合理；放到组织层面，承诺合计已超过实际容量。

这种冲突不会自动在项目启动会上暴露。项目负责人倾向于先按目标日期建立计划，资源经理可能直到执行阶段才看到多项目需求；员工本人则可能同时接到不同管理者的优先指令。最终，组织把系统性问题变成了个人加班、临时协调和交付延期。

3. 计划缺口常隐藏在三个不同的时间尺度里

年度预算解决“长期有多少人”，季度规划解决“哪些能力需要投入”，周级计划解决“具体时段能否交付”。三种尺度缺一不可，但它们回答的问题不同。年度编制充足不代表当前冲刺有空闲，季度项目优先级也不能代替对下周关键资源的确认。

制度应明确每种时间尺度的责任人和更新频率。年度层面处理招聘、外包和能力建设；季度层面处理项目组合和关键岗位容量；周级层面处理冲突、休假、变更和实际投入偏差。把所有决策塞进同一张表，容易出现信息繁杂却没人拥有最终决策权的情况。

三、常见误区：看起来在管理资源，实际上只是在记录愿望

1. 把“已填入计划”误认为“已获得资源”

项目计划里出现某人的名字，只能证明项目负责人提出了需求，不能证明团队已承诺供给。若没有资源责任人的确认字段，也没有确认时间和投入比例，管理者就无法区分申请、暂定安排和正式承诺。这个差异在项目组合扩张时尤其重要，因为多个项目都可能把同一份“暂定安排”当作确定事实。

我会将需求状态拆成“草拟、待核实、已确认、发生冲突、待裁决、已撤销”几类，并规定状态转换条件。比如，“已确认”必须同时满足能力匹配、容量校验、时间窗明确和资源负责人确认；缺少任一条件，只能保持在待核实状态。

2. 用百分之百利用率证明团队高效

把每个人排到100%看起来减少了闲置，却会消灭处理突发任务和工作波动的空间。知识工作存在估算误差、沟通成本和不可预见事件；某位专家若在多个项目之间频繁切换，实际产出还会受到上下文切换影响。因此，满载率不是效率的同义词，更不是越高越好。

利用率指标适合用于观察整体趋势，不适合单独作为个人绩效考核依据。若团队的容量利用率长期接近满载，而承诺准时率下降、延期工作增加，问题通常不在于员工不努力，而在于计划没有为波动、维护和依赖留出空间。

3. 把冲突交给员工自行协调

让员工自行判断哪个项目更重要，相当于把组织级优先级决策转嫁给没有完整业务信息的人。员工可能选择声音更大、关系更近或时间要求更急的一方，短期看似解决了争论，长期却会形成不透明的资源分配规则。

员工可以提供任务切换成本、工作依赖和预计影响，但最终优先级应由具备授权的管理者决定。否则，员工既承担协调压力，又可能在项目延期后成为责任归属的焦点，这既不公平，也难以复制。

4. 把资源冲突全部交给项目负责人处理

项目负责人有责任识别和报告冲突，但往往无权重新分配其他团队的工作，也未必能比较不同项目的战略价值。若要求项目负责人独自解决所有冲突，结果通常是反复沟通、不断升级，或者以临时加班掩盖容量不足。

有效制度应区分提出问题、核实数据、作出裁决和执行调整四种责任。职责分离不是推诿，而是确保决定由掌握相应信息和授权的人作出，并留下可追溯依据。

5. 用临时加班代替重新评估范围

加班可以处理短期、偶发且有明确结束时间的峰值，不应该成为常态容量的组成部分。若关键人员连续数周被安排超出正常投入，组织实际上是在透支未来的交付能力；质量、返工、离职风险和维护积压都可能在之后显现。

当资源冲突持续超过一个计划周期，管理者应比较调整范围、拆分交付、延后里程碑、临时增加资源和取消低优先级工作等方案，而不是默认让原团队吸收全部压力。

四、专业判断逻辑：用一套可复核的规则决定资源分配

1. 先核实需求质量，再讨论优先级

资源冲突会议中，我不会先问“哪个项目更重要”，而会先检查需求是否足够完整。若一个项目只说“下周需要专家支持”，另一个项目能提供具体任务、时间窗口、交付依赖和替代方案，二者并不具备直接比较的条件。需求不完整时，应先补齐信息，而不是让决策人凭声音大小裁决。

一条合格的资源申请至少包含：目标成果、所需能力、投入时段、预估工时、工作依赖、最迟决策时间、未获资源时的影响、可接受的替代方案。对无法准确估算的探索型工作，可以提供区间和置信度，例如“预计16至24小时，当前估算可信度中等”，比伪精确的20小时更诚实。

2. 区分硬约束、软偏好和可交换条件

硬约束包括法规或安全审查窗口、合同承诺、外部依赖截止日期、只有特定资质人员才能执行的工作。软偏好包括项目团队希望固定由某人完成、为了沟通方便而选择的时间、可以通过拆分或替换消化的安排。资源裁决应先尊重硬约束，再比较软偏好和组织价值。

我会要求项目负责人明确哪些条件不可变、哪些条件可以调整。若“某专家必须亲自完成全部工作”其实只是熟悉度偏好，就应检查是否可以让专家做设计评审、由其他成员执行；若必须由认证人员签署，则应把签署能力视为真正的硬约束。

3. 用多因素评分辅助讨论，不把分数伪装成自动决策

可以采用一个简洁的裁决框架，把战略重要性、外部承诺、延期损失、风险降低价值、资源稀缺程度和可替代性纳入讨论。评分的用途是暴露分歧，而不是让表格代替管理判断。不同因素应由对应的业务负责人提供证据，分数变化也要记录理由。

例如，战略重要性和外部承诺可以各按1至5分评分；延期损失可用收入、罚则、客户影响或关键路径延误说明；可替代性则要判断能否换人、换时间、拆任务或调整范围。对无法量化的因素，写明定性证据，不要为了整齐强行转换成看似精确的金额。

4. 让裁决规则与风险等级匹配

低风险冲突可以由资源负责人和项目负责人协商，在规定时限内完成调整；影响多个项目关键路径、客户承诺或合规节点的冲突，应升级到项目组合或业务负责人。升级不是“把问题往上推”，而是因为高影响决策需要更完整的组织视角和相应授权。

我建议制度明确升级触发条件，例如同一岗位容量超出核准值、冲突影响关键里程碑、延期可能突破合同窗口、方案需要跨部门调人，或冲突在一个工作日内未能解决。触发条件应少而清晰，既避免小事层层审批，也避免重大风险留在项目组内部。

5. 记录决策理由，而不只记录最终排期

只保存“谁做什么”无法支持后续复盘。还要记录当时有哪些替代方案、为什么未采用、哪些项目承担了延期或范围调整，以及重新评估的条件。这样，当外部依赖变化或资源释放时，组织可以快速重新排布，而不是重新争论整个问题。

复盘时我重点观察两类偏差：一类是需求预测偏差，例如实际投入比申请高出很多；另一类是决策执行偏差，例如裁决后仍发生未经批准的优先级切换。前者需要改善估算和任务拆分，后者需要加强治理与执行透明度，两种问题不应混为一谈。

五、制度设计案例：从冲突登记到复盘的完整闭环

1. 先建立统一的资源需求字段

在情景推演中，我会让三个项目都使用同一组核心字段，而不是让各自维护格式不同的表格。最小可用字段包括项目名称、任务或成果、所需技能、责任人或候选人、需求周次、预计工时、需求状态、资源确认人、优先级依据、风险说明和最近更新时间。

关键不是字段越多越好，而是要能够分辨申请和承诺、看见时间冲突、追踪决策责任。若一线团队填表负担过重，可以把项目背景、成果定义等信息从项目系统关联过来，避免重复录入；但能力、时间和确认状态必须能够直接检索。

2. 设定需求提交、确认和锁定的时间边界

制度可以规定项目负责人在滚动计划窗口开始前提交需求，资源负责人在固定时限内核实容量，重大冲突进入专项裁决。比如，组织按周规划时，可采用未来六周滚动预测、前两周相对锁定的方式：远期需求允许调整，近期开工承诺需要经过明确变更流程。

这里的“锁定”不是禁止变化，而是让变化有成本意识。若项目在锁定窗口内要求新增工作，应说明新增价值、所需容量和被挤出的原承诺；若只是把任务改名或拆分，不能借此绕开审批。没有替代方案的临时插单，应由提出插单的业务责任人承担优先级决策责任。

3. 为冲突设定响应时限与升级条件

为了避免冲突一直悬而未决，可以采用内部服务时限作为制度建议，而非行业标准：普通冲突在两个工作日内完成核实，影响近期关键路径的冲突在一个工作日内给出临时方案；需要跨项目裁决的事项在约定的管理会议或授权渠道内决定。组织应根据自身决策节奏调整这些时限。

如果在时限内没有完成裁决，默认动作不应是项目团队继续按照原计划消耗未确认资源。更稳妥的处理是标记计划为“有条件”，冻结新增承诺，升级给指定责任人，并明确潜在日期或范围影响。这样做可能让风险更早出现在项目看板上，但比晚期突然延期更可控。

4. 让制度进入日常项目工作流

制度如果只有文档，没有进入项目负责人的日常流程，很快会变成额外表格。一个可执行的工作流应当在立项、阶段计划、迭代规划和变更评审中重复使用相同的资源字段；资源确认的结果能回到项目里程碑、风险登记和团队任务分配中。

对中大型企业及100人以上的组织来说，项目数量、团队边界和跨部门依赖通常会增加人工汇总难度。可以评估使用项目管理平台，例如PingCode，来集中呈现项目计划、责任人、时间安排和风险状态；但工具本身不会替代资源制度。真正需要先明确的是字段定义、权限规则、状态流转和裁决责任，再决定哪些环节适合系统化。

5. 用匿名情景推演验证制度是否可运行

回到前述三个项目，资源负责人核实后发现，资深后端工程师在未来两周可投入的项目容量为每周32小时，而非理论上的40小时；客户交付要求32小时，平台改造要求20小时，合计52小时。安全专家未来一周可用于项目评审的容量为24小时，三项目合计需求36小时。冲突因此从“谁先开口”变成了两组明确的容量缺口。

项目组合负责人随后要求客户交付列出关键路径工作，并确认其中哪些必须由资深工程师亲自完成。评估后，团队把可由中级工程师完成的接口适配转交给另一名成员，资深工程师投入客户交付24小时、平台改造8小时；平台迁移中的非关键模块顺延一周。安全评审则按照外部交付窗口和风险等级排序，先完成高风险变更评审，低风险文档检查改由安全专家异步抽查。

这个推演的重点不是某个具体分配比例，而是每一项调整都说明了代价：谁的工作被替代，谁的里程碑顺延，哪个风险因此增加，何时重新评估。若只宣布“优先支持客户项目”，平台改造团队仍不知道应如何调整，也无法准确说明对后续版本的影响。

6. 用工具支持可见性，而不是追求工具代替判断

资源管理工具至少应支持需求录入、角色与人员能力关联、时间段容量视图、冲突提示、审批或确认记录、变更历史和报表导出。若组织已有项目系统，应先验证这些能力是否能覆盖实际工作流；若数据分散在多个系统，可以先统一关键字段和数据责任，再评估集成方案。

工具上线的判断标准不是“有没有资源甘特图”，而是项目负责人是否能看见承诺状态、资源负责人是否能核实容量、管理者是否能追溯裁决依据。若系统只把多个项目表格汇总到一张图，却没有确认责任和变更流程，冲突会更容易被看见，但不一定更容易被解决。

六、不同情况下的行动建议：把制度落到项目负责人的具体动作

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

小团队不必从复杂审批开始。先维护一张共享的周容量表，明确每个成员的固定职责、已承诺项目和剩余容量；每周用短会处理新增需求和冲突。负责人需要确保所有项目使用同一份表，而不是各自复制一份后各自更新。

当某个关键岗位在未来两周出现超额需求时，暂停把该人员加入新计划，先让相关负责人确定调整方案。对于临时口头需求，也要求至少在共享记录中补充申请人、时间段和影响，避免口头承诺成为看不见的第二套排期。

2. 多部门并行、项目组合较复杂时

项目数量增加后，单靠项目负责人彼此协调很难保持稳定。应建立跨项目的资源核验机制，按固定频率审查稀缺岗位未来数周的容量、关键里程碑和风险。组织还需要指定能跨部门比较业务优先级的决策人，避免各部门经理只优化本部门的局部目标。

这时应按能力类别管理资源，而不是只按部门人数汇总。团队可以统计资深后端、安全评审、数据建模等关键能力在不同周次的需求峰值，再决定调整项目窗口、培养替补人员或购买外部能力。长期冲突反复出现在同一岗位时，它通常已经不是排期问题，而是能力供给或组织设计问题。

3. 需求波动大、项目探索性强时

探索型工作难以准确预测总工时，应把计划拆成短周期的验证任务，并为不确定性设置区间。先承诺一个有限投入窗口，完成技术验证或用户研究后，再依据结果决定是否扩大资源投入。此时强行做出精确到季度的个人排期，往往会带来虚假确定性。

在高波动环境中，资源制度要允许快速重排，但仍要保留决策记录。重点追踪的是资源变更频率、重新估算偏差、关键假设和被挤出的工作，而不是责怪团队没有遵守早期预测。预测越不可靠，越应增加复核频率，而不是增加表格精度。

4. 有严格交付、法规或安全约束时

需要守住合规节点或外部合同窗口的项目，应在计划阶段提前识别不可替代的能力和审查时段。关键评审人员的时间要作为容量约束单独管理，不能等到开发完成后才申请。必要时准备第二审查人、外部认证资源或预留评审窗口。

当组织无法满足硬约束时，应及时升级，正式评估延期、范围缩减或替代方案，而不是默认压缩必要审查时间。资源计划不能以交付速度为唯一目标；若调整会改变安全、质量或法律风险，应由有相应权限的责任人批准并承担记录责任。

5. 工具和数据成熟度不足时

初期可以用轻量表格或现有系统维护统一字段，但要指定数据所有者和更新时点。先选少量关键团队做一个计划周期的试运行，检查需求字段是否填得动、冲突是否能被发现、决策是否能在时限内完成，再决定是否扩展工具功能。

如果团队各自使用不同工具，先统一数据定义比先做复杂集成更重要。比如“可用容量”究竟是否包含例行支持，“已确认”由谁确认，“延期影响”以什么口径记录，都需要先达成共识。否则，系统连接起来的可能只是多个含义不同的数字。

七、不同情况下的取舍：没有零成本的资源冲突解决方案

1. 调整范围：保护关键路径，但要接受交付内容变化

调整范围适用于功能可以分阶段交付、非关键模块可以延后，或项目价值仍能通过最小可用成果实现的情况。优点是能减少资源争抢，保住关键节点；代价是客户或内部用户可能暂时得不到完整能力，产品体验也可能需要后续补齐。

项目负责人应列清楚哪些内容延期、哪些依赖随之变化、后续补做需要什么资源。若范围调整只发生在计划表里，却没有同步更新验收标准和利益相关者预期，团队仍会被按原来的完整范围评估。

2. 调整里程碑：适用于顺序可变、时间窗口有弹性的工作

当项目之间存在不同的时间敏感度时，顺延较低优先级项目可能是最直接的做法。判断时要问：延期是否错过客户窗口、合规时限或关键依赖？延期一周是否会带来连续的连锁推迟？若里程碑具有弹性，主动调整通常比让团队同时对两个目标做出不可信的承诺更稳妥。

延后也有代价，包括收益实现变晚、上下游团队等待以及重新排期成本。因此，延期方案应标注新的承诺日期、恢复条件和受影响的依赖方，并明确何时重新确认资源，而不是只把日期向后移动。

3. 引入临时资源：适用于任务边界清晰、上手成本可控的工作

外部支援、内部借调或临时专家适合处理边界清晰、可以拆分、已有标准流程的工作。若任务依赖大量隐性背景知识，或者要求在短时间内作出高风险判断，临时增加人员可能反而增加核心成员的培训和审核负担。

在引入资源前，应计算交接时间、访问权限、质量审核和结束后的知识留存成本。新增人员不一定立刻增加同等比例的产能；若原团队需要投入大量时间指导，短期净产能可能有限。对关键知识岗位，培养内部替补往往是中长期方案，而非解决本周冲突的即时措施。

4. 加班或压缩周期：只适用于短期、可控且有恢复安排的峰值

短期加班可以用于明确的紧急事件，但应设定持续时间上限、审批人、质量检查点和后续恢复安排。若每个项目都以“最后冲刺”为理由争取超时投入，组织会把一次性应急变成默认容量，最终让正常计划越来越不可信。

压缩周期也不能只靠同时启动更多工作来实现。并行度提高可能增加沟通和等待成本；如果瓶颈是单一专家或外部审批，增加其他成员并不会直接缩短关键路径。管理者应先找出限制交付的具体环节，再判断加速手段是否针对瓶颈。

5. 暂缓低价值工作：短期影响明显，长期有助于恢复组织聚焦

当组织有大量未排序的需求时，取消或暂缓低价值工作有时比增加资源更有效。被取消的事项可能来自历史承诺、部门局部目标或缺乏复盘的项目。资源裁决会议应允许管理者讨论“哪些工作不做”，否则优先级排序只是在不断追加新工作。

这一选择需要透明说明依据，避免被理解为对某个团队或部门的偏好。可以比较业务价值、风险、外部时限、已有投入和重新启动成本，并邀请受影响方确认后续条件。暂缓不是消失，应设定重新评估时间，或明确在什么条件满足时重新进入组合。

6. 选择方案时，比较总成本而非只看新增人天

不同方案的成本分布不同：调整范围影响功能完整性，顺延影响收益和依赖，加人带来培训与沟通成本，加班带来疲劳和质量风险，取消工作则可能损失既有投资。不能只比较哪种方案“少花几个人天”，还要比较风险发生的概率、影响范围和恢复难度。

一个实用的讨论方式，是要求每个方案回答四件事：能否守住关键业务结果，最可能出现什么副作用，成本由哪个团队承担，何时需要重新评估。若无法说明成本归属，所谓方案往往只是把问题推迟到别的团队或未来阶段。

八、如何衡量制度是否有效：少看单点利用率，多看决策质量

1. 观察需求预测与实际投入之间的偏差

可以按岗位能力和项目阶段比较申请工时与实际投入，但不要用一次偏差给个人贴标签。偏差可能来自估算粗糙、任务范围变化、外部依赖等待或临时支持工作。只有把原因分类，数据才有助于改进计划；否则，团队会倾向于故意高报工时或隐藏工作。

如果某类任务连续几个周期都高估或低估，就应调整估算方法、工作拆分粒度或容量折算方式。对探索型工作，采用区间和逐步复核比追求单一准确数字更合理。

2. 观察冲突被发现和解决的时间

统计冲突从首次发现到确认容量、作出裁决、通知执行团队分别耗时多久，比单看冲突数量更有用。冲突数量增加有时意味着透明度提高，并不一定代表管理变差；但大量冲突长期停留在待裁决状态，说明授权、响应时限或升级路径可能存在问题。

还可以区分计划阶段发现的冲突和执行阶段才发现的冲突。前者通常有机会通过范围和时间调整降低损失；后者则可能已经造成返工、等待或关键路径延误。组织的目标不是让冲突归零，而是尽可能在成本较低的阶段识别冲突。

3. 观察承诺兑现、临时插单和返工的共同变化

资源制度是否有效，不应只看计划表是否完整。可以同时跟踪准时交付率、未经计划的插单数量、临时换人次数、等待关键资源的时间和返工比例。如果计划准确率提高，但实际交付没有改善，可能是团队记录更规范，却没有真正改变决策和执行。

指标应作为诊断信号，而不是简单排名工具。某团队插单多，可能是需求入口管理不严；也可能承担了高频运营职责。解释数据时要结合工作类型、风险和责任边界，避免用统一目标压制必要的应急响应。

九、结尾：把资源冲突变成组织的早期信号

1. 资源冲突不应被视为项目负责人的协调失败

资源冲突常常暴露出组织优先级不清、能力供给不足、需求入口失控或项目承诺过量。若每次冲突都靠项目负责人私下协调，组织就失去了从局部事件发现系统问题的机会。更成熟的做法，是把冲突登记为管理信号，分析它是否反复发生在同一岗位、同一时间窗口或同一类业务决策上。

我主张把责任明确到制度层面：项目负责人负责提出完整需求和解释业务影响，资源负责人负责核实容量，业务或组合决策人负责权衡优先级，执行团队负责按确认结果工作并及时报告变化。有责任、无授权会造成推诿；有决策、无记录会造成反复争论；有排期、无容量核验则只是愿望清单。

2. 下一步从一个稀缺岗位和一个计划周期开始

如果组织还没有统一的人力资源计划机制，不必一开始就覆盖所有岗位。先选一个反复发生冲突的稀缺能力，观察未来四至六周的需求；统一需求字段、确认责任和冲突升级规则；运行一个周期后，复盘哪些承诺被改变、冲突花了多久解决、哪些工作因此调整。

下一步可以按顺序推进：先把已承诺容量与待申请需求区分开，再确定冲突裁决人和响应时限，随后把确认结果同步回项目里程碑，最后用真实偏差改进容量估算。制度的成熟不是表格越复杂，而是组织能更早发现不可能同时兑现的承诺，并公开、及时、公平地作出取舍。