人力规划管理指南：项目经理如何做好人力资源计划，流程优化全流程

去年冬天，我陪一家约 120 人的研发组织做年度交付复盘。项目经理在立项会上承诺：Q1 交付三个模块，投入“5 个人、6 周”。六个月后，这三个模块平均延迟了 41 天，而复盘时翻出来的原始表格上，人力栏写的仍然是那行字，“5 人 × 6 周”。没有人造假，也没有人偷懒，问题出在这行字本身：它是一个人数承诺，却一直被当成产能承诺在使用。人力规划管理最容易失效的地方，从来不是不会画甘特图，而是把“有多少人”误当成“能做多少事”。

这篇文章想讲清楚的，就是项目经理如何把人力计划从一张人头表，变成一份可以被验证、被追踪、被追责的产能合约，以及这条链路上每一步该怎么走、在哪里该省、在哪里绝不能省。

一、先给结论：人力规划是产能与承诺的对账，不是填人头表

在展开流程之前，我先把三个判断摆出来。这三个判断如果不同意，后面的方法论基本用不上；如果同意，后面每一节都能直接落到你的项目上。

1. 项目经理规划的对象是“可用工时”，不是“人数”

“5 个人干 6 周”这句话在数学上是 5×6=30 人周，但在现实里，这 30 人周里可能只有 17 人周真正落在你的任务上。剩下的部分被年假、周会、线上值班、跨团队支持、上下文切换和等待评审吃掉了。

我做过一个粗糙但稳定的统计：在 100 人以上的研发组织里，一个工程师名义上每周 40 小时，实际能稳定投入到单一项目关键任务上的时间，中位数落在 22 到 26 小时之间。也就是说，“人周”这个单位本身带有约 35% 到 45% 的系统性虚高。

如果你的人力计划以人为单位，你会在立项时自动获得一个漂亮的数字；如果你以有效工时为单元，你会得到一个难看的数字，但它是能被交付的数字。人力规划的第一价值，是让难看的数字早点出现。

2. 大部分排期风险在立项那一刻就已经注入，而不是在执行中产生

很多人把延期归因于执行不力、需求变更、人员流失。这些确实存在，但它们是放大器，不是源头。源头是立项时那个已经偏了 30% 的产能基数，基数一旦偏了，后面所有的资源平衡、赶工、加人，都是在错的地基上做加固。

我复盘过一个 27 个项目组成的样本，对比三种常见的人力估算方式与实际交付偏差（人天口径，样本推演，非全行业统计）：

3. 人力规划的产出是决策，不是文档

这是我踩过最深的一个坑。早年我很得意于自己做的人力计划表：按角色分、按周分、按模块分，颜色标注齐全。直到有一次总监问我：“如果现在必须砍掉一个模块，你建议砍哪个，理由是什么？”我答不上来。

那一刻我意识到，我做的是一份记录，不是一份决策支持。真正有价值的人力规划，必须能回答四个问题：哪个资源是瓶颈、缓冲还有多少、先牺牲什么、什么时候必须上报。回答不了这四个问题的人力计划，无论排版多漂亮，都只是一份自证勤奋的材料。

二、真实场景：为什么项目经理一到交付期就变成“人力讨债人”

要理解人力规划为什么会烂，得先看清楚它烂在什么环境里。我见过的大多数失效，都不是方法问题，而是信息结构问题。

1. 场景一：三个项目同时抢同一个人，谁都不知道

一个后端架构师，同时被三个项目标注为“核心投入”。三个项目经理各自的人力表上，他都写着 60%、50%、40%。加起来 150%，但没有任何一张表能看见这个 150%。

这类冲突的可怕之处在于，它在立项阶段完全静默。每个项目经理都觉得自己算得很合理，直到第三周这位架构师开始请病假，三条链路同时抖动，大家才发现问题。而此时距离交付只剩一半时间，任何补救都是高成本的。

2. 场景二：组织过了 100 人，人力信息开始分层失真

50 人以内，谁忙谁闲靠走廊里喊一嗓子就能知道，非正式信息网络足够用。超过 100 人之后，这条网络断了，但很多团队没有补上正式机制。

于是出现一种典型状态：项目经理掌握的是“承诺投入”，职能主管掌握的是“人员归属”，财务掌握的是“人力成本”，三份数据各自正确，但拼不到一起。每次需要回答“下个月到底有多少人能干这个项目”，就要开一次跨部门会，会开完的结论往往还是“再确认一下”。

3. 场景三：把“人手不够”当成万能解释

我参加过很多次延期复盘，出现频率最高的一句话是“人手不够”。但只要往下追一层，往往会发现真正的原因不是总量不够，而是结构错配：测试资源在第 5 周闲置 40%，第 9 周却需要 200% 的投入；前端两个人在等接口，后端一个人在等设计稿。

总量不足可以通过加人缓解，结构错配加人只会让错配更严重。而区分这两者，靠的正是人力规划里的负荷曲线，而不是一句感受。

4. 场景四：人力数据散落在表格、聊天记录和某个人的脑子里

这是我见过最普遍、也最容易被低估的问题。人力计划存在 Excel 里，实际排班在某个协作工具的看板里，请假记录在 OA 里，加班和值班在另一个系统里。四份数据之间没有主键关联，唯一的关联方式是“某个人记得”。

一旦这个人休假或者离职，整条链路就断了。我服务过一家 120 人左右的研发组织，他们的人力和项目数据统一收敛到 PingCode 之后，最直接的变化不是效率提升，而是“谁在哪个项目上投入多少”终于只有一个答案。此前这个答案每周要开一次会重新拼出来。

这里我想强调一个判断：对于 100 人以上的组织，人力规划的关键瓶颈通常不在方法，而在数据的单一事实来源。方法可以照抄，数据不能。

三、常见误区拆解：五个让计划注定失准的惯性动作

下面五个误区，我几乎在每一个新接手的项目里都能看到至少两个。它们的共同特征是：看起来很像专业动作，实际上在系统性地放大误差。

1. 误区一：把“可用人力”等同于“人数 × 天数”

这是所有误差的源头。它的隐蔽性在于，公式本身没错，错在分子。人数×天数算出来的是名义产能，而项目需要的是可承诺产能，两者之间隔着四层衰减：非工作时间、协作损耗、支持性占用、风险缓冲。

我的经验值是，这四层加起来通常吃掉 35% 到 50%。也就是说，你按名义产能排出来的计划，天然就超载了近一倍的一半。这个偏差不会因为你更努力而消失，只会以延期、加班、质量下降三种形式兑现。

2. 误区二：用百分比表示投入率

“投入 50%”是一个在管理上极其危险的说法。危险在于它无法被验证：50% 是半天还是一天中的上午？是稳定投入还是被切成五段？是包含会议还是不含会议？

更致命的是，百分比无法跨项目加总后校验。你无法从“A 项目 50% + B 项目 40% + 日常支持 30%”这个组合里，自动算出一个人的负荷是否已经 120%。而工时可以。

我的处理方式是：对外沟通用百分比，对内计算一律用工时。百分比是给人看的概览，工时是给系统算的依据，两者不能混用。

3. 误区三：人力计划立项时算一次，然后归档

人力计划不是一份静态文件，而是一条随时间滚动的曲线。项目每推进一周，剩余工作量在变、可用人力在变、风险在变，三个变量同时变化，计划却停在第一周。

我见过最典型的反面案例：一个 14 周的项目，人力计划只更新过两次，第二次是延期之后补的。复盘时项目经理说“计划赶不上变化”，但真实情况是没有人负责让它赶上变化。

4. 误区四：把关键路径问题当成资源问题

关键路径上的任务延迟一天，项目就延迟一天；非关键路径上的任务延迟，只要没吃掉浮动时间，项目一天都不延。这两类问题需要的解法完全不同：前者要加资源或压缩范围，后者只需要调整顺序。

但很多项目经理在做人力规划时，把所有任务一视同仁地平铺到人力表上，结果把宝贵的瓶颈资源分配给了浮动时间充裕的任务，而关键路径上的任务在等人。这不是勤奋，这是把稀缺资源投到了不敏感的位置。

5. 误区五：跨部门借人靠人情，不靠机制

“我找老王说好了，他下周腾两天给我们。”这句话是很多项目的人力基础。它在小规模、短期、低风险场景下确实有效，问题在于它不可累积、不可预期、不可追责。

当项目需要跨部门借调超过两周，或者同时借三个人，人情机制就会失效。因为出借方也有自己的交付压力，而口头承诺没有优先级约束。等到冲突爆发，项目经理手里没有任何可以主张的依据。

我的判断是：两周以内的人情借调可以接受，超过两周必须走正式的资源承诺流程，并且要落到系统里，让出借方的主管看见这笔占用。

四、专业判断逻辑：四层产能模型与瓶颈优先原则

讲完误区，该给一套能落地的判断逻辑了。我用的是一个叫“四层产能”的模型，它不是理论推演，而是在反复被延期打脸之后，一层一层补上去的。

1. 第一层：名义产能，只用来做上限校验

名义产能 = 人数 × 周期 × 标准工时。这一层的唯一用途是做上限校验：如果连名义产能都不够，那这个承诺一定不可能实现，不需要再往下算。

但如果名义产能刚好够，千万不要就此打住。名义产能充足而实际交付失败，是我见过最高频的误判。

2. 第二层：可用产能，扣除所有“人不在”的时间

可用产能要扣的是：年假、法定假日、培训、病假期望值、公司级活动、值班调休。这些是确定性损耗，可以按历史数据算出稳定比例。

在 100 人以上的组织里，这部分损耗比例通常在 8% 到 12%。低于 8% 说明你的统计口径漏了东西，高于 12% 说明团队处于高流失或高支持状态，需要单独分析。

3. 第三层：有效产能，扣除协作损耗与上下文切换

这一层最容易被跳过，但它往往是最大的一块。有效产能要扣的是：会议、评审、答疑、跨团队同步、上下文切换、等待依赖。

关键在于并行度。一个人只做一个项目时，协作损耗大约 15%；同时做两个项目，损耗升到 22% 左右；同时做三个及以上，损耗可能超过 30%。因为每次切换都需要重新加载上下文，而加载成本不产出任何交付物。

所以我在做人力规划时有一条硬规则：同一个人在同一周内，最多同时承担两个项目的实质性任务。超过两个，我宁可把人整周切给一个项目，也不要让他三个项目各占三分之一。

4. 第四层：可承诺产能，扣除支持性占用与风险缓冲

可承诺产能才是能写进承诺书的数字。它要再扣两块：一是支持性占用（线上问题、客户答疑、内部工具维护），二是风险缓冲。

支持性占用建议按历史数据单独核算，不要笼统地塞进“其他”。风险缓冲则是一个需要显式决策的参数：项目不确定性高，缓冲留 15%；技术成熟、需求稳定，留 8%；涉及外部依赖或合规审查，留 20% 以上。

缓冲不是浪费，缓冲是对不确定性的定价。不留缓冲的承诺，本质上是把不确定性成本转嫁给执行团队，让他们用加班来支付。

5. 判断优先级：先找瓶颈资源，再看总量平衡

有了四层产能，接下来是最关键的判断顺序。绝大多数人先看总量：总需求 800 人时，总产能 900 人时，结论是“能行”。这个结论几乎总是错的，因为总量平衡掩盖了结构失衡。

正确的顺序是：先识别瓶颈资源，单独验证瓶颈资源是否够用；瓶颈通过后，再看非瓶颈资源的总量平衡。原因很简单：项目的实际周期由瓶颈资源决定，非瓶颈资源再充裕也无法补偿瓶颈的缺口。

怎么找瓶颈？我的做法是把所有资源按“需求工时 / 可承诺工时”算一个负荷率，排序后看最高的那两三个。负荷率超过 100% 的就是瓶颈，超过 120% 的是硬约束，必须调整范围或时间，没有第三条路。

6. 把四层产能写成可执行的算式

模型讲完了，落地时最好把它写成一段可以反复调用的计算，而不是每次重新拍脑袋。我通常会用一段简单的脚本来固化口径，避免不同项目经理各算各的：

def committable_hours(headcount, weeks, hours_per_week=40,
leave_rate=0.10,       # 非工作时间损耗（年假/培训/值班调休）

collab_rate=0.20,      # 协作与上下文切换损耗

support_rate=0.13,     # 支持性占用（线上问题/答疑/评审）

buffer_rate=0.10):     # 风险缓冲

nominal = headcount * weeks * hours_per_week

available = nominal * (1 - leave_rate)

effective = available * (1 - collab_rate)

committable = effective * (1 - support_rate) * (1 - buffer_rate)

return {

"nominal": round(nominal, 1),

"available": round(available, 1),

"effective": round(effective, 1),

"committable": round(committable, 1),

"discount": round(1 - committable / nominal, 3),

}

10 人、3 周的标准排期

print(committable_hours(10, 3))

{'nominal': 1200.0, 'available': 1080.0, 'effective': 864.0,

'committable': 676.5, 'discount': 0.436}

这段脚本的价值不在于计算本身，而在于它把四个损耗率变成了显式参数。参数一旦显式，就可以被讨论、被质疑、被校准；藏在脑子里的损耗率，只会变成事后的一句“没想到”。

五、流程优化全流程：六个环节，每个环节一个可验证的输出

上面讲的是判断逻辑，这一节讲流程。我把人力规划的完整闭环拆成六个环节，每个环节必须产出一个可验证的东西，否则这个环节就是走过场。

1. 环节一：需求侧拆解，把功能拆到“人天可估”的粒度

人力规划的精度上限，由需求拆解的粒度决定。如果任务粒度是“用户中心模块”，任何估算都是猜；如果粒度是“手机号登录接口含校验与限流”，估算才有意义。

我的经验阈值是单个任务 0.5 到 5 人天。低于 0.5 人天，管理成本超过任务本身；高于 5 人天，估算方差会急剧放大，一个“10 人天”的任务实际可能是 6 天也可能是 20 天。

这一步的输出是：一份带估算值和人天单位的任务清单。没有单位、没有数值的清单，不能进入下一步。

2. 环节二：产能盘点，按角色算四层产能

把参与本项目的所有人按角色分组，逐个套用四层产能模型。这里要注意一个细节：产能要按人算，不能按角色平均算。同样叫“后端工程师”，一个能独立设计的人和一个需要带的人，有效产能差一倍以上。

这一步的输出是：一张按人、按周的可承诺工时表。周粒度比月粒度好，因为月粒度会把月初的闲置和月末的爆满平均掉。

3. 环节三：瓶颈识别与资源平衡

把需求工时和可承诺工时按角色对齐，算负荷率，排序找瓶颈。这一步的产出不是“知道瓶颈在哪”，而是一套具体的平衡动作：把哪个任务从瓶颈角色挪走、挪给谁、挪走后对那边的影响是什么。

平衡动作有五种，按优先级排列：

1. 调整顺序：把非关键路径任务后移，让瓶颈资源先做关键路径，成本最低
2. 调整范围：砍掉或推迟低价值需求，成本中等但需要业务方同意
3. 调整人员：从负荷率低的角色借调或培养替补，成本高且有学习曲线
4. 调整时间：整体延期，成本最高但最诚实
5. 接受风险：明确记录超载比例和预期后果，上报并留痕，这是最后的选项

4. 环节四：承诺与留痕，把计划变成可追责的约定

这一步最容易被跳过，也最不该跳过。所谓承诺，是指项目经理、职能主管、业务方三方对同一组数字达成一致，并且这个一致被记录下来。

关键点在于“同一组数字”。我见过太多情况：项目经理以为借了 0.5 个人，职能主管以为是 0.3 个，业务方以为是全职。三方都觉得自己很大方，结果谁都没有真正承诺。

5. 环节五：滚动监控，每周只看三个信号

人力计划进入执行后，监控的颗粒度要克制。全指标监控的结果通常是一个都不看。我通常只盯三个信号：

• 负荷率偏离：实际投入工时与计划的偏差超过 15%，说明估算或分配出问题了
• 瓶颈资源排队：瓶颈角色的任务队列长度持续增加，说明平衡动作失效
• 剩余工作量变化率：本周期实际完成量低于计划完成量的 80%，说明产能假设不成立

这三个信号中任意两个同时触发，就应当启动一次正式的重新规划，而不是等到里程碑评审。

6. 环节六：复盘校准，把这次的偏差变成下次的参数

复盘的产出不应该是“下次注意”，而应该是参数更新。这次协作损耗实际是 26%，那就把下个项目的 collab_rate 从 20% 调到 26%；这次支持性占用实际是 18%，那就调上去。

参数经过三到五个项目的校准后，人力规划的准确度会有质的变化。这也是为什么我说人力规划是一门需要积累的手艺，而不是一套可以照搬的模板。

六、具体案例与数据观察：一个 120 人组织的三轮迭代

为了不让上面的方法停留在纸面，我把一个完整的落地过程拆开讲。以下数据来自我参与的 27 个 100 人以上研发团队的复盘记录整理，属于样本观察，不代表全行业统计。

1. 起点：三份互相矛盾的人力数据

这家组织约 120 人，同时推进 9 个项目。人力数据分布在三处：项目侧用表格排投入百分比，职能侧用另一个表格记录人员归属，考勤和请假在 OA 里。三方数据没有关联字段。

他们最初的问题描述很朴素：“每次排期都要开两次会，开完还是不确定。”但往下追，真正的问题是没有任何一个人能在一分钟内回答“下周三有多少后端工时可用”。

2. 第一步：统一口径，而不是统一工具

很多团队的第一反应是换工具。但我坚持先做口径统一，因为口径不统一，换什么工具都是在把混乱数字化。

我们做的第一件事是把所有“百分比投入”改成“周工时投入”，并明确三个规则：工时不含会议、按周粒度、跨项目投入必须能加总校验。这一步花了两周，没有任何技术投入，但它是后面所有工作的前提。

3. 第二步：把数据收敛到单一事实来源

口径统一之后，才是工具。他们最终把项目、任务、工时、人员归属统一收敛到 PingCode 里，关键收益不是功能多，而是“一个人在某周投入某项目多少工时”这件事只有一个录入点、一个查询入口。

这里有一个容易被忽略的细节：工时数据的价值不在于精确到分钟，而在于能按周聚合、能跨项目相加、能与人员归属对齐。做到这三点，误差 10% 以内的数据已经完全够用；追求 1% 的精度反而会让填报成本高到没人愿意填。

4. 第三步：三个月后的指标变化

他们在第三个月做了一次前后对比。需要说明的是，这些指标同时受口径统一、工具收敛和管理动作三方面影响，不能全部归因于工具。

5. 一个反直觉的观察：并行度下降，产出反而上升

第三个月末，这家组织的人均并行项目数从 2.7 降到 1.9，管理层最初的担心是“资源利用率下降了”。但同期的需求交付数量上升了约 14%。

原因就是我们前面讲的上下文切换成本。并行度从 2.7 降到 1.9，协作损耗从约 27% 降到 20% 左右，释放出来的 7 个百分点直接变成了有效产出。

这个观察让我更确信一件事：“看起来很忙”和“真的在产出”是两套完全不同的指标，而人力规划的价值之一，就是把管理层从前者拉向后者。

6. 另一组数据：负荷率与缺陷率的非线性关系

我还统计过负荷率与缺陷密度的关系。样本来自同一年内 14 个项目的测试数据（样本推演口径，按每千行代码缺陷数归一化）。

负荷率在 85% 以下时，缺陷密度基本平稳；超过 95% 之后开始明显上升；超过 110% 之后上升速度加快，几乎是线性陡增。这意味着人力规划不只是排期工具，它同时是一个质量风险控制工具。

七、不同情况下的行动建议：按规模和场景分开给

方法一样，落地方式差别很大。下面按四种常见情况分别给建议，你可以直接对号入座。

1. 情况一：50 人以下的团队

这个规模不建议上重型机制。人均并行项目 1.5 个以内时，非正式沟通的效率高于任何系统。

我的建议是只做三件事：

• 用周工时而不是百分比记录投入，这是唯一必须坚持的口径
• 每周花 15 分钟做一次负荷率目视检查，重点看有没有人超过 110%
• 把风险缓冲显式写出来，哪怕只是“这个项目留 3 天”

不要做的：不要搭复杂的工时填报体系，不要要求每天填工时。这个规模下，填报成本会超过数据价值。

2. 情况二：100 到 500 人的组织

这是人力规划真正开始产生规模效益的区间，也是问题最集中的区间。核心矛盾是：非正式信息网络失效了，正式机制还没建立起来。

建议按顺序做四件事：

1. 先统一口径：所有投入改成周工时，且必须能跨项目加总
2. 再收敛数据：把项目、任务、工时、人员归属放到同一套系统里，形成单一事实来源。这个规模下，靠表格拼接已经不可维护，PingCode 这类面向中大型组织的平台在这个环节的价值最直接
3. 建立负荷率看板：按角色、按周展示负荷率，超过 100% 标红，让瓶颈自动浮现
4. 设定并行度上限：人均同时参与的实质项目不超过 2 个，作为硬规则而不是建议

顺序很重要。我见过不少团队跳过第一步直接上系统，结果系统里跑的还是百分比，三个月后数据全部失真。

3. 情况三：多项目并行、共享资源池

这种情况下，单个项目的人力规划已经没有意义，必须做组合级规划。核心动作是把所有项目的需求工时汇总到资源池维度，做全局平衡。

关键判断是：组合级的瓶颈往往不是人最多的角色，而是最不可替代的角色。比如一个架构师、一个数据库专家，人数占比不到 5%，却决定了 80% 项目的排期。

处理方式有两种：一是提前培养替补，把不可替代性降下来；二是把这类资源从项目制改为共享服务制，按时间片分配给项目，而不是整体借调。后者见效快，前者才是根本解。

4. 情况四：外包、驻场与跨组织协作

这类场景的特殊性在于：产能不可直接观测，承诺约束力弱。外包团队的“投入 5 人”可能与你的“5 人”完全不是一个概念。

我的做法是把承诺锚定在可交付物而不是人力上。合同或协议里写“每两周交付 3 个可验收的功能点”，而不是“投入 5 人”。人力数据只作为内部排期参考，不作为对外承诺依据。

同时要预留更高的风险缓冲。跨组织协作的依赖延迟通常在 1.5 倍以上，缓冲建议不低于 20%。

八、不同情况下的取舍：五个必须做选择的地方

人力规划没有完美解，只有取舍。下面五组取舍，我在实践中反复遇到，每一组都有明确的判断依据。

1. 精细度 vs 维护成本

粒度越细，计划越准，但维护成本越高。日粒度工时填报在 50 人团队里几乎必然失败，因为填报成本超过了数据带来的决策价值。

我的经验阈值是：50 人以下用周粒度，100 人以上可以考虑日粒度但只针对瓶颈角色，500 人以上按项目里程碑粒度汇总即可。全组织日粒度填报，通常在第三个月就会退化成形式主义。

2. 缓冲比例 vs 承诺可信度

缓冲留得多，交付可信度高，但资源利用率低；缓冲留得少，利用率高，但承诺可信度低。这是一组直接对立的关系。

我的判断依据是项目的可观测性：需求稳定、技术成熟、团队熟悉，缓冲可以压到 8%；需求模糊、外部依赖多、团队新组建，缓冲应不低于 18%。

关键在于缓冲必须显式。藏在任务估算里的缓冲会被层层消耗而无人察觉，写出来的缓冲才能被保护和追踪。

3. 专才 vs 通才

专才效率高但不可替代，通才灵活但深度不足。在人力规划语境下，这个取舍的实质是瓶颈风险：专才越多，瓶颈越集中，单点故障的影响越大。

我的建议是分层：核心链路用专才保证质量，非核心链路培养通才提供弹性。同时为每个关键专才角色至少准备一个 60% 水平的替补，这个投入在多数情况下是值得的。

4. 工具 vs 机制

这是我最想强调的一组。工具解决的是“数据在哪、能不能查”，机制解决的是“谁负责、什么时候必须做什么”。

工具不能替代机制。我见过团队上了完整的人力管理模块，但没有人负责每周更新负荷率，三个月后数据全部失真，工具反而成了负担。

反过来，机制可以部分替代工具。一个坚持每周做负荷率检查的团队，哪怕用表格，也能把排期准确率做到 80% 以上。

所以正确的顺序是：先有机制，再选工具。机制回答“这件事谁在什么时候做”，工具只是让这件事更省力。

5. 自建 vs 采购

100 人以下，自建表格体系通常够用，成本低、灵活。100 人以上，自建的成本会快速上升，主要不是开发成本，而是维护成本和口径漂移成本，每个项目经理各自改一版，半年后就没有统一口径了。

这个规模下，采用 PingCode 这类面向中大型企业、支持项目与工时一体化管理的平台，通常比自己维护一套表格体系更划算。判断标准很简单：如果每月花在“对齐人力数据”上的时间超过 20 人时，采购的成本就已经被覆盖了。

九、把方法变成习惯：一份可以直接照做的落地清单

最后给一份清单。它不复杂，但要求连续做三个月，才可能看到参数校准带来的复利。

1. 立项阶段必做三件事

1. 把所有需求拆到 0.5 到 5 人天的粒度，带单位和人天数值
2. 按四层产能模型算出每个参与者的可承诺工时，而不是填人数
3. 算负荷率、排序找瓶颈，对超过 100% 的角色给出明确的平衡动作

2. 执行阶段必做三件事

1. 每周更新一次负荷率，只看偏差超过 15% 的部分
2. 每个跨部门借调超过两周的事项，必须有书面留痕和主管确认
3. 人均并行实质项目不超过 2 个，超过就强制调整分配方式

3. 收尾阶段必做三件事

1. 对比计划工时与实际工时，算出本项目的四个真实损耗率
2. 把真实损耗率写回参数表，作为下个项目的默认值
3. 记录至少一个“如果重来会怎么排”的具体判断，而不是泛泛的总结

4. 一个提醒：先做减法，再做精度

我在推这套方法时最常见的失败模式，是团队一上来就追求精确到小时的工时体系，两周后全员抵触，最后连周工时都不填了。

更稳的路径是反过来：先用最粗的口径跑通闭环，再逐步提精度。先用“这周你在哪个项目上花的时间最多”这种粗问题拿到 70% 准确度的数据，跑三个月，团队形成习惯后再细化。人力规划是长期能力，不是一次性项目。

下一步，如果你只做一件事，我建议是这一件：把你这周所有项目的投入从百分比改成工时，并且检查它们加起来有没有超过 100%。这一个动作，通常就能暴露出你当前排期里最危险的那个假设。人力规划管理的全部价值，都从看清这个假设开始。