认知负荷是什么
认知负荷原指人在处理信息时需要占用的心智资源总量，被 Team Topologies 引入组织设计：每个团队能稳定掌握的领域与系统是有限的，超出上限后交付速度、质量与人员留存会同时下滑。管理手段是拆分过重子系统、把公共能力收敛到平台。
负荷来源
| 内在负荷 | 业务域本身的复杂度，例如规则密集、状态机复杂，难以消除 |
|---|---|
| 外生负荷 | 工具、环境、流程带来的额外复杂度，可以治理 |
| 团队边界 | 团队负责的领域与系统数量决定负荷上限 |
| 平台作用 | 把重复的运维与基础设施复杂度收敛到平台侧，降低各团队外生负荷 |
典型使用场景
- 团队长期人手紧张，判断是人数问题还是负责范围过宽
- 规划系统拆分：把没人能整体理解的模块按业务域切开
- 平台建设立项：用外生负荷过高说明必须收敛工具与流程
- 招人决策：用负荷上限判断加人是否能真正提升吞吐
- 组织调整后检查：新边界是否让某团队同时背了过多系统
负荷过高信号
负荷过高信号
团队同时维护十个以上系统或服务
值班告警来自互不相关的技术栈
新人上手周期持续拉长，三个月仍在问基础问题
改动一处需要理解大量历史背景与隐性约定
关键人长期瓶颈，评审与答疑都排队找他
# 出现三条以上时，优先减范围而不是加人力信号与对策
| 信号 | 可能原因 | 对策 |
|---|---|---|
| 系统数量过多 | 边界按历史而非业务域划分 | 按业务域重新划分所有权 |
| 告警互不相关 | 缺少统一可观测平台 | 建设平台能力，收敛告警标准 |
| 上手周期变长 | 文档缺失、隐性约定多 | 补关键设计说明并安排带教 |
| 流程步骤繁多 | 外生负荷未治理 | 梳理并消除重复审批与手工步骤 |
认知负荷是解释性的边界工具：它给出团队负责范围的参考上限，但具体数字要结合业务复杂度与团队经验判断，不宜机械套用。