认知负荷和瓶颈

谈到认知负荷，我们可以简单地将其理解为任何一个人在给定的时间内大脑中所能保存的信息量是有上限的。对于任何一个团队来说，简单地将所有团队成员的认知能力累加起来即可。

然而，当给一个团队分配职责或者软件组件的时候，我们几乎不会考虑认知负荷。可能是因为可用容量和认知负荷会达到的水平都难以量化，或者可能是因为期望团队能够不假思索地完成被交代的任务。

如果不考虑认知负荷，团队就会做大量并行工作，尝试覆盖过多的职责和领域。这让团队开始疲于奔命，精力在不断的任务切换中消耗殆尽。

低代码平台供应商OutSystems的资深开发工程师Miguel Antunes介绍过一个非常有挑战性的例子。OutSystems的工程生产力团队已经成立五年了。这个团队的使命是帮助产品团队有效地执行构建任务、维护基础设施、提高自动化测试执行率。随着团队规模不断扩大，他们又承担了额外的职责，包括持续集成（CI）、持续交付（CD）和基础设施自动化。

伴随他们的成功，问题也开始显现。比如，由八名成员构成的小组在迭代计划时，需要面对他们职责范围内的大量需求。不仅难以给出需求优先级，一个迭代周期内任务的频繁切换也极大地打击了团队的主动性。如果考虑到Dan Pink的内在动机三要素，这就一点儿也不奇怪了：自治（被多个团队源源不断的请求和优先级所淹没）、精通（样样都懂却无一精通）、目标（过多的职责领域）。

虽然在这个行业案例中，团队面向内部开发团队提供服务，但是对那些为外部用户提供软件的团队来说，效果是一样的。产品团队负责的服务和组件数量（换句话说，团队的需求）通常会随着时间不断增长。然而，新服务的开发通常是按照团队能够全职投入来规划的，并不是根据团队的认知负荷来规划的。这些被忽视的部分恰恰是有问题的，因为团队依然要修复和改进已有的服务。最终，团队成了交付的瓶颈，而他们的认知负荷也大幅超标，从而导致了延迟、质量问题，并且这也持续地伤害了团队的工作意愿。

我们需要把团队摆在第一位，鼓励去限制他们的认知负荷。将认知负荷明确作为团队规模、分配职责和建立团队边界的有力工具。（我们将在第3章详细讨论这一内容。）

总而言之，团队拓扑方法提倡组织设计要优化运行系统的变更和反馈流程。这需要限制团队的认知负荷，明确设计团队之间的交互模式，以帮助生成我们所需的软件系统架构（基于康威定律）。