资源管理资源全流程：项目负责人协同管理与一文讲清

去年冬天，我在一家做工业软件的公司旁听他们的月度资源会。投影上是一张 87 行的人力排期表，颜色标得很漂亮，绿色代表空闲。项目经理老周指着 3 月第 2 周说：这里显示还有 2.5 个人力，为什么我提的三个需求都说没人？职能主管回了一句：那 2.5 个是名义上的，其中一个人下个月要离职、正在交接，一个在客户现场驻场，还有半个是实习生。会议室安静了五秒，然后大家开始讨论下一个议题。

那个五秒的安静，几乎概括了我见过的绝大多数资源管理失败：表格没有错，错的是表格里的数字从来没有被定义过。名义可用率、真实可用率、承诺、意向、预留、缓冲，这些词在不同人的嘴里指的是不同的东西，而项目负责人要去抢的，恰恰是这些没有被定义清楚的东西。这篇文章我想把"资源管理全流程"这件事从头到尾拆一遍：从需求进来、到承诺形成、到执行偏差、到回流修正，中间项目负责人到底该协同什么、凭什么协同、协同不了的时候怎么裁决。

一、核心结论：资源管理管的是"承诺"，不是"人"

先把结论摆在前面，后面所有内容都是为这几句话做论证。资源管理的对象从来不是人，而是"承诺"，谁在什么时间段、以多高的投入比例、为哪个交付物、做出了什么等级的承诺。人只是承诺的载体。当一个组织把资源管理做成"人员名单 + 排期格子"，它管的其实是载体，而不是内容，于是永远在救火。

1. 结论一：全流程的四个环节，缺一个就会退化成排期表

我把资源全流程拆成四段：需求归集 → 容量核定 → 承诺形成 → 偏差回流。这四段是一个闭环，不是四个动作。

• 需求归集：把"要做的事"变成可比较的资源请求，带优先级、带交付窗口、带技能标签。
• 容量核定：算出真实可用容量，而不是编制人数乘以 100%。
• 承诺形成：把容量分配成有等级、有记录、有owner的承诺条目。
• 偏差回流：执行中出现偏差时，偏差要能反向修改承诺台账，而不是只在周报里被描述一次。

绝大多数团队做了第一段和第三段的一半，跳过了第二段和第四段。于是出现一个典型症状：排期表每周都在更新，但没有人知道上周承诺的东西为什么没交付。表格在动，承诺没动，这就是伪资源管理。

2. 结论二：项目负责人的协同难题，本质是接口问题而不是沟通问题

我特别反对把资源冲突归因为"沟通不到位"。沟通不到位是结果，不是原因。真正的原因是项目负责人和职能主管之间没有定义清楚的接口：谁有权把某个人从 A 项目调到 B 项目、调动需要什么信息、调动之后原项目的排期由谁负责修订、调动记录存在哪里。

接口不清的时候，唯一的解决办法就是"谁嗓门大谁赢"。这也解释了为什么很多技术能力很强的项目负责人反而拿不到资源，他们不擅长在会议上争夺，而组织的资源分配机制恰好只奖励争夺能力。这不是人的问题，是机制设计的问题。

3. 结论三：可视化不解决冲突，只让冲突提前暴露

这句话我想强调得重一点。把资源负荷做成热力图，不会让冲突消失，只会让冲突提前 2 到 6 周出现在你面前。很多团队上了可视化之后抱怨"问题变多了"，其实是因为以前看不见的问题现在被看见了。

所以正确的顺序是：先有裁决规则，再上可视化。反过来做，你会得到一个所有人都在看、但没人能改的红色热力图，三个月后它会被静音，然后退化成一张"例行展示用"的图。

4. 一句话框架

如果你只想记住一句话：资源全流程 = 用可比较的需求去占用可验证的容量，把占用结果写成可追溯的承诺，并让偏差自动回到台账。这句话里的四个"可"字，分别对应上面四个环节的质量标准。缺任何一个，流程就会退化成一张漂亮的排期表。

二、背景与真实场景：为什么资源冲突总在第三个月爆发

我复盘过自己参与的资源冲突案例，有一个非常稳定的规律：冲突的爆发点几乎总是集中在项目启动后的第 8 到第 12 周。不是第一周，也不是最后一周。这个时间点不是巧合，它对应着三个结构性原因的叠加。

1. 场景一：多头立项，资源在立项那一刻就被口头抵押了三次

第 1 到第 4 周，各个项目在立项。立项会上没人细算资源，因为"反正人是在的"。于是同一个后端架构师，在三个项目的立项材料里都出现了，每个项目都默认他能投入 50%。三个 50% 加起来是 150%，但没有人当时算这个加法。

到第 8 周，三个项目同时进入开发高峰，架构师开始三边救火。这时候冲突才被感知到，而感知到的时候，三个项目都已经对外承诺了交付时间。资源冲突的本质不是资源不够，是承诺在形成时没有被加总校验。

2. 场景二：职能主管的考核指标和项目交付不同频

这是矩阵型组织里最难解的一环。职能主管关心的是团队稳定性、技术债、人员培养、以及自己条线的交付质量；项目负责人关心的是本项目的里程碑。这两套指标在季度末会直接打架。

我见过一个很典型的做法：某公司的研发总监在季度初会把"支援项目 X 的人月数"写进职能团队的 OKR，权重 15%。结果那个季度资源到位率从 54% 提到了 81%。不是大家变配合了，是配合这件事终于有了记账的地方。

3. 场景三：名义可用率和真实可用率之间，有一条很宽的沟

做容量核定的时候，最容易犯的错是用"编制人数 × 项目投入比例"。一个 12 人的团队，理论产能 12 人月，如果按 80% 投入项目，就是 9.6 人月。而实际能落到项目交付上的，通常是 6 到 7 人月。

差额去哪了？我用一个实际观察来说明：在某 180 人的研发组织里，我们做过一次为期 6 周的时间去向抽样（每周随机抽取 40 人，记录 5 类时间的实际占比），结果如下。

4. 数据观察：真实可用率的经验区间

基于我自己跟进过的 9 个研发型组织（规模 80 到 900 人），从事核心交付的成员，其真实可用率大致落在 55% 到 70% 之间，中位数在 62% 左右。也就是说，如果你按编制人数做容量规划，你会系统性地高估 30% 到 45% 的产能。

这个数字我建议每个资源管理者自己去测一遍，因为行业差异很大：做客户定制交付的团队会更低，做标准化产品的团队会更高；有大量线上运维职责的团队会更低。但无论具体数字是多少，把"我以为的可用率"和"实测的可用率"这两个值同时写进容量台账，是我见过投入产出比最高的一次管理动作。

三、拆解常见误区：五个看起来对、实际在制造问题的做法

下面这五个误区，我在不同公司反复见到。它们的共同点是：每一个单独看都很合理，甚至是被管理教科书推荐的，但在资源全流程的语境里会造成系统性偏差。

1. 误区一：把资源管理做成一张人力表

人力表的问题是它是静态快照。它记录"张某某 3 月在第 2 项目"，但不记录他对什么做出了承诺、承诺的等级是什么、如果被调走会影响哪个里程碑。于是当冲突发生时，你只能看到"人在这里"，看不到"承诺在这里"。

判断一张资源表是否合格，我有一个很简单的测试：随便指一个人，你能不能在三秒内说出他当前所有承诺的交付物和时间窗口。如果做不到，这张表就只是排期表，不是资源台账。

2. 误区二：以为资源利用率越高越好

这是我认为危害最大的一个误区。利用率 100% 的团队，交付周期会趋近于无穷大，这不是修辞，是排队论的基本结论。当系统负载接近容量上限时，队列长度会非线性增长。

用具体的数字说：当一个团队的平均利用率从 70% 提到 85%，其平均任务等待时间通常会增加到原来的 2 到 3 倍；从 85% 提到 95%，等待时间会再翻一倍以上。这就是为什么看起来"更高效"的资源压缩，最终表现为交付变慢、插单能力归零。

3. 误区三：项目负责人越强势，越能拿到资源

短期看是对的，长期看是灾难。强势的项目负责人会拿到超额资源，代价是资源被配置到了优先级不是最高的事情上。更糟的是，这会训练整个组织：会叫的孩子有奶吃。于是一年后，你发现所有项目负责人都变成了谈判专家，而没有人认真做需求价值评估。

我在一家公司看到过这个后果：资源协调会从每月一次变成每周两次，每次 2 小时，参会 14 人。一年下来仅这一个会议就消耗了约 1456 人时，而这些时间换来的不是更优的资源配置，只是把争夺过程制度化了。

4. 误区四：用会议解决资源冲突

会议是裁决场所，不是解决手段。区别在哪？如果会议前没有带数据的方案选项，会议就只是把冲突从私下搬到台面上，然后以"再议"结束。

合格的资源协调会应该有这个结构：会前 48 小时分发资源冲突清单（含冲突项、影响范围、可选项 A/B/C 及各自代价），会上只做选择，不做信息同步。信息同步放在会前的文档里完成。我服务过的一个团队照这个改了之后，会议时长从 2 小时压到 35 分钟，决议执行率反而上升。

5. 误区五：把工时填报当成资源管理

工时数据是后视镜，资源管理需要的是挡风玻璃。工时能告诉你"过去两周这个人在哪几个项目上花了多少时间"，但不能告诉你"下个月他的承诺是否已经超载"。

更现实的问题是，工时填报的数据质量普遍不高。我抽查过三个团队的工时记录，与项目实际产出比对，偏差在 15% 到 30% 之间的比例相当高，主要来自补填、按比例平摊、以及"填个大概"。工时可以用来做趋势和校准，但不适合用来做承诺决策。

• 纯人力排期表: 冲突平均发现时延 11 天；说明=问题通常由交付延期反向暴露，属于事后发现
• 工时填报驱动: 冲突平均发现时延 18 天；说明=工时是后视数据，往往在月底汇总时才发现超载
• 每周资源协调会: 冲突平均发现时延 6 天；说明=靠人肉会议同步，发现较快但决议执行不稳定
• 负荷可视化看板: 冲突平均发现时延 3 天；说明=提前暴露是主要价值，但没有裁决规则时决议率低
• 承诺台账加月度裁决: 冲突平均发现时延 2 天；说明=偏差能自动回流，冲突在形成阶段即被拦截

说明: 这张图对比的是"发现时延"这一个维度，强调一个判断：越靠后的发现机制，修复成本越高，因为它留给调整的窗口越短。

四、专业判断逻辑：五条判断规则与三个裁决口

这一节是我认为整篇文章最有价值的部分，因为它不是流程描述，而是在信息不完整、意见不一致的时候，凭什么做判断。资源管理的日常决策几乎全部发生在模糊地带，规则比工具重要。

1. 判断一：先给资源定价，再谈排期

资源的价格不是钱，是机会成本。同一个高级前端，投入到 A 项目意味着 B 项目延后 3 周。如果你不把这个代价显性化，所有资源请求都会显得"很急且免费"。

我的做法是给每类稀缺角色标一个"占用成本"：不是金额，而是"占用 1 人月 = 其他项目平均延后多少天"。这个数字一旦公开，需求方自己就会开始排序，因为他们终于看到了自己要付的账。

2. 判断二：承诺必须分级，不分级就等于没有承诺

我在实践中固定用三级承诺。这套分级最大的价值是让"没承诺"变成一个可以被说出口的状态，而不是所有人都含糊地说"我尽量"。

这张表看起来简单，落地时最难的是禁止软承诺进入基线。几乎所有的交付事故，都可以追溯到某个软承诺被当成了硬承诺写进对外计划。我建议把这条做成硬规则，宁可让计划看起来保守。

3. 判断三：设三个裁决口，其余场合不裁决

裁决口的意思是：只有在这三个时间点，资源冲突才会被正式处理，其他时间的冲突一律进入队列等待。这听起来很官僚，但它解决了一个真实问题，随时可以裁决等于随时被打断。

1. 立项口（每月一次）：新项目进入，必须校验资源加法。此时算总账，此时可以否决立项。
2. 月度滚动口（每月一次，与立项口错开一周）：处理未来 8 周的容量与需求错配，做承诺的升降级。
3. 周度异常口（每周 30 分钟）：只处理已经发生的偏差，不做新承诺，只做承诺的修订与再分配。

三个口的分工非常明确：立项口管"要不要做"，月度口管"能不能做"，周度口管"做歪了怎么办"。混在一起开，就会变成既没有战略判断也没有执行修正的例会。

4. 判断四：用容量缓冲吸收波动，不要用加班吸收波动

波动是必然的，问题是用什么吸收。加班吸收波动的成本被严重低估了：它看起来免费，实际成本体现在之后的效率下降、缺陷率上升和人员流失上。我在两个相似团队做过对比观察，长期靠加班吸收波动的团队，其季度缺陷密度比靠缓冲吸收的团队高 40% 以上。

缓冲的正确用法是显性预留：在容量台账里直接划出 15% 到 20% 作为"未分配"，并明确说明这部分的用途是吸收插单和故障。预留被消耗时要记录，消耗速度本身就是组织健康度的一个指标。

5. 判断五：偏差必须回流成信号，否则台账会腐烂

资源台账最常见的死法是"数据不再被信任"。原因几乎总是同一个：偏差发生了，但台账没有更新，于是台账逐渐偏离现实，最后没人看。

解决办法不是要求大家勤更新，而是把更新动作挂到已有的流程节点上：迭代结束时、里程碑评审时、人员变动时，各触发一次台账校验。让更新成为流程的副产品，而不是额外的负担。这一条我在后面 PingCode 的案例里会展开具体怎么落。

五、案例与数据观察：一个 420 人研发组织的资源台账改造

这一节我用一个具体案例来讲，因为抽象的原则讲再多，落地时的坑还是那些坑。案例对象是一家做智能硬件加配套软件的公司，研发体系约 420 人，其中软件侧 260 人，横跨 7 条产品线、同时并行 20 到 30 个项目。这家公司属于中大型企业规模，正是 PingCode 这类平台主要服务的对象区间（100 人以上组织）。

1. 改造前的状态：三张表、两个会、零个台账

改造前他们有两套东西在并行：职能侧用 Excel 维护人力表，项目侧用另一套 Excel 维护项目排期，两边通过每周一次的协调会对齐。我进场时做的第一件事是把两边的数据对了一遍，结果如下：

• 职能表里标记"3 月可投入"的 34 人次中，有 11 人次在项目排期里已经被占用；
• 项目排期里标记"已分配"的 27 人次中，有 6 人次在职能表里处于"待分配"；
• 两边对同一个人的投入比例，平均差异 18 个百分点，最大差异 50 个百分点；
• 过去 6 个月发生过 23 次人员调动，其中 15 次没有任何书面记录。

这些数字说明的不是执行力问题，而是他们根本没有一个单一事实源。两份数据各自都"对"，放在一起就都错了。

2. 改造的关键设计：把资源建成三种对象

这是我在 PingCode 里做配置时的核心思路，也是我认为可以复用到任何平台的思路：不要试图用一张表描述资源，要把资源拆成三种对象。

对象一：成员容量（Capacity）

成员 ID

可用周期（起止日期）

名义可用比例（按编制与岗位职责，如 100%）

真实可用比例（按实测校准，如 62%）

不可用时段（休假、驻场、培训、交接）

对象二：项目角色（Role）

项目 ID

角色名称（如"后端主程""测试负责人"）

技能标签（用于匹配，而非用于分配）

是否关键路径角色（true / false）

对象三：承诺条目（Allocation）

承诺 ID

成员 ID + 项目 ID + 角色

承诺等级（硬承诺 / 软承诺 / 意向）

投入比例（如 60%）

生效窗口（起止日期）

交付物（关联到具体里程碑或需求）

授权人（职能主管 + 项目负责人）

变更记录（谁、何时、为什么、影响哪个里程碑）

这三种对象分开建之后，很多原本需要开会讨论的问题变成了查询问题：某成员在某个时间窗口的承诺比例总和是否超过真实可用比例，直接就是一个可以自动算出来的校验。超过 100% 就是硬冲突，超过 85% 就是预警。

3. 落地过程：90 天分三段推进

我在这个项目里坚持不搞一次性大上线，原因很实际：资源台账这种东西，如果第一版数据不准，团队就再也不会信任它。所以前 30 天的目标不是"管起来"，而是"让数据值得信"。

1. 第 1 到 30 天：只做容量核定，不做分配。把 260 人的真实可用比例测出来，把不可用时段录进去。这一阶段不碰项目分配，避免引发资源争夺。
2. 第 31 到 60 天：只做承诺登记，不做裁决。把过去已经存在的口头承诺补录成承诺条目，标注等级。这一阶段的产出是一张"现状快照"，通常会让管理层第一次看到超载的真实程度。
3. 第 61 到 90 天：接入三个裁决口。月度滚动口和周度异常口开始运转，承诺的升降级开始走书面流程，偏差开始回流。

我特别想强调第二阶段的价值。补录承诺的时候，你会发现大量"意向"被当成了"硬承诺"在用。把这些意向显性降级，是改造中收益最大也是最疼的一步，因为它等于当场告诉几个项目负责人：你原来的计划不成立。

4. 结果数据：六个指标的前后对比

下面是改造前后各取 6 个月的数据对比。需要说明的是，这些数字来自该公司的内部统计，我参与了指标定义和数据核对，样本是该研发体系下的 27 个项目。

5. 冲突来源的帕累托：真正该修的只有两项

改造进行到第 4 个月时，我们从台账里导出了全部 186 条冲突记录，按来源归类。结果非常集中：前两类占了近 68%。这个发现直接改变了后续的改进重点，原本管理层以为主要问题是"人不够"，数据说不是。

6. 一个反例：为什么另一家公司同样的方案失败了

同年我还跟进过另一家规模相近的公司，用了几乎相同的对象模型和流程设计，但半年后回访时，台账已经废弃。差别在哪？我复盘出三点。

• 他们的职能主管没有参与承诺授权。承诺全部由项目负责人单方登记，职能侧不认账，于是硬承诺在职能眼里只是软承诺。
• 他们没有真正的裁决口。月度会开了，但所有冲突都以"再评估"结束，没有一次正式的否决或降级。三次之后，大家就不带问题来了。
• 他们的第一版数据是估的。为了赶上线时间，真实可用比例直接用了 85% 的默认值，导致所有校验都失效，团队第一次用就发现"这表不准"。

这三点对应的正是本文第一节的结论：承诺要有双方授权的接口、要有裁决规则、要有可验证的容量。工具和对象模型可以复制，这三样只能自己建。

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

资源管理没有统一答案，只有匹配当前组织形态的答案。下面按规模和形态给建议，你可以直接对号入座，也可以看相邻两档找过渡路径。

1. 按组织规模：从"先记账"到"先定权"

50 人以下：不要上系统，也不要建复杂台账。这个阶段资源冲突的绝对数量很少，一张共享的承诺清单（谁、做什么、到什么时候）足够。重点是把"口头承诺"变成"写下来的承诺"，这一步的收益远超任何工具。

100 到 300 人：这是资源管理开始失效的临界区间。建议做两件事：核定真实可用比例（抽样即可，不必全量），以及建立月度滚动口。这个规模通常已经可以引入专业平台，因为跨 5 个以上项目后，Excel 的维护成本会快速超过平台成本。

300 到 1000 人：必须有三层裁决口和分级承诺。这个规模的组织里，资源冲突往往是跨部门的，靠人际关系协调的成功率会明显下降。同时要开始关注关键角色的单点依赖，通常只需要管住 5% 到 8% 的关键岗位，就能消除一半以上的高风险冲突。

1000 人以上：重点从"管资源"转向"管规则和度量"。总部定承诺分级标准和度量口径，各事业部按自己的业务节奏落地。此时最大的风险是标准过度统一，用同一套缓冲比例要求需求波动差异极大的业务线，会导致合规但低效。

2. 按组织形态：三种矩阵的协同重心不同

• 项目型组织（人是项目的人）：协同重心在项目之间的资源交接。核心机制是项目结束时的资源释放与再分配规则，要防止项目末期人员闲置而新项目抢不到人。
• 职能型组织（人是部门的人）：协同重心在职能主管的考核指标。如果职能 KPI 里没有"支援项目的记账"，再好的流程都会被架空。
• 强矩阵（双线汇报）：协同重心在承诺的双方授权。这一类最容易出现"两份数据都真"的情况，必须强制单一事实源。

3. 落地路线：90 天三阶段清单

下面这张路线图是我在多个项目里反复调整后的版本，注意它的顺序刻意把"裁决"放在最后，因为前两阶段是在建立可信度，没有可信度的裁决只会引发对抗。

4. 如果你只有两周：三件立刻能做的小事

1. 抽 20 个人，问一个问题的答案。让他们列出当前所有承诺的交付物和截止时间。如果他们说不出或者说不全，你就找到了第一个要修的地方。
2. 把下一次资源协调会的材料提前 48 小时发。材料里必须有可选项和代价，会上只做选择。这一条改动几乎零成本，效果立竿见影。
3. 给所有在册承诺加一个等级字段。哪怕只是一个下拉框，标上"硬/软/意向"，你会发现大量对外计划建立在"意向"上。

七、不同情况下的取舍：四个必须想清楚的权衡

讲完怎么做，我想讲清楚哪些地方必须做选择。资源管理的难点不在于不知道方法，而在于每个方法都有代价，你要选自己付得起的那一份。

1. 取舍一：资源透明度 vs 组织政治成本

资源完全透明，意味着每个人的分配都可见。好处是冲突无法隐藏，坏处是它会放大部门之间的比较心理，也会让"某个团队长期资源不足"这类敏感事实公开化。

我的判断是：对承诺透明，对个人利用率半透明。也就是所有人都能看到"某角色在某项目上被承诺了多少比例"，但不做个人维度的利用率排行。前者服务于协同，后者只会制造防御行为。这个取舍在不同公司差别很大，如果组织文化本身互信度低，建议先做角色维度再做个人维度。

2. 取舍二：精细化程度 vs 维护成本

颗粒度越细，台账越准，但维护成本呈平方级上升。我见过把投入比例精确到 5% 的团队，结果是每周花 4 小时维护，而数据的实际决策价值并没有提升。

3. 取舍三：自建、表格还是专业平台

这个取舍我不建议按"哪个功能多"来定，而应该按冲突校验能不能自动化来定。因为资源管理里最耗人的动作就是加总校验，而这个动作恰恰最适合自动化。

• Excel / 在线表格：适合 5 个以内并行项目、承诺变更频率低的情况。上限很明显，跨表校验需要手工，一旦人数超过 100，维护成本会失控。
• 自建轻量工具：适合有稳定技术团队且流程已定型的组织。风险是流程一变就要改代码，且很难沉淀成组织能力。
• 专业平台：当并行项目超过 10 个、或组织超过 100 人时，平台的价值主要不在功能，而在强制所有人使用同一套对象定义。这一点是表格和自建工具很难做到的。

以 PingCode 为例，它的资源管理能力是挂在项目和工时体系上的，而不是独立模块，这个设计的实际意义是：承诺条目能直接关联到里程碑和需求，所以偏差回流不需要人工搬运数据。对于已经在这个平台上管理项目的组织，边际成本很低；对于完全没用过项目管理平台的组织，反而建议先解决项目管理的规范性，再谈资源台账。

4. 取舍四：强矩阵 vs 弱矩阵的授权边界

强矩阵下项目负责人对资源有较大调配权，响应快，但容易造成职能侧的技术债和人员消耗；弱矩阵下职能主管掌握资源，稳定性好，但项目响应慢。没有绝对优劣，关键看你的业务是交付驱动还是能力驱动。

交付驱动（客户定制、项目制交付）适合偏强矩阵，因为响应速度直接决定收入；能力驱动（平台型产品、技术底座）适合偏弱矩阵，因为能力沉淀需要稳定的团队边界。混着来的组织，建议按业务线分别设定，而不是全公司一刀切。

八、下一步：把资源管理变成一份可审计的承诺台账

回到开头那个会议室里的五秒安静。那五秒之后如果没有人追问"这 2.5 个人力到底是什么"，那么这家公司的资源管理就还会在原地循环很多年。我认为资源全流程的改造，本质上是一次把模糊语言替换成明确对象的过程：把"我尽量安排"换成"软承诺，窗口 3/1 到 3/20，未扣减"；把"人手紧张"换成"该角色未来 8 周承诺合计 137%，超出真实可用上限"。

语言一变，决策就会变。因为模糊的说法无法比较，明确的说法可以加总、可以排序、可以被否决。这也是我在整篇文章里反复强调承诺分级和偏差回流的原因，它们不是流程装饰，而是让资源这件事变得可讨论的前提。

1. 三个常见追问

问：小团队也需要承诺台账吗？需要承诺，但不需要台账系统。10 个人的团队用一张共享清单标清楚"谁、做什么、到什么时候、是硬还是软"就够了。台账系统的价值在 100 人以上才会真正显现，因为在那个规模，加总校验已经超出人脑的处理能力。

问：职能主管会不会觉得台账是在削弱自己的权力？这个担心很真实。破解办法是把授权动作设计成职能主管的权力而非负担，硬承诺必须由职能主管签字才生效，这实际上是给了他一个正式的否决权，而不是夺走调配权。我在案例里那家公司的做法是，把"承诺授权"写进职能主管的职责说明，同时在系统里留痕，让他的每一次授权都有据可查，反而提升了他在跨部门协调中的话语权。

问：数据不准怎么办，还要不要继续用？继续用，但要标注置信度。我的做法是给容量数据加一个"实测/估算"标记，估算数据不参与硬承诺的校验，只用于趋势观察。承认数据不完美，比假装它准确要健康得多，因为前者会推动持续校准，后者只会导致一次崩塌式的信任丧失。

2. 我建议你现在就做的三件事

1. 本周内，测一次真实可用率。随机抽 20 人，记录他们过去两周实际投入交付的时间占比。这个数字会改变你对产能的所有判断。
2. 本月内，把所有现存承诺标上等级。哪怕只在一张表里加一列。你会发现有多少对外计划建立在"意向"之上，这个发现本身就足够推动改变。
3. 下个季度，跑通一个裁决口。不要三个一起上，先跑月度滚动口，用一个季度验证"决议能不能被执行"。能执行，再扩；不能执行，先修授权机制。

资源管理最容易犯的错，是把它当成一个工具选型问题。它其实是一个把承诺变得可计算、可追溯、可裁决的组织设计问题。工具只是让这套设计跑得更省力，而设计和规则，只能由组织自己长出来。当你下一次在会议室里听到"这里还有 2.5 个人力"的时候，希望你能问出那句最关键的话：这 2.5 个人力，对谁做出过什么等级的承诺？