数据智能团队如何分工与合作

1. 数据智能团队 5 大岗位

数据智能团队由以下两个部分组成。左边是传统的数据团队，右边是数据产品经理和数据运营人员两类新兴岗位，两者共同构成数据智能团队。

数据开发组

数据开发组由以下三类常见的工程师构成，他们不仅是各大公司数据团队的常备军，人才培养体系也相当成熟。

• 数据开发工程师：负责搭建、运营和维护大数据平台和数据仓库。
• 数据分析工程师：负责汇总公司业务数据，完成数据分析。
• 数据算法工程师：通过建立数学模型、算法模型满足业务需求。

数据产品运营组

数据开发组支撑起团队数据收集与分析工作。然而，建立数据智能团队的目的是通过数据与业务场景结合，解决业务和产品痛点。

为了实现数据商业闭环的最终目标，我们需要加入数据产品经理和数据运营人员的角色。

• 数据产品经理：

  作为两个新岗位之一，数据产品经理主要针对具体业务场景，评估利用数据驱动解决业务痛点的可行性。

  数据驱动不是万能的痛点解决方案。比如一个产品的痛点是功能的缺位，需要在营销系统或 CRM 系统上增加功能，这类偏向业务系统类的需求只需交给信息化团队执行。

  数据产品经理需要准确识别和评估各类需求，抽象出共性的数据驱动需求，形成标准化产品，减少工作量。

• 数据运营人员：

  数据运营人员是数据智能团队中另外一个新角色，主要负责帮助业务团队解决数据产品使用问题。

  大部分人认为数据产品运营是产品经理的职责。但我认为，由于数据产品具有较高的业务复杂度和技术复杂度，业务团队在使用过程中不可避免地出现各类问题。

  因此，增设专门的数据运营岗，为团队提供相应的使用指导非常必要。

2. 团队角色与定位

在明晰数据智能团队的岗位设置后，需要了解各个岗位所承担的角色。了解角色的最终目的，是提高人才与岗位的适配性，帮助团队寻找合适的人员

数据开发工程师

数据开发工程师是相对纯粹的研发岗，在人员招聘时只需要关注其 Hadoop、Spark、Flume 等技能的掌握程度。

数据分析工程师

数据分析师需要同时关注业务能力和技术能力。分析师的工作分为两大部分，一部分是依赖数理统计、数据分析技能进行的分析工作。

另一部分是业务向的工作，如梳理业务挖掘产品痛点、建立业务流指标体系、搭建 BI （Business Intelligence，商业智能）系统等等。

因此，除了要求数据分析工程师具备业务分析、数学分析的能力外，还要关注他们的业务理解度，考量其既往经验与行业背景的适配度。

算法工程师

算法工程师主要完成技术实施的工作，包括数据分类、业务预测、机器学习或深度学习的算法等等。在人员选择上主要关注其技能掌握度，对业务场景的熟悉度要求较低。

数据产品经理

我想着重介绍数据产品经理的职能要求。数据产品经理必须具备需求分析、产品设计与迭代、项目管理等产品经理的基本技能。此外，数据产品经理对技术能力也有着较高的要求。

数据产品经理都拥有一定的技术背景，甚至做过技术研发相关工作。

在技术能力的要求下，熟悉业务的技术人员可以转为数据产品经理，但互联网企业以体验型主的产品经理则无法转岗为数据产品经理。

数据运营人员

数据运营人员的工作是将产品推广至业务部门。今天我分享的数据工具大部分是对内的，用于增效。所以公司内部业务团队是我们数据产品的主要用户，比如销售团队、市场团队、投放团队等

数据产品的一大特征是跨部门使用：比如我们的产品有三大模块，第一个模块是给投放团队的，第二、第三个模块可能会交付给品牌相关的团队。

因此，数据运营人员需要具备积极外向的性格特征，因为他需要和公司几乎所有的业务团队打交道。

数据运营人员在工作中，需要充分传递和收集信息。只有数据团队和业务团队进行良好沟通，才能快速发现产品在业务使用过程中暴露出的痛点与不足、准确梳理产品需求，完成闭环迭代。

在数据团队 1.0 时代，我们推崇的是由前三个角色构成的增长团队。

在相对成熟的业务形态下，公司只需配备数据开发工程师、数据分析工程师和算法工程师，就能推动业务发展，解决增长难题。

由以上五个岗位组成的专业度更高的数据智能团队，才能满足新形势下的业务需求，准确梳理公司业务痛点，提升运营效率。

3. 项目分工：1 个资源池 +N 个项目组

我们通过划分工种组建数据团队。但在实际团队运营中，我们会根据不同的业务场景，组建极具专业性的项目组与之适配。

一个资源池支撑项目发展

资源池由上文提到的三类传统技术人员构成。我们可以把资源池理解成数据团队的公共资源，根据项目需要灵活调配。

由于技术中很多基础代码、模块都是共用的，所以资源池中的技术人员可以在同一时间段内实现跨项目运作。

这种操作方法也决定了他们不会像产品经理和产品运营一样，和产品项目有很深的耦合。

N个项目组协同业务需求

针对不同的业务场景，增长团队需要建立相应的产品项目组。即在与投放有关的项目中，应该在团队中配备具有投放经营的产品经理和运营人员。社群、知识图谱等其他业务项目的构建思路也是如此。

在项目组中，产品经理可以共用：一个产品经理管理多个产品项目组。但必须保证每个项目组中有明确的产品经理和运营人员对产品直接负责。

为产品项目选择调性相符的产品运营和产品经理，辅之以灵活数量的技术工程师，能够极大地提升人员的使用效率，同时有效解决产品痛点。

团队建设与产品实践

1. 结构：部门构成与人员配比

下面以某个阶段数据团队的构成为例，为大家介绍团队的组织架构和人员配比情况。

数据团队由数据智能中心统领，下设创新数据产品部、数据平台开发部、数据分析部和数据算法部，各部门人员分配有所不同。

数据算法部

从招聘的角度而言，组建算法部门的难度最大。因为培养一个合格的算法人员成本非常高，且高水平算法人员十分稀缺。

在数据算法部中，不同业务场景对算法的依赖和需求程度不同，因此各公司可以按需设计算法人员数量。

数据分析部

主要由 BI 公司组建，在整体构成上，人员一半偏技术，一半偏业务。公司对数据分析部的需求完全取决于具体业务场景。

最开始我们只有不到 10 个学科，只需要三五个分析师便可完成十几个 SKU 的数据分析。

随后，建立五大事业线，拥有接近 20 个学科。为支撑起庞大的产品矩阵，我们的数据分析师人数也随着具体业务出现线性增长。

数据平台开发组

开发组主要由纯技术人员组成。不同规模的公司对数据开发组人员的需求不同。

规模较小的企业在数据团队启动时可能只有三五人，而后随公司业务发展稳定至八至十人。

总体而言，数据平台开发组人数相对稳定，因为开发人员主要负责基础性平台运维，业务增量更多体现在数据仓库扩容而不是人员数量增长上。

创新数据产品部

这个部门除了产品经理和运营人员外，还有会少数研发人员。

因为我们的交付产品还包括应用系统。应用系统界面设计、前端和后端相关工作需要研发人员配合完成。

产品部的人数设置相对灵活，主要取决于具体的项目规模。

2. 产出：数字产品矩阵

项目制的产品迭代方式存在较高的失败率。如此一来，业务对数据团队和产品团队的配合要求显著提高。

各个业务线在产品使用中会提出不同的需求，数据团队不会也不能响应所有的业务需求，所以必须有的放矢地处理需求

对于业务线相对小的团队，我们鼓励其通过标准化的产品满足普适性的业务需求。诸如数据投放、教学运营、社群相关等分析工具具有复用性，可以满足不同业务场景的需求。

由于数据团队向最高决策层负责，因此在做增长时，不能偏向于某条业务线或者某个独立产品，而应把精力放在最有价值或最有潜力的方向上，实现公司价值最大化的目标。

在产品决策的过程中，数据团队应该对全部需求进行优先级排列，优化选择方式。

运营实践的两大关键点

建立数据增长团队必须是个一把手工程，即由 CEO 或业务总经理直接拍板决策。

1. 一把手工程

大部分公司会将数据增长团队或者数据增长任务挂职到 CTO 名下。然而 CTO 需要投入大量精力去搭建和运维业务系统，以至于他无暇关注业务增长。

数据团队并不是技术团队内部做一个工具自嗨，它需要与销售团队、市场团队、投放团队协同作战，以达到公司用户增长的核心业务目标。

因此，数据团队是一个跨职能的中间团队，而不能单一地将其定义为技术团队或业务团队。

其次，业务团队比技术团队更能理解增长需求。在我向 B 端企业推介人工智能产品的工作经历中，当我对接的是业务人员，我们在业务商讨、需求解决上具有更大的共通意义空间；当对接的是技术人员时，就很难建立高效的交流。

技术团队通过数据挖掘、算法等手段实现增长，对技术产品的需求更加旺盛。而业务团队如销售 VP、市场总监等更能理解数据增长的需求，协助业务增长。

综上两个原因，决定了增长团队的最高负责人必须是业务的一把手。

2. 数据产品的思维与迭代

数据团队一定要注重数据产品的迭代，使其无限逼近业务。

数据团队做增长任务，首先要完成好开源，开源比节流更重要。

过去我向公司提供咨询业务时，他们希望提高自有数据价值，挖掘出对增长最有帮助的业务。面对这类需求，我的解决方案是首先关注营销环节。因为这个环节永远是 CEO 最关注的，同时也是离钱最近的。

只要我们把营销环节做出效果，公司的销售也会得到提升，企业也会逐步意识到营销的价值。这就是开源的思维和实践。

然而，传统的增长思维倾向于关注节流。人工智能在商业化最初阶段，智能客服是其最初的落地产品。然而智能客服的推广鲜有成功，因为它是一个节流的工作，主要目的是为公司节省资金。

实际上，通过智能客服节省出的资金，在最高决策预算中的占比微不足道。

节流思维出现的根本原因，是大家忽视了公司最核心的目标——增长。公司很多问题都可以被增长覆盖，但如果没有增长，公司就会暴露出很多问题。

因此在公司发展阶段，数据团队需要关注增长这个核心问题。

为了帮助大家理解一把手工程与数据产品思维，我给大家介绍 5 个相关概念：

明确的战略

做数据驱动增长的过程，也是企业文化构建的过程。因此建立增长团队，必须要有一个非常明确的战略，指导产品实践。

一把手工程

从公司战略下发到具体产品战略制定，决定了建立数据团队必须是个一把手工程。只有获得公司最高决策层的支持，数据团队才能协同公司各部门，完成数据驱动增长的核心目标。

Data talks

增长团队的核心要义是用数据说话，而不是拍脑袋决策。

产品思维

增长团队需要用产品制替代项目制，建立产品思维。

举个例子：当业务方需要获取数据时，我们不能简单地交付由爬虫结果得出的报告。产品需求的真正解决，建立在业务场景、数据和产品三者组成的闭环当中。

只有建立其产品思维，以问题为导向持续追踪产品，才能完成长期的、持续的迭代。

人才战略

建设增长团队最大的痛点在于增长型人才的匮乏，不仅缺乏理解增长的人才，具备增长能力的人才也同样缺乏。

在增长团队的 5 类角色中，前 3 类已经非常难招了，数据智能团队还需加入数据产品经理和产品运营等角色。

如何招聘人才、管理人才成为目前企业内部组建增长团队最大的困难。

困难来源主要有两个方面。一是难以找到与增长团队角色相契合的简历。目前大部分公司都处在增长团队的组建阶段，因此很难通过从竞品公司挖掘增长型人才的方式建立团队。

二是传统增长型人才与现有阶段的增长需求不相匹配。过去的增长人员多使用 BI、Excel 等工具输出报表，工作内容仅限数据的处理与分析，缺乏对业务痛点梳理、数据产品思维等增长概念的了解。

基于此，我向大家提两个建议。一是对于前三类相对成熟的工种，公司可以直接招聘专业人才，匹配相关岗位。

至于后两个新兴角色，可以通过内部挖掘和培养的方式完成。比如从产品经理团队中寻找技术背景较强的人，或者把对数据非常敏感的业务人员转型成数据产品经理

综上所述，数据团队实际上是一个将多个工种凝聚起来的部队。只有赋予团队角色明确的分工，建立明确的战略框架，配套数据驱动增长的企业文化，才能使数据团队高效地为增长目标服务。

关于数据团队的两点思考

1. 数据团队的主要工作

数据团队的工作包括两个部分。

• 第一部分工作是寻找增长的第二曲线。当公司的主要业务线 SKU 过于平静，面临增长天花板时，就需要数据团队为公司寻找新的业务增长。
• 第二部分工作涉及公司运营，如提高投放效率、降低投放成本、提高销售转化率、优化用户体验、增加用户活跃度、提升用户复购率等等。

数据团队通过关注这类指标，指导产品、运营、销售的日常工作，提高公司整体运营效率，以达到增长的目的。

2. 打造数据团队影响力

构建影响力是数据团队最困难也是最重要的工作。在数据团队与各业务部门协作的过程中，如果缺乏影响力，就很难用数据增长逻辑说服业务方。

数据团队的影响力源自它的领导力，而领导力直接与公信力挂钩。因此数据团队影响力的构建，依赖于公信力、领导力和影响力的三力合一。

举个例子：大家需要服从公司 CEO 下发的任何命令。因为 CEO 具有最强公信力，他所发布的每一个指令都是公司的最高战略，大家必须执行。同时，CEO 是所有人的领导，天然具备影响力。最后，CEO 能通过各种手段强制执行某个命令，这是他的三力来源。

总体而言，CEO 的三大能力通过行政手段得到保障。然而，数据增长团队不是任何业务部门的直属领导，销售部门、市场投放团队等没有义务服从增长团队提出的方案及建议。

同时，数据产品的准入门槛高，需要业务方学习相关数据可视化、Python 等技术知识，进一步降低了业务方的产品接受意愿。

为了令业务方确信产品能对业务增长、效率提升产生正向效果，提高业务方的产品使用意愿，我有如下两个建议：

一是构建闭环式的项目执行方式。

采用项目制的产品迭代方式，无法响应业务团队持续的、长期的业务需求。

尤其是当数据团队成果仅供业务方测试时，新的渠道或新的 SOP 会促使业务部门直接放弃某个数据团队成果。这时数据团队所做的尝试和努力也付诸东流。

在这种情况下，数据团队的影响力会随着时间快速衰减，最终使大家忘记产品的成效与数据团队的存在。

因此，数据团队应不断追踪业务部门的真正需求，持续迭代更新解决方案，一切以驱动增长为目标。

二是关注公司业务的主赛道

分增长团队会将增长工作集中于较差的业务线中，认为他们底盘小，增长可行性大。

但在我的经验看来，试图通过数据驱动较差业务线增长、力挽狂澜，这个实践方向的成功概率非常低。

做增长的前提是产品实现 PMF。一般而言，在探索产品 0～1 的规模建设中，业务洞察力和决策力的作用远大于数据驱动。

在产品起步阶段，业务规模小，所产生的数据量也小，通过数据分析、建模驱动的难度非常大。

产品在 0～1 的探索阶段中失败，更多的原因在于公司没有做出有价值的产品，无法从解决用户痛点，而不是增长支持的缺位。

因此，数据团队在做增长时，一定要关注公司业务的主赛道，通过产品帮助主业务线实现较高增长，快速打造自身影响力。

综上，公信力、领导力和影响力是支撑数据团队成功的三大因素。各位在数据团队的管理与运营中，也可以反问自己的团队是否具备足够的公信力、领导力和影响力，以此找到团队的运营路径。

互联网公司的成功很大一部分归结为人才储备，如何打造有活力、持续创新的研发团队，相信很多管理者都比较关心。

 

下面我们从业务支撑、技术架构、团队建设这几个方面做简单剖析

 

业务支撑

 

快速发展已经成为互联网公司的一种常态，那么在这么快的节奏下，如何快速支撑业务？尤其是在资源紧缺的情况下，既要做业务，也要做系统优化升级。确实很难做取舍。

 

我的观点是看公司的规模，如果是创业早期，活下来才是第一要素，我们会将业务分为日常项目和重点项目。所谓重点项目就是能影响市场抢占度，甚至影响公司生死的项目。因此，对于重点项目，我们有一个明确的要求，即 P0 排期，让重点项目能够随时启动、快速上线，以雷霆之势赢得战略优势。

 

理想是美好的，但与业务对接时，可能会遇到一些问题：

 

1、每次业务都说需求很急，火急火燎，确很少关注数据指标，项目一旦上线，就没有了下文。

2、研发完全是被动角色，像驴脑袋前挂根胡萝卜，永远被牵着鼻子走

3、产品缺乏清晰的业务规划、业务架构，很多时候都是走一步看一步。而研发作为合作伙伴，感觉像个外包，没法跟业务一起思考，共进退，缺乏成就感。

 

 

 

如何提高研发的参与感，快速支撑业务？首先要关心业务，不打无准备仗。

 

正如拿破仑说的“不想当元帅的士兵不是好士兵”，做为研发工程师，如果不关心业务，也很难有高性价的技术方案产出。不管是前期的需求分析、市场调研、竞品分析，技术同学如果有精力，最好都参与下。你不仅会了解到这个需求是怎么来的，还能预想到未来业务可能的迭代方向。提前做规划，这样在做设计技术方案时才会充分考虑系统的扩展性，而不是“将提升扩展性只是当成喊口号”。

 

研发的价值不仅是满足当下的业务需求，还要为为后续业务迭代预留好扩展。千万不要把自己定位成“需求翻译机器”、“架构优化机器”，相反我们要做从技术视角去推动平台业务发展的业务架构师。

 

技术架构

 

业务方面要发扬主人翁精神，技术方面同样要有成就感。关注市场主流的技术架构，选择合适的技术框架应用到项目中。具体我们要关注哪些方面？

 

1、架构设计

 

借助DDD思想指导我们落地一系列的微服务，通过注册中心完成各服务间的路由和发现。通过"拆' 降低系统复杂度，提升扩展能力。如果公司的业务较多，结合当下流行的中台战略，按业务模块拆分，水平支持上层一系列业务。将一些通用的逻辑沉淀到中台，统一规划支持，减少重复造轮子成本。

 

另外，做技术的同学都知道，架构是演化来的，很难一步到位。所以在做技术方案时，要充分考虑上线时间、人工成本、系统复杂度等因素，挑选性价比最高的技术方案，先满足当下业务诉求，后面再慢慢技术改造，迭代升级

 

2、工程效率，包括动态化、配置化、工具化、自动化等

 

工程效率对业务会有比较直接的支撑，而我们做技术驱动的整体思路，就是把工程效率中的每条线、每个子模块，都去做动态化、配置化、工具化、自动化。

 

从发布到运维，从测试到自动化。通过一系列的工具化，首先大家有成就感，借助工具提高工作效率；其次这些事情都有一定的技术挑战和技术深度，让整体团队的技术氛围得以增强。

 

画外音：复杂的事情简单化，简单的事情标准化，标准的事情流程化，流程的事情自动化。

 

3、系统稳定性

 

系统稳定性是一家公司的底线，如果一个线上系统经常宕机，相信不会做大做强。在稳定性上，除了形成很多固定的流程机制外，我们还通过一些优化策略，紧急预案来保证，包括测试 / 灰度、降级 /限流/ 容灾 / 回滚、监控告警等。

 

团队建设

 

1、团队项目管理透明化

 

通过白板或者jira需求列表，将团队中所有事务全部罗列出来，包括需求列表、迭代列表、问题风险列表等，把所有的信息透明化。

 

比如在白板左侧列出需求列表，中间写上迭代表，团队这一个迭代内需要完成的任务，之后列出团队目前遇到的问题及风险。另外，还有需求燃起图、迭代燃尽图等，便于查看每一个迭代图完成了多少个需求。还可以加上一份团队日历，标注出在迭代过程中的重要事项和重要时间节点，帮助我们能够看到团队中所有人的任务和进度。

 

2、个人激励

 

团队中每位成员都有自己负责的业务及系统，责任田机制，每人在自己负责的地盘有较大的自由度，精耕细作，待来年拿个好的“年终奖”。放权更容易激发团队成员的主观能动性，激发个人潜能。这样也能给团队负责人更多的时间精力统筹思考规划团队的未来方向，业务越做越大，脚步越走越稳。

 

了解团队成员的职业生涯或成长通道，按照这个方向帮助他提升个人能力。关注团队中的个人，给他尊重与认可。当然，这方面也需要团队的透明制度作为支撑。

 

3、考核机制

 

考核虽然比较敏感，也比较让人讨厌。但确是激发个人产出最有效的手段。想阿里巴巴实行的271考核，如果考核评到前20%，年底年终奖可能会拿到至少5个月的奖励，是不是很诱人。

 

考核是一把双刃剑，用不好很容易挫败人的积极性，甚至会导致员工离职。所以在设置合理绩效目标很重要，既要有一定难度，但也不能是镜中月水中花，难已实现。同时也要关注实现比例，如果年底，团队成员都超出期望实现自己的目标，那可就难办了。

 

考核一定要透明，切记不要搞暗箱操作，诚信规则很重要，否则很容易丧失公允力。

 

4、文档建设

 

工作中沉淀较完善的技术文档，这样后面有新同学入职后，可以自己熟悉业务，快速投入到工作中。

 

 

带团队要注意的问题

 

1、方向要明确。业务方向、团队目标，大家要达成一致，千万不要项目排的很多，让大家疲于奔命却又没有成就感。这样很容易导致人员流失

 

2、目标清晰。如果团队负责人都感到模糊的事情最好不要分配给下属，否则会让对方无所适从，要么不当一回事，不会引起重视。如果是调研型工作，要跟下属明确需要完成的目标，这样才能保证效率和产出。

 

3、优先级一致。作为团队负责人，任何时候面前只要超过一件事，心中肯定有优先级之分。这个优先级需要清晰明确的告知团队，并且就此与团队达成一致，避免因信息不一致或者大家的认识不同，引起不必要的扯皮，耽误事儿。

 

4、多跟业务沟通，时刻关注业务动向，提前做好技术储备，避免一些让人措手不及的复杂任务从天而降，尽量减少搞突击。

 

5、留出弹性空间，项目适当留些buffer。避免一些突击项目搞的你很被动。

 

6、技术就是生产力。鼓励团队多开发一些提高效率的小工具，例如自动化测试脚本、部署工具和一些解放人力重复性工作的小程序。

 

 

往期推荐

 

• 聊聊电商促销业务

• 快速上手Spring-Data-Redis

• DDD是如何解决复杂业务扩展问题？

• 线上服务的FGC问题排查，看这篇就够了！

• 优惠券有哪些玩法？

• 如何用好缓存？全面梳理（第三篇）

• 如何实现 查找“附近的人” ？

• 重大事故！IO问题引发线上20台机器同时崩溃

• springboot + aop + Lua分布式限流的最佳实践

• 电商交易系统核心技术

• 一线电商平台架构方案汇总

关注【微观技术】

 

我们热衷于收集&分享高并发、系统架构、微服务、消息中间件、 RPC框架、高性能缓存、搜索、分布式数据框架、分布式协同服务、分布式配置中心、中台架构、领域驱动设计、系统监控、系统稳定性等技术知识。

关注公众号，后台回复“中台”，下载PDF学习资料

如何打造高效的团队（一） - 团队架构
如何打造高效的团队（二） - 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。

四种团队类型

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

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

这些听起来可能比较抽象，我后续应该会单独发文章介绍一些它们的实战事例。有些区分其实还挺隐晦的，比如infra team和platform team其实有着本质的区别，而清醒的认知这些区别，对于团队效率经常都有很好的影响。理解这四种团队类型的划分、并且明确自己所在的团队和打交道的团队类型是非常重要的。

三种团队交互模型

书中将团队和团队之间合理的交互总结为三种类型：

1. Collaboration: 即两个团队直接紧密合作。不过虽然这种方式往往能带来快速的思想交流，同时它也需要付出更大的代价：比如更多的交流，需要说服更多的人，两个团队之间要有更多的协调，两个团队之间产生互相的依赖等等。所以一般建议一个团队在同一个时间最多只和另一个团队以collaboration的方式合作；同时最好提前明确collaboration的时长和要达成的结果。
2. X-as-a-service: 将团队产生的价值通过（内部）产品、服务的方式推广出去；接受方同理。服务指可以让对方以self-service方式consume的价值，可以是API，可以是library，可以是一套工具，可以是文档等等。上面提到的platform team和complicated system team一般情况下最终目的都是以这样的方式去服务stream-aligned team。
3. Facilitating: 帮助另一个团队扫清障碍、建立能力；接受方同理。这种方式的直接代价就是提供facilitation的团队的工程师需要占用自己用在维护或产出新功能的时间，不过好处是可以进行宣传和教育、增强公司内对相应技术、工具等的认知。一般建议一个团队同时不要facilitate很多个团队；提前协调好时长；并且以被facilitate的团队最终可以独立运行为目的（自主掌握、可以自己解决这方面的问题，或者说不用再考虑这方面的问题）。

这篇文章到现在分享了我个人认为Team Topologies这本书的一些主要概念。后续我应该会结合一些实战事例再对书里的内容进行讨论。不过还是非常建议读一读这本书，应该会有更多共鸣和收获。