资源冲突怎么做？管理层实操方法：人力资源计划从0到1

去年第三季度，我陪一家做工业软件的公司开了整整两天的资源协调会。参会的有研发副总、四个产品线负责人、测试经理和两位架构师，议题只有一个：十月底之前，三个项目同时要人，到底谁先谁后。会议室白板上写满了人名和日期，擦掉又写上，第二天下午依然没有结论。散会时研发副总说了一句话，我印象很深：“我们不是缺人，我们是不知道自己有多少人。”

这句话几乎是所有资源冲突的真相。绝大多数管理者遇到资源冲突，第一反应是“协调”，拉个会，把当事人叫到一起，谁嗓门大、谁级别高、谁的项目挂着老板的名字，资源就往谁那边倾斜。这种做法能解决眼前的这一次冲突，但会让下一次冲突来得更快、更猛，因为整个组织没有因此获得任何新的判断依据。

这篇文字想讲清楚一件事：资源冲突不是协调问题，是承诺问题。人力资源计划从 0 到 1，真正要建的不是一张排期表，而是一本能让所有人看见“我们到底有多少产能、已经承诺出去多少、还剩多少可以许给别人”的账。下面我会按结论、场景、误区、判断逻辑、案例、行动建议、取舍七个部分拆开讲，其中包含我在多家 100 至 2000 人规模企业里踩过的坑和验证过的做法。

一、核心结论：先有产能账本，才有资源协调

我把结论放在最前面，因为它决定了后面所有动作的顺序。资源冲突的解决效率，取决于冲突被发现的时点，而不是被处理的手段。冲突在计划阶段被发现，处理成本是一次排期调整；冲突在交付前两周被发现，处理成本是一次范围削减或者一次加班；冲突在客户验收前被发现，处理成本就变成了信誉。

很多团队把 90% 的精力花在“冲突发生后怎么谈”，只有 10% 花在“怎么让冲突早点暴露”。这个比例是反的。我的经验是，把这个比例倒过来，七成精力放在产能可见，三成放在冲突裁决，资源冲突的总量会下降一半以上。

下面这张图来自我对六家客户在 2023 至 2024 年间处理方式的观察汇总，解决周期和复发率是我按各自的项目管理系统的工单时间戳统计出来的均值，样本量不大，但方向很稳定。

注意看这张图的一个细节：第三种方式的优势不在“裁决更快”，而在“不需要裁决”。当产能账本把每个人的可承诺时间挂在墙上，产品经理提需求时会自己先算一遍，很多冲突在提需求的那一刻就被自我否决了。这才是从 0 到 1 的真正含义，不是建立一个更强的裁判，而是让冲突少发生。

由此可以推出人力资源计划的三个必备输出，缺一不可：

• 产能基线：一个团队一个季度到底有多少“真正可交付的人天”，而不是有多少个脑袋乘以 90 天。
• 承诺台账：已经许出去的部分，包括正式立项的、口头答应的、以及被默认要接的支持性工作。
• 裁决规则：当剩余产能不足以覆盖新需求时，谁在什么时限内、依据什么标准做出取舍。

三样东西凑齐，资源冲突才从“政治事件”变成“管理事件”。缺任何一样，会议就会重新变成嗓门比赛。

二、背景：资源冲突为什么总是在特定阶段集中爆发

资源冲突不是线性增长的，它有明显的台阶。我在做组织诊断时反复看到一个规律：团队规模每跨过一个阈值，资源冲突的性质就会变一次。20 人以内靠喊，50 人以内靠周会，100 人以上如果还在靠周会，冲突就会开始失控。

1. 三个阈值：50 人、150 人、300 人

50 人左右是第一个坎。这个规模下，创始人或者研发负责人还能记住每个人在做什么，资源调配靠脑内地图。一旦超过 50 人，脑内地图开始失真，你会发现自己记不清某个人上个月到底投入在哪个项目上。这时候冲突第一次以“我怎么不知道他在做这个”的形式出现。

150 人左右是第二个坎，也是最危险的一个。这个规模下跨团队协作的链路开始变长，一个需求从提出到交付要穿过产品、设计、前端、后端、测试、运维六个环节。任何两个环节的排期错位都会表现为“资源冲突”，但实际上冲突的根因是排期逻辑没有对齐。很多公司在这个阶段引入项目管理工具，以为工具能解决，结果只是把纸面上的混乱搬到了系统里。

300 人以上是第三个坎。这个规模下会出现“资源池”和“资源需求方”的正式分化，出现专职的项目管理办公室或者 PMO，出现跨部门的资源预订机制。如果没有建立这套机制，冲突会从项目层上升到部门层，变成部门负责人之间的博弈，处理成本急剧上升。

2. 真实场景：一个典型的中型研发组织的资源冲突长什么样

我去年深度参与过一家 400 人规模的智能硬件公司的资源梳理。他们有 6 条产品线，共用一支 40 人的嵌入式团队和一支 25 人的结构团队。产品线负责人各自向 CEO 汇报，嵌入式团队和结构团队向 CTO 汇报。

冲突的典型形态是这样的：A 产品线要在 11 月送样，需要嵌入式的三个人全职投入六周；B 产品线在做量产前的最后一次固件迭代，同样需要这三个人；C 产品线的客户定制需求承诺了 30 天交付，也要人。三条线的负责人在周会上互相看，CTO 说“我协调一下”，然后私下给每个人打招呼，让他们“辛苦一下”。

结果是这三个人连续三个月每周工作 60 小时以上，B 产品线的固件迭代延期两周，C 产品线的定制交付出了两个严重缺陷，A 产品线的送样虽然赶上了，但测试覆盖率只有平时的六成。更隐蔽的代价是，这三位核心工程师在半年内走了两位。

这个案例里没有坏人，每个人都在做“正确”的事。问题出在三个地方：产能没有统一口径、承诺没有统一入口、优先级没有统一裁决。三条产品线各自承诺客户，谁都不知道别人许了什么，CTO 手上没有一本账可以查。

3. 资源损耗发生在哪里：从需求到交付的漏斗

很多管理者以为资源冲突是“需求太多”，但我做过的一个漏斗统计显示，真正的损耗不只在需求端。以 100 个进入排期的需求为起点，最后能按原计划、原范围、原质量交付的往往不到 40 个，剩下的损耗分散在各个环节。

这张漏斗真正想说的是：“通过产能校验”这一步的 28 个损耗是良性的，其余损耗才是问题。一家公司如果不敢在排期阶段拒掉 28% 的需求，就会在开发阶段被动丢掉另外 30%，而且丢得毫无计划。

三、拆解常见误区：五种看起来有效但会加重问题的做法

我见过太多团队在资源冲突面前做出本能反应，这些反应短期看起来都有效，但几乎全部会把问题推到更贵的地方。下面五种是最常见的，我按危害程度排序。

1. 误区一：加人。边际收益在第三个人之后急剧下降

资源冲突的第一反应永远是“招人”。但在一支已经满负荷的团队里加人，前三个月是净负收益。新人需要老人带，老人本来就没有余量，只能从交付里挤时间，于是交付更慢，冲突更多。

我观察过的一个粗略规律是：一个成熟模块上，团队规模从 3 人扩到 5 人，总产出大概提升 40%；从 5 人扩到 8 人，总产出提升可能只有 15%，沟通成本吃掉了大部分增量。这不是说不能加人，而是说加人解决的是“长期产能缺口”，不是“这个季度的资源冲突”。用加人应对季度冲突，等于用一年后的产能解决这个月的排期。

2. 误区二：加班。它把资源冲突从显性问题变成隐性问题

加班最糟糕的地方不是消耗员工，而是它让产能数据失真。一旦团队默认可以靠加班补缺口，产能账本上的“可承诺时间”就永远算不准，因为真实产能被一个不可见的缓冲垫遮住了。等到这个缓冲垫被消耗完，通常是连续加班两三个月之后，冲突会以集中爆发的方式回来，而且那时候团队已经没有人愿意再接。

我在做复盘时有个经验判断：如果某个团队的加班时长连续三个月超过 15%，那么这个团队的所有排期数据都应该被视为不可信。因为排期已经不是在管理产能，而是在透支产能。

3. 误区三：把所有冲突都升级到最高层裁决

有些管理者走向另一个极端，要求所有资源冲突必须由他拍板。这在 50 人以内可行，超过之后必然崩盘，因为裁决带宽有限。更麻烦的是，一旦最高层成为唯一裁决人，中层就会放弃判断，把所有模糊地带都往上推，组织彻底失去自主排序的能力。

正确的做法是分层裁决：同一团队内部的冲突由团队负责人裁决，跨团队冲突由双方共同的上级裁决，涉及战略级客户或生死线的冲突才上升到经营层。每一层都要有明确的时限，比如 48 小时内必须给出结论，否则自动升级。

4. 误区四：用工具替代机制

这是近几年最常见的一个坑。很多公司上了项目管理工具，把人天、工时、迭代都录进系统，就以为资源冲突解决了。结果发现系统里的数据是死的，工时填报靠自觉，填报率不到 60%，填的内容还经过了“美化”；资源视图看起来很漂亮，但没有一个人真的拿它做决策。

工具能放大机制，但不能替代机制。如果一家公司没有明确“谁有权承诺资源”“冲突按什么标准裁决”，把它搬进任何系统都只是把混乱数字化。我在评估一家公司是否适合上资源管理模块时，会先问三个问题：有没有统一的优先级定义？有没有唯一的资源承诺入口？有没有人真的会看这张报表做决定？三个都是否，先别上系统。

5. 误区五：追求工时颗粒度越细越好

精细化管理的诱惑很大，很多管理者希望看到每个人每半天在做什么。我试过，也见过客户试过，结论是：工时颗粒度细到 0.5 天以下，数据质量会断崖式下跌，而管理收益接近于零。

原因很简单，填报工时对工程师来说是纯成本，没有即时收益。颗粒度越细，伪造的成本越低，数据的可信度越差。更合理的选择是按“周”或“迭代”为单位记录投入比例，比如某人在本迭代 60% 投入 A 项目、30% 投入 B 项目、10% 投入支持，这个精度已经足够做资源冲突预警了。

四、专业判断逻辑：人力资源计划的四层结构

讲完误区，进入正题。人力资源计划从 0 到 1，我的做法是搭四层结构，从组织层一直落到个人层，每层只解决一个明确问题，不越界。这个结构的价值在于：它把“资源冲突”这个大词拆成了四个可以分别处理的具体问题。

1. 第一层：组织层，名义产能与预算边界

组织层只回答一个问题：我们一共有多少可用的产能，成本上限是多少。这一层的输出通常是一张按部门、按角色、按季度展开的编制表，包含在岗人数、HC 缺口、外包和外协额度。

这一层最容易犯的错是把“在岗人数”直接当成产能。一个人力资源计划如果只有编制表，那它只是一张花名册。真正的产能要把请假、培训、公共事务、管理职责全部扣掉，剩下的才是可分配的部分。

我的经验口径是：一名工程师的年度有效产能大约是其名义工作日的 65% 至 75%。100 人左右的团队取 75%，因为公共事务相对少；300 人以上取 65%，因为会议、汇报、跨部门协同的占比会明显上升。这个系数不是拍脑袋，是拿实际交付人天和名义人天做除法算出来的，每家公司应该自己算一遍。

2. 第二层：团队层，技能矩阵与稀缺度

团队层回答的问题是：哪些能力是稀缺的，稀缺到什么程度。资源冲突之所以难处理，往往不是因为总产能不够，而是因为某一种能力只有两三个人具备。

我建议每个技术团队维护一张技能矩阵，横轴是人，纵轴是关键能力项，格子里填熟练度。不一定要填得很细，三级就够：能独立做、能带人做、能做技术决策。关键要看的是纵轴上只有一两个人达到“能带人做”的那些行，这些行就是未来所有资源冲突的高发地带。

识别出稀缺能力之后，有三种应对方式，选哪种取决于时间尺度：短期靠错峰排期，中期靠结对和轮岗把稀缺度降下来，长期靠招聘或者外部合作补位。多数公司只做第一种，所以同一个坑年年踩。

3. 第三层：项目层，角色投入与时间窗口

项目层回答的问题是：每个项目在什么时间窗口需要哪些角色、需要多少投入。这一层的产出决定了冲突能不能被提前看到。

我要求客户在这一层至少做到两件事。第一，每个立项的项目必须按角色拆出投入曲线，而不是只给一个总人天。一个项目说“需要 120 人天”，对资源计划毫无用处；说“第 1-3 周需要后端 2 人、第 4-8 周需要后端 1 人加前端 2 人”，才能拿去和别人的需求比对。

第二，所有资源占用必须有明确的时间窗口和结束日期。开放式占用是资源计划的天敌，一个“长期支持”的标签能让一个团队 30% 的产能永久性消失而无人察觉。

下面这个产能构成图，是我给一家 12 人研发团队做的季度盘点，你可以对照看看自己团队的构成是否类似。

4. 第四层：个人层，时间分配与负荷预警

个人层回答的问题是：具体某个人在某个时间段被几个项目占用，超载了吗。这一层是预警的最后一公里，也是唯一需要落到人名的层级。

我用一个简单的三色规则：一个人在同一周内被分配的工作量占其有效工作时间的 85% 以下为绿色，85% 至 100% 为黄色，超过 100% 为红色。红色状态不允许出现在已承诺的排期里，一旦出现，必须由裁决人当场做出取舍，而不是留到后面再说。

这里有个细节很容易被忽略：一个人的黄色状态最多只能连续维持六周。超过六周，产出质量会开始下降，返工率上升，实际产能反而低于绿色状态。这个判断来自我对多个团队缺陷密度的观察，连续高负荷的第六周左右，缺陷密度往往会出现一个明显的抬升拐点。

四层结构落下去之后，最好用一个统一的口径把产能算出来。下面这段是我给客户做产能基线时常用的计算逻辑，用伪代码表达，重点是口径而不是实现。

# 单人季度可承诺产能（单位：人天）
名义工作日 = 季度自然日 – 周末 – 法定节假日 # 约 62 天

有效工作日 = 名义工作日 – 年假 – 病假 – 培训 – 公共事务 # 约 55 天

有效产能系数按组织规模取值

if 组织规模 < 100: 系数 = 0.75

elif 组织规模 100%: 触发冲突裁决流程

这段逻辑看起来粗糙，但它比任何精细的工时系统都更有用，因为它简单到所有人都会用，也用得起。资源计划的第一原则是可用性优先于精确性，一个所有人都理解的粗模型，胜过一个没人维护的精模型。

五、案例与数据观察：把一个 600 人研发组织的资源冲突降下来

下面这个案例来自一家做企业级 SaaS 的公司，规模约 600 人，研发 320 人，分 9 个研发团队。他们的冲突特征很典型：项目数量多、跨团队依赖多、产品经理承诺随意、没有统一的资源视图。我们在 2023 年下半年开始做人力资源计划的从 0 到 1 建设。

1. 起点：先承认自己不知道

第一步不是上工具，是做了一次为期两周的产能盘点。做法很笨：把过去两个季度所有立项项目拉出来，按角色统计实际投入人天，再除以名义人天，算出真实的产能系数。结果是 0.58，远低于管理层以为的 0.8。

这个数字公布的时候，会上安静了很久。因为它意味着公司过去所有的排期都是建立在错误的基数上的，凭空多算了 40% 的产能。这解释了为什么每个季度都在赶工，但每个季度都赶不完。

第二步是找冲突源头。我们把过去半年的资源冲突事件按类型做了归类，用帕累托图看分布，结论非常集中。

2. 做法：用 PingCode 把产能账本落到流程里

机制设计清楚之后，需要一套系统把规则固化下来，否则所有约定都会在三个月内退化回原样。这家公司最终选了 PingCode，主要原因不是功能多，而是它的需求、迭代、工时、资源视图在同一个数据模型里，不需要在三个系统之间做数据搬运。PingCode 主要服务中大型企业及 100 人以上组织，这个规模区间的痛点恰恰是跨团队资源可见性。

具体做了四件事，每一件都对应一个具体的冲突来源。

（1）把销售承诺接入需求入口，前置拦截

过去销售在合同里写交付日期，产品线负责人只能事后接。改造后，所有对外的交付承诺必须先在企业内部创建一条需求，并挂上预估的角色投入。系统会根据当前季度的可承诺产能自动提示是绿色、黄色还是红色。

这条规则刚开始遭到销售强烈反对，理由是“影响签单效率”。实际运行三个月后，销售的反对声消失了，因为他们发现前置暴露风险反而让承诺更可信，之前那种签完单再回来扯皮的情况少了很多。最终统计，销售承诺未经校验导致的冲突从 47 件降到 9 件。

（2）用跨项目资源日历暴露稀缺技能占用

针对那 3 位掌握分布式事务能力的工程师，做法是把他们的时间在系统里按项目做预订，任何团队要用，必须在资源日历上申请时段。这一条把隐性的排队变成了显性的档期。

效果很有意思：冲突数量没有立刻下降，但冲突的处理周期从平均 6 天降到 1.5 天。原因是大家不再需要开会对质“你到底答应谁了”，日历上写得清清楚楚。这也印证了前面那个判断：资源冲突的治理收益，很大一部分来自信息透明，而不是裁决权力。

（3）设立固定支持轮值，把救火变成可预测占用

线上问题临时抽调是最容易被忽视的产能黑洞，因为它每次都“只占半天”，累计起来却很惊人。做法是每个团队固定一个轮值岗，每人轮一周，轮值期间不承担项目交付任务，产能账本上直接扣掉。

这个改动看起来是“减少了可用人力”，实际效果相反：团队的项目交付准时率提升了 11 个百分点，因为项目排期不再被随机打断。这个反直觉的结果值得所有管理者记住，把不确定的占用显性化，账面产能下降，实际产出上升。

（4）用迭代回顾校准产能系数

最后一个动作是建立校准机制。每个迭代结束后，系统会自动对比计划投入和实际投入，偏差超过 20% 的会进入回顾议题。产能系数每季度重新计算一次，滚动修正。

这一条是整套机制能否长期活下去的关键。产能系数不是一次算完就固定的常量，它会随团队成熟度、业务复杂度、人员结构变化而漂移。不校准，第一年准，第二年就会重新失真。

3. 结果：六项指标的变化

运行九个月后，我们对比了六项指标。需要说明的是，这些是单家公司的落地数据，不构成行业基准，但变化的方向和幅度有参考价值。

有一点我必须说清楚：这套机制的红利期大约在第六到第九个月达到峰值，之后如果不持续校准，指标会缓慢回落。我见过两家公司在第一年做得很好，第二年因为不再做季度校准，冲突数量又爬回原来的水平。人力资源计划不是一次项目，是一项运营工作。

六、不同情况下的行动建议

上面的案例是 600 人规模的做法，直接照搬到 80 人或 2000 人的组织都会出问题。这一节我按规模和冲突类型分别给出建议，你可以对号入座。

1. 按组织规模：三种起步路径

100 人以下：不要做体系，做一张表。这个阶段的组织经不起流程成本，你需要的是一张共享的产能表，列上人名、当前项目、投入比例、预计释放时间，每周更新一次。工具用什么都行，关键是每周有人真的看。这个阶段最该建立的不是流程，而是“承诺资源要说一声”的习惯。

100 至 500 人：建立四层结构的前三层。这个规模下个人层可以粗一点，但团队层和项目层必须做实，因为跨团队冲突已经占了主流。重点动作是统一优先级定义、设立唯一的资源承诺入口、建立 48 小时升级时限。工具上可以考虑引入像 PingCode 这类把需求、迭代和资源视图打通的项目管理平台，避免在多个系统之间做人工对账。

500 人以上：必须有人专职负责。这个规模下资源计划已经是跨部门的公共事务，没有专职 owner 就会退化成各部门自说自话。专职的人不一定要成立正式 PMO，可以是一个两三个人的虚拟小组，但它必须拥有三样东西：完整的数据视野、明确的裁决权限、以及向经营层直接汇报的通道。

2. 按冲突类型：四种针对性动作

如果是“同一人被多项目占用”，动作是建立跨项目资源日历，把隐性占用显性化，并设定单人周负荷上限。这类冲突最容易解决，因为数据一旦可见，当事人自己就会提出来。

如果是“稀缺技能排队”，动作是短期错峰、中期结对、长期招聘三管齐下。要注意的是，稀缺技能的排队问题不能靠“提高优先级判断准确性”解决，因为无论怎么排，总有项目要等。真正的解法是把稀缺度降下来，比如把某个只有一人能做的模块拆成可协作的形式。

如果是“跨团队依赖错位”，动作是在排期阶段就画依赖图，并强制上游团队给出明确的交付日期承诺。这类冲突有个隐蔽特征：它常常不表现为资源冲突，而表现为“下游团队这段时间没事干，被临时调去做别的，然后上游一交付，人回不来了”。

如果是“需求变更导致范围扩大”，动作是建立变更的产能校验环节。任何在立项后追加的需求，都要重新走一遍产能校验，而不是默认由原团队消化。这一条如果执行到位，能消掉相当一部分冲突。

七、不同情况下的取舍

所有管理方法都是取舍，没有只赚不赔的方案。这一节讲清楚人力资源计划从 0 到 1 过程中必须做的四个取舍，以及我的选择倾向和理由。

1. 取舍一：透明与灵活的权衡

产能账本的前提是透明，但透明会降低灵活性。一旦每个人的档期挂在系统里，临时插队就有了成本，管理者会感觉“不如以前方便”。

我的判断是在 100 人以上必须选透明，因为不透明带来的“方便”本质上是把成本转移给了执行者。临时插队之所以显得方便，是因为被插队的人默默承担了加班和延期。当组织大到无法靠人情消化这些成本时，透明是唯一可持续的选择。

但要给灵活性留一个口子：在产能账本上明确预留 10% 至 15% 的缓冲，专门用于战略级插单和突发。有缓冲的透明，比绝对的透明更容易活下来。

2. 取舍二：集中调度与团队自治的权衡

集中调度的好处是全局最优，坏处是反应慢、团队丧失自主性；团队自治的好处是灵活，坏处是资源在部门内形成事实上的私有化，跨部门调配极难。我把这两种模式的差异做了个对比。

我的倾向是混合模式：资源的所有权归团队，调度权归一个跨部门的资源委员会。团队负责人的职责是保证本团队产能数据的真实和技能的持续积累，资源委员会负责在季度层面做跨团队调配，并且只调“未承诺的剩余产能”和“缓冲池”，不动已经承诺的部分。这样既保留了专业积累，又避免了资源私有化。

3. 取舍三：精细度与可持续性的权衡

前面讲过，工时颗粒度越细，数据质量越差。但反过来，颗粒度太粗也不行，按季度记录投入，等到发现冲突时已经过去三个月了。

我给出的建议是按迭代或按周记录投入比例，按季度校准产能系数。周级别的投入比例足以支撑冲突预警，因为绝大多数资源冲突的窗口期都在两周以上；而产能系数的校准则不需要频繁，季度一次足够。

这里有个实用的判断标准：如果某个数据项的采集成本超过它带来的决策价值，就不要采。很多公司采集了一堆数据，最后没有一个进入决策，纯粹是给一线增加负担。

4. 取舍四：短期止血与长期建设的权衡

最后这个取舍最现实。当资源冲突已经火烧眉毛时，你不可能停下来做三个月的体系建设。我的做法是两条线并行，但用不同的颗粒度。

止血线做三件事，一周内可以完成：列出当前所有在跑项目的角色占用、标出红色负荷的人、由最高负责人对这三人涉及的冲突做一次性裁决。这三件事不需要任何系统，一张表加一次会就够。

建设线做三件事，三个月见效：定义统一的优先级标准、设立唯一的资源承诺入口、建立 48 小时升级机制。建设线的动作要和止血线分开管理，不要指望同一个会议同时解决两件事，否则永远只会处理紧急的，不会处理重要的。

5. 什么时候可以不做人力资源计划

最后说一个反常识的判断：不是所有组织都需要做人力资源计划。如果一家公司同时满足三个条件，项目数量稳定在 3 个以内、团队成员技能高度重叠、业务节奏可预测，那么靠周会协调就足够了，建一套体系反而是负担。

反过来，只要出现下面任一信号，就说明该动手了：连续两个季度有项目因资源不足延期；核心人员连续三个月负荷超过 100%；同一个稀缺技能在三张不同的排期表上同时出现；管理者说不清某个员工上个月主要做什么。这四个信号里出现任意一个，再等下去只会更贵。

八、下一步怎么做：从明天开始的三件事

写到这里，方法论已经讲完。但读完不行动，等于没读。我把最该做的三件事按顺序列出来，你可以明天就开始。

第一件事，用两周时间算出你自己的产能系数。方法很笨：挑过去一个季度已经交付的 5 个项目，统计每个项目实际投入的人天，除以参与人员的名义工作日，得到一个比值。这个数字大概率会让你不舒服，但它比任何咨询报告都真实。算完之后，把它贴在你下次排期会的白板上。

第二件事，找出你的三个稀缺技能。拿一张纸，横轴写团队所有人的名字，纵轴写你业务上关键的 10 项能力，标出每项能力上能做到“带队交付”的人有几个。少于两人的行，就是你未来半年所有资源冲突的高发地带。针对这些行，现在就排一个结对计划或者外部补位计划。

第三件事，把资源承诺的入口收成一个。规定从下个月起，所有涉及跨团队资源占用的需求，必须走同一个入口登记，并附带角色投入和时间窗口。这条规则刚推的时候一定有人绕开，你要做的是准备一个明确的后果，比如未登记的占用不进入季度资源评审，出了冲突优先级最低。规则的权威性来自后果，不来自宣贯。

我最后想强调的一点是，资源冲突从来不是纯粹的算术问题，它本质上是一个组织如何对待“承诺”的问题。当一家公司里每个人都能看到产能的真实边界，并且知道越界的代价由谁承担，冲突就自然变成了一个可以讨论、可以计算、可以裁决的普通管理议题。而人力资源计划从 0 到 1 的全部工作，就是把这件事从人的脑子里，搬到所有人都能看见的地方。

这件事没有终点，只有校准。你在第一个季度建立的产能账本，到第四个季度一定已经失真，需要重新校准。真正做得好的组织，不是一次把计划做对的组织，而是把“每个季度重新算一遍”变成习惯的组织。