资源怎么做？项目负责人最佳实践：资源管理从0到1

2023年我接手过一个很典型的复盘：一家做工业设备的公司，年初立项12个项目，年底交付了9个，其中5个延期超过6周。老板的第一反应是"人不够，招人"。但我把三个月的工时数据拉出来之后发现，那段时间里这家公司的人均并行任务数是3.4个，真正用于项目交付的有效工时只占名义工时的61%，剩下的被会议、线上问题、售前支持、面试和返工吃掉了。也就是说，问题不是"人不够"，而是"人不知道被谁用、用了多少、还剩多少"。

这就是资源管理从0到1真正要解决的事。它不是排一张漂亮的甘特图，也不是把所有人的名字填进一张表，而是把"组织到底有多少可用产能、这些产能在为哪些目标服务、偏差出现时怎么纠偏"这三件事变成一套可被观测、可被讨论、可被复盘的机制。下面我按结论、场景、误区、判断逻辑、案例、行动建议、取舍的顺序，把这套机制拆开讲，中间会给出可以直接照抄的口径、公式和落地节奏。

一、先给结论：资源管理的本质是约束管理，不是分配管理

大部分团队做资源管理的起点是错的。他们从"这个项目要几个人"开始，于是资源管理变成了一个分人的动作：谁嗓门大谁先拿人，谁的项目挂在老板名下谁先拿人。分完之后没有任何人知道分得对不对，因为没有人算过总容量。

我的核心判断是：资源管理的顺序必须是"先算容量，再定优先级，最后才分人"。容量是分母，优先级是分子，分人只是这个除法做完之后的呈现结果。顺序一旦颠倒，你得到的永远是一张不断被推翻的排期表，而不是一套可以被信任的计划。

1. 三个必须先回答的问题

在动手建任何表格、任何看板之前，先回答三个问题。这三个问题答不上来，后面所有的工具都会变成摆设。

• 我们有多少产能？不是"有多少人"，而是"有多少个可用的人天，扣掉会议、支持、休假、培训之后还剩多少"。
• 产能该给谁？不是"谁先提需求"，而是"按什么规则排序，排完之后谁有权推翻这个排序"。
• 偏差怎么发现？不是月底看报表，而是"当某个人的实际投入偏离计划20%时，第几天能被看到"。

这三个问题对应三张表：资源台账、容量看板、分配决策记录。很多人一上来就做第一张表，做完发现没人维护，因为第二张和第三张不存在，台账就变成了一个静态的通讯录。

2. 从0到1的四件事，顺序不能错

如果让我把一个100人以上的组织从零带到"资源管理能跑起来"，我会按下面四步走，每一步有明确的完成标准，不达标不进下一步。

1. 统一口径（2-4周）。完成标准：全公司对"一个角色一个月有多少可用工时"有同一个答案，误差不超过10%。
2. 建立资源池与技能矩阵（3-6周）。完成标准：任何一个新需求进来，10分钟内能查出"谁能干、什么时候有空、空闲多少"。
3. 建立分配规则（4-8周）。完成标准：资源冲突有明确的裁决人和打分依据，而不是靠会议吵。
4. 建立反馈闭环（持续）。完成标准：计划投入与实际投入的偏差能在周级别被发现，并且有对应的纠偏动作。

这里最容易犯的错是跳过第一步直接做第二步。口径不统一的时候，做出来的资源池一定有水分：A部门按8小时算一天，B部门按6.5小时算一天，两边看板上都写着"张工本周空闲2天"，实际上一个是16小时一个是13小时，排期一排就崩。

3. 一个反常识结论：先建口径，再建池子

我见过太多团队花两个月选型、配置、导入数据，最后因为"工时口径不一致"导致整个看板没人信，项目就此停摆。工具的配置成本是可见的，口径的对齐成本是不可见的，而后者才是决定成败的那一项。

反过来说，如果你的口径已经对齐，哪怕暂时用电子表格，资源管理也能跑起来；如果口径没对齐，再贵的平台也只是把混乱搬到了线上。这条判断在后面的取舍章节还会展开。

先看一组我复盘过的样本：把过去三年参与诊断的27个团队的延期原因做归因，资源相关的原因（含资源冲突、关键技能单点、隐性占用未计入）占比接近一半，远高于需求变更。

二、真实场景：项目从12个到37个，人没少，产能却"蒸发"了

前面那家工业设备公司，2022年项目数是12个，2023年涨到37个，团队人数从180人涨到210人，人增了17%，项目增了208%。这是一个非常典型的增长错配：业务侧的立项速度远超组织侧的产能建设速度，中间那道缺口完全由"员工加班"和"交付质量下降"来填。

1. 第一个月：所有人都很忙，没人说得清在忙什么

我进场第一周做的事不是访谈管理层，而是让每个人填一张"上周你实际做了什么"的表，按半天为粒度。收回来之后的景象很一致：几乎没有人的时间能对上项目计划。

一个机械结构工程师的一周被切成了11段：3段在A项目的详细设计，2段在B项目的评审，2段在产线问题上，1段在给售前做方案，1段在面试，1段在培训，1段在填各种报表。他自己也说不清这一周到底推进了哪个项目，因为每一段都不够长，长到能出成果。

2. 第三个月：冲突开始以"抢人"的形式爆发

当并行项目超过某个阈值之后，资源冲突不再是"排期冲突"，而是"人际冲突"。表现形式是：项目经理开始在群里@某个人，开始绕过部门负责人直接找人，开始在周会上公开指责"某某部门不配合"。

这个阶段最危险的不是效率下降，而是信息开始失真。因为谁都知道说自己"很忙"能减少被分配的任务，于是所有人都说自己满负荷，真实的空闲被隐藏起来，管理层看到的永远是一个"全公司都饱和"的假象。

3. 第六个月：真正的成本是切换损耗

我在这个团队做过一次小范围测量：让6个工程师记录两周内每次任务切换的时间点和切换后的"重新进入状态"耗时。结果是平均每次切换损耗23分钟，一天切换4次以上的日子，当天的有效产出比切换1-2次的日子低32%。

这个数字和我在其他团队观察到的量级接近。并行不是免费的，它的价格是切换损耗乘以切换次数。当一个组织把"人均并行3个项目"当作高效率的象征时，它实际上在为每一次上下文切换付隐性税。

三、六个高频误区，我几乎在每个团队都能看到

资源管理之所以难，不是因为它复杂，而是因为它反直觉。下面六个误区，我在不同规模、不同行业的团队里都反复见到，其中前三个几乎是人人都踩过的坑。

1. 误区一：把资源管理做成排班表

排班表回答的是"谁在哪天做什么"，资源管理回答的是"我们有没有能力做这件事、值不值得做"。前者是执行层的副产品，后者是决策层的输入。把两者等同起来，会导致一个典型症状：排班表永远在做，但没有人用它来做决策。

判断方法很简单：如果你的资源表只在新项目立项时被打开一次，平时没人看，那它就是排班表，不是资源管理。

2. 误区二：只用人天，不看技能与时段

"这个需求需要15人天"是一个几乎无信息量的表述。它没有说明需要什么技能、需要在哪一段时间内完成、能不能拆给多个人。结果就是：账面上有15人天的空闲，实际上没有一个合适的人有空。

我建议的最小口径是三维的：角色 + 技能等级 + 时间窗口。缺任何一维，资源池都会在排期时失效。

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

这是我最想纠正的一条。利用率不是越高越好，它是一条倒U型曲线。当团队利用率长期高于90%，交付周期会非线性上升，返工率同步上升，因为没有任何缓冲去吸收估算偏差和突发问题。

我在多个研发团队观察到的甜蜜区大致在75%-85%之间，交付型项目（有明确验收节点、变更少）可以到85%-90%，而探索型、预研型工作应该压到60%-70%。把所有人排到100%，本质上是把风险全部转移到交付日期上。

4. 误区四：让项目经理兼任资源经理

这两个角色的目标函数是冲突的。项目经理要为自己的项目争取最多最好的资源，资源经理要在多个项目之间做最优配置。让一个人同时干这两件事，结果一定是他手上的项目优先级最高，因为那是他唯一能直接感知的痛苦。

100人以下的组织可以接受这种兼任，但必须有一个明确的"跨项目裁决人"，通常是技术负责人或交付负责人。300人以上就不要再兼了，一定要有独立的资源调度角色。

5. 误区五：先买工具，后定规则

工具会把现有流程放大，而不是修复它。规则没定的时候上工具，得到的是一个"数字化的混乱"：字段更多、报表更花、争议更大。

正确的顺序是：先用表格跑通一个季度的容量测算和分配决策，把规则跑出肌肉记忆，再上工具把规则固化下来。这时候工具的价值才是"降低执行成本"，而不是"制造新的管理动作"。

6. 误区六：资源池做成了通讯录

资源池的核心字段不是姓名、部门、职级，而是可用性、技能标签、当前承诺。一个只有前三项的资源池，和公司内网的员工名录没有区别，它不能支撑任何一次排期决策。

下面这张表是我用来判断一个团队的资源管理处在哪个阶段的对照，可以直接拿去自查。

四、专业判断逻辑：四层模型与三张表

把资源管理拆成四层，是我在实操中最常用的框架。它的好处是每一层都有明确的输出物，出了问题能定位到具体是哪一层断了，而不是笼统地说"资源管理没做好"。

1. 容量层：先算清"我们到底有多少产能"

容量的计算公式不复杂，难的是把每个参数的口径定死。我用的版本是这样的：

可用产能（人天）= 在岗人数 × 期间工作日 × 出勤系数 × 有效工时系数 − 固定占用

• 出勤系数：扣除年假、病假、法定假日后的实际出勤比例，通常取0.92-0.95。
• 有效工时系数：扣除会议、邮件、日常沟通后的专注工作时间占比，研发类岗位我一般取0.75-0.85，支持类岗位取0.65-0.75。
• 固定占用：已经承诺出去的、不可压缩的时间，比如运维值班、售前支持、面试、导师带教。

这里有一个必须强调的点：有效工时系数一定要用自己的数据测，不要抄别人的。同样是研发团队，一个会议密度高的团队可能只有0.68，一个远程异步协作的团队可能到0.88，用错系数会让整个容量模型偏差20%以上。

2. 分配层：用优先级而不是嗓门决定谁先拿人

分配层要解决的是"产能有限时，谁先拿"这个问题。我的做法是把它变成一个显式的打分，让争论从"我觉得我这个更重要"变成"我们来看这几项打分"。一个可以直接用的权重方案：

打分不是为了算出绝对值，而是为了让排序过程可被质疑。当有人说"我这个应该排前面"，你可以问"你在哪个维度上比他高"，讨论立刻从情绪转向事实。

规则里还要写清楚两件事：谁有权推翻排序（裁决人），以及推翻时需要付出什么（比如必须同步调整另一个项目的交付承诺）。没有代价的推翻，会让规则迅速失效。

3. 执行层：把"投入"变成可观测的消耗

执行层唯一的任务是让"实际消耗"变得可见。这里我强烈建议不要追求精确到小时的工时填报，那会引发强烈的抵触，且数据质量极差。按半天或按天填报，配合每周一次的一致性校验，比精确到小时但没人认真填要好得多。

执行层还需要一个常被忽略的字段：计划外工作。线上问题、临时支持、突发的客户演示，这些如果不单独记录，就会全部隐藏在"计划内任务"的进度里，让偏差看起来像是估算不准。

4. 反馈层：用偏差校准下一轮计划

反馈层是四层里最少人做的，也是最能体现专业度的一层。它的核心指标不是"完成了多少"，而是计划投入与实际投入的偏差率。偏差率长期偏一个方向的团队，说明它的估算有系统性错误，而不是执行不力。

我一般看两个数：单项目偏差率（衡量估算质量）和团队级偏差率（衡量容量模型质量）。后者如果稳定在±10%以内，说明容量模型已经可以用于对外承诺；如果长期在±25%以上，说明口径里还有没被识别出来的固定占用。

下面这段脚本是我常用的容量测算原型，先用它把口径算清楚，再决定要不要上系统。参数需要替换成自己团队的数据。

def capacity(headcount, workdays, attendance=0.93, focus=0.80, fixed_load=0.0):
"""

计算一个角色在给定周期内的可用产能（人天）

headcount: 在岗人数

workdays:  周期内工作日数

attendance: 出勤系数，扣年假/病假/法定假日

focus:     有效工时系数，扣会议/沟通/支持

fixed_load: 已承诺的固定占用（人天），如值班、售前、面试

"""

gross = headcount * workdays

available = gross * attendance * focus

net = max(available - fixed_load, 0)

return {

"nominal": round(gross, 1),

"usable": round(available, 1),

"net": round(net, 1),

"buffer_ratio": round(net / gross, 3) if gross else 0,

}

示例：12人后端组，一个季度约62个工作日，固定占用40人天

result = capacity(headcount=12, workdays=62, attendance=0.93, focus=0.80, fixed_load=40)

nominal: 744.0  usable: 553.4  net: 513.4  buffer_ratio: 0.690

判断口径是否可用于对外承诺

if result["buffer_ratio"] >= 0.70:

print("容量模型可用于承诺，建议保留10%团队缓冲")

elif result["buffer_ratio"] >= 0.60:

print("容量模型可用于内部排期，对外承诺需附加条件")

else:

print("固定占用过高，先清理占用再谈排期")

这段代码的价值不在于算得多准，而在于它强迫你把每个系数说清楚。当团队为了"有效工时系数到底取0.75还是0.85"吵起来的时候，你就知道该去做一次实测了，而不是继续猜测。

五、案例与数据观察：一家800人企业把资源管理跑通的18个月

下面这个案例来自一家智能制造企业，800人左右，三个事业部，研发、交付、售前共用同一批技术资源。为保护客户信息，公司名称和部分绝对数值做了脱敏处理，趋势和相对变化是真实的。这个案例我会重点讲它在 PingCode 上怎么落地，因为100人以上组织的资源管理，靠表格撑不过第二个季度。

1. 起点：三个事业部，三套口径

进场时的状态是：A事业部按8小时折算人天，B事业部按6.5小时，C事业部干脆不折算，直接按"人"排期。结果是集团层面的资源看板根本合不起来，每个月的人力协调会都在争论"到底谁更缺人"，而争论的依据是各自的表格。

更麻烦的是技能口径。同一个"高级工程师"，在A事业部指的是能独立带项目，在C事业部指的是能独立做模块设计，两边的能力水位差了一到两年。这直接导致跨事业部借调时频繁出现"借过来干不了"的情况。

2. 第一步：统一角色字典与工时口径（第1-2月）

这一步没有用任何工具，纯粹是开会加文档。我们做了三件事：把全公司的岗位收敛成14个标准角色；给每个角色定义4级技能等级和对应的行为描述；统一工时口径为"1人天=7.2小时有效工作"。

2这个数字不是拍脑袋定的，是从现有工时数据里反推出来的：先让三个事业部各抽20人填两周的真实工时，算出的加权平均值是7.18小时。用一个有数据来源的数字，比用一个"看起来合理"的数字更容易被接受。

3. 第二步：在 PingCode 里搭资源池与技能矩阵（第3-4月）

口径统一之后才开始配置系统。之所以选 PingCode，核心原因是它的组织架构、角色权限和工时数据是同源的，不需要在三个系统之间做同步；对800人、三个事业部的组织来说，跨部门借调的审批链和可见性是最难的部分，而不是功能多少。

具体配置上，我们做了四件事：

1. 把14个标准角色映射为系统里的资源标签，每个标签绑定技能等级，形成可查询的技能矩阵。
2. 把工时填报粒度设为半天，并强制关联"计划外工作"类型，避免临时支持被隐藏。
3. 建立跨部门借调的审批链：需求方发起 → 资源所属部门负责人确认 → 交付负责人裁决冲突。
4. 配置容量看板：按角色、按部门、按未来4周三个维度展示"已承诺/可用/缺口"，直接进入周例会。

这里有一个实操细节值得说：技能矩阵第一版一定要手工维护，不要指望系统自动生成。自动生成的标签通常来自历史任务标题，噪声极大。我们第一版是每个部门负责人花两天手工填的，虽然粗糙但可信，可信比完整重要得多。

4. 第三步：把"排期"变成"承诺"（第5-8月）

这是整个项目最难的阶段，因为它触及权力。以前项目经理可以直接找人，现在必须先查容量看板、再走借调审批。前两个月阻力极大，最常见的说法是"这样太慢了，等项目做完再说"。

我们的应对是把"慢"这件事量化：上线前，一次跨部门借调从提出到人到岗平均9.5天（因为要反复找人、等回复、协调部门负责人）；上线后压到2.8天。当规则比人情更快的时候，规则才会被自愿使用。

另一个关键动作是把资源决策记录下来。每一次"谁先拿人"的裁决，都写清楚依据和代价，形成分配决策记录。三个月后，这份记录成了最有说服力的材料，因为它让"资源不够"这个笼统的说法变成了"哪类角色在哪个季度缺口多少人天"的具体结论。

5. 结果：六项指标在18个月里的变化

下面是我跟踪到的六项指标变化。需要说明的是，这些是单一组织的实施观察，不是行业基准，但变化的方向和量级在我参与的其他项目里也有类似表现。

值得单独说一句的是"关键技能单点"这一项。它从17项降到4项，靠的不是招人，而是把借调变成了带教机会：每次跨部门借调都要求带一个本部门的人跟做，借调结束时要留下一份可复用的文档。这条规则写在流程里，成本极低，但对组织能力的改善是复利式的。

6. 一条被低估的经验：先做减法，再做精细化

这个项目里我认为最有价值的决策，是在第3个月砍掉了两件事：一是取消周级别的详细工时审批，二是取消所有部门自定义的资源报表。前者减少了大量无效管理动作，后者消灭了口径分裂的土壤。

很多团队做资源管理时会本能地增加管控点，结果是填报负担上升、数据质量下降、看板没人信。资源管理的精细化必须建立在数据可信的基础上，而数据可信往往来自减少动作而不是增加动作。这一点在后面讲取舍时会再展开。

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

资源管理没有一套通用方案。同样一套规则，在30人团队里是负担，在800人组织里是必需品。下面按组织规模和业务类型分别给出建议，可以直接对号入座。

1. 30人以下：不要做资源池，做"周承诺表"

这个规模下，所有人都知道彼此在干什么，做资源池是纯粹的管理成本浪费。你需要的是每周一次15分钟的承诺会：每个人说这周要交付什么，谁的手上有空闲，谁的活卡住了。

唯一值得建的是一张共享的技能清单，标注每个人能独立交付什么、在学什么。这张清单在招人、接单、请假时能救急，成本几乎为零。

2. 50-150人：技能矩阵 + 容量看板，两个就够

这个阶段是资源管理的"第一次疼痛期"：开始出现"某个人被三个项目同时需要"，但还没有专职的资源管理角色。建议做两件事：建立带技能等级的技能矩阵，建立按未来4周的容量看板。

规则上只需要一条硬约束：单人并行项目数不超过2个。这一条能解决这个规模下80%的资源冲突，而且执行成本极低。

3. 300-1000人：必须有独立的资源调度角色

到这个规模，项目经理和资源经理的职责必须分开。资源调度角色不一定要全职，但必须明确到人，并且拥有跨部门调度的实际权力，而不是只有协调权。

这个阶段还要建立季度容量规划：不是排具体的人，而是算清楚"下个季度各角色的缺口是多少人天"，然后把这个结论交给招聘和外包决策。季度容量规划是把资源管理从"救火"变成"预防"的分水岭。

4. 1000人以上或多事业部：做资源交易机制

超大组织的核心问题不是算不清容量，而是部门没有动力把资源借出去。因为借出去的人产生的价值记在别人的账上，成本却留在自己部门。

解决办法是内部结算：借调产生的人天按内部价格计入借出部门的产出，或者直接抵扣其年度人力预算。这套机制听起来重，但在多事业部组织里，它是唯一能让资源流动起来的方式。

5. 项目型 / 产品型 / 交付型的三条不同路线

业务类型对资源管理的影响，比组织规模更大。三种典型形态的差异如下：

举一个具体的差别：项目型组织里，把利用率做到95%是合理的，因为项目有明确结束点，空闲意味着亏损；但产品型组织里做到95%是危险的，因为探索性工作需要冗余。同一个指标，在不同业务形态下的正确取值可能相差20个百分点。

七、取舍：资源管理没有最优解，只有代价可接受的解

我在咨询里被问得最多的不是"怎么做"，而是"做到什么程度才够"。这个问题没有标准答案，但每一组取舍都有明确的代价，把代价说清楚，决策就不难了。

1. 精细度 vs 管理成本

按小时填报能得到最精确的数据，但填报成本高、数据质量差、员工抵触强。按半天填报数据粗一些，但完整率能从40%提到90%以上。在大多数组织里，"90%完整率的半天数据"比"40%完整率的小时数据"有用得多。

什么时候需要按小时？只有当人力成本是主要成本、且计费与工时直接挂钩时（比如外包结算、咨询计费）。内部研发团队绝大多数不需要。

2. 透明 vs 组织政治

资源看板一旦公开，所有人都会看到谁在忙谁在闲，这会带来政治压力：闲的人怕被塞活，忙的人怕被认为效率低。结果是数据开始失真，大家学会"表演忙碌"。

我的做法是分层可见：个人只看到自己的承诺和负荷，部门负责人看到本部门的明细，跨部门只看到聚合后的角色级缺口。既能支撑决策，又不制造对个人的公开审视。这一条比任何填报制度都更能保护数据质量。

3. 集中调度 vs 团队自治

集中调度效率高，但响应慢、容易脱离一线实际；团队自治响应快，但容易出现资源孤岛和重复建设。经验上的分界点是：当跨团队借调占全部资源分配的30%以上时，就必须集中调度；低于15%时，集中调度是负担。

这个数字可以自己算：统计一个季度内所有跨团队的人员借调人天，除以总人天。这个比例本身就是组织协同度的一个好指标。

4. 工具 vs 表格

表格灵活、零成本、随时改；但表格没有权限、没有审批、没有历史版本，多人协作时会迅速失控。分界线大致在"同时维护资源数据的人超过5个"。超过这个数，表格的冲突合并成本会超过工具的学习成本。

这里的取舍不是"要不要工具"，而是"什么时候上工具"。我的建议是先用表格跑通一个完整季度，把规则和字段稳定下来，再上系统。这时候选型的判断标准也会清晰得多：不是看功能列表，而是看它能不能无损承接你已经跑通的规则。

5. 缓冲 vs 满负荷

缓冲是资源管理里最容易被砍掉的一项，因为它看起来"浪费"。但缓冲的作用不是让人闲着，而是吸收估算偏差、突发问题和人员波动。没有缓冲的团队，所有风险都会以延期的形式在客户端兑现。

我的建议值是：团队级缓冲10%-15%，关键单点技能缓冲20%。后者经常被忽略，但它是性价比最高的一项，因为一个只有一人能做的技能，一旦这个人请假两周，整个项目就得停两周。

八、下一步怎么走：90天落地清单

如果你现在就想起步，我建议按90天分三段推进。这个节奏的设计原则是：每一段都有可交付的成果，且不依赖下一段的完成，这样即使中途资源被抽走，前面的投入也不会白费。

1. 第1-30天：只做口径

1. 定14个以内的标准角色，宁少勿多，多了没人记得住。
2. 抽20-30人填两周真实工时，反推出自己的有效工时系数，不要抄。
3. 定义技能等级的4级行为描述，每级给一个能观察到的行为例子。
4. 产出物：一页纸的口径说明，全公司在同一个文档上对齐。

这一阶段不要碰任何工具，也不要开始填报制度。目标只有一个：让所有人对"一个人一个月有多少可用产能"有同一个答案。

2. 第31-60天：建池子和看板

1. 手工建立第一版技能矩阵，由各部门负责人填写，允许粗糙，必须可信。
2. 建立未来4周的容量看板，按角色聚合，不做个人级别的公开排名。
3. 定一条硬约束：单人并行项目数上限，先按2个执行。
4. 产出物：一张能被周例会真正使用的容量看板。

验收标准很朴素：如果周例会上没有人打开它，说明它没用。这时候要改的是看板本身，而不是要求大家"必须看"。

3. 第61-90天：定规则、上工具

1. 发布优先级打分规则，明确四个维度与权重，明确裁决人。
2. 建立分配决策记录，每一次资源裁决都留下依据和代价。
3. 把已经跑通的规则迁移到系统里（这一步才是选型和配置的时机）。
4. 产出物：一份可被质疑的分配规则 + 一份可被追溯的决策记录。

到第90天，你应该能回答三个问题：我们的净可用产能是多少人天？下个季度哪类角色缺多少人天？上一次资源冲突是按什么依据裁决的？能答上这三个问题，资源管理就算从0走到了1。

最后说一个我自己的判断。资源管理做得好不好，有一个很简单的观察指标：项目经理在争取资源时，是在讲数据还是在讲情绪。如果他张口就是"我这个项目真的很急、客户催得很厉害"，说明组织的资源管理还停留在人情阶段；如果他说的是"我这个项目在战略对齐度上是5分、收入影响上是4分、需要2个后端3周，缺口在容量看板上能直接看到"，那这套机制就真的立起来了。

从0到1从来不是把表填满，而是让一群人开始用同一套语言讨论同一件事。先把口径定下来，把容量算出来，把规则写下来，工具的事放到最后。这四步里，前三步都不需要预算，只需要有人愿意先做那个把7.2小时这个数字算出来的人。