资源冲突怎么做？PMO数据分析：人力资源计划从0到1

去年第四季度，我在一家做智能硬件的公司旁听他们的季度资源评审会。投影上是一张 47 行的人力表，三个产品线负责人在同一行“嵌入式架构师 A”后面分别填了 100%、80%、60%。会议开了两个多小时，最后靠一位 VP 拍板：A 优先给最紧急的 B 项目，C 项目“自己想办法”。三个月后 C 项目延期六周，复盘报告里的第一条原因写着“关键人不到位”。

这件事让我印象很深，因为整个会议室里没有人说谎，也没有人偷懒。问题出在那张表上，它把一个人同时算给了三个项目，却没有任何机制阻止这件事发生。资源冲突真正的源头，往往不是人不够，而是计划系统里根本不存在“同一个人”这个概念。

这篇文章我想把“人力资源计划从 0 到 1”这件事拆开讲清楚：冲突是怎么产生的、PMO 到底该建什么、哪些做法看起来专业其实在制造麻烦，以及在不同组织规模下应该怎么取舍。文中涉及的案例数据来自我参与过的项目复盘与访谈，部分对比数据为示意口径，我会在相应位置标注。

一、先给结论：资源冲突的本质是计划系统缺三样东西

如果只允许我用一段话回答“资源冲突怎么做”，答案是这样的：把“人”从组织架构里的一个名字，变成时间轴上的一段可分配容量，然后给这段容量装上优先级规则和刷新节拍。没有这三样东西，再多的协调会也只是在给同一个漏洞打补丁。

下面四条结论，是我在十一家不同规模企业里反复验证过的判断。它们不一定让人舒服，但基本能解释你正在经历的绝大多数冲突。

1. 结论一：多数冲突不是产能不足，而是可见性不足

我复盘过的资源冲突里，真正因为“总人力确实不够”导致的，大约只占三成。剩下七成，是同一个人的时间被重复承诺、被碎片化切分、或者被低优先级任务占住而无人知晓。

有个很典型的测算：一家 800 人规模的软件公司，研发序列名义编制 420 人。按每人每月 21.75 个工作日、每天 8 小时算，理论产能约 73,000 人时/月。但扣除年假、培训、内部会议、招聘面试、线上支持、技术债处理之后，真正能投入项目的容量只有 54% 左右。

计划层看到的是 100%，执行层感受到的是 54%，中间那 46% 从来没被写进任何一张表。冲突就长在这个差值里。你以为在抢 100 个人，实际上能分配的只有 54 个人的等效产能。

2. 结论二：PMO 的产出是分配规则，不是更漂亮的甘特图

我见过不少 PMO 团队，把大量精力放在把计划画得更细、颜色配得更好看上。但真正让冲突减少的，从来不是图变漂亮了，而是“当两个项目都要同一个人时，谁先拿、拿多久、拿不到怎么办”这个问题有了明确答案。

规则要能回答三件事：优先级怎么定、冲突怎么仲裁、例外怎么记录。这三件事不写清楚，PMO 就只是一个数据汇总部门，所有实质决策仍然会回流到高管层，会议越开越长，冲突越来越多。

3. 结论三：从 0 到 1 只需要做对三件事

很多团队一开始就想做“完整的人力资源管理体系”：能力模型、职级体系、九宫格、继任计划，一整套上。结果半年过去，连一张能对得上账的资源池都没有。

从 0 到 1 阶段，真正必须做对的只有三件：统一口径、建立池子、设定节拍。口径解决“一个人的时间怎么算”，池子解决“有哪些人能用在哪些事上”，节拍解决“多久刷新一次承诺”。这三件事做完，60% 的冲突会自动消失，因为它们本来就不该发生。

4. 结论四：人力计划的精度上限，由业务节拍决定

这是个容易被忽视的判断。你的人力计划能做到多准，不取决于你排得多细，而取决于你的需求侧有多稳定。需求每周变三次的团队，做季度精确到人的排班，投入产出比极低，维护成本还会拖垮 PMO 的公信力。

我的经验基准是：需求月度稳定度低于 70% 的组织，人力计划做到“月度 + 技能组”粒度就够了；高于 85% 的组织，才值得做到“周 + 具体人”。粒度不是越细越好，细过业务节拍就是一种自欺。

二、背景：资源冲突是怎么在组织里长出来的

理解了结论，还要理解冲突的生长过程。因为绝大多数组织并不是某一天突然开始抢人的，而是在规模扩张的过程中，一点点把冲突养大的。

1. 从单项目到多项目并行，冲突是结构性产物

项目数量少的时候，资源冲突靠“喊一嗓子”就能解决。一个负责人手里有三个项目，谁急先给谁，口头协调的成本极低，而且信息是完整的，他知道每个人在干什么。

当项目数超过某个阈值，这种非正式协调就会失效。不是因为人变懒了，而是因为信息带宽超过了个人记忆的容量。一个人能同时跟踪的并行任务大约在 5 到 7 个之间，超过之后必然出现“我以为他在做另一个项目”这类错误。

这就是结构性产物的含义：它不是管理失误，而是规模越过临界点后的必然结果。指望靠加强责任心解决，等于指望人脑扩容。

2. 一个典型现场：三条产品线抢同一个领域专家

我服务过一家做工业软件的公司，900 多人，三条产品线共用一个 12 人的算法团队。这个团队里有两位做数值求解的专家，是全公司唯二能改核心求解器的人。

每个季度的排期会上，三条产品线都会把这两位专家排进自己的关键路径。三个项目都需要他们各投入 60% 以上的时间，加起来是 180%。三轮会议之后，解决方案是“每人分一点”，结果两位专家每周在三个项目之间切换，单次上下文切换成本大约 2 到 3 小时。

半年后统计，这两个人的实际有效产出比专注状态下降了约 40%，而三个项目全部延期。表面上看是分配问题，本质上是稀缺技能没有被当作稀缺资源来管理。

3. 三个信号说明你的组织已经进入冲突高发期

不用等冲突爆发才反应过来，有三个前置信号可以提前判断。

• 人均并行项目数超过 1.8。低于 1.5 时协调成本可控，超过 2.0 之后冲突频率会非线性上升。
• 资源协调会议从月度变成周度，且时长超过 90 分钟。会议频率是被冲突推着走的，不是被流程推着走的。
• “借调”开始以口头或聊天记录形式存在。一旦资源流动脱离台账，账实不符就是时间问题。

4. 为什么 HR 系统和项目系统永远对不上账

这是我在几乎每家公司都会遇到的现象：HR 系统显示某部门 68 人，项目管理系统里的资源占用加起来是 79 人。两个数都对，但它们统计的不是同一件事。

HR 系统的口径是“雇佣关系”，最小单位是人，时间维度是月；项目系统的口径是“工作量承诺”，最小单位是人·天或人时，时间维度是任务。中间缺少一层翻译：这个人这个月到底有多少小时是可分配的。

没有这一层翻译，两个系统就永远并行存在、永远对不上账。而 PMO 最该做的第一件事，恰恰就是把这一层补上，而不是去争论哪个系统更准。

三、拆解五个常见误区，每个都在让冲突变严重

讲完背景，我想说说那些看起来正确、实际上在制造麻烦的做法。这五个误区我在不同公司反复见到，它们有一个共同特征：短期内都让数字变好看了。

1. 误区一：把资源利用率当成越高越好

很多 PMO 把“资源利用率 90% 以上”写进 KPI，认为这是效率的体现。但利用率超过某个点之后，交付表现会掉头向下。

原因不难理解：利用率高意味着没有缓冲，没有缓冲意味着任何一次需求波动、任何一个 bug、任何一次人员请假，都会直接冲击交付。而且高利用率下任务只能按最优路径排，一旦某个环节延迟，后面全部连锁。

我跟踪过的一组数据显示，利用率从 70% 提升到 85% 时，交付周期基本持平；从 85% 提升到 95% 时，平均交付周期反而延长了 22%，返工率上升了 31%。真正的甜区在 75% 到 85% 之间。

2. 误区二：排人，而不是排技能

“张三这个月给 A 项目”，这是排人。“这个月需要 1.5 个具备分布式存储经验的中级工程师”，这是排技能。前者在人员稳定时能用，后者才能承载变化。

排人思维最大的问题是把资源绑死在具体个体上，导致所有冲突都必须以人为单位解决。而排技能思维允许替换：同样是中级后端，具备消息队列经验的人可以顶上，冲突立刻从“不可解”变成“可解”。

建立技能矩阵的成本并不高。一个 200 人的研发组织，用两周时间把关键技能标签化、把每项技能的熟练度分三级，就能支撑起 80% 的调度判断。

3. 误区三：用平均可用工时掩盖碎片化

“每人每月 21.75 天，减去假期，平均可用 18.5 天。”这个算法看起来严谨，实际把最关键的损耗藏起来了。

真实情况是：一个人这 18.5 天不是连续可用的，而是被切成无数碎片。周一上午例会、周二下午面试、周三支持客户、周四处理线上问题。每次切换都要重新进入状态，深度工作的连续时间可能只有 40%。

资源计划的单位不是“天”，而是“可连续工作的半天”。如果按天排，你会得到一个数学上完美、执行上必然崩盘的计划。

4. 误区四：以为上线工具就解决了协同

这是我见过最贵的误区。花几十万采购一套项目管理平台，上线三个月，冲突照旧。因为工具解决的是“记录和呈现”，而冲突的根源在“规则和授权”。

工具能让冲突被看见，但看见冲突不等于解决冲突。如果没有优先级规则，工具只会让会议开得更精确、吵得更具体。我一般的建议是：先用 Excel 把规则跑通两个月，规则稳定了再上系统，这时候系统才是放大器而不是放大器里的噪音。

5. 误区五：所有冲突都升级给老板

升级本身不是错，事事升级才是错。当冲突解决全部依赖高管裁决时，会出现两个后果：一是决策带宽被耗尽，二是所有项目负责人都学会了“会哭的孩子有奶吃”，资源分配从按优先级变成按嗓门大小。

合理的结构是分层：约 70% 的冲突在资源经理层面解决，20% 在 PMO 的仲裁机制里解决，只有 10% 真正需要上升到管理层。这个比例可以用来做健康度诊断，如果你的升级率长期超过 30%，说明规则层是空的。

四、专业判断逻辑：人力资源计划从 0 到 1 的四层模型

接下来是我实际使用的方法框架。它不复杂，但每一层都有明确的产出物和验收标准，缺一层就会出现对应的典型症状。

四层分别是：口径层、池子层、节拍层、规则层。顺序不能颠倒，因为上层依赖下层的产出。跳过口径层直接做规则层，最后一定会在数据对不上账时推倒重来。

1. 第一层 口径层：把“人”翻译成“可分配容量”

这一层的唯一任务，是定义一个全公司认可的计算方式：一个人在一个月里，到底有多少小时可以承诺给项目。

我的建议是三级口径：名义工时 → 可用工时 → 可承诺工时。名义工时是 21.75 天 × 8 小时；可用工时扣除假期、培训、公司级活动；可承诺工时再扣除会议、支持、管理事务和碎片化损耗。

这三个数字必须公开、可解释、可审计。因为一旦有人质疑“为什么他只算了 60%”，你需要能拿出扣减明细，而不是一句“经验值”。

2. 第二层 池子层：资源池与技能矩阵

资源池不是把部门名单复制一遍。它需要满足三个条件：有边界、有标签、有容量。

• 有边界：哪些人属于可以被跨项目调配的池子，哪些人固定在某个产品线里。边界不清，池子就等于没有。
• 有标签：每项技能分领域和熟练度两级标签，例如“分布式存储-L2”“前端性能优化-L3”。标签数量控制在 30 到 50 个，太多就无法维护。
• 有容量：每个池子有明确的月度可承诺工时总量，且随人员变动自动更新。

很多团队在这一层犯的错是把池子做成了花名册，只有名字没有容量，导致资源池在实际调度中毫无用处，最后还是回到打电话问人。

3. 第三层 节拍层：把需求排进时间桶

节拍层的核心是“时间桶”这个概念。把未来 3 到 6 个月切成月桶，每个桶里放需求，需求必须声明所需技能、所需容量和期望时间窗。

时间桶的价值在于让“未来”变成“现在可以讨论的东西”。没有时间桶，需求永远是“下个季度再说”，而资源承诺永远是“到时候看”，两者永远无法对齐。

节拍频率要和业务匹配。我的经验值：需求月度变动率在 15% 以内用月度节拍；15% 到 30% 用双周节拍；超过 30% 说明需求管理本身有问题，先治需求再谈资源。

4. 第四层 规则层：优先级与仲裁机制

规则层要回答三个问题，且答案必须写下来、公示、可追溯。

1. 优先级怎么定：用结构化打分，维度建议为战略匹配度、收入影响、合规风险、依赖阻塞度，各占权重。避免“按领导重视程度”这种不可复现的标准。
2. 冲突怎么仲裁：设立一个三人左右的仲裁小组，包含 PMO、业务方代表、技术负责人。约定 48 小时内出结论，结论必须写入资源台账。
3. 例外怎么记录：每次绕过规则的操作都要留痕，每月统计例外率。例外率超过 20% 说明规则本身不合理，需要修订而不是加强执行。

5. 一个可以直接用的容量计算式

下面这段不是代码，是我在多个项目里用过的容量计算式，可以直接搬到表格里当公式用。它的作用是把“感觉人不够”变成“具体缺多少个等效人月”。

可承诺容量（人时/月）
= 池内人数

× 月均工作日（21.75）

× 日标准工时（8）

× (1 – 假期与培训占比) // 经验值 0.10 ~ 0.14

× (1 – 会议与协作占比) // 经验值 0.12 ~ 0.20

× (1 – 支持与事务占比) // 经验值 0.06 ~ 0.12

× (1 – 碎片化损耗系数) // 经验值 0.05 ~ 0.10

缺口（人月）

= Σ(需求所需容量) / 可承诺容量 – 现有池容量

示例：池内 30 人，需求侧合计 41.5 人月

75 × 8 = 174 小时/人月
174 × 0.88 × 0.82 × 0.90 × 0.93 ≈ 105 小时/人月 ≈ 13.1 人天

30 人 × 13.1 人天 = 393 人天 ≈ 19.7 人月（按 20 人天/人月折算）

缺口 = 41.5 – 19.7 ≈ 21.8 人月

这个式子最重要的作用不是算出 21.8 这个数字，而是让讨论从“我觉得忙不过来”变成“我们缺 21.8 个人月，是要延期、要外包，还是砍范围”。前者只能吵架，后者可以直接决策。

五、一个 1200 人企业的 90 天：数据与三个反常识发现

前面的框架听起来顺理成章，但真实落地远没有那么干净。我把一个完整案例拆开讲，包括我们走错的路。

先说明数据来源：以下数字来自该企业 PMO 的月度台账、项目复盘记录和我的访谈笔记，涉及效率对比的部分为同期口径测算，个别指标为示意数据，我会标注。

1. 起点：Excel 台账加每周例会

这家企业做企业级软件，1200 人，研发约 620 人，分 5 条产品线、11 个交付团队。2023 年底的状况是：人力台账由 3 个人分别维护三份 Excel，口径各不相同；资源协调会每周一次，平均 2.5 小时；冲突升级到高管层的比例约 34%。

最要命的是数据不可信。同一个部门，HR 报 68 人，项目台账写 79 人，财务的成本分摊表又是 71 人。三个数字打架的时候，任何资源决策都变成了政治博弈。

2. 第 1 到 30 天：只做口径统一和技能矩阵

第一个月我们什么工具都没上，只做了两件事。第一是定义三级工时口径，并让财务、HR、PMO 三方签字确认。第二是把 620 名研发的技能标签化。

技能矩阵这一步花的时间远超预期。原计划两周，实际用了 23 天，主要卡在两个地方：一是标签粒度争论不休，二是团队负责人倾向于给下属打高分。最后我们用了一个笨办法，让每个人提交三个“最近半年实际交付过的能力证据”，由技术负责人交叉校验，虚标率从初版的 31% 降到 9%。

3. 第 31 到 60 天：建时间桶，跑第一次滚动计划

第二个月建立 6 个月的时间桶，把所有在途和规划中的需求放进去。第一次跑完，结论让所有人意外：按可承诺容量计算，未来两个月的需求总量超出了 27%，但其中 41% 的需求优先级打分低于 60 分。

也就是说，冲突的大头不是“重要的事抢不到人”，而是“不重要的事占着人”。这个发现直接推动了需求侧治理，低分需求统一进入待定池，不占用当期容量，一下子释放出约 18% 的容量。

这个月还发生了一次典型的反扑。某产品线负责人坚持要把自己的三个低优先级需求留在计划内，理由是“万一能做呢”。我们没有强行砍，而是把这些需求标注为“机会型”，明确告知：一旦占用容量，将在下月计划中自动置底。两个月后，他自己撤掉了两个。

4. 第 61 到 90 天：规则落地，用 PingCode 承接

第三个月才引入系统。选择 PingCode 的原因很实际：它的产品线覆盖项目集、需求、迭代、工时和资源视图，能把我们前面用 Excel 跑通的“时间桶 + 资源池 + 技能标签”直接映射成系统对象，不需要再做一层中间表。

对 100 人以上、多产品线并行的中大型组织来说，这一点比功能清单重要得多。很多平台的资源视图是事后统计，而我们需要的是事前预占，在需求排进时间桶的那一刻就能看到容量水位，而不是月底才知道超了。

落地的具体做法是三步：把技能标签同步成人员属性；把时间桶映射成月度计划视图，设置容量红线预警；把仲裁结论作为正式字段写入需求记录，形成可追溯的决策链。

需要说明的是，工具本身没有让冲突变少。让冲突变少的是前两个月建立的规则，工具只是把规则变成了每天都会看到的默认界面。这个顺序如果反过来，大概率会失败。

5. 结果与三个反常识发现

90 天结束时的对比数据如下（效率类指标为同期口径测算，部分为示意数据）：

第一个反常识发现：冲突数量下降最快的时点，出现在第二个月，而不是系统上线之后。真正起作用的是“把低优先级需求移出计划”这个动作，工具上线只是让效果稳定下来。

第二个反常识发现：技能矩阵带来的收益，主要不是调度效率，而是减少了争论。以前讨论“能不能换人”要开半小时会，有了标签和证据记录，五分钟就能有结论。会议时长从平均 2.5 小时降到 55 分钟。

第三个反常识发现：高管介入次数减少之后，决策质量反而提高了。升级率从 34% 降到 11%，但每次升级的问题都是真正需要跨部门权衡的，讨论深度明显增加。这印证了前面的判断，70% 的冲突本就不该到这里。

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

同样的方法，在不同规模的组织里要换不同的做法。下面按人数分三档给出建议，再按业务形态补充差异。

1. 100 人以下：轻量台账加双周节拍

这个规模不要建复杂的体系。我见过 60 人的团队搞了一套九宫格加继任计划，最后维护成本比收益还高，半年后全部废弃。

该做的三件事：一张共享资源台账（人、技能标签、当前占用）、双周一次的 30 分钟协调会、一条明确的优先级规则。不需要专职 PMO，由一位项目负责人兼任即可。

该放弃的：技能熟练度分级、容量精算、月度滚动预测。这个阶段用不上精度，用得上的是让所有人看到同一张表。

2. 100 到 500 人：资源池加技能矩阵加月度滚动

这是我建议大多数中大型组织起步的档位，也是投入产出比最高的区间。核心配置是三样：分产品线或职能的资源池、30 到 50 个标签的技能矩阵、月度滚动的时间桶。

这个规模开始需要专职或半专职的 PMO 角色，但不需要大团队。我的经验配置是 1 到 2 人，重点是维护口径和主持仲裁，而不是做报表。

工具在这个阶段值得投入。多产品线并行、跨团队借调频繁，靠 Excel 维护的账实一致率通常只能做到 70% 左右，再往上必须靠系统约束。

3. 500 人以上多产品线：PMO 建制加系统化加仲裁委员会

到了这个规模，冲突已经不可能靠个人协调解决，必须建制化。需要的是三层结构：资源经理负责日常调配，PMO 负责口径、节拍和仲裁组织，管理层负责战略级优先级。

仲裁委员会要真正运转，必须有两个保障：明确的决策权限（不需要每次请示）和固定的裁决时限（48 小时内）。没有这两条，委员会会变成第二个扯皮会。

这个阶段工具的作用从“记录”变成“约束”。资源预占、容量红线预警、跨项目视图这些能力，决定了规则能不能被执行到位。像 PingCode 这类覆盖项目集和资源视图的平台，在这类组织里通常承担的是把规则固化到日常操作路径上的角色。

4. 三类业务形态的差异

规模之外，业务形态的影响同样大。同样的框架，侧重点完全不同。

• 研发型（产品自研）：重点是技能稀缺管理。关键专家通常只占 5% 到 10%，但他们决定 60% 的关键路径。要做的是专家梯队和结对机制，而不是简单排期。
• 交付型（项目外包/实施）：重点是容量与合同的匹配。冲突往往来自签约时的乐观承诺，治理点在售前而不是执行。需要建立“人月供给曲线”并强制售前参考。
• 运维型（持续服务）：重点是排班与弹性。冲突表现为突发工单挤占计划工作，治理点在于设置固定的计划工作保护时段，通常建议不低于总工时的 40%。

5. 工具选型的判断清单

我不建议从功能列表开始选型，而应该从“你的规则需要系统提供什么约束”开始。下面这张表是我常用的对照清单。

按这张表去对照，会发现很多平台的资源模块只满足“事后统计”，不满足“事前预占”。这个差别决定了工具是帮你解决问题，还是帮你在事后更清楚地看到自己没解决问题。

对 100 人以上、多产品线并行的组织，我一般建议优先看那些把项目集、需求和资源视图打通的产品。PingCode 在这方面的路径比较直接：需求进入计划视图时就能看到所属资源的容量占用，仲裁结论可以留在需求记录里形成链。对交付节奏快、跨团队借调多的组织，这种“同一份数据在不同视图下复用”的设计，比多一个报表功能有用得多。

七、取舍：没有“全都要”的方案

写到这里必须说清楚一件事：人力计划不是越精确越好，也不是越集中越好。每一个选择都有代价，关键是知道自己在付什么。

1. 精度与敏捷的取舍

追求精度意味着更长的计划周期和更稳定的需求假设；追求敏捷意味着接受一定程度的资源闲置和频繁调整。这两者不可兼得。

我的判断标准是需求稳定度：月度变动率低于 15% 的组织，把精度做上去，收益明显；高于 30% 的组织，把精度做上去基本是浪费，不如把节拍缩短、把缓冲留足。

2. 集中调配与团队自治的取舍

集中调配能提高整体利用率，但会带来响应速度下降和团队归属感削弱。团队自治响应快、士气高，但容易出现资源孤岛和整体次优。

我倾向于混合模式：常规容量下放给团队，稀缺技能集中管理。也就是 80% 的人力由团队自己安排，20% 的关键资源进中央池，由 PMO 统一调度。这样既保留了灵活性，又管住了最要紧的那部分。

3. 利用率与弹性的取舍

把利用率推到 95%，短期报表很好看，长期会用交付延期和人员流失来还债。留 15% 到 25% 的缓冲，看起来“浪费”，实际上是组织吸收波动的能力。

这个取舍在财务口径上尤其容易出错。财务报表看的是人力成本摊薄，管理者看的是交付确定性，两个目标天然冲突。我的建议是明确把“缓冲容量”作为一项正式预算科目列出来，让它可见，而不是藏在利用率的分母里。

4. 自建与采购的取舍

自建的好处是贴合业务，坏处是维护成本和人员依赖。采购的好处是开箱可用，坏处是必须迁就产品的对象模型。

我的经验分界线：如果核心需求是“把现有规则固化”，采购更划算；如果核心需求是“处理独特的资源约束逻辑”（比如带地理位置的现场服务调度），自建或深度定制更合适。中间地带建议先采购跑半年，用真实数据判断哪些是产品缺失，哪些只是习惯差异。

5. 什么时候应该放弃做人力计划

这话听起来反直觉，但确实存在不该做的情况。当组织处于剧烈重组期、业务方向月度级调整、或者管理层并不打算遵守计划约束时，做精细的人力计划只会消耗信任。

这种情况下更实际的做法是：只做容量看板和冲突记录，不做承诺排期。等组织稳定下来再推进。硬推的结果通常是 PMO 背了所有延期的锅，而问题一个都没解决。

八、总结：把冲突从突发事件变成可管理的日常

回到开头那个会议室。三个人都在同一行填了 100%，这不是谁的责任心问题，而是整个组织缺少一套把“人的时间”当资源来管理的语言。PMO 从 0 到 1 要建的，就是这套语言。

1. 三句话概括

第一句：资源冲突的根因是可见性和规则缺失，不是产能不足。先把账算对，再谈加人。

第二句：从 0 到 1 只做四件事，口径、池子、节拍、规则，顺序不能乱，工具放在最后。用 Excel 把规则跑通两个月，再上系统。

第三句：精度要匹配业务节拍，利用率要留出缓冲，治理模式要混合而非极端。每一个“更精确”的选择，都在别处付代价。

2. 三十天行动清单

如果你准备下周就开始，我建议按这个顺序推进，不要跳步。

1. 第 1 周：拉齐 HR、财务、PMO 三方的人员口径，确认一个数字作为基数，签字留档。
2. 第 2 周：测算你所在组织的容量折损率，用本文的式子跑一遍，得到可承诺容量的真实值。
3. 第 3 周：为 20 到 30 名关键人员建立技能标签，用“近半年交付证据”校验，先做小范围。
4. 第 4 周：建一个三个月的时间桶，把在途需求放进去，按容量红线标出超载月份。
5. 第 5 到 8 周：跑第一次滚动计划，把优先级低于阈值的需求移出当期，观察容量释放情况。

3. 下一步该做什么

如果你现在只能做一件事，我建议做这个：把下个月所有项目的资源需求汇总，按本文的容量式子算一次总账，看看超出多少。这个动作通常只需要两天，但它会给你一个之前从未有过的数字，你到底缺多少，或者你到底有多少容量被低优先级的事情占着。

有了这个数字，你就可以决定下一步是砍范围、调优先级、还是真的去要人。而在此之前，所有的讨论都只是在互相确认“我们都很忙”。

资源冲突不会消失，多项目并行的组织永远会有冲突。成熟的组织和混乱的组织，差别不在于有没有冲突，而在于冲突是被提前预见并规则化处理的，还是每次都要靠一场会议重新博弈。前者的成本是可预算的，后者的成本会随着规模扩大而成倍上升。