六个人扩到十个人，季度交付量没变。第一反应是"新人不行"或"老人不配合"，这两个解释都不成立也不解决问题。真正发生的事更朴素：产能不是人数的线性函数，加人改变的是三个乘数里的一个，而另外两个通常会同时变差。
核算产能的目的不是给团队打分，是判断"再招两个人有没有用"、"该先修哪一段"。
1. 产能方程：三个乘数
把产能写成三项相乘，比写成"人力"一个数有用得多。
// 产能的粗算式：三项都是乘数，任一项接近零，总量就接近零
产能 ≈ 有效工时 × 并行度 ÷ (1 + 等待系数)
有效工时 // 一天里真正在推进交付的时间，不含会议、答疑、救火
并行度 // 同时在推进且互不阻塞的独立任务数，有上限
等待系数 // 等待时间 / 有效工时，随协作人数与依赖数上升
| 组成 | 典型量级 | 加人后怎么变 | 谁能让它变好 |
|---|---|---|---|
| 有效工时 | 一天 4–6 小时 | 线性增加 | 减少打断、减少救火 |
| 并行度 | 3–5 条独立流 | 受任务可切分度限制 | 架构解耦、任务拆分 |
| 等待时间 | 常占总日历时间一半以上 | 随人数上升 | 缩短评审链、减少跨团队依赖 |
第三行是要点：多数团队盯着第一行做加法，而交付量被第三行卡住。
2. 等待时间：五个来源
等待不是"摸鱼"，是任务在等人。它不产生交付，也不留在任何人的工时表里，所以最容易被低估。
| 来源 | 典型形态 | 谁在等 | 缩短手段 |
|---|---|---|---|
| 评审 | 提交后等评审人 | 作者、下游 | 限定评审人与时限，拆小改动 |
| 环境 | 等构建、等测试环境、等数据 | 开发者 | 环境自服务，失败可自查 |
| 依赖方 | 等别的团队给接口、给数据 | 整条链 | 契约先行，桩先行 |
| 决策 | 等方案被拍板 | 执行者 | 明确决策人与截止时间 |
| 审批 | 等合规、等预算、等权限 | 全员 | 提前量单独排，别混进技术任务 |
五个来源中，前三个是工程问题，后两个是组织问题。只修工程侧，等待系数降不下来，因为后两个经常是链条里最长的一段。
3. 人月不是产出
投入和产出要用不同单位记：投入是人·天，产出是"完成并验证的交付单元"。混用会得出"人月越多产出越多"的错觉。
| 记法 | 单位 | 问题 |
|---|---|---|
| 工时统计 | 人·小时 | 只记投入，不记产出，可用于解释忙碌 |
| 故事点/任务数 | 个 | 口径随人变，跨季度不可比 |
| 完成并验证的条目 | 个 | 需要"完成"的定义，但可比 |
| 流动时间 | 天/条 | 反映系统而非个人，最抗争论 |
单位选错会带来一个具体后果：加班能被记录，等待不能被记录。于是所有复盘都在讨论"人不够"，而不是"卡在哪"。
口径还必须跨季度稳定。改一次定义（比如把"完成"从合并改成上线），历史曲线立刻断掉，而断掉的曲线通常被解释成"产能提升了"。定义写进配置文件、带版本，比写在文档里靠人记可靠。
4. 并行度的三个前提
想提高并行度，需要同时满足三个条件，缺一个就会出现"人多活少"。
| 前提 | 不满足时的表现 | 破坏它的常见做法 |
|---|---|---|
| 任务可切分 | 十个人做三件事，七个人围观 | 按人事分配，不按接口分 |
| 依赖可解耦 | 谁的改动都要等别人合 | 全局共享分支、共享配置 |
| 评审能力跟得上 | 提交排队，评审人成瓶颈 | 只有两三个人有合并权 |
第三条常被漏算：加人后提交量上升，评审队列变长，等待时间上升，净产出可能为零。并行度的上限由最窄的那道门决定，不由人数决定。
5. 加人的三项成本
新增一人不是一个"+"，而是三项同时发生。
| 成本 | 形态 | 持续期 | 由谁承担 |
|---|---|---|---|
| 培训期 | 新人产出低于自身成本 | 一到三个月 | 团队整体 |
| 沟通成本 | 协作路径随人数平方增长 | 永久 | 全员 |
| 分心 | 老人答疑、带看代码 | 前两个月最重 | 现有成员 |
沟通路径的增长可以算出来，这也是布鲁克斯定律的工程版本：
// 沟通路径数：n 个人两两之间都可能有依赖
n = 6 → 6×5/2 = 15 条
n = 10 → 10×9/2 = 45 条 // 人数 +67%，路径 +200%
路径数不等于实际沟通量，但它是上限，也是"加人变慢"最直接的解释：你增加了 67% 的产能，同时把需要协调的关系翻了三倍。
把它写成收支表，招人这件事就有了判据，而不是靠感觉：
// 新增加一人的粗略收支：右侧为负项，按项目实测替换占位值
+ 有效工时 +1.0 人 × [0.2, 0.6] 系数 // 培训期系数，按个月抬升
- 沟通成本 +2(n-1) 条路径 / 总路径数 // 人越多，单位路径成本越高
- 现有成员分心 -[0.1, 0.3] 人 // 前两个月最重
= 净收益 大于零才招，否则先修瓶颈
左侧系数是区间而不是点值，因为同一团队在不同阶段差别很大：新人第一个月通常是净负，第三个月才转正。用点值讨论会得出精确但错误的结论。
6. 瓶颈只有一个
任何时刻，限制交付的环节只有一个（其余都是被它拖着的）。优化非瓶颈，产出不变，只是把库存堆在瓶颈前面。
| 做法 | 瓶颈在评审 | 瓶颈在依赖方 | 瓶颈在决策 |
|---|---|---|---|
| 加开发 | 提交更多，队列更长 | 更早开始等 | 更多方案等拍板 |
| 加测试 | 无用 | 无用 | 无用 |
| 缩短评审链 | 有效 | 无效 | 无效 |
| 契约先行 | 无效 | 有效 | 部分有效 |
识别瓶颈的办法不是问人，而是看队列：队列最长的那一段就是瓶颈，而不是最忙的那一段。
// 从工单/PR 时间戳粗算各段等待，找出最长段而非常最忙段
$ jq -r '.[] | [.stage, (.wait_hours)] | @tsv' events.json \
| awk '{s[$1]+=$2; c[$1]++} END{for(k in s) printf "%s\t%.1fh\t%d条\n", k, s[k]/c[k], c[k]}'
7. 在制品过多会掩盖瓶颈
"看起来很忙"与产能在多数情况下无关。忙的成因通常是在制品（WIP）过多：每个人手上三件事，每件都推进一点。
| WIP 状态 | 表现 | 对瓶颈的影响 |
|---|---|---|
| 每人 1–2 件 | 偶有空闲，流转快 | 瓶颈暴露，可观测 |
| 每人 3–4 件 | 人人有活干 | 瓶颈被排队掩盖，周期变长 |
| 每人 5 件以上 | 到处在切换 | 瓶颈不可见，交付抖动大 |
这也是"加人没变快"的另一种解释：新人加入时任务没减少，WIP 直接翻倍，于是等待时间上升，把新增工时的收益吃掉。
8. 产能与质量：赶工是延后付款
压产能最直接的手段是压缩验证环节。它当期有效，代价以缺陷形式在后期返还，返还时的单价更高——修复成本随发现时间上升，这一点在 quality-gate-economics.md 里有单独的账。
| 压缩项 | 当期收益 | 延迟返还 |
|---|---|---|
| 免评审 | 交付快一两天 | 缺陷与不一致在集成期出现 |
| 免回归 | 周期短 | 线上问题与回滚 |
| 需求不澄清就开工 | 看起来启动快 | 返工，且返工不进原估算 |
核算产能时若不同时看缺陷与返工，得到的数字会被系统性高估。反过来也成立：一个季度交付多、返工少，才能算产能真的提高；交付多但线上事故翻倍，那只是把工作推到了下个季度。
9. 度量：测系统，不测人
工时统计测的是投入，且会立刻被游戏化（填满八小时）。应测的是流动。
| 指标 | 定义 | 判据 | 反噬 |
|---|---|---|---|
| 流动时间 | 从开始到完成的中位数 | 下降即系统变好 | 靠切小任务美化 |
| 在制品数 | 同时在推进的条目 | 有上限即可 | 上限外条目被藏起来 |
| 瓶颈段利用率 | 瓶颈段忙碌占比 | 接近满负荷才正常 | 逼非瓶颈也满负荷 |
| 等待占比 | 等待 / 总日历时间 | 高于一半说明协作贵 | 靠改口径下降 |
这套指标的边界要写清：它们描述的是团队这个系统，不是个人绩效。一旦用于个人考核，数据会在两周内失真。
// metrics.yaml：口径写成配置，避免每季度换一次定义
flow:
start_event: pr_opened
done_event: deployed_to_prod
percentile: [50, 85]
wip:
limit_per_person: 2
measure: in_progress_at_day_end
bottleneck:
detect: longest_queue // 看最长队列，不看最忙的人
review_window_hours: 24
10. 症状对照
| 症状 | 更可能的根因 | 先动哪 |
|---|---|---|
| 加两人交付不变 | 瓶颈在评审或依赖方 | 缩短评审窗，先不招人 |
| 人人加班但流转慢 | WIP 过多 | 限在制品，砍并行任务 |
| 交付量波动极大 | 频繁切换与救火 | 保护有效工时 |
| 新人三个月仍不独立 | 任务不可切分 | 拆接口，给独立小任务 |
| 评审排队越来越长 | 合并权集中 | 扩评审人，缩小改动粒度 |
11. 边界的边界
| 场景 | 为何精细核算不划算 | 该做什么 |
|---|---|---|
| 团队小于五人 | 沟通路径少，瓶颈随人流动 | 每周看一眼队列就够 |
| 任务完全独立 | 并行度已接近人数 | 不必管等待系数 |
| 周期极短的一次性项目 | 校准成本高于预测收益 | 给时间盒，不做产能模型 |
| 组织处于强约束期 | 产能不由团队决定 | 只核算自己能改的那一项 |
还有一条：产能核算的成本本身要计入。每次为算清楚而开的会、填的表，如果超过它能带来的调整收益，结论就是"别算了，去看最长队列"。
12. 自测
- 产能方程的三个乘数里，加人直接影响哪一个，通常恶化哪一个？
- 五个等待来源中，哪些是纯组织问题，为什么修工程侧降不下来？
- 六人扩到十人，沟通路径增加多少？这解释了什么？
- 怎么判断瓶颈在哪？为什么不能问"谁最忙"？
- WIP 过多如何掩盖瓶颈，加新人时它为什么会翻倍？
- 流动时间指标一旦用于个人考核，会发生什么？