团队是执行力的基础

产品的差异来自于执行力的差异，执行力的差异来团队的差异。人口红利的消失，呼唤精细化管理。

软件开发是一个富有创造性的职业，产品的质量、产品的迭代速度有很大程度上依赖于架构师和工程师的水平。如何让人更高效的发挥自己的价值，并且让个人价值更好的服务于整个团队需要，绝对是一项很重要也很体现个人水平的技能。

两种团队

过分务虚

过分务虚的团队对于业务和技术都比较缺乏深入的见解，运用了许多组织模型但却缺乏明确的解决问题的方向，我相信这些团队长期一定难以做出应有的影响力。

过分务实

过于务实的团队指的是更关注于底层技术细节的准确性，但是缺乏更深层次更高维度的对业务整合的理解、对解决什么问题的解构、对团队协作和团队文化的建设；这种类型很容易很吃力但没什么真正的影响力、或者人心涣散。

系统设计从团队设计开始

这是根据康威定律很自然的一个延伸，当年决定团队架构的时候，你就已经在决定系统架构了。

管理者是不是需要懂技术？根据这条原则管理者是需要懂她负责的业务的，而且需要非常懂。当然业务在这里很多情况下指的就是技术，但不仅限于技术本身，还包括技术和产业的结合，需要解决什么样的问题，技术、资源配置和优先级之间的权衡等。管理者不一定是团队里最精通相关业务的，但一定是业务大局观最好的。

懂业务和懂技术，和是不是写代码无关，归根结底是能不能 hands-on，懂实操。

团队是执行任务的最小单元

书中的另外一个原则就是团队是执行任务的最小单元。“团队”这个词在书中有明确的概念：一个拥有5到9人、有共同目标的稳定小组。作为执行任务的最小单元，公司应该把任务分配给团队而不是个人。

高效的团队有以下的特征：

团队规模不应过大，比如贝佐斯的两个披萨原则：Every internal team should be small enough that it can be fed with two pizzas. 书中引用了许多理论和研究来佐证，业界推荐的智力工作型团队最佳人数为5-9人。
业务上“高内聚，低耦合”。
连续性和稳定性，团队需要经历一段时间的招募、磨合和成长才能进入高产期，频繁的变换团队架构(reorg)一般来说都不是好现象。
明确的团队目标和团队的边界。
合理的团队Cognitive Load（认识负荷）。

四种团队类型

书中认为所有高效的公司，团队类型需要最终都能被四种类型覆盖：

Stream-aligned team：流式团队，迭代业务输出、交付用户价值的主要团队类型。一个公司里大部分团队都应该属于这个类别。其它团队都是围绕着怎么支持stream-aligned team（流式团队）来构建的——减少Stream aligned team的Cognitive Load（认知负荷），使之更高效。（对于Stream的理解。Stream就是用户value在产品中从设计到交付的一个过程/流/周期。Stream-aligned 的这种团队设计方式，有利于团队对最终交付负责，并得到用户反馈，持续改进提供给用户的价值。)
Enabling team: 赋能团队，一般是由专家、顾问或者培训师组成，帮助另外的团队onboard某个新系统或者建立某种能力。一般来说都会有一个明确的赋能exit criteria和任务时间，最终的目的是让被赋能的团队可以独立运行。比如team A开发了一套新框架，某个stream-aligned team B决定采纳，team A决定在一个quarter的时间里协助他们迁移到新框架上并且培训team B让他们可以独立运行(exit criteria)。
Complicated system team: 复杂子系统团队，负责某个具体高门槛的核心技术的实现、维护和提升，并通过提供工具或接口的方式赋能其它团队。比如一个具体的数学库、或者语音识别的算法库，如果普通的团队要掌握的话一般需要付出很多的精力。这个时候我们可以招募一批专家负责封装细节和提供self-serviced服务。
Platform team: 平台团队，实现对底层细节的屏蔽，帮助Stream-aligned team更高效的关注业务层面，交付更快。

有些区分其实还挺隐晦的，比如infra team和platform team其实有着本质的区别，而清醒的认知这些区别，对于团队效率经常都有很好的影响。理解这四种团队类型的划分、并且明确自己所在的团队和打交道的团队类型是非常重要的。

三种团队交互模型

Collaboration（协作）

即两个团队直接紧密合作。不过虽然这种方式往往能带来快速的思想交流，同时它也需要付出更大的代价：比如更多的交流，需要说服更多的人，两个团队之间要有更多的协调，两个团队之间产生互相的依赖等等。所以一般建议一个团队在同一个时间最多只和另一个团队以collaboration的方式合作；同时最好提前明确collaboration的时长和要达成的结果。

X-as-a-service（XaaS）

将团队产生的价值通过（内部）产品、服务的方式推广出去；接受方同理。这里的服务指自助服务，可以是API，可以是library，可以是一套工具，可以是文档等等。上面提到的platform team和complicated system team一般情况下最终目的都是以这样的方式去服务stream-aligned team。

Facilitating（赋能）

帮助另一个团队扫清障碍、建立能力；接受方同理。这种方式的直接代价就是提供facilitation的团队的工程师需要占用自己用在维护或产出新功能的时间，不过好处是可以进行宣传和教育、增强公司内对相应技术、工具等的认知。一般建议一个团队同时不要facilitate很多个团队；提前协调好时长；并且以被facilitate的团队最终可以独立运行为目的（自主掌握、可以自己解决这方面的问题，或者说不用再考虑这方面的问题）。