技能介绍

它解决什么问题

团队编制在 15 到 35 人之间，需求按 P50/P90/P99 波动，管理层却只给了一个“峰值要稳得住”的模糊目标。日常利用率已经 88%，SLA 开始下滑；招聘预算批了，你却不知道该不该在 Q1 一次放量，现有团队会不会被迅速稀释。这类决策在传统做法里靠经验、靠开会拍板，最后写进 PowerPoint——这是运营产能规划里最贵的反模式。

这个技能把决策拉回算术层：用排队论和运营领导力理论，回答四个工程问题：

给定 P50/P90/P99 需求，各利用率水位下的 SLA 违约概率是多少？
当前团队的真实利用率健康度如何，谁在危险区？
未来 12 个月，招聘、离职、QoQ 需求增长如何影响产能？
经理编制在哪个季度需要触发？

核心能力与工作流

三个 Python 脚本组成，仅依赖标准库，不调用 LLM：

capacity_modeler.py：基于 Erlang-C，结合 AHT、SLA 目标、当前 FTE、shrinkage 与 --profile（support / cx / bizops / finance-ops / it-ops），输出 70/80/90% 利用率下的违约概率与风险区间（SAFE / WATCH / AT_RISK / CRITICAL）。
utilization_analyzer.py：按成员生成红黄绿灯健康度，并给出团队级判定（HEALTHY / SQUEEZED / OVERLOADED / UNBALANCED）。持续高于 85% 利用率的成员是吞吐崩溃风险；团队内均值差超过 30 个百分点，先纠偏再招聘。
hiring_sequencer.py：按 12 个月排期，内置 ramp curves、attrition、季度需求增长与最大招聘约束；管理幅度超过 7 IC/manager 时触发经理招聘，前重后轻（Q1 35% vs Q4 15%）。

运行前必须采集 90 天以上历史需求，计算 P50/P90/P99；如果只有平均值，先回去拉分布。计划落地前，逐条回答 forcing-question 库的七个问题：瓶颈是否实测、服务取舍是否显式、P90 与 P99 差距、违约概率、attrition 替换、管理幅度触发点、P99 天的 surge 预案。

适用边界

只处理排队型工作（tickets / cases / work items），不是项目管理或研发交付节奏。
季度内需求分布需足够平稳；发生 step-change（新产品、并购、监管变化）时，季度中途要重跑。
至少 90 天历史需求数据；不足时先用销售或用户基数预测生成分布。
服务按单队列单类建模；硬优先级分层需拆成独立队列分别建模再汇总。

设计上刻意避开八大反模式：不按 100% 利用率排产、不假设新人立即满产、不把离职率当零、不无限堆 IC、不只按 P50 排产、不忽略 shrinkage、不多渠道套单渠道模型、不为 P99 预留 surge 就开干。瓶颈还没用队列时间数据实测确认前，先跑 process-mapper，再跑本技能。