capacity-planner

capacity-planner

面向处理排队工作的运营团队的规模规划工具——客户支持、客户体验（CX）、客户成功、业务运营、IT 运营、财务运营。基于 Erlang-C 排队论、Little 定律和运营领导力经典著作（Fournier、Larson、Cleveland、Reinertsen）构建。结果确定，仅使用标准库，不调用大模型。

用途

你是一位运营负责人，团队规模从 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，需要判断问题出在规模、流程还是瓶颈。
• 并购 / 新业务线发布建模——为新团队或合并后的组织规划规模。

工作流

1. 收集需求数据。从工作系统（Zendesk、Intercom、JSM、ServiceNow、Salesforce）提取每日工单/案件量的 P50/P90/P99 数据。如果你手头只有平均值，请先停下来，提取完整的分布。只用单点估算需求，是运营工作中代价最高的反模式。
2. 建立吞吐量模型。使用需求量、AHT、SLA 目标、当前 FTE 和人员损耗率运行 capacity_modeler.py。使用 --profile 选择你的职能（support / cx / bizops / finance-ops / it-ops）。查看 80% 利用率对应的行——这是你的规模规划基准。
3. 标记利用率风险。使用团队当前的实际利用率数据运行 utilization_analyzer.py。根据 Reinertsen 的研究，持续超过 85% 的人员有吞吐量崩塌风险。团队成员之间的差异超过 30 个百分点，意味着团队状态为 UNBALANCED——招聘前先解决这个问题。
4. 安排招聘顺序。输入当前 FTE、年底目标人数、爬坡时间、人员流失和需求增长，运行 hiring_sequencer.py。它会将招聘前置（Q1 占 35%，Q4 占 15%）、应用爬坡曲线，并在管理幅度超过每位经理管理 7 名 IC 时触发招聘经理。
5. 逐一阅读强制思考问题库（见下文）。一次回答一个问题。不要跳过。承诺计划前，必须写下答案。

脚本

• scripts/capacity_modeler.py — 使用 Erlang-C 进行规模规划，并调整人员损耗，计算 P50/P90/P99 违约概率。使用 --profile 获取行业默认值。
• scripts/utilization_analyzer.py — 提供个人层面的红黄绿灯状态，以及带差异检测的团队健康结论。
• scripts/hiring_sequencer.py — 制定 12 个月季度计划，纳入爬坡、人员流失、需求增长、每季度最多招聘人数限制和经理招聘触发逻辑。

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

快速示例

# Emits an Erlang-C capacity model (required headcount + P50/P90/P99 breach probabilities) for the built-in example
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。如果没有，请先根据销售额／用户群预测生成分布。
• 一个队列中的服务属于单一类别。如果有严格的优先级层级（P1/P2/P3，且各类别有不同的 SLA），请将每个层级建模为单独的队列，然后求和。
• 渠道的建模方式协调一致。 多渠道团队应使用适当的 --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 4 项指标、故事点、部署频率和周期时间瓶颈衡量工程吞吐量。它适用于交付代码的工程团队。此技能适用于处理工单／案例的运营团队。两者的工作单位不同，计算方法不同（Erlang-C 与 DORA），瓶颈也不同（忽略排队情况的人员配置，与 WIP + 前置时间）。
• c-level-advisor/chro-advisor 进行战略性劳动力规划（1–5 年的能力组合、人才供应、领导层继任）。此技能则根据需求进行运营性的 0–12 个月产能规划。根据 Lawler 的说法，混淆两者会让你接受一份不合适的工作。
• project-management/* 跟踪项目的交付吞吐量（Jira 速度、冲刺产能）。此技能则围绕稳态排队工作确定规模。
• 同级技能 process-mapper 用于找出瓶颈。此技能用于围绕已知瓶颈确定团队规模。操作顺序：先运行 process-mapper，再运行 capacity-planner。围绕错误的约束招聘会浪费招聘名额。
• business-growth/cs-coverage（如果存在）按 ARR/CSM 比率和细分群体确定客户成功覆盖规模。此技能按排队工作量（工单、案例、升级事项）确定规模。对于同时处理客户关系工作和工单队列的 CS 团队，请同时运行两者。

追问问题库（Matt Pocock 式盘问纪律）

纪律：一次只讨论一个问题。不要提前跳到后面的问题。必须写下答案。如果无法回答某个问题，那就是接下来需要调查的事项。

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

推荐答案：工作流中一个有明确名称、经过测量的阶段，并有队列时间数据表明工作在哪些地方等待。不能凭感觉，也不能只说“升级处理太慢”。必须是实际测量得到的队列。

为什么这是第一个问题：Goldratt（《The Goal》，1984）指出，每个系统在同一时刻恰好有一个制约约束。围绕错误的约束确定规模会完全浪费招聘名额。如果你不知道瓶颈在哪里，请先运行 process-mapper，再使用此技能。

经典著作：Eli Goldratt，《The Goal》（1984）；Reinertsen，《Principles of Product Development Flow》（2009）。

Q2 — “你接受了什么样的服务取舍？”

建议回答：明确写下你的选择——快速还是体贴，广泛还是深入，低成本还是高品质。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》（第 4 版，2019）；A.K. Erlang，《The Theory of Probabilities and Telephone Conversations》（1909）。

Q4 — “按计划的利用率计算，在 P90 和 P99 情况下，P（违反 SLA）分别是多少？”

建议回答：给出两个概率，并使用你具体的 N、AHT 和 SLA 目标通过 Erlang-C 计算得出，而不是猜测。如果 P（P90 时违反 SLA）> 10%，说明在配置基准点上人手不足。如果 P（P99 时违反 SLA）> 50%，说明你没有应对激增的计划，下一个高峰事件就会引起 CEO 的关注。

依据：Erlang（1909）；Hopp 和 Spearman，《Factory Physics》（第 3 版，2008），VUT 方程。

Q5 — “你是否为今年预计会出现的人员流失编列了替补招聘预算？”

建议回答：是，并给出具体人数。按年度人员流失率 30%（Bersin BPO 中位数）计算，一支 20 FTE 的团队今年会流失约 6 人。如果你的“净增 5 人”计划实际上意味着“招聘 11 人”，招聘规模就会大幅变化。反模式 #3。

依据：Bersin/Deloitte 人才基准数据（2015-2023）；Edward Lawler，《Strategic Workforce Planning》（USC CEO，2008）。

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

建议回答：给出具体季度（依据 hiring_sequencer.py），并至少确定一名候选人（内部主管或外部招聘人选）。每位经理管理超过 7 名 IC 后，一对一沟通会变差，反馈周期会延误，人员流失会增加。超过 10 人，就会出现覆盖危机。要在超过 10 人之前招聘经理，而不是事后补救。

依据：Camille Fournier，《The Manager's Path》（O'Reilly，2017），第 5 章；Andy Grove，《High Output Management》（1983）。

Q7 — “针对 P99 当天，你有什么激增应对计划？”

建议回答：给出明确且有记录的计划——溢出处理层级、BPO 合同约定的产能、值班轮值、管理层升级汇报链，或者一份书面的服务降级约定，明确说明“在 P99 日，我们会将 SLA 延长至 X 分钟，并主动通知客户”。如果回答是“到时候再想办法”，那么 P99 日就会成为董事会关注的重大突发事件。

依据：Hopp 和 Spearman，《Factory Physics》（2008）；Reinertsen（2009）关于产能余量管理的论述。

---

按顺序逐一讨论这七个问题。一次讨论一个。把答案写下来。你提交的计划，是否站得住脚，取决于你对这七个问题的回答。