容量规划师

capacity-planner
分类通用
作者Alireza Rezvani
许可MIT
评分4.90/5
使用11.0K

capacity-planner

针对处理队列工作的运营团队（支持、CX、客户成功、BizOps、IT 运营、财务运营）的测算工具。基于 Erlang-C 排队论、利特尔法则（Little's Law）以及运营领导力经典理论（Fournier, Larson, Cleveland, Reinertsen）构建。确定性模型，仅使用标准库，无需 LLM 调用。

目的

你是一名运营负责人，团队规模从 15 人扩大到 35 人，但并不清楚 35 人的组织在峰值负载下实际表现如何。或者，你的利用率处于 88%，SLA 开始下滑。或者，你的招聘预算已获批，需要将其分配到四个季度，且不能让现有团队精疲力竭。本工具通过算术而非凭感觉来回答这些问题。

它将生成三个交付物：

1. 容量测算：针对 P50/P90/P99 需求，在 70/80/90% 利用率下的测算，包含每个时间点的 P(SLA 违约) 以及 SAFE/WATCH/AT_RISK/CRITICAL 风险等级。
2. 利用率健康度：提供成员级别的红绿灯状态以及团队整体判定（HEALTHY/SQUEEZED/OVERLOADED/UNBALANCED）。
3. 12 个月季度招聘计划：考虑入职爬坡曲线、流失率、季度需求增长以及管理幅度触发阈值。

使用场景

  • 年度运营容量规划（通常在 10 月至 11 月为下一财年规划）。
  • 季度重新测算：当需求变化 >15% 或流失率激增时。
  • 预算申请前防御：向 CFO 证明人员编制需求的数学依据。
  • 诊断分析：当运营团队未达成 SLA 时，用于判断是容量问题、流程问题还是瓶颈问题。
  • M&A / 新业务线启动模拟：为新团队或合并后的组织进行测算。

工作流

1. 需求采集。从工作系统（Zendesk, Intercom, JSM, ServiceNow, Salesforce）中提取 P50/P90/P99 的日单量/案例量。如果你只有平均值，请停止并提取分布数据。单点需求估算是运营中最昂贵的反模式。
2. 吞吐量建模。运行 capacity_modeler.py，输入需求、平均处理时间 (AHT)、SLA 目标、当前 FTE 和损耗率。使用 --profile 指定你的职能（support / cx / bizops / finance-ops / it-ops）。查看 80% 利用率所在行 —— 这就是你的测算基准点。
3. 标记利用率风险。针对当前团队的实际利用率数据运行 utilization_analyzer.py。根据 Reinertsen 的理论，任何持续利用率 >85% 的成员都存在吞吐量崩溃风险。团队成员间利用率差距 >30 个百分点意味着 UNBALANCED（不平衡） —— 在招聘前请先解决此问题。
4. 规划招聘顺序。运行 hiring_sequencer.py 并输入...
当前 FTE、目标年终人数、上手时间（ramp time）、流失率和增长率。它将采取前置招聘策略（Q1 35%，Q4 15%），应用上手曲线，并在管理幅度超过 7:1（IC/经理）时触发经理招聘。
5. 遍历“强制性问题库”（见下文）。一次一个问题，不要跳步。在确定计划之前，必须写下答案。

脚本

  • scripts/capacity_modeler.py — Erlang-C 容量测算，包含损耗（shrinkage）调整和 P50/P90/P99 违约概率。使用 --profile 可加载行业默认值。
  • scripts/utilization_analyzer.py — 成员级红绿灯分析 + 团队级健康状况判定（含方差检测）。
  • scripts/hiring_sequencer.py — 12 个月季度计划，包含上手时间、流失率、增长率、单季最高招聘人数限制以及经理触发逻辑。

以上三个脚本均支持 --input <path> (JSON)、--output {markdown,json}、--sample (内置示例) 和 --help。仅使用标准库。

快速示例

bash
# 为内置示例生成 Erlang-C 容量模型（所需人数 + P50/P90/P99 违约概率）
cd business-operations/skills/capacity-planner && python3 scripts/capacity_modeler.py --sample

参考资料

  • references/queueing_theory_canon.md — Erlang, Little, Hopp & Spearman, Reinertsen, Kingman, Cleveland, ITIL, Armony 等（共 8 个来源）。涵盖数学原理。
  • references/ops_workforce_planning_canon.md — Fournier, Larson, Google SRE Workbook, Frei, Lawler, Bersin, Gartner, Grove（共 8 个来源）。涵盖人员因素。
  • references/capacity_anti_patterns.md — 11 种命名反模式，附带引用来源、工具防护措施，以及 Lencioni + Goldratt + Christensen 定义的元学科。（8 个以上命名来源。）

资源

  • assets/capacity_brief_template.md — 20 分钟快速填写模板，包含三个工具的 JSON 骨架和输出检查清单。

前提假设

本技能假设：

  • 工作是排队式的（工单、案例、工作项），而非项目式。如果你的团队工作不是排队模式，则不适用本技能。
  • 需求在季度内具有足够的平稳分布。阶梯式变化（如新产品发布、并购、监管变动）需要在季度中途重新运行模型。
  • 你拥有至少 90 天的历史需求数据以计算 P50/P90/P99。如果没有，请先根据销售/用户基数预测生成分布。
  • 队列内服务是单类别的。如果你有严格的优先级分级（具有特定 SLA 的 P1/P2/P3），请将每个级别建模为独立队列并求和。
  • 渠道建模具有一致性。 多渠道团队应使用带有内置损耗溢价的相应 --profile。

反模式

完整分类及来源请参阅 references/capacity_anti_patterns.md。前八位为：

1. 按 100% 利用率规划 (Reinertsen 原则 12)
2. 将上手时间视为瞬时完成 (Larson)
3. 在 12 个月计划中忽略流失率 (Bersin)
4. 仅招聘 IC 而无经理触发机制 (Fournier)
5. 仅按 P50 需求测算规模 (Cleveland)
6. 未进行损耗调整 (Cleveland, SRE Workbook)
7. 用单渠道模型处理多渠道工作 (Gartner, Kingman)
8. 针对 P99 事件缺乏激增计划 (Hopp & Spearman, Reinertsen)

区别于

  • c-level-advisor/vpe-advisor 通过 DORA 四项指标、故事点、部署频率和周期时间瓶颈来衡量*工程*吞吐量。它适用于交付代码的工程团队。而本技能适用于处理工单/案例的运维团队。两者的工作单元不同，数学模型不同（Erlang-C vs. DORA），瓶颈点也不同（q
  • c-level-advisor/chro-advisor 负责*战略性*人力规划（1-5 年的能力组合、人才供应、领导力接班）。而本技能负责*运营级*的 0-12 个月需求容量测算。根据 Lawler 的观点：将两者混淆会导致招聘到错误的人才。
  • **project-management/* 跟踪项目的交付吞吐量（Jira 速率、Sprint 容量）。而本技能针对的是稳态队列工作进行测算。
  • 关联技能 process-mapper** 负责*寻找*瓶颈。而本技能负责*围绕*已知瓶颈来配置团队规模。操作顺序：先执行 process-mapper $\rightarrow$ 再执行容量规划。围绕错误的约束条件招聘会导致人力浪费。
  • business-growth/cs-coverage（如果存在）根据 ARR/CSM 比例和客群对客户成功（CS）覆盖率进行测算。而本技能根据队列工作量（工单、案例、升级事件）进行测算。对于既处理关系维护又处理工单队列的 CS 团队，建议两者同时运行。

强制性问题库（Matt Pocock 式的严苛审问法）

纪律：逐一进行，不要跳跃。答案必须书面记录。如果无法回答其中任何一个，那就是你接下来的调研方向。

Q1 —— “你的瓶颈是什么？你是否通过实证确认了它？”

推荐答案：一个被命名且经过测量的流程阶段，并附带显示工作等待时间的队列数据。不能是“感觉”，不能是“升级处理太慢”，而必须是实际测量的队列。

为何是第一个问题：根据 Goldratt 的《目标》（1984），任何系统在同一时间只有一个关键约束。围绕错误的约束进行规模测算会完全浪费人力。如果你不知道瓶颈在哪里，请在本技能之前运行 process-mapper。

经典理论：Eli Goldratt, *The Goal* (1984); Reinertsen, *Principles of Product Development Flow* (2009)。

Q2 —— “你接受什么样的服务权衡（Trade-off）？”

推荐答案：一个书面且明确的选择 —— 快速 vs. 共情，广度 vs. 深度，低成本 vs. 高质量。Frances Frei 明确指出：你无法在四个维度上全部获胜。试图全赢的团队最终将一无所获。

为何重要：平均处理时间 (AHT)、服务水平协议 (SLA) 和损耗率 (Shrinkage) 的输入值是这种权衡在运营上的体现。如果它们不一致（例如：AHT 设置为追求“共情”，但 SLA 设置为追求“速度”），那么该计划在内部逻辑上是不自洽的。

经典理论：Frances Frei & Anne Morriss, *Uncommon Service* (HBR Press, 2012)。

Q3 —— “你的需求 P90 是多少？与 P99 的差距是多少？”

推荐答案：基于过去 90 天数据的两个具体数值，并注明各自的日历背景（例如：“普通周二的 P90 是 480 张工单/日；11 月发布次日的 P99 是 720 张”）。按 P50 配置的团队有一半时间会违反 SLA；按 P99 配置的团队则会过度配置 30-50%。根据 Cleveland 的观点，P90 是正确的运营测算点。

经典理论：Brad Cleveland, *Call Center Management on Fast Forward* (4th ed., 2019); A.K. Erlang, *The Theory of Probabilities and Telephone Conversations* (1909)。

Q4 —— “在计划的利用率下，P90 和 P99 时的 SLA 违约概率 $P(\text{SLA breach})$ 分别是多少？”

推荐答案：两个概率值，基于你的具体人数 $N$、AHT 和 SLA 目标，通过 Erlang-C 公式计算得出（而非猜测）。如果 $P(\text{breach at P90}) > 10\%$，说明你在测算点上的人员不足；如果 $P(\text{breach at P99}) > 50\%$，说明你没有应对激增的计划，下一次峰值事件将引起 CEO 的注意。

经典理论：Erlang (1909); Hopp & Spearman, *Factory Physics* (3rd ed., 2008), VUT equation。

Q5 —— “你是否为人员流失的替换招聘预留了预算？”

“今年预计的人员流失率是多少？”

推荐回答：是的，且需给出具体数字。若年流失率为 30%（Bersin BPO 中位数），一个 20 人的全职团队今年将流失约 6 人。如果你的“净增 5 人”计划实际上是“招聘 11 人”计划，那么招聘量将发生剧烈变化。这就是反模式 #3。

权威参考：Bersin/Deloitte 人才基准 (2015-2023)；Edward Lawler，《战略人力资源规划》(USC CEO, 2008)。

Q6 — “管理幅度在何时会触发经理职位的招聘？候选人是谁？”

推荐回答：一个具体的季度（来自 hiring_sequencer.py）以及至少一名已确定的候选人（内部主管或外部招聘）。当管理幅度超过 7:1（经理与个体贡献者比例）时，一对一沟通质量下降，反馈周期滞后，流失率上升。一旦超过 10:1，你将面临覆盖危机。请在人数达到 10 之前招聘经理，而非之后。

权威参考：Camille Fournier，《管理者的路径》(O'Reilly, 2017) 第 5 章；Andy Grove，《高效管理》(1983)。

Q7 — “针对 P99 峰值日，你的应对计划是什么？”

推荐回答：一份明确且文档化的计划 —— 包括溢出层、BPO 合同容量、值班轮转、高管升级树，或者一份书面的降级协议，规定“在 P99 日，我们将 SLA 延长至 X 分钟并主动通知客户”。如果回答是“到时候再说”，那么 P99 日将演变成一场董事会都能看到的火灾。

权威参考：Hopp & Spearman，《工厂物理学》(2008)；Reinertsen (2009) 关于容量边际纪律的论述。

---

请按顺序逐一审视这七个问题。将答案写下来。你提交的计划之可靠性，取决于你对这七个问题的回答程度。