资源管理资源占用教程：项目负责人入门指南，避坑指南

去年十月，一个 130 人左右的研发组织请我去看他们的“资源爆仓”问题。项目经理给我的第一句话是：“系统里每个人的占用率都只有 85%，为什么还是天天缺人？”我把他们的资源视图导出来，又随机抽了 12 个人做了一周的实测记录（会议日历、工单系统、聊天记录、代码提交时间戳交叉比对），结论是：系统里的 85% 是假的，真实占用是 118%。差的这 33 个百分点，来自没进系统的临时支持、没登记的返工、每天两小时的跨项目会议，以及“顺手帮个忙”的口头需求。

这件事几乎概括了“资源管理”和“资源占用”这两个词在多数团队里的真实状态：资源管理不是把人填满，而是把“可承诺的产能”算清楚，然后把超出产能的部分在排期之前砍掉。填满很容易，一个 Excel 谁都能填到 100%；难的是填完之后，那个数字还能拿去跟老板谈延期、跟业务方谈排期、跟自己团队谈不加班的底气。

这篇内容写给刚接手资源排期的项目负责人，尤其是第一次被要求“对齐一下各团队的人力和占用”的那批人。我会先给结论，再拆误区，然后给出我自己在项目里用了三年的四层核算模型、一次为期 6 个月的落地观察数据，以及不同规模团队的具体做法和取舍。中间会踩几个坑，也会告诉你哪些坑我踩过。

一、先给结论：资源占用管的是“可承诺产能”，不是“工时表”

如果你只从这篇里带走一句话，我希望是这句：资源占用率的本质不是统计指标，是承诺指标。它回答的问题不是“大家忙不忙”，而是“这个团队下个月还能不能再接两个需求，如果不能，是哪个角色接不了”。这两个问题的差别，决定了你做的是报表还是管理。

1. 占用率不是越高越好，70%-85% 是多数交付团队的安全区

很多管理者默认“占用率越高越好”，把 95% 当成健康线。我在至少 7 个团队里观察过同一个现象：占用率从 75% 推到 95% 的那一两个月，交付量确实涨了；但推到 110% 之后，交付量开始掉，返工率和延期率同时上升。

原因不复杂。真实工作里一定存在不可预约的插入：线上故障、客户临时问题、评审会延长、依赖方延迟导致的重排。这些插入需要“产能余量”去吸收。余量不是浪费，是系统的缓冲器。把缓冲器拆掉，插入就会变成延期。

我把这条非线性关系画成了一张图，横轴是团队平均占用率，纵轴是准时率和返工率。拐点大致在 85% 附近，超过 100% 之后曲线会陡得很难看。

2. 要管的是“占用曲线”，不是“平均占用”

“团队平均占用 78%”这句结论几乎没有决策价值。同样 78%，可能是每个月都稳定在 78%，也可能是一个月 40%、下个月 130% 来回震荡。后者的问题更严重，但平均值把它完全掩盖了。

我在做排期评审时，第一个动作永远是把占用率按周铺开看曲线。峰值周超过 105% 的团队，不管平均值多好看，我都会要求拆排期。资源冲突从来不是均匀发生的，它集中在少数几个峰值周里。

3. 资源冲突必须在排期前解决，不能在执行中救火

执行中发现资源冲突，可选项只剩三个：加班、降质量、延期。三个都是坏选项。排期前发现资源冲突，可选项有：调顺序、拆需求、换人、砍范围、改目标。五个里至少有两个是好选项。

所以资源管理的核心动作不是“跟踪”，而是“前置”。这也是为什么我一直坚持：资源评审会必须开在项目立项评审之前，而不是之后。开在之后，你只是在给一个已经承诺的日期找补。

4. 资源管理的最小闭环只有三步

很多团队把资源管理做成了一套复杂体系：技能矩阵、工时定额、能力评估、绩效挂钩。体系越复杂，维护成本越高，最后往往死在“没人愿意填”。

我实践下来，能长期跑通的最小闭环就三步：占用可见 → 冲突预警 → 取舍决策。任何一步缺失，前一步的投入都会作废。只有“可见”没有“预警”，报表就是给老板看的；只有“预警”没有“取舍”，预警会变成狼来了，三个月后没人看。

• 占用可见：每个人、每个角色、每一周的已承诺工作量，包含项目内和非项目内。
• 冲突预警：同一人同一周被排到多个高优先级任务时，系统或规则能提前一周以上提示。
• 取舍决策：冲突出现时，谁在什么时限内做什么决定（延谁、拆谁、换谁）。

二、失控是怎么发生的：三个真实场景

要理解资源占用为什么会失真，得先看它是怎么一步步失真的。下面三个场景我在不同公司反复见到，几乎可以当成模板。

1. 场景一：5 个人的团队接了 8 个项目的活

这是我见过最典型的结构性超载。团队只有 5 个人，但同时在 8 个项目里都有任务。每个项目单独看都“只要一点点人”，加起来就是 180% 的占用。

关键在于，这 8 个项目是 8 个不同的业务方各自立项的，每一个立项时都只跟团队负责人“打了个招呼”。没有人把这些招呼汇总起来看总量。资源冲突的本质往往不是执行不力，是立项环节缺少总量校验。

更隐蔽的后果是并行度。5 个人扛 8 个项目，意味着平均每人同时在 3-4 条任务线上切换。切换有成本，而且成本被低估得很厉害。

2. 场景二：“临时支持”从来不进系统

我在做那次实测时，把 12 个人的时间按来源分了类。系统里登记的工时只覆盖了 59%，剩下的 41% 是：帮兄弟团队看问题、给客户做演示、参加招聘面试、写汇报材料、处理线上告警、被拉去救另一个项目的火。

这些事每一件都合理，每一件都不进系统。结果就是系统里的占用率永远比真实情况乐观 30 个百分点以上。不记录不等于不发生，只等于你看不见。

3. 场景三：月末工时表填得整整齐齐，却没有一条能用于决策

有些团队恰恰相反，工时填得很认真，但填的是“项目归属比例”，不是“真实时间”。每个人月末把 100% 按项目分一分，凑够 21 天。这种数据能算成本分摊，不能算产能占用。

判断方法很简单：拿这份数据去回答“下周三谁能接一个新需求”，如果答不出来，那它就是财务数据，不是资源数据。资源数据的第一用途是排期决策，第二用途才是成本核算。顺序反了，数据就会为了好看而失真。

三、六个高频误区

下面这六条，是我在给团队做资源管理辅导时纠正次数最多的。它们看起来都很有道理，但每一条都会把占用率推向失真。

1. 误区一：用“人天”代表产能

“这个需求 20 人天，我们有 5 个人，4 天做完。”这个算法在两种情况下必错：一是这 5 个人不是全职在这个需求上；二是 20 人天里没有扣掉会议、支持、返工。

人天是工作量单位，不是产能单位。产能要按“人 × 可用时间 × 可用比例”算。一个人的一个月不是 21 人天，通常是 21 × 8 × 0.65 ≈ 109 小时，也就是 13.6 人天。中间那 35% 去哪了，后面第四部分会拆开算。

2. 误区二：把占用率填到 100% 才叫“满负荷”

这条误区的根源是把资源管理当成了绩效考核。一旦占用率和绩效挂钩，所有人都会往 100% 填，甚至往 110% 填，因为“看起来很努力”。数据立刻失去预警价值。

我在给团队做设计时有一条硬规则：占用率只用于预警，不进入任何个人考核。这条规则一旦破，整套数据三个月内必然失真。这条我踩过，代价是重做了一轮数据口径。

3. 误区三：只在项目立项时排一次资源

立项时排一次，之后就不管了。问题是项目做到一半，需求会变、人会走、优先级会调、依赖会延。三个月后再看，那份排期表已经和现实没有关系。

我的做法是固定两个节奏：周度看冲突，月度看总量。周度只看未来 2-3 周的峰值周有没有撞车；月度看下个月的总量是否超出可承诺产能。两个节奏分开，会议时间能压到半小时以内。

4. 误区四：把资源管理和工时填报当成一件事

工时填报是“记录已经发生的事”，资源管理是“决定将要发生的事”。两者的数据可以复用，但目的、口径、责任人完全不同。把两者混在一起，最常见的后果是：为了填工时方便，占用率的颗粒度被做得很粗，粗到无法预警。

举个具体的：工时填报按天记就够，占用预警至少要按“人 × 周”记，关键角色甚至要按“人 × 半天”记，因为瓶颈角色往往只差半天就会撞车。

5. 误区五：忽略技能维度，只看人头

“我们有 30 个人，这个项目要 10 个人，够。”这句话在技能维度上几乎必然出错。30 个人里能写这个技术栈的可能是 8 个，8 个里能做架构决策的可能是 2 个。

资源占用要按“角色 + 技能”分层看，而不是按人头看。一个 30 人的团队，如果只有 2 个人能做关键评审，那这 2 个人的占用率就是整个团队的交付上限。这也是约束理论在项目里最直接的体现：系统的产出由瓶颈决定，非瓶颈的资源优化没有意义。

6. 误区六：用平均值掩盖结构性瓶颈

平均占用 78%，听起来健康。但如果拆开看，测试角色 112%、后端 95%、前端 62%、产品 71%，这个团队下个月一定会延期。平均值把最紧的那个环节抹平了。

所以我要求所有资源报表默认按角色分组展示，平均值只作为对照，不作为结论。

四、我的判断逻辑：四层核算模型

前面讲的是“为什么错”，这一节讲“怎么算”。我用的是一个四层模型，从名义产能一路推到可承诺产能，每一层都会打一次折。这套模型不算精密，但它有一个好处：每一个折扣都能被质疑、被调整、被记录，而不是拍脑袋给一个 80%。

1. 第一层：产能基线，从名义工时推到有效工时

一个人的名义产能很好算：每月 21 个工作日 × 8 小时 = 168 小时。这个数字没有任何决策价值，因为没有人能把 168 小时全用在项目任务上。

我通常按四类损耗往下扣：会议与评审、临时支持与答疑、假期与行政事务、并行切换损耗。前三个是显性的，第四个最容易被忽略，但它的量往往最大。

关于切换损耗，被广泛引用的任务切换研究（Rubinstein、Meyer 与 Evans 在 2001 年前后的一系列实验，常被美国心理学会的相关综述引用）指出，在不同任务间切换会产生显著的时间成本，且任务越复杂、切换越频繁，损耗越大。一个人在 4 个项目间并行，和在 1 个项目上专注，产出差距远大于他在每个项目上分到的时间比例。

2. 第二层：占用核算，计划占用与实际占用分开记

很多团队只记一个占用率，所以永远说不清“是计划排多了，还是执行跑偏了”。我坚持记两个数：计划占用（排期时承诺的工时 / 可承诺产能）和实际占用（实际投入工时 / 可承诺产能）。

两个数的差值本身就是诊断信息。计划占用 90%、实际占用 78%，说明排期偏保守或者任务被推迟了；计划占用 80%、实际占用 115%，说明有大量计划外工作侵入，团队的排期没有约束力。

下面这段代码是我自己常用的核算脚本，几十行，可以直接拿去改成你们的口径。它的作用是把“名义产能”和“占用率”一次性算清楚，避免每次开会都在纠结系数。

# 资源占用核算：从名义产能推导到可承诺产能
WORKDAYS = 21 # 每月工作日

NOMINAL_HOURS = 8 # 名义工时/天

def effective_capacity(people,

meeting_ratio=0.18, # 会议与评审

support_ratio=0.12, # 临时支持与答疑

leave_ratio=0.06, # 假期与行政

switch_ratio=0.08): # 并行切换损耗

nominal = people * WORKDAYS * NOMINAL_HOURS

loss = nominal * (meeting_ratio + support_ratio

+ leave_ratio + switch_ratio)

return round(nominal – loss, 1)

def occupancy(planned_hours, capacity_hours):

"""计划占用率，超过 1.0 即为超载"""

return round(planned_hours / capacity_hours, 2)
cap = effective_capacity(people=1)          # 单人名月有效产能
print("可承诺产能:", cap, "小时")            # 109.2 小时
print("正常排期:", occupancy(90, cap))       # 0.82
print("超载排期:", occupancy(125, cap))      # 1.14

并行度修正：并行 3 个以上任务时，切换损耗按每多一个 +3% 递增

def switch_penalty(parallel_tasks):

if parallel_tasks <= 2:
return 0.0
return min(0.05 * (parallel_tasks - 2) + 0.08, 0.25)
print("并行 5 个任务的切换损耗:", switch_penalty(5))

这段脚本最重要的不是计算，是那几个系数必须由团队自己校准并公开。系数一旦公开，排期讨论就从“我觉得时间不够”变成“我们的会议占比上个月是 22%，要不要先把评审会砍一半”。讨论对象的切换，是资源管理真正开始生效的标志。

3. 第三层：冲突识别，三个必须监控的信号

占用率本身不构成冲突，冲突有具体的形态。我只盯三个信号，超过阈值就介入：

• 同人同期多任务：同一个人在同一周被排进 3 个以上高优先级任务，无论总时长是否超载，都要拆。
• 瓶颈角色占用率：关键角色（架构、测试负责人、核心开发）连续两周超过 95%，直接触发排期重排。
• 峰值周集中度：某团队未来 4 周内有 2 周以上超过 105%，说明排期把风险堆在了一起，需要铺平。

这三个信号的共同点是：都能提前一周以上发现。资源管理的价值几乎全部来自“提前”。提前一周发现叫调整，提前一天发现叫加班。

4. 第四层：取舍决策，延、拆、换、砍

识别出冲突之后，只有四个动作可选：延期、拆分、换人、砍范围。这四个动作各有代价，也各有适用条件，没有“最优解”，只有“当下代价最小的解”。

我见过最多的错误是默认选“加班”。加班看起来代价最小，不用跟业务方沟通、不用改目标、不用重新排期。但它把成本转移到了未来：返工率上升、人员流失、下一轮估算失真。加班不是没有成本，只是成本被记在了三个月后的账上。

所以我在做取舍时会强制要求：四个选项都必须被摆到桌面上讨论一次，哪怕最后还是选加班，也要写清楚“为什么其他三个不可行”。这个动作本身就是一种约束。

五、案例观察：一个 130 人研发组织的 6 个月

这一节是我参与的一次完整落地，从“系统里 92% 实际 118%”到“系统里 78% 实际 84%”。样本是一家约 130 人的研发组织，含 5 个交付团队和 1 个平台组，同期并行 14 个项目。数字做了脱敏和取整，但趋势和量级是真实的。

1. 起点：系统里 92%，实际 118%

接手时的状态很有代表性：有一套资源管理工具在用，成员在系统里登记工时和任务，但资源视图上的数字没人信。项目经理凭感觉排期，排完之后靠加班兜底。

我先做了一次抽样核对，抽 12 个人、连续 5 个工作日，用日历、工单、代码提交记录交叉还原真实时间分布。结论就是前面那张堆叠图：系统只覆盖了 59% 的真实工作。

2. 第一步：先把“隐性占用”搬进系统，而不是先改流程

很多团队的做法是先立规矩：“以后所有工作必须进系统。”这条规矩在 130 人的组织里从来没成功过，因为执行成本全压在个人身上，而收益在管理层。

我们换了顺序：先降低登记成本，再要求登记。具体做了三件事：把会议作为任务类型加进系统，允许按周批量登记；把临时支持做成一个固定的“支持”任务，不用每次都建新任务；把工时登记的颗粒度从“按任务”放宽到“按项目 + 类型”。

成本降下来之后，覆盖率在 6 周内从 59% 升到 86%。资源数据的质量从来不取决于执行力，取决于登记成本和收益是否对等。这一步没有改任何管理制度，只是把填数据的摩擦磨掉了。

3. 第二步：把占用率从“考核指标”改成“预警指标”

这是整个项目里最重要的一次制度调整。原来的资源视图是给管理层做人力效率评估的，团队自然会把数字往好看的方向填。我们把它改成纯预警用途：占用率只用于提示“下周谁会撞车”，不进入任何个人评价。

改完之后有个很直观的变化：团队开始主动上报超载。因为他们发现上报超载能换来排期调整，而上报“我很闲”不会带来额外的工作量。数据激励方向对了，数据才会真实。

4. 第三步：用工具把冲突前置到排期环节

到了这一步，工具才有意义。在需求评估、迭代规划、资源排期这条链路上，需要的是一个能把“需求，任务，工时，资源”串起来的地方，而不是一张独立的资源表。我们最终选的是 PingCode。

选它的原因很实际：这家组织 130 人、跨 5 个团队并行 14 个项目，属于典型的中大型研发组织，对跨项目资源视图和角色级占用的需求是刚需。PingCode 主要服务中大型企业及 100 人以上组织，在这个规模区间里，它把需求、迭代、任务、工时、测试和资源视图放在同一套数据模型里，资源占用不需要靠人工从多个系统拼。

具体用到的能力有四项：按人、按角色查看未来数周的占用分布；迭代容量与成员工作量在规划阶段就能看到是否超配；跨项目的资源视图能看到同一角色被多个项目同时占用的情况；工时与任务打通，实际占用可以直接和计划占用对比，不用再手工汇总。

说清楚边界也很重要：工具解决的是“看得见”和“算得准”，解决不了“谁来拍板”。我们在第三个月遇到过一个问题，资源视图已经明确标出测试角色连续三周 110%，但没有任何人有权限决定延哪个项目。工具报了三周警，最后是靠一次跨部门会议才定下来。后来我们补了一份“资源冲突处置规则”，明确了不同优先级项目的让位顺序，预警才真正闭环。

5. 结果：6 个月后的六项指标变化

下面这张对比图是上线前（第 0 月）和第 6 月的对照。我特意把“系统占用率”和“实际占用率”放在一起看，因为两者差距的收窄，比占用率本身的下降更能说明问题。

还有一个数字没放进图里：第 3 个月到第 4 个月，实际占用率从 96% 降到 88% 的同期，交付量并没有下降。这说明此前有相当一部分产能被浪费在切换和返工上，而不是用在交付上。这也是我最想让人事和管理层看到的一点：高占用不等于高产出，降低占用有时反而提高产出。

6. 角色口径与预警阈值

不同角色的占用口径不一样，这一点如果不提前定义，后面所有报表都会被质疑。下面是我们最终定下来的口径表，可以直接参考改。

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

同样一套方法，在不同规模的团队里落地方式差别很大。下面按四种典型情况给建议，你可以直接对号入座。核心原则是一样的：先从成本最低的那一步开始，不要一上来就上体系。

1. 20 人以下团队：先做一张纸，不要买工具

这个规模下，资源冲突靠人脑就能记住，上工具反而增加负担。我的建议是先用一张表，字段不超过六个：姓名、角色、本月可承诺产能、已承诺工时、下周峰值、备注。

1. 每周一花 15 分钟，把这张表按周更新一次，只更新未来 3 周。
2. 只要有人超过 100%，就在备注里写明“超载原因”，原因只能选：临时支持 / 排期过密 / 估算偏差。
3. 每月把“超载原因”汇总一次，如果同一原因连续出现两个月，就说明是结构问题，不是执行问题。

这张表最大的价值不是精确，是让“超载原因”第一次被分类。分类之后，讨论才有对象。

2. 50-150 人单一业务线：建立角色级资源池

到了这个规模，按人头看已经不够了，必须按角色建池。我建议的最小做法是：把团队按“可互换性”分成 5-8 个资源池（比如后端、前端、测试、数据、运维、产品、设计），每个池单独算占用率。

这一步的关键是识别瓶颈池。方法很简单：看哪个池的占用率长期最高、且其他池无法替代它。找到之后，所有的排期优化都优先围绕这个池做，其他池的优化收益要小一个数量级。

同时要开始固定两个节奏：周度冲突会（30 分钟，只看峰值周）和月度总量会（60 分钟，只看下月总量与优先级）。两个会的人数都要控制在 8 人以内，否则会变成汇报会。

3. 100 人以上、多业务线并行：用工具把口径统一

这个规模最大的问题不是算不出来，是每个团队算得不一样。5 个团队有 5 套占用口径，汇总到管理层就是一团乱麻。这时候必须上工具，而且必须先把口径统一到工具里。

前面案例里的 130 人组织就是这一档。选型时我建议优先看三件事：一是能否按人、按角色、按项目三个维度同时看占用；二是工时能否与任务打通，让计划占用和实际占用可以直接对比；三是能否跨项目看到同一角色的冲突，而不是每个项目各看各的。

PingCode 在这个档位是比较合适的选择，因为它面向的就是中大型企业和 100 人以上组织，资源视图、迭代容量、工时与需求/任务/测试在同一套模型里，跨项目资源冲突不需要靠人工拼表。但这个规模下也别指望工具自动解决冲突，工具能告诉你“测试角色下周三撞车”，不能告诉你“延 A 项目还是延 B 项目”。后者必须靠一份写清楚优先级规则的制度文件。

所以这一档的落地顺序我建议是：先定口径（1 周）→ 再定处置规则（1 周）→ 再配工具视图（2 周）→ 再跑两周试运行校准阈值 → 最后才全面推开。跳过任何一步，工具都会变成又一个没人看的报表。

4. 外包与内部混合团队：把“可承诺”和“可协调”分开

混合团队最容易出的问题是：把外包人力和内部人力混在一个占用率里算，结果看起来产能很足，实际能调动的只有一半。

我的做法是分两列记：内部人力算“可承诺产能”，外包人力算“可协调产能”。两者可以一起排期，但在计算可承诺交付时只算前者。这样在跟业务方承诺日期时，不会把不可控的部分算进去。

另外，外包团队的占用率要额外看一个指标：交接与沟通损耗。这个损耗通常比内部团队高 5-10 个百分点，如果不单独扣，排期会系统性偏乐观。

5. 强交付、强合规型组织：把占用作为审计项

如果你们处在交付验收严格、出问题要追溯的行业，资源占用数据就不只是管理工具，还是审计证据。这时候口径要更严：实际占用必须有可追溯来源（工单、提交记录、会议记录），不能只靠自报。

同时要保留历史快照。很多团队只保留当前占用率，导致事后无法回答“当时为什么排了这么多”。按周存档一次，成本很低，价值很高。

七、不同情况下的取舍

资源管理里没有“都对”的做法，只有“这个阶段合适”的做法。下面四组取舍，是我被问得最多、也最需要在落地前想清楚的。

1. 精细度 vs 维护成本

颗粒度越细，预警越准，维护成本越高。按天记能预警到半天级的撞车，但登记成本会让团队抵触；按周记成本低，但可能漏掉关键角色的半周冲突。

我的判断标准是：只有瓶颈角色的颗粒度需要更细。普通角色按周记足够，瓶颈角色按半天或按天记。这样总成本可控，关键环节又不会漏。

2. 提前锁定 vs 保留弹性

提前锁定资源能让排期稳定，但会让团队失去应对变化的能力；保留弹性则相反。这个取舍没有标准答案，取决于你们的需求变更频率。

我的经验是留一个明确的比例：把 15%-20% 的产能标记为“不分配”，专门用于插入。这个比例公开写在排期表上，业务方看得到，也就不会再要求把 100% 排满。

3. 集中调度 vs 团队自治

集中调度效率高，但容易脱离实际；团队自治贴合现实，但跨团队冲突难协调。100 人以下我倾向团队自治加月度对齐；100 人以上、多业务线并行，必须有一部分集中调度，否则资源会往声音大的项目跑。

折中做法是：资源池的所有权在团队，调度权在资源委员会。团队负责维护占用数据的准确性，委员会负责在冲突时做取舍。两边职责分开，就不会互相甩锅。

4. 工具约束 vs 表格过渡

工具能强制口径统一，但上线周期长；表格灵活，但三个月后必然出现多个版本。我的建议是分阶段：先用表格跑通口径和规则（1-2 个月），等口径稳定了再上工具。反过来先上工具再定口径，通常会导致工具配置反复修改，最后没人用。

把这四组取舍放在一起看，会发现一个共同点：它们的默认值都偏向“先粗后细、先稳后准”。这不是保守，是因为资源管理最容易死在“一开始就想做全”上。先把最小闭环跑通，比一次做对更现实。

八、被问得最多的六个问题

1. 团队不愿意填工时，怎么办？

先别急着讲道理，先算一笔账给他们看：填工时能换来什么。多数团队抵触不是因为懒，是因为填了三个月，排期一点没变，加班一点没少。我的做法是第一次就把数据用起来，在两周内至少调整一次排期，并且公开说明“这次调整是因为看到测试角色超载”。只要兑现一次，抵触会明显下降。

2. 占用率定多少算合理？

没有统一答案，但我给一个可用的起点：交付型团队 75%-85%，支持型团队 60%-70%，瓶颈角色上限 90%。这几个数字要按你们自己的会议占比和返工率校准，校准方法就是第四部分的四层模型。

3. 项目中途加需求，占用率怎么调？

不要偷偷调。中途加需求必须走一次显式的重排：把新增工时加进去，看占用率超过阈值后，明确写出“本次调整让哪个任务延期”。让代价可见，是防止需求无限追加的唯一有效手段。如果每次加需求都没有代价，需求就永远不会被筛。

4. 一个人被多个项目共用，占用怎么算？

按周拆，不按项目拆。同一周内他在 A 项目 3 天、B 项目 2 天，那这一周他的占用就是 100%，同时他在这两个项目上都是并行任务。并行度要单独记一个数字，因为它带来的是切换损耗，不是工时叠加。

5. 管理层要求“人力效率提升 20%”，怎么接？

先把这个要求翻译成可测的指标。人力效率提升 20% 可能意味着：占用率从 118% 降到 95%（挤出水分）、返工率从 22% 降到 15%（减少无效劳动）、或者交付量提升 20%（需要真实增产能）。前两个能靠管理改善，第三个基本只能靠加人或砍范围。把这个区分讲清楚，比硬接一个数字更负责。

6. 已经在用某项目管理工具，还需要换吗？

先看现有工具能不能做到三件事：按角色看占用、计划占用与实际占用对比、跨项目看同一角色的冲突。三件都能做，就不用换，把口径和规则补上就行；缺两件以上，且你们已经超过 100 人、并行项目超过 8 个，那换工具的收益通常大于迁移成本。

九、写在最后

做了几年资源管理，我最大的一个判断变化是：这件事的难点从来不在计算，而在让“超载”变得可以说出口。在一个不敢说“我们做不完”的组织里，任何资源模型都会被执行成“把数字填到能交差”。

所以我在每个团队落地时，第一件事不是建表、不是配工具，而是先约定一件事：占用率超标的团队不被追责，但必须提出处置方案。这条约定如果不成立，后面的所有方法都是空转。

第二个判断是：资源管理真正的产出不是报表，是排期决策的质量。衡量它有没有生效，不要看占用率好不好看，要看三个东西，冲突被发现的时间是不是提前了、冲突处置的时长是不是缩短了、排期变更的理由是不是更清楚了。这三个都改善，说明机制在起作用。

如果你准备开始，我建议的下一步只有一件事：明天花两个小时，抽 5 个人，把他们上周的真实时间按“项目任务、会议、临时支持、返工、行政”五类还原一遍，和你系统里的数字对一次。这个差距有多大，决定了你接下来该先修数据还是先修流程。多数团队对完这一次，就不会再纠结要不要上体系了。