资源负载产能全流程：项目成员入门指南与一文讲清

去年十一月，我陪一家做工业软件的客户做季度交付复盘。他们有一条很典型的症状：项目计划上每个人的负载都标在 80% 左右，看上去非常健康，可那个季度 6 个项目里有 4 个延期，平均延期 23 天。把工时数据拉出来之后，问题根本不在"负载够不够"，而在于那 80% 是排期表上的 80%，执行时同一个人手上平均压着 4.3 个并行任务，光任务切换就吃掉了三成时间。

这件事让我重新梳理了一遍"资源负载产能"这条链路。它不是三个并列的名词，而是一条有先后顺序的计算链：资源决定名义产能，负载决定真实占用，两者相减得出还能不能接活，而中间那几层损耗，才是项目能不能按时交付的全部真相。这篇《资源负载产能全流程：项目成员入门指南与一文讲清》，我按自己实际落地的顺序来讲，先给结论，再讲失控的机制，然后拆误区、给判断逻辑、上案例数据，最后说清楚什么情况下该做、什么情况下该停。

一、先给结论：资源、负载、产能是一条计算链

如果只记一句话，我希望是这句：资源管理管的是"供给"，负载管理管的是"需求"，产能管理管的是"两者的差在什么区间内可承诺"。大部分团队的资源管理失败，不是因为不会填工时，而是把这三件事混成了一张表。

1. 结论一：产能必须分四层算，只用一层一定算错

我见过最多的一种算法是：100 人，每人每月 21.75 天，每天 8 小时，所以月产能 17400 小时。这个数字本身没错，但它叫"名义产能"，是理论上限，不是你能承诺的东西。真正要用的，是往下扣了三层的数字。

第一层，可用产能：扣掉法定假、年假、病假、培训、会议、行政事务、面试、线上支持。在研发型组织里，这层扣完通常只剩 68%-75%。第二层，有效产能：再扣任务切换、等待依赖、返工、环境准备，落到 50%-60%。第三层，承诺产能：只把有效产能的 80%-85% 拿出来对项目承诺，剩下的做缓冲。

算一遍就明白为什么很多团队"感觉人不少，活就是出不来"：17400 小时名义产能，经过三层折损，可承诺的只有 7500 小时左右，折合 43 个人月。也就是说，100 人的团队，实际能对项目承诺的产能大约相当于 43 个全职人力。这个数字第一次算出来的时候，我那个客户的研发总监沉默了很久，他过去一直按 90 人月排计划。

2. 结论二：负载有四个口径，只统计"计划负载"等于自欺

负载这一侧同样有四层。计划负载是排期表上派下去的；承诺负载是需求方已经接受、不能随便撤的；实际负载是工时或实际消耗反映出来的；隐含负载是从来没进过任何表、但确实在吃时间的部分，线上问题、跨部门答疑、评审、带新人、面试。

我复盘过的团队里，隐含负载普遍占实际工时的 18%-32%，而它在排期表上的记录通常是 0。这就是为什么"计划负载 80%"和"实际体感 110%"可以同时成立。项目成员最容易在这里吃亏：你不把这些活登记进系统，管理层的视图里你就是"还有余量"，下一个需求还会派给你。

3. 结论三：80% 不是健康线，是警戒线的下沿

很多管理文章把 80% 负载率当成健康标准，我不完全同意。80% 在"月度平均"口径下看着舒服，但如果这是有效产能口径的 80%，意味着团队已经进入了排队敏感区，任何一点需求波动或人员请假，都会立刻变成延期。原因在第三节用排队论讲清楚。

我自己的经验区间是：有效产能口径下，65%-78% 是可以稳定承诺的区间；80% 开始进入警戒；90% 以上属于过载，延期会非线性放大。"非线性"这三个字是关键，多数人把它当线性理解了。

4. 结论四：项目成员真正要做的动作只有五个

作为项目成员，你不需要学会整套资源管理体系，但下面五件事必须做，而且顺序不能反：

1. 认领容量：每个迭代/月度开始前，确认自己这个周期可用的天数，扣掉已排的假期、培训、支持值班。
2. 拆到可估算粒度：单个任务不超过 2-3 天，超过就继续拆，否则估算误差会吃掉整个缓冲。
3. 显性化隐含负载：支持、答疑、评审、面试，全部建成工作项登记，哪怕只登记一个总量。
4. 每周更新剩余工时：只更新"还剩多少"，不更新"花了多少"，前者才驱动预测。
5. 偏差超过 20% 主动上报：不等到延期才说，偏差发生在第一周，成本最低。

5. 结论五：全流程的成败在口径，不在工具

这句话我在第五节的案例里会用数据证明。同一套平台，一家企业用得风生水起，另一家 18 个月后彻底废弃回归表格，差别不在功能选型，而在"工时到底登记在哪个层级""承诺容量由谁确认""偏差要不要写原因"这三个口径约定上。

二、失控的机制：资源为什么"看起来够、实际不够"

要理解资源负载产能为什么总是失控，得先接受一个不太舒服的事实：失控很少是因为人不够，而是因为可用的时间被结构性地切碎了。下面三个场景，几乎在每个 100 人以上的组织里都能找到对应。

1. 场景一：共享专家被三个项目同时按 50% 排

我做过一次统计：一个 120 人的研发组织，2 名架构师被 3 个项目集共享。项目 A 排 50%，项目 B 排 50%，项目 C 排 50%，单看每一条都合理，加起来 150%，已经超了。而实际上每个项目真正需要的介入强度是 60%-70%，需求侧合计 190%。

结果是三件事同时发生：三个项目的关键评审都在等同一个人的时间窗口；架构师每天在三个上下文之间切换；每个项目经理都觉得"他只给了我们一半时间"，于是各自加派了对接人，组织又多出三层沟通。这就是共享资源在百分比口径下的经典失真：百分比可以相加超过 100%，但一个人的一天只有 8 小时。

2. 场景二：支持型负载从不入账

线上问题、售前答疑、客户拜访、内部评审、招聘面试、新人带教，这些活有两个共同特征：不可预测、不可拒绝。它们从不进入排期表，但真实消耗时间。我抽样看过 9 个团队三周的工时记录，支持型负载占实际工时的中位数是 26%，最高的一组是 41%。

这意味着什么？如果一个团队按名义产能排到 90%，实际可用只剩 74%，而支持型负载再吃掉 26%，真实的项目可用产能是 48%。计划从第一周就已经注定完不成。

3. 场景三：计划按"理想周"排，执行按"真实周"跑

理想周是 5 天 × 8 小时，真实周是 3.6 天 × 7 小时左右的可支配产出时间。差距来自晨会、临时插入的会议、环境故障、等审批、等测试环境。这不是员工不努力，而是组织运行的物理损耗。

比较务实的做法是：排期时直接用"真实周"作为单位，一人一周按 3.5 个有效人天计算。这个系数在研发、测试、设计岗位上都适用，销售、运维等被打断频率更高的岗位要降到 3.0 甚至 2.5。用一次，你就再也不想回到 5 天的算法了。

4. 失控的数学解释：排队论里的利用率悬崖

为什么提高到 90% 利用率，延期不是多 10% 而是多几倍？因为任务到达是随机的，处理时间也是随机的。在 M/M/1 排队模型里，平均等待时间与服务时间之比约等于 ρ/(1-ρ)，其中 ρ 是利用率。

代入数字：利用率 50% 时，等待时间是服务时间的 1 倍；70% 时 2.3 倍；80% 时 4 倍；85% 时 5.7 倍；90% 时 9 倍；95% 时 19 倍。从 80% 到 95%，只提高了 15 个百分点，等待时间却翻了将近 5 倍。

这就是我一直反对把"人均利用率 95%"当管理目标的原因。它不是让团队更高效，而是把整个系统推到悬崖边上，任何一次请假、一个线上故障、一个需求变更，都会引发连锁延期。真正的高效组织，看起来总是"有点闲"，因为那份闲就是系统的缓冲。

三、六个常见误区，每一个都能让负载表失效

下面六个误区，是我在复盘里重复遇到频率最高的。它们不是认知问题，而是操作习惯问题，所以纠正方式也必须落到具体动作上。

1. 误区一：把工时填报当成资源管理

工时填报记录的是"过去发生了什么"，资源管理要回答的是"未来还能不能接"。两者的数据结构完全不同：前者是流水，后者是余额。只填工时不做预测的团队，本质上是在做财务记账，不是在做产能规划。

判断方法很简单：如果你的负载视图只能看本月，看不到下个月，那它就不是资源管理，只是成本核算。我一般要求至少能看到未来 6-8 周的负载分布，否则调整窗口太短，什么也改不了。

2. 误区二：把 100% 利用率当目标

上一节已经用数字说明了。这里补一个组织行为学的观察：当利用率被当作考核指标，员工会主动制造"看起来很忙"的负载，把 1 天的活拆成 3 天登记、把等待时间也登记成工作、拒绝承接短期任务。指标一旦变成考核，数据就失真，而失真的数据比没有数据更危险。

3. 误区三：用"忙"衡量产能

"大家都很忙"是我最不喜欢听到的一句话。忙是投入，产能是产出，两者之间隔着效率和方向。一个团队可能全员满负荷地在做一个已经被市场否定的需求，忙得毫无意义。

有效的替代指标是吞吐量（单位时间完成的工作项数）和流动效率（实际工作时间 ÷ 从开始到交付的总时长）。流动效率低于 25% 的团队，说明大部分时间在等，这时候加人没用，得先解决阻塞。

4. 误区四：认为人天可以直接相加

1 个人干 10 天，不等于 10 个人干 1 天。沟通路径数按 n(n-1)/2 增长：3 个人是 3 条，5 个人是 10 条，10 个人是 45 条。加上知识传递、上下文对齐、集成冲突，人多之后边际产出会掉得很快。

我的经验系数是：在知识型工作上，3 人 20 天（60 人天）的任务，加到 5 个人通常需要 18-22 天，而不是 12 天；加到 8 个人，往往比 5 个人更慢。所以压缩工期靠的是拆解和减少依赖，不是堆人。

5. 误区五：用平均产能覆盖分布差异

团队里 20% 的人通常承担 45%-60% 的关键路径任务，这是我在十几个团队都验证过的帕累托分布。如果你用"人均 3.5 人天/周"去排期，看上去总量正好，实际上关键的那几个人已经被排到 140%，而其他人只有 50%。

结果就是：整体负载率 78%，看起来健康；关键人负载 140%，持续三个月后离职。资源管理最贵的错误，是把结构性过载藏在平均值里。

6. 误区六：只排一次，不做滚动

年度计划排完就锁死，是资源管理最常见的死法。需求在变、人在流动、优先级在调整，一份三个月前的负载表，准确率通常低于 50%。我要求的最低频率是双周滚动一次：每两周重算未来 6 周的负载，只看变化部分，15 分钟就能完成。

滚动的价值不在精度，而在"提前发现"。提前 2 周发现的资源冲突，有 80% 的概率能通过调顺序解决；提前 2 天发现的，基本只能靠加班或延期。

四、专业判断逻辑：怎么算、怎么判、怎么调

这一节是整篇文章的方法论核心。我把这套逻辑压成五步，每一步都给出可执行的动作和判断标准，你可以直接拿去用。

1. 第一步：先把产能口径定死

口径不统一，后面全是扯皮。我通常用一张四列表把口径固定下来，写进团队的工作约定里，谁都不能临时改。

这张表最好打印出来贴在项目群里。我经历过最有效的一次口径对齐，就是团队把"承诺产能 = 有效产能 × 85%"写进了迭代准入规则，任何迭代的计划工时超过这个上限，就不许进入开发。

2. 第二步：把四个来源的负载全部收进来

负载收集的关键是"不漏"，而不是"精确"。四个来源缺一不可：项目任务、支持事务、组织事务（会议、培训、面试）、个人事务（假期、调休）。

我的做法是给后三类各建一个"容器型工作项"，不拆细，只登记总量，每周更新一次。比如"本周线上支持：1.5 人天"，就这一行，不需要拆成 20 个小问题。粒度粗一点没关系，漏掉才是致命的。

3. 第三步：算负载率，并按区间判断状态

负载率的分母必须是有效产能，不是名义产能。这一点错了，整个判断都会偏移。算完之后对照下表，直接落到动作上。

这里要提醒一句：88% 以上的过载状态下，"加班"不是解决方案，而是问题的转移。它把当期的产能缺口转移到下一期的返工和人员流失上，账面好看一个季度，代价是后面两个季度。

4. 第四步：看结构，不只看总量

总量健康、结构崩溃，是最隐蔽的情况。要检查三个结构维度：

• 人维度：是否有单点依赖？某个人被 3 个以上项目共享，就是红色信号。
• 技能维度：某个关键技能（如数据库调优、安全评审）是否只有 1-2 人具备？这类负载无法靠加人缓解。
• 时间维度：负载是否集中在某两周？峰值负载往往是平均值 2 倍以上，而项目延期几乎都发生在峰值期。

我一般会专门看"峰值负载率"这个指标：不看月均，看最忙那一周的负载。如果一个团队月均 75%，但有三周超过 105%，那它实际上是过载团队，只是被平均值掩盖了。

5. 第五步：调整手段有严格优先级

发现过载之后，很多团队的第一反应是加人或加班。按我的经验，成本从低到高、效果从快到慢的顺序是：

1. 砍范围：把本期非核心需求移出，成本几乎为零，效果立竿见影。
2. 调顺序：把不依赖外部时间的任务后移，削平峰值。
3. 改做法：降低交付标准（比如先上核心路径，边缘场景下期补），或用现成方案替代自研。
4. 调人：从欠载团队借调，或临时引入外部资源，有 1-2 周的上手成本。
5. 延期：重新谈判交付日期，对客户关系有成本，但比交付一个残缺品要好。
6. 加班：成本最高、可持续性最差，只能作为 1-2 周的应急手段，不能作为方案。

把顺序倒过来用，是很多团队陷入"越忙越乱"的根本原因。加班解决的从来不是产能问题，它只是把问题延后，并且加了利息。

6. 一个可以直接跑的计算脚本

下面这段逻辑我用了三年，Excel 和脚本都能实现，核心是把四层口径固化下来，避免每次手工换算出错。

# 资源负载率计算：以"有效产能"为分母
HOURS_PER_DAY = 8

WORKDAYS_PER_MONTH = 21.75

AVAILABLE_RATIO = 0.72   # 扣假期、会议、培训、支持

EFFECTIVE_RATIO = 0.78   # 再扣切换、等待、返工

COMMIT_RATIO    = 0.85   # 只承诺 85%，留缓冲

def capacity(headcount):

nominal   = headcount * WORKDAYS_PER_MONTH * HOURS_PER_DAY

available = nominal * AVAILABLE_RATIO

effective = available * EFFECTIVE_RATIO

committed = effective * COMMIT_RATIO

return {

"名义产能": round(nominal),

"可用产能": round(available),

"有效产能": round(effective),

"承诺产能": round(committed),

}

def load_rate(assigned_hours, effective_hours):

分母必须是有效产能，不是名义工时

return round(assigned_hours / effective_hours * 100, 1)

cap = capacity(100)

{'名义产能': 17400, '可用产能': 12528, '有效产能': 9772, '承诺产能': 8306}

print(load_rate(8500, cap["有效产能"]))  # 87.0 -> 警戒区，禁止接新需求

这段脚本的价值不在代码本身，而在于它把"用哪个数当分母"这件事变成了不可绕过的规则。口径一旦写进代码，就不会因为某个人换岗而漂移。

五、案例与数据观察：把这条链路跑通需要什么样的载体

前面讲的都是逻辑。但逻辑要落地，必须有一个地方承载"工作项，工时，容量，负载视图"这条数据链。这也是为什么这类流程最终都会落到项目管理平台上，而不是留在表格里。

1. 为什么表格撑不住

表格的问题不是功能弱，而是维护成本随规模超线性增长。10 个人的负载表，一个人每周花 30 分钟能维护；100 个人的跨项目负载表，涉及到 200 多个工作项、4 类负载来源、每周滚动更新，人工维护的成本会超过它带来的收益。

我在一家 260 人的企业看到过极端情况：资源管理员每周花 11 个小时手工汇总 7 张表，做出来的负载视图在发出当天就已经过时。第 14 个月，这套表被彻底放弃。

2. 我们在 PingCode 里的落地方式

后面这家企业换成了 PingCode，服务对象是中大型企业及 100 人以上组织，这个定位和他们的规模是匹配的。落地过程我拆成四步，顺序很重要。

（1）先统一工作项层级

把工作项收敛成需求、任务、缺陷三类，工时只登记在"任务"这一层，且任务必须挂在迭代下。这一条看起来是规范问题，实际是数据一致性问题，如果工时可以挂在任意层级，汇总时一定会重复计算。

（2）再建立迭代容量承诺

每个迭代开始前，成员先确认自己本迭代的可用人天（扣掉假期、培训、支持值班），系统据此算出团队的承诺工时上限。计划工时超过上限，迭代不予启动。这个"不许启动"的硬约束，是整套流程里最有效的一环，它把负载控制从"事后统计"变成了"事前拦截"。

（3）然后打开跨项目的资源负载视图

按人、按角色看未来 6-8 周的负载分布，超载用颜色标出。这一步的关键不是看总量，而是看共享资源的冲突，哪个架构师被三个项目同时排，一眼就能看出来。

（4）最后固化双周滚动复盘

每两周对比计划工时与实际工时的偏差，偏差超过 20% 的工作项必须填写原因。原因分类只有五种：需求变更、估算偏差、依赖等待、支持插入、人员变动。三个月后，这张分类统计表会告诉你团队产能损耗到底出在哪一环。

3. 上线前后九个月的数据观察

下面是我跟踪这 9 个月拿到的对比数据。需要说明：这是单一样本，未做对照组，不能当作普遍规律，但方向性是清楚的。

值得单独说的是"人均并行任务数"这一项。从 4.3 降到 2.1，不是通过增加人手实现的，而是通过负载视图暴露冲突之后，主动做了任务合并和顺序调整。并行度是多数团队最容易改善、也最容易被忽视的产能杠杆。

4. 一个反例：只换工具不改口径，18 个月后回归表格

同一年，我接触到另一家规模相近的企业，也上了同类平台，结果完全不同。他们把平台当成了"更好的表格"，工作项层级混乱、工时登记的粒度从 0.5 小时到 3 天不等、没有迭代容量承诺、没有偏差复盘。

18 个月后，资源负载视图彻底废弃，团队回归 Excel。真正的原因不是工具不好用，而是三个口径约定一个都没建立：工时挂在哪个层级、谁对承诺容量负责、偏差要不要归因。这三件事不解决，任何平台都只是把混乱数字化了一遍。

这也是我一直强调的判断：资源负载产能全流程的成败，70% 在口径和管理约定，30% 在工具承载。工具的作用是让正确的口径变成不可绕过的约束，而不是替代你去想清楚口径。

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

方法论不能一刀切。团队规模、项目结构、组织成熟度不同，该做的事情优先级完全不同。下面按四种典型情况给建议，你可以直接对号入座。

1. 8 人以下团队：先做可见，不做精确

这个规模不需要负载率计算。人少，谁忙谁闲一眼就能看出来，做复杂的产能模型纯属浪费。要做的是两件事：一是把任务拆到 2 天以内，二是每周花 10 分钟对齐一次"这周谁在做什么、下周谁有空"。

这个阶段最大的风险不是负载失控，而是过早引入流程。我见过 6 个人的团队搞三套工时报表，结果一半时间在填表。记住：这个规模下，沟通成本远低于管理成本。

2. 8-30 人团队：以单项目为主，做容量承诺

到了这个规模，开始出现"一个人同时干两个项目"的情况。核心动作是建立迭代容量承诺：每个周期开始前，每人报可用天数，加总得到团队容量上限，计划不超过上限的 85%。

同时要开始显性化支持型负载。哪怕只用一个"支持事务"的工作项登记总量，也比完全不记强得多。这个阶段的判断标准很简单：月末能不能说清楚这个月的时间都去哪了。

3. 30-100 人团队：多项目共享，必须做技能维度

这是最难的区间。项目变多，共享资源变多，平均值彻底失效。核心动作有三个：

• 建立跨项目负载视图，按人看未来 6 周分布，重点盯共享资源。
• 建立技能矩阵，标出每个关键技能的可替代人数，只有 1 人的技能就是红色风险。
• 设置资源冲突的升级机制：冲突在项目组内解决不了，48 小时内升级到资源负责人。

这个阶段最常见的失败是"每个项目都在局部最优，整体崩盘"。解决办法只有一个：把资源分配权从项目经理手里部分收归到资源负责人手里。这件事有组织阻力，但不做就永远在抢人。

4. 100 人以上组织：项目集 + 资源池，做滚动预测

这个规模靠手工已经不可能，必须依赖平台。重点从"算准"转向"算稳"：建立资源池（按角色而不是按部门归集）、做 8-12 周滚动预测、把产能规划纳入年度经营预算。

PingCode 这类面向中大型企业的平台在这个阶段的价值才真正体现出来，不是因为功能多，而是因为它能把工作项、工时、迭代容量、跨项目负载放在同一条数据链上，让口径变成系统约束。100 人以下的组织用不用平台差别不大，100 人以上不用平台基本做不成。

5. 外包与跨部门协作：管接口人负载，不管团队负载

跨组织协作时，你无法管理对方的产能，只能管理接口。这时候要盯的是接口人负载和交付节拍：对方谁在对接、他手上还有几个项目、他的响应周期是几天。

一个实用做法是给每个外部接口设置"响应 SLA + 每周固定同步窗口"，把不确定的等待变成可预测的节拍。我见过最有效的一次改善，只是把跨部门评审从"随时提"改成"每周二、周四两次批量评审"，等待时间从平均 4.2 天降到 1.1 天。

七、取舍：什么时候不该做全流程

讲完了怎么做，更重要的部分是什么时候不做。资源负载产能全流程本身是有成本的：数据维护、会议、填报、复盘，一个 50 人团队跑完整套，每月大约要消耗 18-25 个人天。如果它带来的收益低于这个成本，就不该做。

1. 需求波动极大时，排序优先于排期

如果你们的需求月度波动系数超过 0.5（也就是每月需求量的标准差超过均值的一半），做精细排期的意义不大，排完就变。这种情况下应该把精力放在优先级排序机制上：确保任何时候被砍掉的都是低价值需求。

判断标准：过去三个月中，有多少比例的计划外需求插入了当期？超过 35%，就别做细排期了，先做需求准入。

2. 项目周期短于 6 周时，看板优于负载表

短周期项目的产能模型精度要求低，但响应速度要求高。这时候看板的"在制品数量限制"比负载率更有效，限制同时进行的任务数，比精确计算每个人还剩几小时更实用。

我一般在 6 周以内的项目上用 WIP 限制（每人同时在制任务不超过 2 个），6 周以上才启用负载表。用错工具的成本，比不用工具更高。

3. 组织还没统一工作项语言时，先统一语言

如果需求、任务、缺陷在不同团队有不同的定义，工时登记在不同层级，那先做资源管理一定会失败，数据根本对不上。这时候的正确顺序是：统一工作项定义 → 统一工时口径 → 再做负载管理。

这个顺序颠倒的案例我见过太多。共同特征都是：平台上线三个月，数据一片混乱，然后得出结论"这个工具不适合我们"。

4. 成本边界：投入超过收益的三个信号

下面三个信号出现任意两个，就该考虑收缩流程，而不是继续加码：

• 管理性工作（填报、会议、复盘）占团队总工时超过 12%。
• 负载视图的更新频率低于每周一次，且没人主动查看。
• 偏差复盘连续两个季度没有产生任何调整动作。

这三个信号的本质是同一个：这套流程已经不再驱动决策，只剩下仪式感。这时候应该砍掉流程，而不是增加考核。

5. 三个"宁可不做"的场景

第一种，团队正在经历大规模重组，人员流动率超过 30%。这时候负载表每周都失效，做了也是白做，不如先稳定组织。

第二种，公司还没有稳定的产品方向，处于探索期。探索期的核心是快速试错，不是资源效率，精细的产能管理会扼杀试错空间。

第三种，团队处于明显的欠载状态（负载率长期低于 55%）。这时候的问题不是分配，而是需求不足，做负载优化等于优化一个不缺的东西。

八、总结：把产能当成预算来管

写到这里，我想把整套东西收束成一个比喻：产能就是团队的钱包，负载就是支出，资源管理就是记账加预算。你不会因为账上还有余额就随便花，也不会把每一分钱都花光不留应急，团队的时间也是同理。

三个我认为最值得记住的判断。第一，产能要分四层算，分母用错，后面全错；第二，80% 是警戒线不是健康线，因为等待时间在 85% 之后会陡增；第三，平均值会掩盖结构性过载，关键人负载必须单独看。

还有一个反直觉的结论：资源管理做得好的团队，看起来往往有点"闲"。那份闲不是浪费，是系统抵抗波动的能力。追求 100% 利用率的团队，短期报表漂亮，长期一定在救火。

1. 下一步：一周内可以做完的三件事

1. 算一次真实的产能：拿你团队的人数，按 21.75 天 × 8 小时 × 72% × 78% 算一遍，和你们现在排计划用的数字对比。差距会让你重新理解很多延期。
2. 统计一次隐含负载：让每个人回忆上周有多少时间花在了没进系统的事情上，算个百分比。这个数字通常会超过所有人的预期。
3. 找出三个单点依赖：列出团队里只有 1 个人会做的关键事情，这就是你未来三个月最大的交付风险。

2. 一个月内可以建立的机制

如果上面三件事做完了，接下来建两个机制就够了：迭代容量承诺（计划不超过承诺产能的 85%）和双周负载滚动（只看未来 6 周，15 分钟完成）。

这两个机制不需要任何工具就能跑起来，等它们稳定运行两个月、团队认可了口径之后，再考虑用平台承载。先有口径，再有工具；反过来做，八成会失败。

最后留一句话给正在纠结要不要做这套流程的人：如果你现在说不清团队下个月还能不能接新需求，那你已经在为这个空白付代价了，只是代价以延期的形式出现，没被记在资源管理的账上而已。