如何打造高效的团队（一） - 团队架构
如何打造高效的团队（二） - Android平台团队架构实例
如何打造高效的团队（三） - 领导力
关于团队管理的常见误解
从我个人的感觉，国内互联网公司开始越来越注重团队的管理。一方面是人口红利的消失，互联网从跑马圈地到精耕细作，需要更加精细化的管理，和竞争对手之间的竞争往往是在一点点细节上的差异，而这些细节的差异很大程度上即是执行力的差异，而团队的打造是执行力的基础。另一方面是软件开发本身的属性和人力成本的增加。软件开发是一个富有创造性的职业，产品的质量、产品的迭代速度有很大程度上依赖于架构师和工程师的水平。如何让人更高效的发挥自己的价值，并且让个人价值更好的服务于整个团队需要，绝对是一项很重要也很体现个人水平的技能。
如果在现在这样的背景下，依然认为技术管理还只是软件开发里的附属品、只要技术好技术管理能力就自然而然的好、技术管理非常务虚、技术管理没有什么难度，我觉得其实就有点对不起认知升级的成长趋势了。
从我个人非常有限的认知，我觉得我接触到的不是很成功的团队管理有两种常有的倾向，一种是管理过分务虚，一种是过分务实。前者对于业务和技术都比较缺乏深入的见解，运用了许多组织模型但却缺乏明确的解决问题的方向，我相信这些团队长期一定难以做出应有的影响力。过于务实的情况指的是更关注于底层技术细节的准确性，但是缺乏更深层次更高维度的对业务整合的理解、对解决什么问题的解构、对团队协作和团队文化的建设；这种类型很容易很吃力但没什么真正的影响力、或者人心涣散。
这篇博客基于Team Topologies这本书和我对书中内容的理解。讨论的是团队管理里最基础的内容之一：团队架构，即你该创立什么样的团队，这个团队负责什么事情，这个团队怎么接入整个公司。个人认为这本书还是非常值得推荐的。
团队设计基本原则
康威定律
康威定律最早是在1967年Conway发表的论文《How Do Committees Invent?》被提出，之后《人月神话》里引用并将其命名为康威定律（Conway’s law）。
康威定律说的大致是：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。或者更进一步就是系统是设计该系统的组织结构的映射。比方说如果将设计开发一个compiler的任务交给三个团队，最终出来的结果很可能就会是一个3-step compiler。
康威定律是Team Topologies整本书的核心。
系统设计从团队设计开始
这是根据康威定律很自然的一个延伸，当年决定团队架构的时候，你就已经在决定系统架构了。
所以回到上文的务实和务虚的讨论，管理者是不是需要懂技术？根据这条原则管理者是需要懂她负责的业务的，而且需要非常懂。当然业务在这里很多情况下指的就是技术，但不仅限于技术本身，还包括技术和产业的结合，需要解决什么样的问题，技术、资源配置和优先级之间的权衡等。管理者不一定是团队里最精通相关业务的，但一定是业务大局观最好的。
至于懂业务或者说更具体点懂“技术”是不是指写不写代码, 是不是hands-on，我觉得就太狭隘了。我个人是崇尚还是需要保持hands-on一些的，因为这对我个人来说可以帮助我去了解细节和促进学习；但实在不敢认同以此作为judge别人技术能力的指标。感觉这和问一个人读书多不多类似，读得多的人不见得见识一定更好、读得少的也不见得认知会更少。还是希望心态更开放一些。
团队是执行任务的最小单元
书中的另外一个原则就是团队是执行任务的最小单元。“团队”这个词在书中有明确的概念：一个拥有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: 将团队产生的价值通过（内部）产品、服务的方式推广出去；接受方同理。服务指可以让对方以self-service方式consume的价值，可以是API，可以是library，可以是一套工具，可以是文档等等。上面提到的platform team和complicated system team一般情况下最终目的都是以这样的方式去服务stream-aligned team。
- Facilitating: 帮助另一个团队扫清障碍、建立能力；接受方同理。这种方式的直接代价就是提供facilitation的团队的工程师需要占用自己用在维护或产出新功能的时间，不过好处是可以进行宣传和教育、增强公司内对相应技术、工具等的认知。一般建议一个团队同时不要facilitate很多个团队；提前协调好时长；并且以被facilitate的团队最终可以独立运行为目的（自主掌握、可以自己解决这方面的问题，或者说不用再考虑这方面的问题）。
这篇文章到现在分享了我个人认为Team Topologies这本书的一些主要概念。后续我应该会结合一些实战事例再对书里的内容进行讨论。不过还是非常建议读一读这本书，应该会有更多共鸣和收获。