在 上一篇文章 为什么每个程序员都应该了解“康威定律”中，我们说了开发出来的产品是其背后的组织沟通方式的体现。那么我们如果有机会去负责一个产品，我们就要首先考虑如何搭建符合我们产品的团队。

所以本文是接着上一篇文章 为什么每个程序员都应该了解“康威定律”，如果没有看的同学可以一起阅读想用。本文主要是介绍什么样的团队是一个好的团队，以及我们如何来利用团队的力量来打造我们的产品。

背景

一方面，在新业务开展或者团队人数较少时，团队需要更为高效的适应当前的环境，另一方面，随着业务的增加或者组织的发展，团队势必会越长越大，团队之间需要更为有效的沟通和协作方式。同时，如果团队想要在业界或者组织内部占有一席之地，也必须不断加强自身实力和技术深度。这个时候团队成员势必会感到压力陡增，但是有无法描述具体的问题或者寻找合适的解决方法。这是每个团队都会面临的问题。

image

大多数都会从团队人数不足，团队成员能力层次不齐来找原因。但是又有那个团队敢说自己人充足的，又有多少个团队能做到每个都是能力卓越的精英。这些在大部分团队来说都是常态，所以在这个时候这两个原因明显不能解决当前的问题。即使我们去招更多优秀的人，结果也不一定如我们所愿。因为问题很有可能出现在团队的架构和沟通上面。

邓巴系数

根据社会学家 Dunbar 的研究，

团体中可以深入互相信任且 share working memory 得人数基本上大概是 5 个人左右，极限就是是 15 人，而能互相信任的上限大概就是 50 个人，当超过 150 人时就已经高过了社交认知的上限，就连要记住对方的名字都很难。

所以根据 Google 内部长时间的研究，各个 Team 之间得 dynamic （动态互动）对于产出的影响，远远大于有某个大大在某个团队里面。而会影响团队动态互动的因素有哪些呢？

• Team Size 团队大小

• Team Lifespan 团队能固定在一起工作的时间

• Team Relationship 团队成员之间的关系

• Team Cognition 团队的认知

所以好的团队的第一个基础就是 ：小巧竟敢且长存的团队。

这里小的定义大概是 5-9 人，固定的团队成员的意思是为一个目标工作的时间至少一年以上。

为什么要提到至少一年以上呢？因为根据 Tuckman 的理论，一个团队从组成到真正可以产出绩效，至少要经历四个阶段：

1. Forming 组成阶段：英雄来自四面八方，人员陆续补充进来，很少一步到位

2. Storming 磨合风暴阶段：大家要怎么变成利益共同体，需要花时间习惯彼此

3. Norming 形成团队阶段：团队逐渐演化出标准的流程方法与默契

4. Performing 绩效产出

但要知道的是，从 2 ~ 3 其实是会一直持续发生的，因为每次有人离去和新人加入，团队成员的家庭和生理状况变化，以及随着团队成熟度与业务量的变化，都会产生新的化学变化，这也是团队的绩效产出为什么会一直变化。不是可以简单用缺人加人就可以解决的问题。

团队优先思考模式

团队优先思考模式原文是 Team First Mindset,，顾名思义，就是要利用团队的力量，就要建立团队的概念。 进一步说，什么是团队优先思考模式？

• 团队对某个软件（系统）负责，并且持续的关注与改善

• 团队会议要承诺参与并且不要迟到

• 团队对于内部事务要持续讨论

• 专注在 Team Goal

• 帮助他人移除阻碍

• 培训新人，互相帮助成长

• 避免争输赢的争论，要能包容探索各种可能性的言论

image

此外如果要让团队能以高效的模式运作，首先要以小巧精干的长存团队为单位，并且限制与减少不必要的沟通，这边所谓限制不是说让团队互相隔离，而是并不是所有的交流的都是好的和必要的，其实就跟系统开发一样，一开始也许大家都可以互相调用，但是随着系统变大逻辑变复杂，团队与团队之间要建立沟通的规范与 API 接口。

而这个沟通的规范就是我们接下来要讲的：认知负担

最小化认知负担

thoughtworks 等技术咨询团队在很早之前就开始调研并拥护团队拓扑这一理念，而团队拓扑的作者将认知负担分为三个种类：

• Intrinsic Cognitive Load （内在认知负担）：比如说了解 Code 怎么写

• Extraneous Cognitive Load（外在认知负担）：比如说要怎么 deploy

• Germane Cognitive Load（有意义的认知负担）：比如说 Service 之间怎么沟通

那该如何最小化认知负担呢？就是把稀缺的脑力放在有价值的地方，我们可以透过使用好的 IDE 和 tool 或是教育训练，结对编程等方式来有效降低内在认知负担。

透过 SOP 或是专属的 Infra Team / DevOps Team 来帮助建置优化开发部署流程，消灭工程师的外在认知负担。

让工程师更专注在于产生价值的 Germane Cognitive Load（有意义的认知负担），设计更好的系统来解决客户的问题带来价值。

所以当随着业务量变大以及团队成长，但是团队的绩效和产出却开始下滑，并且同仁们开始怨声载道时，这时候可不能简单的认为，应该是人力资源不足加人就好，而是应该是要先从团队的认知负担开始检讨。是不是单一团队承载太多认知负担了？

切分团队

那么如果说上面分析之后的确是团队承担了太多的认知负担，我们就要考虑切分团队。

团队的切分也是一门艺术，传统的思考模式是，某个 domain / project 变大变复杂，那就找多一点人或团队一起加入帮忙，于是到处开始资源盘点和借人。

另一个常见的场景就是，某团队把某个案子或产品做的有声有色，于是就会有更多的工作和事情塞给他们，由于绩效不错又帮公司赚钱，所以工作更多的状态下，老板也会同意让他们补更多的人，但是也就越增加他们的认知负担。

但是现在我们应该认识到：应该要先从把大 domain / project 切分成许多 sub domain / sub project 开始，再考虑这些 sub domain 之间的关系，要分别切分给哪些团队处理。

切分完 domain 和团队完后，也要思考团队间的协作性，某些团队之间可能更需要紧密的合作，某些团队可能只需要维持最小程度的同步。

这不就像是单体化应用切分成微服务的过程一样吗？所以这就回到康威定律：团队的切分与组织的沟通模式会决定你的系统架构。

总结

今天我们聊了如何建立一个好的团队，并引用了一些关于团队建设的理念和知识。一个好的团队对内一定是有效的沟通，这个就需要我们团队的规模不能过大，过大就会造成每个人的认知负担。

其次，我们需要通过使用工具来减轻团队内部成员的外部认知负担和内部认知负担，让团队成员都可以专注于有意义的工作中上。其次要通过培训等各种方式培养团队内部的团队意识，形成团队优先的思考模式。

最后就是维护好每个团队之间的协作，让每个团队都将外部的团队当作自己的客户，不断培养外部客户的习惯来更好的使用团队产出的产品（文档，代码等）。

如果喜欢我的分享，欢迎关注“雨夜随笔”

原文链接：为什么每个程序员都应该了解“康威定律” (qq.com)