如何组建权责明确、运营高效的数据团队？

今天，我将基于过往的实践与感悟，为大家分享组建数据团队的责任与运营实践。内容主要包括两个部分：一是如何设计数据团队角色与分配责任；二是数据驱动业务增长的运营经验。

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

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

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

数据产品运营组

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

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

• 数据产品经理：

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

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

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

• 数据运营人员：

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

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

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

2. 团队角色与定位

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

• 数据开发工程师：

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

• 数据分析工程师：

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

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

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

• 算法工程师：

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

• 数据产品经理：

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

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

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

• 数据运营人员：

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

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

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

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

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

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

然而，在疫情影响下，为了迎合用户线上消费偏好，获取新一轮增长空间，传统企业加快了线上转型的步伐。

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

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

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

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

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

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

N个项目组协同业务需求

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

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

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

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

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

• 数据算法部：

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

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

• 数据分析部：

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

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

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

• 数据平台开发组：

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

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

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

• 创新数据产品部：

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

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

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

2. 产出：数字产品矩阵

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

在充分调研各类业务需求后，开课吧构建了具有在线教育行业特色的数据产品矩阵，以核心业务线为靶向，推动公司业绩增长。

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

在开课吧具体实践中，我们有一个不成文的约定——每月营收不超过 1000 万的业务线，我们基本上不会为它定制任何数据产品。

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

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

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

我们把营销销售拆解成市场投放、一对一电销转销、社群转销、高潜用户发掘、高净值用户画像分析等环节，制作出对应的数据产品，服务各业务部门的智能销售、个性化推荐与智能决策。

1. 一把手工程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一把手工程

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

Data talks

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

产品思维

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

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

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

人才战略

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

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

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

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

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

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

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

开课吧增长团队中的一个数据产品经理，就是从产品经理岗转型过来的。我们团队中的一个数据产品运营，也是我直接从业务团队中挖过来的。

他们原本负责为公司业务提供决策支持，因此具备一定的基础的服务器管理能力、Python 的编写能力。同时他们在业务部门工作了相当长的时间，非常了解业务。最后，他们人缘很好，能够与业务部门进行良好沟通，减少产品在使用和推进的阻力。

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

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

第一部分工作是寻找增长的第二曲线。当公司的主要业务线 SKU 过于平静，面临增长天花板时，就需要数据团队为公司寻找新的业务增长。

第二部分工作涉及公司运营，如提高投放效率、降低投放成本、提高销售转化率、优化用户体验、增加用户活跃度、提升用户复购率等等。

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

2. 打造数据团队影响力

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

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

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

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

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

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

一是构建闭环式的项目执行方式。采用项目制的产品迭代方式，无法响应业务团队持续的、长期的业务需求。

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

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

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

二是关注公司业务的主赛道。部分增长团队会将增长工作集中于较差的业务线中，认为他们底盘小，增长可行性大。

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

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

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

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

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

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

以上就是我今天分享的内容，谢谢大家！