运营团队科学排班

问题背景：当运营团队不再靠感觉排班

在许多支持、CX、BizOps、IT 运维和财务运营团队里，排班更多是一门手艺而非科学：旺季来了，工单堆积，SLA 开始飘红；老板批了预算，却不清楚这 35 个人到底能不能撑住明年 P90 的需求；团队利用率长期趴在 88%，看上去很忙，但没人能说清离崩溃还有多远。当你依赖单点估计、把平均工单量当基准、或者忽略新员工的爬坡曲线，最终往往招了人、花了钱，却依然在峰值日被 CEO 看到事故。容量规划技能的目标，就是用排队论的算术替代「凭感觉」。

工作方式：从需求分布到季度招聘计划

这套工具只依赖 Python 标准库，无需联网或调用大模型。它围绕队列型工作（工单、Case、待办项）展开，核心产出三份文档：

• 容量测算表：以 Erlang-C 和 Little 定律为基础，在 70%/80%/90% 利用率下分别计算 P50/P90/P99 需求的 SLA 违约概率，并给出 SAFE、WATCH、AT_RISK、CRITICAL 四档风险标签。80% 利用率行就是排班基准点。
• 利用率健康诊断：逐人红绿灯视图 + 团队级判定（HEALTHY / SQUEEZED / OVERLOADED / UNBALANCED）。当个人持续 >85% 或团队内方差超过 30 个百分点时，系统会明确警告你：这是吞吐崩溃的先兆，先做平衡再考虑扩招。
• 12 个月招聘节奏表：输入当前 FTE、目标年末人数、爬坡周期、年流失率、季度需求增速和管理幅度上限，脚本会输出四个季度各招多少人，并在 IC 数突破 7 时自动触发管理层招聘建议（提前预留，而不是等到跨过 10 才补救）。

具体操作分五步：

1. 拉取真实需求分布。从 Zendesk、Intercom、JSM、ServiceNow 或 Salesforce 导出 90 天的日工单量，算出 P50、P90、P99。如果只有平均值，请立刻停下——这是运营排班里最昂贵的反模式。
2. 运行容量模型。调用 capacity_modeler.py，指定 --profile（support / cx / bizops / finance-ops / it-ops）自动匹配该职能的典型收缩率与服务时长。优先看 80% 利用率那一行。
3. 检查现有利用率。调用 utilization_analyzer.py 分析团队实际工时利用数据。如果发现 UNBALANCED，先去修复负载分配，再谈招人。
4. 编排招聘节奏。调用 hiring_sequencer.py，它会把新人爬坡、月均流失、季度增速都算进去，并确保每个季度的招聘量不超过可执行上限。
5. 逐一回答强制问题。七个问题（瓶颈确认、服务取舍、P90/P99 差距、违约概率、流失预算、管理触发、P99 预案）必须逐个作答并书面记录。跳过任何一题，你的计划在向 CFO 或投资人展示时都会站不住脚。

边界与注意

它只适用于队列型工作：工单、案例、等待处理的项。如果你的团队按项目交付、没有持续的排队输入，这个工具不适合你。其次，季度内需求应近似平稳；若遇到新产品发布、并购或法规突变，必须季中重算。另外，硬性优先级分层（如 P1/P2/P3 各有 SLA）需要把每一类队列单独建模再求和。最后，这套算术无法替代流程改进——如果瓶颈未确认、或团队正被严重 UNBALANCED，先做瓶颈识别和负载均衡，再谈扩编。

注意避免八大反模式：计划到 100% 利用率、把新人当成即插即用、12 个月计划里忽略流失、永远招 IC 不设管理触发、只按 P50 排班、不扣收缩率、用单渠道模型套多渠道、对 P99 日没有应急预案。这些问题在 references/capacity_anti_patterns.md 中有完整梳理。