高效能团队模式

豆瓣读书：https://book.douban.com/subject/35528423/

很薄的一本书，还不到 200 页吧，买回来一看居然还是彩图的。
本书看起来像是《设计模式》在团队管理上的一种推广，
实际读下来，感觉它是对 “康威定律” 夹带实战经验的一些总结。

康威定律指的是：系统架构与组织架构是同态的。
设计系统的组织由于受到约束，这些设计往往是组织内部沟通结构的副本。
即，组织架构（沟通结构） 决定了 系统架构。

在康威定律之上，作者提到了好多扩展点：

• 逆康威定律：系统架构 -> 组织架构（沟通结构）
  • 即我们想得到什么样的系统架构，就怎么设计团队的组织架构
• 认知负荷：团队内部的价值流转速度，受限于成员的认知负荷，每个人都疲于奔命的话，交付效率会大打折
• 团队 API：以团队作为最小作战单位来考虑事情，团队之间的交互方式也非常值得考量
  • 通过设计团队边界，把高频沟通放到团队内部，中频沟通放到合作团队之间，不相关的团队应该尽量不沟通

有了这些扩展点之后，作者提到了自己解决问题的思路。

• 人为重组团队边界，通过组织架构来影响系统架构
• 最小化沟通成本，以降低每个人的认知负荷
• 限制团队规模，以加强团队内部成员之间的信任度

然后作者提出了模式（套路） —— “团队拓扑” 来支撑自己的方案，让方案看起来更 “普适”、更 “高大上”。
四类基本团队拓扑：

• 流动式团队
• 赋能团队
• 复杂子系统团队
• 平台团队

我重点看了一下 “平台团队” 相关的注意事项，感觉与作者还是有很多共鸣的。

• 平台团队，是为了提供服务的，用户是开发者，所以目标应是为了所服务的目标团队更高效的工作。
• 最小可用的平台，远比面面俱到的解决方案要更好
• 做平台也要应用产品思维，应用软件产品管理，否则特性会爆炸，或在用户短期需求池中乱撞
• 平台应以降低开发者用户的认知负荷为己任
• 为了吸引用户，降低使用成本，平台团队更应该关注用户体验
• 用户操作手册应该聚焦于具体问题的解决办法，而不是罗列平台的功能细节
• 平台底下可能还依赖了其他平台，平台团队抹平这个细节，但是要告知用户全景图
• 平台应按生产级别的系统来对待，可用性、故障响应、轮值表、问题反馈渠道，非常重要

后面关于团队的 “交互模式” 部分就略读了。不同 “团队拓扑” 的团队，其交互模式默认也是不同的。

整本书的结构，康威定律 以及 它的扩展点，这些思想很重要，但是作者提到的 “模式” 我却不全认同。
作者也提到了，一个真实的团队，其实并不从属于其中任何一个模式，
采用 “团队拓扑” 来介绍，只是让我们在设计团队时，有素材可以参考。

所以综上所述，本书可以看做是 “康威定律” 的 “集大成者”。
根据 “康威定律” 推导出了一系列 “团队设计模式”。

但实际用起来如何，还真不好说，大家都知道降低 “沟通成本” “降低认知负荷”，提升 “价值交付速率”，
本书更多的还是在论证这些想法是对的，可以像看 “网络爽文” 一样看。

文风如下：“好的团队 怎么怎么样” “优秀的团队 怎么怎么样” ……
但很多真实的团队，其实达不到这些 “好” “优秀” 团队的标准。
有很多团队甚至还没到 “需要重组” 的层次，因为与其说是 “沟通过于频繁”，不如说是 “缺少沟通”。

这也许是 国内国外 软件开发领域不同的状况导致的吧，我们还有很长的路要走。
不过，软件开发逐渐成为了一种 “社会学” 现象，看起来已经板上钉钉了，作者就差说一下这句断言了。

对康威定律不太熟的朋友，值得读一下前几章。
后面几章我觉得略读一下就行了，毕竟只是作者的一家之言，挑有用的部分拿来就行了。