交付吞吐
统计单位时间内完成验收的场景数，并区分新建与维护两类。吞吐上升而返工不升，说明配置匹配；只升吞吐不降返工，多半是验收环节放了水。这个指标要按月看，单月波动没有参考价值。
接管负担
记录每人每周的接管次数与时长，按渠道与问题类型分组。接管持续偏高说明模型能力或知识供给不足，问题不在人数；此时加人只会把同样的低效按比例放大，根因仍然留在知识库和流程里。
返工归因
按场景统计返工轮次与原因，区分需求变化、标准不清与技术缺陷三类。需求变化占比高，问题在业务负责人；标准不清占比高，问题在验收设计。归因清楚之后，调整动作才不至于变成一律加人。
能力留存与负荷
看关键人休假或离职后场景能否维持，逐个场景标注依赖程度与替补。连续两周超时或积压上升，是配置失衡的早期信号。负荷指标通常比产出指标更早出现，适合作为季度调整的触发条件。
适用与不适用
适合谁
- 团队运行半年以上、需要评估配置的企业
- 正在决定是否扩编的部门负责人
- 需要向管理层说明团队价值的组长
不适合谁
- 团队刚成立、尚无稳定交付节奏的组织
- 只关心单个项目成败、不看长期能力的项目组
典型场景
某企业的 AI 小组半年交付七个场景，管理层准备扩编。复盘发现返工集中在两个场景，原因是验收标准写得含糊，而接管负担并不高。最终没有扩编，改为给这两个场景补业务负责人与标准，下一季度返工明显下降，扩编需求也自然消失。
可执行步骤
- 建一张场景台账，逐条记录交付时间、返工轮次与接管次数，按周更新。
- 按月统计五类信号，把异常项单独标出并注明异常幅度与发生时间。
- 对异常项做原因归类，区分人的问题、流程问题与工具问题三类根源。
- 按归因结果选择调整动作，优先改流程，其次调角色，最后加人的顺序。
- 季度末回看调整是否奏效，把无效动作记录在案避免重复，以免重犯。
常见坑
- 只统计交付数量，不看返工与接管，团队看起来高产而业务体感很差，扩编申请也会被质疑。
- 把接管量高直接归因为人手不足，扩编后负担分摊但根因仍在，三个月后接管量重新回到原点。
- 能力留存从未评估，关键人一走场景全线停摆，临时补救的成本远高于平时做替补安排与文档交接。
自检与验收清单
- 是否有场景台账，逐条记录交付、返工与接管
- 返工是否按需求变化、标准不清与技术缺陷三类归因
- 是否评估过关键人依赖，替补是否真的可用且能接班
- 负荷指标是否设了触发线、复核人与处理顺序
常见问题
多久评一次合适？
月度看负荷与接管，季度看交付与返工。频率过高会增加填报负担，过低则错过调整窗口；团队规模小时可合并为季度一次，但负荷数据仍建议每月更新一次，避免长期积累。
交付多但业务不用，算成功吗？
不算。配置的目标是可持续的可用交付，未被使用的场景应计入失败。评价时应把使用率与接管记录放在一起看，而不是只数上线数量，否则会把无效工作算成业绩。
评价结果要不要公开？
建议在管理层与团队内部公开结论与调整动作，不公开个人排名。公开动作能减少猜测与传言，个人排名会让填报失真，最终连台账数据都不再可信，也就失去了观察价值。