name: cognitive-load-assessment description: 测量和管理团队认知负荷 allowed-tools: Read, Glob, Grep, Write, Edit
认知负荷评估技能
何时使用此技能
使用此技能当：
- 认知负荷评估任务 - 处理测量和管理团队认知负荷
- 规划或设计 - 需要认知负荷评估方法的指导
- 最佳实践 - 希望遵循已建立的模式和标准
概述
测量和管理团队认知负荷，以优化生产力和可持续性。
强制：文档优先方法
在评估认知负荷之前：
- 调用
docs-management技能 获取认知负荷模式 - 通过 MCP 服务器验证概念（困惑度）
- 基于认知负荷理论和 Team Topologies 提供指导
团队认知负荷理论
三种类型的认知负荷：
┌─────────────────────────────────────────────────────────────┐
│ 总认知负荷 │
├─────────────────────────────────────────────────────────────┤
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ 内在负荷 │ │ 外在负荷 │ │ 相关负荷 │ │
│ │ （领域） │ │ （意外复杂性）│ │ （学习） │ │
│ │ │ │ │ │ │ │
│ │ • 业务复杂性 │ │ • 不良工具 │ │ • 新技能 │ │
│ │ • 领域知识 │ │ • 技术债务 │ │ • 成长 │ │
│ │ │ │ • 手动流程 │ │ • 创新 │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
│ │
│ 目标：减少外在负荷，管理内在负荷，允许相关负荷 │
└─────────────────────────────────────────────────────────────┘
内在认知负荷
内在负荷：领域的固有复杂性
来源：
• 业务领域复杂性
• 所需领域知识
• 问题空间难度
• 集成复杂性
• 合规要求
管理策略：
• 清晰的边界上下文
• 领域驱动设计
• 合适团队对应合适领域
• 需要专家
• 文档和培训
评估问题：
□ 业务领域有多复杂？
□ 需要多少领域知识？
□ 团队必须理解多少系统？
□ 需要协调多少利益相关者？
□ 合规要求有多复杂？
外在认知负荷
外在负荷：不必要的复杂性（浪费）
来源：
• 差劲的工具和流程
• 技术债务
• 不清晰的需求
• 手动部署
• 遗留系统
• 差劲的文档
• 会议过多
管理策略：
• 投资于开发者体验
• 减少技术债务
• 自动化重复任务
• 清晰的沟通
• 自助服务平台
• 减少交接
评估问题：
□ 在非价值工作上花多少时间？
□ 部署有多痛苦？
□ 上下文切换有多少？
□ 有多少手动流程？
□ 等待他人多久？
相关认知负荷
相关负荷：生产性学习和成长
来源：
• 学习新技术
• 技能发展
• 创新工作
• 流程改进
• 掌握领域
管理策略：
• 受保护的学习时间
• 参加会议
• 黑客松
• 导师项目
• 拓展任务
评估问题：
□ 有多少时间用于学习？
□ 有多少创新工作？
□ 人们的技能在成长吗？
□ 知识在共享吗？
□ 有实验时间吗？
认知负荷评估
评估框架
团队认知负荷公式：
总负荷 = 内在负荷 + 外在负荷 + 相关负荷
健康：总负荷 < 容量
压力：总负荷 ≈ 容量
过载：总负荷 > 容量
容量因素：
• 团队规模
• 经验水平
• 工具质量
• 流程成熟度
• 支持可用性
评估问卷
每个项目评分 1-5（1=低负荷，5=高负荷）：
内在负荷（领域复杂性）
□ ___ 业务领域复杂性
□ ___ 拥有的系统数量
□ ___ 集成复杂性
□ ___ 利益相关者协调
□ ___ 合规要求
内在分数：___/25
外在负荷（不必要复杂性）
□ ___ 工具和基础设施摩擦
□ ___ 手动流程和部署
□ ___ 技术债务负担
□ ___ 依赖等待时间
□ ___ 上下文切换频率
外在分数：___/25
相关负荷（学习与成长）
□ ___ 新技术采用率
□ ___ 流程变更频率
□ ___ 技能发展需求
□ ___ 创新期望
□ ___ 文档/培训工作
相关分数：___/25
总认知负荷：___/75
解释：
< 30：低负荷（容量充足）
30-45：中等负荷（可持续）
45-60：高负荷（有风险）
> 60：过载（不可持续）
领域复杂性评估
领域复杂性矩阵
| 因素 | 低（1） | 中（3） | 高（5） |
|---|---|---|---|
| 实体 | <10 | 10-50 | >50 |
| 规则 | 简单 | 中等 | 复杂 |
| 集成 | 0-2 | 3-5 | >5 |
| 利益相关者 | 1-2 | 3-5 | >5 |
| 法规 | 无 | 一些 | 繁重 |
团队-领域匹配
领域规模评估：
小领域（团队可完全拥有）：
• 有限的边界上下文
• 清晰边界
• 可管理复杂性
• 5-9 人团队合适
中领域（接近团队极限）：
• 多个子领域
• 一些复杂性
• 一些依赖
• 可能需要拆分
大领域（团队过载）：
• 多个边界上下文
• 高复杂性
• 许多依赖
• 必须拆分为多个团队
认知负荷减少策略
减少外在负荷
平台策略：
• 自助服务基础设施
• 常见任务的黄金路径
• 自动化测试和部署
• 集中化可观察性
• 清晰文档
流程策略：
• 减少会议
• 异步沟通
• 清晰所有权
• 减少交接
• 消除批准瓶颈
工具策略：
• 投资开发者体验
• IDE 集成
• 本地开发对等
• 快速反馈循环
• 减少上下文切换
管理内在负荷
团队设计策略：
• 合适大小的边界上下文
• 将团队对齐到领域
• 复杂子系统的专家
• 清晰的团队 API
• 减少依赖
知识策略：
• 领域文档
• 入职程序
• 结对编程
• 知识共享
• 交叉培训
保护相关负荷
学习策略：
• 20% 时间用于学习
• 会议预算
• 培训项目
• 创新冲刺
• 导师关系
成长策略：
• 拓展任务
• 轮岗项目
• 领导力发展
• 技术职业轨道
• 社区参与
评估模板
# 认知负荷评估：[团队名称]
## 团队概况
- **规模：** [N 人]
- **成立时间：** [月/年]
- **领域：** [描述]
- **当前负荷：** [高/中/低]
## 内在负荷分析
### 领域复杂性
[领域复杂性描述]
### 分数：[X/25]
| 因素 | 分数 | 备注 |
|--------|-------|-------|
| 业务复杂性 | [1-5] | [详情] |
| 拥有的系统 | [1-5] | [详情] |
| 集成复杂性 | [1-5] | [详情] |
| 利益相关者协调 | [1-5] | [详情] |
| 合规要求 | [1-5] | [详情] |
## 外在负荷分析
### 痛点
[不必要复杂性描述]
### 分数：[X/25]
| 因素 | 分数 | 备注 |
|--------|-------|-------|
| 工具摩擦 | [1-5] | [详情] |
| 手动流程 | [1-5] | [详情] |
| 技术债务 | [1-5] | [详情] |
| 等待/阻塞 | [1-5] | [详情] |
| 上下文切换 | [1-5] | [详情] |
## 相关负荷分析
### 学习能力
[学习需求描述]
### 分数：[X/25]
| 因素 | 分数 | 备注 |
|--------|-------|-------|
| 新技术 | [1-5] | [详情] |
| 流程变更 | [1-5] | [详情] |
| 技能发展 | [1-5] | [详情] |
| 创新工作 | [1-5] | [详情] |
| 文档工作 | [1-5] | [详情] |
## 总体评估
| 负荷类型 | 分数 | 状态 |
|-----------|-------|--------|
| 内在 | [X/25] | [良好/警告/关键] |
| 外在 | [X/25] | [良好/警告/关键] |
| 相关 | [X/25] | [良好/警告/关键] |
| **总计** | **[X/75]** | **[总体状态]** |
## 推荐
### 立即行动（减少外在）
1. [行动]
2. [行动]
### 短期（管理内在）
1. [行动]
2. [行动]
### 长期（保护相关）
1. [行动]
2. [行动]
## 重新评估计划
- 下次审查：[日期]
- 跟踪指标：[列表]
工作流程
评估认知负荷时：
- 收集团队输入：调查或访谈团队成员
- 评分每种类型：评估内在、外在、相关负荷
- 识别热点：负荷最高的地方
- 分析原因：为什么负荷高
- 优先减少：首先关注外在负荷
- 计划行动：具体改进措施
- 跟踪进展：定期重新评估
参考文献
详细指导：
最后更新： 2025-12-26