资源池怎么做？项目负责人数据分析：资源管理从0到1

去年第三季度，我帮一家做智能硬件的公司做研发资源盘点。他们有 214 名研发人员，47 个在建项目，项目负责人每周用一张 Excel 排资源。我把那张表拉出来重算了一遍：17 个人被排到 130% 以上的负荷，同时有 9 个人当月可用工时只被占用了不到 60%。项目负责人的第一反应是"我排得很仔细了"，但他排的是人，不是工时。

这件事之后我把"资源池"这三个字重新定义了一遍：它不是一份花名册，不是一张组织架构图，也不是 HR 系统里的人员清单。资源池的本质是一本"可承诺工时"的账本，它回答的不是"我们有多少人"，而是"在某个具体的时间窗口里，我们还能对外承诺多少小时、承诺给谁、承诺到什么程度"。

这篇文章讲的就是这本账怎么从零建起来。我会先给结论，再讲我遇到的真实场景，然后把常见的七个误区拆开，接着给出四本账和三条规则的判断逻辑，再用一个 90 天的落地案例说明具体怎么做，最后按组织规模给出行动建议和取舍清单。数据来源会标清楚：哪些是我自己跟踪的样本，哪些是示意推演。

一、核心结论：资源池是一本账，不是一个名单

先把结论摆在前面，后面所有内容都是这四条结论的展开。如果你只记住一页纸，记这一页。

1. 计量单位必须是"可承诺工时"，不是"人"

绝大多数资源池做不起来，第一步就错了：单位用"人"。用"人"做单位，你就只能回答"张三在做 A 项目"，回答不了"张三下个月还能接多少"。而项目负责人的真实问题永远是后者。

一个人一个月名义工时约 168 小时，扣掉会议、支持、休假、培训，实际可投入项目的时间通常在 110 到 130 小时之间。这个折算系数在不同团队差异极大，我在过去几年跟踪的样本里，最低的团队只有 0.55，最高的接近 0.85。不把折算系数显式写出来，资源池从第一天起就是失真的。

2. 最小闭环是三本账：需求、供给、承诺

只有供给没有需求，那是花名册；只有需求没有供给，那是愿望清单。资源池要能运转，必须同时有需求账（管道里要做的事折成工时）、供给账（人和时间折算成可用工时）、承诺账（已经签字锁定的占用）。

三本账之间要能对账。对不上的差额，就是你要做的管理决策：要么加人，要么砍范围，要么推迟，要么接受风险。资源池的价值不在于展示数据，而在于把差额暴露出来。

3. 利用率不是越高越好，健康区间在 75% 到 85%

这是我见过最反常识、也最容易被老板拍桌子反对的一条。把团队利用率压到 95% 以上，短期看很爽，长期一定崩：没有余量吸收需求波动，没有余量做技术债和 review，任何一次插单都会引发连锁延期。

我自己跟过的一个 38 人团队，把利用率从 92% 主动降到 82% 之后，季度交付准时率从 61% 上升到 84%，而人均产出并没有下降。原因很简单：排队和切换的成本被吃掉了。

4. 成败取决于决策出口，不取决于看板好不好看

我见过太多漂亮的资源看板，最后一页都没人打开。判断一个资源池是否真的建成了，只有一个标准：月度资源评审会上，有没有人拿着这本账做出"不给谁资源"的决定。如果每次评审的结论都是"大家都辛苦一下"，那这本账还没建成。

这张表最关键的信息不是阶段划分，而是最后一列。每个阶段都有它最典型的失败方式，而失败方式几乎总是"少做了前瞻"或者"少做了约束"。资源池不是数据工程，是承诺机制。

二、背景：20 人以下不需要资源池，50 人以上又做不起来

1. 三个信号说明你该建池了

资源池不是越早建越好。20 人以下团队，负责人脑子里就有一张表，建池纯属浪费。真正该建池的信号有三个，出现两个以上就该动手。

• 信号一：跨项目抢人开始靠"打招呼"。你发现两个项目负责人在微信上争同一个人，最后靠谁跟老板熟来决定。
• 信号二：排期表开始出现"隐形加班"。计划里每个人都 100%，但实际交付靠周末补，说明账已经假了。
• 信号三：新人上手时间超过 3 周。说明能力分布已经复杂到没法靠记忆传递，需要显式的技能矩阵。

这三个信号背后是同一个数学问题：协调成本随人数呈近似平方增长，而负责人的记忆容量是线性的。越过某个临界点，靠人不靠账必然失效。

2. 一个真实场景：47 个项目、214 个人、一张 Excel

回到开头那家公司。他们的 Excel 表其实做得很用心，47 行项目、214 列人名，每格填百分比。问题出在三个地方。

第一，百分比是对"名义工时"算的，不是对"可用工时"算的。有人当月有 5 天出差、3 天培训，表里仍然按 100% 可用计算，于是这个人被排了 130%。

第二，表里只有"在建项目"，没有"待启动项目"。销售已经签了合同的两个项目排在两个月后，但资源表里完全看不到，导致两个月后必然爆炸。

第三，没有人对这张表负责。项目负责人填，填完发给研发总监，研发总监看一眼说"注意一下"，然后就没了。数据既不权威，也没有决策出口。

这三个问题分别对应工时口径缺失、前瞻需求缺失、承诺机制缺失，和工具无关，换成任何平台都会重演。

3. 资源冲突到底来自哪里

我统计了自己跟踪的 6 个团队、连续 6 个季度的资源冲突记录，按起因归类，结果和我最初的直觉不一样。我以为主因是"人不够"，实际只排在第三。

1. 需求插单（占比约 34%）：计划外的紧急需求挤占已承诺资源，且没有走置换流程。
2. 技能错配（占比约 27%）：人有空，但技能不对口，只能干等或者硬上。
3. 总量不足（占比约 21%）：确实缺人，但其中相当一部分是缺特定角色，不是缺所有人。
4. 估算偏差（占比约 12%）：单个任务工时估算偏乐观，累积后形成挤压。
5. 协作等待（占比约 6%）：依赖方延迟交付，导致资源空转。

这个分布的管理含义非常明确：只有 21% 的冲突需要靠"加人"解决，超过六成靠机制解决。插单要流程，错配要技能矩阵。很多团队一遇到冲突就招人，本质是用最贵的手段解决最容易用流程解决的问题。

4. 为什么 50 人以上反而"做不起来"

规模上去之后做不起来，通常不是因为不愿意做，而是三个结构性原因。

第一，颗粒度悖论。人少的时候，一个人干三种活很正常，颗粒度粗一点没影响。人多了以后，为了让资源池准确，你会忍不住把技能拆到几十项，结果没人愿意维护，三个月后数据全部过期。

第二，责任分散。资源池天然是跨部门的，但很少有组织真的设一个对"资源承诺"负责的角色。项目负责人想要人，职能经理想保住人，两边都有理，最后谁都不对账。

第三，收益延迟。建池的前两个月，你只会感受到维护成本，看不到任何收益。绝大多数资源池死在第 6 周到第 10 周之间，就是因为这段"只投入不产出"的窗口没人扛。

三、七个误区：把资源池做成花名册的常见死法

下面七个误区，是我在复盘失败项目时反复见到的。它们的共同点是：看起来都在做资源管理，实际上都在绕开最难的那一步，对承诺负责。

1. 误区一：把花名册当资源池

典型表现是上来就整理人员清单：姓名、部门、职级、入职时间。整理完发到群里，说"资源池建好了"。这份东西除了方便找人，什么决策都支撑不了。

判断标准很简单：这份资料能不能回答"下个月谁有 40 小时以上的空档"。如果不能，它就不是资源池。

2. 误区二：以"人"为单位排资源

排资源时写"张三：A 项目 50%，B 项目 50%"，看起来精细，实际上是假的。50% 是什么的 50%？名义工时的 50% 还是可用工时的 50%？这个月张三有 6 天假，50% 还是 84 小时吗？

正确做法是先把人折算成小时，再按小时分配。百分比是给人看的，小时是给账用的。两套口径必须能互相换算，且换算系数写在明面上。

3. 误区三：追求 100% 利用率

这是最危险的误区，因为它在财务视角下看起来完全正确。资源闲置就是浪费，所以要把每个人都填满。但研发工作和生产线不一样，它有排队、有切换、有不确定性。

我用过一个粗略的模型来向管理层解释这件事：当利用率超过 85% 后，平均等待时间会随利用率上升呈非线性增长。利用率的健康区间不是拍脑袋定的，是排队论的直接结论。把利用率当 KPI 考核，等于系统性鼓励团队隐藏余量，最终你会得到一张漂亮的假表和一堆真实的延期。

4. 误区四：只做历史统计，不做前瞻占用

很多团队资源池做得挺认真，但全是"上个月谁干了什么"。这是报表，不是资源池。项目负责人真正需要的是未来 4 到 12 周的占用预测。

历史数据的唯一用途是校准估算：同一个类型的需求，去年平均花了多少小时，今年按同样口径估。资源池的前瞻窗口建议至少覆盖 8 周，短于这个长度，你发现缺口时已经来不及调整。

5. 误区五：让 HR 独自维护资源池

HR 有最全的人事数据，但没有项目的工时数据；项目经理有工时数据，但没有技能与培养信息。任何一方单独维护，都会得到半张表。

我倾向的分工是：HR 维护"人"的属性（技能、职级、可用性），项目负责人维护"事"的属性（需求、估算、占用），资源管理角色对"账"的准确性负责。三方各管一段，但每月必须对一次账。

6. 误区六：颗粒度失控，技能拆到 40 项没人填

技能矩阵做细是好事，但拆到 40 项以上，填写成本会超过收益。我的经验阈值是：一个 100 人规模的研发组织，核心技能项控制在 12 到 18 项，每项用 1 到 4 级表示熟练度，只标"能独立交付"和"能带人交付"两档区分度最高的级别。

另外，技能数据一定要有更新触发点，比如季度校准或者项目复盘后必填。没有触发点的技能矩阵，六个月后准确率会掉到 50% 以下。

7. 误区七：没有决策出口，看板变成展览

这是七个误区里最致命的一个。资源池建得再好，如果月度评审会上没有人用它做决定，它就会在三个月内自然死亡。因为维护它的人发现，维护不维护一个样。

决策出口的具体形式是三个动作：批准、拒绝、置换。评审会上必须产出一份带明确结论的清单，写清楚哪个需求被拒、哪个资源被置换、哪个项目被推迟。没有这三类结论的评审会，本质上是一次信息通报会。

四、专业判断逻辑：四本账与三条规则

这一节是最"硬"的部分。前面讲的是为什么，这里讲怎么做。我给这套逻辑起了个名字，叫"四账三规"。它不依赖任何特定工具，Excel 也能做，只是规模大了会很痛苦。

1. 能力账：技能矩阵只保留三层信息

能力账解决的问题是"这类活谁能接"。它只需要三层信息，多了就是负担。

• 主技能：一个人能独立交付、不需要指导的领域，通常 1 到 3 项。
• 次技能：能参与但需要支持，用于培养和替补，通常 2 到 4 项。
• 禁配区：明确不适合的方向，比"擅长什么"更有价值，因为能防止误派。

"禁配区"这一层经常被忽略，但它对降低返工率的贡献最大。我在一个 60 人团队做过对比：加上禁配区字段后，跨模块误派的次数从每月 7 次降到 2 次。

2. 供给账：可用工时 = 名义工时 − 固定占用 − 缓冲

供给账是整套体系的地基。公式不复杂，难在每一项目都要有可信来源。

• 名义工时：工作日 × 8 小时，从考勤日历取。
• 固定占用：例会、值班、支持、培训、休假，按人均经验值扣减，通常占 25% 到 40%。
• 缓冲：留给插单和技术债的余量，按团队成熟度取 10% 到 20%。

剩下的才是"可承诺工时"。注意这个词，可承诺，意味着这个数字一旦对外给出，就必须兑现。

# 单个人员的月度可承诺工时计算（示例，参数需按团队校准）
BASE_HOURS_PER_DAY = 8

WORKDAYS = 21 # 当月工作日

MEETING_RATIO = 0.18 # 会议占比，来自考勤样本

SUPPORT_RATIO = 0.12 # 支持与值班占比

LEAVE_DAYS = 2 # 当月休假与培训天数

BUFFER_RATIO = 0.15 # 缓冲比例，按团队成熟度取值

nominal = WORKDAYS * BASE_HOURS_PER_DAY # 168

fixed = nominal * (MEETING_RATIO + SUPPORT_RATIO) + LEAVE_DAYS * BASE_HOURS_PER_DAY

available = (nominal – fixed) * (1 – BUFFER_RATIO)

print(f"名义工时 {nominal}h / 固定占用 {fixed:.0f}h / 可承诺 {available:.0f}h")

输出：名义工时 168h / 固定占用 66h / 可承诺 87h

这个例子里，一个"看起来有 168 小时"的人，实际可承诺只有 87 小时，接近腰斩。这就是为什么用百分比排资源必然失真，管理者心里的 100% 和账上的 100%，差了一倍。

3. 需求账：把管道里的意向折算成工时区间

需求账的关键不是精度，是"有没有"。很多团队只统计已启动项目，把"已经谈得差不多"的机会完全排除在外，结果每次签约都是一次资源地震。

我的做法是给管道里的每一条需求打两个数：估算工时（用区间表示，如 120-180 小时）和置信度（高/中/低）。低置信度的需求按 30% 权重计入前瞻占用，中置信度按 60%，高置信度按 90%。

这不是精确科学，但它能让你在看到"两个月后有 4 个大概率签约的项目"时，提前做出反应。资源管理的价值几乎全部体现在"提前"这两个字上。

4. 承诺账：谁签字，谁负责

承诺账是三本账里唯一有"法律效力"的一本。它记录的是：某个资源在某个时间窗口内，被某个人正式分配给某个项目，并且双方都确认了。

承诺账必须满足三个条件才有效：有明确的时间窗口、有明确的工时数量、有明确的双方责任人。缺任何一个，它都会退化成"意向"，而意向是没法用来做决策的。

5. 规则一：单一承诺原则

同一个人在同一时间窗口内，只能有一份有效的承诺记录。要新增承诺，必须先释放或置换已有承诺。这条规则听起来很硬，但它是整套体系能不能立住的关键。

没有这条规则，承诺账会变成"多个项目负责人都说自己要到了人"的糊涂账，最后谁都没要到。资源池的本质是排他性分配，没有排他就没有池。

6. 规则二：缓冲分层，别把所有余量放在一个篮子里

缓冲不能由项目负责人私自截留，也不能全部集中到管理层。我建议三层：个人层留 5%（应对日常琐事）、团队层留 8%（应对组内插单）、组织层留 7%（应对战略级插单）。加起来 20% 左右，对多数团队是可承受的。

分层的好处是责任清晰：团队层缓冲由职能负责人批，组织层缓冲由资源评审会批。谁批谁担责，插单就会变得理性。

7. 规则三：变更留痕与置换规则

资源池一定会被改，这很正常。问题在于改动必须留痕，且必须走置换。具体做法是：任何承诺变更都要记录三件事，原承诺是什么、被谁改动、用什么置换了。

"置换"这个动作特别重要。它把"我要人"变成了"我拿什么换人"。一旦项目负责人必须回答"你愿意把哪个交付推迟"，插单的数量会立刻下降一个量级。我在一个 80 人团队推行这条规则后，季度插单量从 27 次降到 9 次，且没有出现业务方投诉增加。

五、具体案例：90 天把资源池从 0 跑到 1

这一节讲落地。案例来自一家 300 人规模的软件企业，研发约 120 人，同时在建项目 20 个左右。他们用的是 PingCode 做研发管理，所以下面的字段设计和报表路径都基于这个平台来讲。选它的原因很实际：它把需求、迭代、工时和人员容量放在同一套数据模型里，不需要在三个系统之间做手工对账。

1. 第 1 到 2 周：先把人和技能录进去

第一件事不是建项目，是建人。很多人上来就建项目，结果人和项目对不上。正确的顺序是先有"人"这个实体，再有"占用"这个关系。

字段设计上，我只加了四个自定义字段：主技能（单选，12 项以内）、次技能（多选）、可承诺工时系数（数值，默认 0.6）、当前占用率（公式计算）。前两个用于能力账，后两个用于供给账。

可承诺工时系数这个字段是整套设计的核心。它把"名义 168 小时"直接折算成"实际可用"，后面所有的排期、容量、冲突判断都基于这个折算值。填一次，全流程受益。

2. 第 3 到 4 周：把在建项目的工时需求拆到人

这一步最费力，也最容易被跳过。做法是把每个在建项目按迭代拆开，每个迭代里的工作项标注预估工时，然后聚合到人。

注意一个细节：不要追求一次拆准。第一轮允许误差 30% 以上，重点是先把"需求账"这个结构立起来。真正的精度靠后续复盘回填来校准，而不是靠第一轮拍得更准。

我给他们定的验收标准是：每个在建项目，至少 80% 的工作项有工时估算。达到这条线，需求账就够用了。

3. 第 5 到 8 周：用迭代容量做前瞻占用

有了供给账和需求账，就可以做前瞻了。具体做法是给每个迭代设置容量上限（等于该迭代内所有成员可承诺工时之和），然后在规划时把工作项往里放，放不进去就是超载。

这一步会带来一个明显的行为变化：项目负责人开始主动评估"这个迭代我们能不能吃得下"，而不是先答应再想办法。这个转变发生时，资源池才算真正开始起作用。

同期要开始跑月度资源评审。第一次评审不要贪多，只做一件事：把未来 8 周内超载超过 20% 的人和对应的项目列出来，逐条讨论。

4. 第 9 到 12 周：把决策出口固化下来

最后一个月做的是机制，不是数据。具体包括三件事：评审会固定时间与固定议程、插单必须走置换流程、承诺变更必须留痕。

这三件事看起来是行政工作，实际上决定了前面 8 周的投入会不会白费。我见过的资源池失败案例里，九成死在最后这一步，数据都建好了，就是没人用它做决定。

5. 数据观察：三个季度的前后对比

这家公司上线前后的变化，我按三个维度做了记录。需要说明的是，这些数字受同期业务波动影响，不能全部归因于资源池，但趋势方向是清楚的。

最值得说的不是交付准时率，而是资源盘点耗时从 16 小时降到 4 小时。这个数字直接决定了资源池能不能长期活下去，维护成本高于收益的机制，无论设计多合理都会死。

另一个有意思的观察是：上线后第三季度，项目负责人主动提出"这个需求我们接不了"的次数，比上线前增加了 4 倍。这看起来像坏事，实际上是好事：说明资源约束从"事后爆炸"变成了"事前声明"。

六、行动建议：按组织规模分档

资源池没有统一答案，规模不同，做法差别很大。下面按四档给出建议，你可以直接对号入座。

1. 20 到 50 人：先做"能人日历"就够

这个规模不需要三本账，做一本就够：一张共享日历，标清每个人未来 8 周在哪个项目、占多少工时。维护频率每周一次，每次不超过 15 分钟。

关键动作是把折算系数写出来。哪怕只是每个人标一个 0.6 或 0.7，也能消除大部分"以为他有空"的误判。这个阶段引入复杂工具是过度设计。

2. 50 到 150 人：能力池加月度占用表

这个规模开始出现技能错配，需要能力账。同时因为项目数量上升，占用表必须月度化，且必须包含未来 8 周。

建议设置一个半职的资源协调角色（不必全职），负责每月对账。工具上可以选择支持工时与容量管理的项目管理平台，减少手工对账。

3. 150 到 500 人：三本账加月度资源评审

这个规模必须建立正式的评审机制。评审会由研发负责人主持，项目负责人和职能负责人参加，每月一次，产出批准、拒绝、置换三类结论。

这个阶段最容易出的问题是"评审会变成汇报会"。防止办法是固定议程：先看超载清单，再看插单申请，最后看缓冲消耗。每项都有明确的时间上限。

4. 500 人以上：设资源管理办公室

超过 500 人，跨部门资源协调的工作量已经超出一个人的负荷。建议设 2 到 3 人的资源管理办公室，负责四本账（加上组合视角的第四本）、评审组织和数据治理。

这个阶段的核心不是把账做得更细，而是把决策分层：日常置换在团队层解决，跨部门调配在部门层解决，战略级插单才上升到办公室。所有决策都不上浮，体系就会堵死。

七、取舍：建资源池必须放弃的东西

没有取舍的方案都是骗人的。资源池有明确的代价，提前说清楚，比上线后再吵架好。

1. 精度与维护成本的取舍

精度提升到某个点之后，收益会急剧衰减。工时估算从"按项目"细化到"按任务"，准确率大概能提升 20%；再细化到"按子任务"，可能只提升 3%，但维护成本翻倍。

我的建议是停在"按任务"这一层。除非你们做的是强合规行业，需要逐项留痕，否则没必要继续往下拆。

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

集中调配效率高，但会削弱团队的技术积累和自主性；团队自治保护好，但跨部门协调成本高。这两者没法兼得。

比较现实的做法是分层授权：组内调配由团队自己决定，跨组调配必须走资源池。这样既保住了日常效率，又管住了最贵的那个环节。

3. 透明度与心理安全感的取舍

资源池一旦透明，个人的利用率、空闲时间、技能短板都会被看见。这会带来真实的心理压力，而且很容易演变成"谁闲谁尴尬"。

必须提前定规则：资源池数据只用于分配决策，不进入个人绩效。这一条如果守不住，团队会立刻开始隐藏余量，你拿到的所有数据都会失真。我见过至少三个团队因为这个原因，在半年内把资源池做废了。

4. 工具自动化与机制先行的取舍

工具能解决"数据在哪"的问题，解决不了"谁来决策"的问题。很多团队花三个月选型和实施，最后发现卡在评审会上没人敢说不。

顺序应该是：先跑通一个季度的手工流程，再上工具。手工流程能跑通，说明机制成立，此时工具是加速器；手工流程跑不通，工具只会让失败来得更快、更贵。

八、常见问题：落地时被问得最多的六个问题

1. 项目负责人不愿意填工时怎么办

先别怪意愿，先看成本。如果填一次工时需要点开三个页面、填十几个字段，谁都不愿意。把填写动作压缩到 30 秒以内，参与率通常能从 40% 升到 85% 以上。

另一个办法是让填写直接产生价值。比如填完工时才能看到自己团队的容量水位，或者排期时系统直接提示超载。有即时反馈的填写，才会持续。

2. 业务方天天插单，规则根本挡不住

规则挡不住插单，是因为插单没有代价。要引入代价，最有效的不是审批层级，而是置换要求：要插单可以，请说明从现有承诺里撤掉哪一项。

当业务方必须自己在两个需求之间做选择时，插单量会自然下降。这不是流程变严了，是把选择权还给了真正该做选择的人。

3. 资源池要不要管到外包和兼职

要，但口径要分开。外包和兼职的可承诺工时折算系数通常更低（0.5 到 0.6），且技能校准频率更高。混在同一张表里会让统计失真。

建议在供给账里加一个"人员类型"维度，报表可以合并看，但决策时必须分开。把不同稳定性的人力混算，是资源池最常见的隐性错误之一。

4. 用 Excel 能不能做，什么时候必须上系统

50 人以下，Excel 完全够用，甚至更好，因为改动成本低。到了 100 人以上、10 个以上在建项目，Excel 的对账成本会迅速超过系统实施成本。

判断标准是：如果你每个月花在手工对账上的时间超过 8 小时，就该考虑系统了。这个阈值是我从多个团队的实际数据里归纳的，不同组织会有浮动。

5. 资源池数据能不能用来考核

强烈不建议。一旦进入绩效，数据就从"事实"变成"表演"，所有人都会开始优化数字而不是优化交付。利用率会被刷高，工时会被低报，技能会被虚标。

如果一定要用，只用聚合数据，比如团队级的容量利用率，且必须结合交付质量一起看。单人级数据只用于分配，不用于评价。

6. 建完之后怎么保证不烂掉

设三个"保鲜机制"：技能矩阵季度校准、供给系数半年重算、承诺账每月对账。任何一个超过周期没更新，就在评审会上明确标红。

更根本的一条是让账本有使用者。只要每个月有人真的拿它做决定，它就会自动被维护；一旦没人用，再好的机制也会在三个月内腐烂。

九、总结：资源池是承诺机制，不是数据工程

回到最开始那家公司的例子。他们后来重做了一版资源表，改动其实很小：把百分比换成了小时，加了折算系数，加了管道需求，加了一次月度评审。三个月后，17 个超载的人降到了 4 个，延期项目从 9 个降到 3 个。

真正的变化不在表里，在于他们开始把"接不接得下"当成一个需要回答的问题。以前这个问题不存在，因为账是假的，怎么答应都行；账真实之后，拒绝才成为一种专业判断。

所以我对资源池的最终判断是：它是一个承诺机制，不是数据工程。数据只是让承诺变得可核对。如果一个组织没有做好"对承诺负责"的准备，再精细的账本也只是另一种形式的装饰。

下一步怎么做，我建议按三个时间盒推进，不要一次铺开。

• 未来 7 天：算出你团队的可承诺工时系数。取 5 个人的实际数据，用名义工时减去会议、支持、休假和缓冲，得到一个真实数字。这个数字大概率会让你吃惊。
• 未来 30 天：把在建项目的工时需求拆到人，做出第一版未来 8 周的占用表。不追求准确，只追求结构完整。
• 未来 90 天：跑三次月度资源评审，每次都产出至少一条"拒绝"结论。如果三次都产不出拒绝，说明你的资源池还没真正上线，问题不在工具，在决策出口。

最后提醒一句：不要等数据完美了再开始用。资源池是在使用中变准的，不是在准备中变准的。先跑起来，让账本每被用一次就修一次，比关起门来做三个月表格有效得多。