前言

回顾21年，自己管理起了整个数据产品团队，有了更高的目标，也对整个数据大团队认知范围有了新的拓展，专注做事同时的兼并团队管理，从成就自己到成就他人，这种视角的转变会在脑子里形成新的思维体系，由模糊懵懂到逐渐精确的感觉很奇妙，就打算以本文的新式做一下整个数据团队搭建的梳理，如果你是一位基层的数据工具人，希望本文能为你在数据团队的组织新式认知上，带来一点启发。

对了提一句，这里我们指的数据大团队包括，数据开发，产品，分析，算法，数据团队的组成肯定不仅限有数据产品，但因为数据产品负责人处于数据上下游的核心节点，对其全局掌控意识要求较高，数据产品负责人的规划很大程度上代表了整个数据团队的前进方向，所以思考问题就不能仅限于数据产品团队本身，管理视角要以整个数据大团队来进行考量。

数据团队的职责

首先要明确数据团队要做什么事情，再说团队怎么组成

面试数据产品经理的时候我有时候会问到候选人是否了解数据团队的职责，这个看似简单的问题如果没有事先深度思考过的话是回答不到点子上的，本质上因为每个数据团队在刚入职之前就已经有很多零散的需求等着你去做，所以导致每个人都一头扎进漫无边际的需求世界里，忘记了我们要去的远方。

职责的意思是代表了在公司希望数据团队提供的价值，什么做好调度工具，实时计算引擎这些不是职责，这是我们作为数据团队要满足职责目标下要做的关键举措，这点数据人员尤为需要注意。简单来说，在公司来看，数据团队的职责体现在两个方面：生产数据，生产广度的数据，数据量大，维度足够丰富，生产深度的数据，保证数据质量，保证数据的时效；消费数据，消费生产的数据，对齐业务认知，辅助业务决策，提高经营效率。我们将职责细化到执行层面：

生产数据

生产广度数据：数仓分层建模，埋点体系框架，NLP数据解析

生产深度数据：数据同步开发平台（包含实时计算），作业调度平台，数据质量平台，元数据管理平台，推荐引擎

消费数据

对齐业务认知：搭建指标体系，报表体系，临时提数

辅助业务决策：BI分析平台，业务洞察平台，用户行为分析平台

提高经营效率：DMP（用户标签平台），CDP（客户数据平台）

上面这些内容后续都会写出实战文章，目前可参考：

1、BI分析平台：https://xie.infoq.cn/article/c98f8ddcaba8fda725266ec4a

2、业务洞察平台：https://xie.infoq.cn/article/71e6938066ad65a9133928b6b

3、用户行为分析平台：未完成作业

4、DMP：https://xie.infoq.cn/article/3db64b1633e8b34f6b9419d1b

5、CDP：https://xie.infoq.cn/article/585a707d9f1c30b38f51d8d2f（文章里重点讲的是用户运营理论层面的内容，CDP产品层面的内容是DMP的功能拓展，有机会在单独讲一讲）

6、数仓分层建模：未完成作业

7、埋点体系框架：https://xie.infoq.cn/article/877d368dfe1618674c3afbf54

8、数据门户 （数据开发平台，作业调度，数据质量，元数据管理）：https://xie.infoq.cn/article/ff77982ef042c482694a49e7e（理论篇）

未完成作业（实践篇）

数据团队的组成

不同规模的业务和体量，一般都是怎么样的组织新式

微团队

组织形式：没有正规意义上的数据部门，从业务开发后台里出两个能写sql的人做邮件报表，以发业绩报表为主，日报，周报，月报等等

需求实现方式：安需推动，没有数仓，直接从mysql，oracle等业务备库写sql捞数据，python+shell脚本+crontab的形式

人数：1-2人

小型团队

组织形式：研发内部依附在某个二级部门下成为一个独立的数据小组，固定几个人专门做报表和提数，业务的报表和数据要啥给啥，至于业务需求的依赖上下文不做涉及，也不涉及数据的持续运营

需求实现方式：对数据的广度有了要求，有基本的ODS层，DWD层，DM层。其中DWD全部以中间表新式存储，上层应用以对齐基本业务认知（做各种主题的报表）为主。

人数：5-6人

中型团队

组织新式：研发内部有数据二级部门，部门内部有明确的任务重心，一般会为数据资产（做数仓，做报表，做标签，做表，临时查数），数据工具（BI分析，用户行为分析，dmp），数据平台（数据门户，Hadoop体系，HBase等核心组件的开发），数据产品（负责设计给数据资产，工具，平台提需求）

需求实现方式：数据的广度与深度均有要求，有了中后台的数据模型标准数仓，也有面向业务前台的数据集市，上层应用除了对齐基本业务认知（做各种主题的报表）外，也有建设各类数据工具，做辅助业务决策（BI分析平台，业务洞察平台，用户行为分析平台），并尝试进行提高经营效率的探索

人数：10-30

大型团队

组织新式：这种数据的组织新式会进一步靠近业务，多见于以集团中台+数据BP的组织形式，而且数据人员不会集中在一个部门里，各个方向会独立成组依附在对应的组织上，但核心的数据资产，数据工具团队，数据平台团队会在单一业务线的数据中台存在（当然像阿里那样目标要对齐所有业务线的超级数据中台我们想想就行了，一般组织消耗不起这么大的成本），数据产品与分析会一分为二，除了建设通用性的数据产品面向中台以外，剩下人会以数据BP的形式深入到各个业务线当中，进行双线汇报（直属leader，与业务leader）

需求实现方式：进一步加强数据的广度与深度，数仓不在成为数据部门独有的内容，一切与业务价值和提高组织效率为导向，会出现各个业务线数据团队各自为战的情况，所有的数据生产与消费将重点以提高经营效率为主，数据生产侧重标签，特征，实时计算等算法工程化内容，数据消费侧重推荐，用户精细化运营。

人数：30以上

至于公司该配置怎么样的团队，主要还是看业务的规模，包括了2c的消费者业务，以及2b的企业业务，数据团队基本上都是跟着业务规模走的，初始期间业务规模大，数据团队就会大，如果不是奔着人力外包，处于成本考量随着基础建设逐步完善以后会进入一个平稳期。

与业务的协同

明确数据团队的组成以后，下面就是和与业务搭配做成事

数据团队能不能成事，很大程度上就看你为业务干了什么事情，所以和业务的协同就显得尤为重要，能良好协同的前提是站在业务角度思考业务需要什么，才能更好协同。

如何了解业务

了解业务没啥好说的，个人心得了解业务三步走：

(1) 看业务周会月会的经营指标体系，结果/过程指标，规模类、质量类、结构类，方便定位当前工作的环节和scope

(2) 看组织架构，依托于这些指标是哪些关键对接人在扛，这些人是才是数仓产出的原始需求方

(3) 找人找文档，过去有哪些经验和知识沉淀，建议怎么做

保持良好关系

我记得在看《蚂蚁金服-独角兽崛起》的时候，提到过OceanBase负责人为了能锤炼一把OB的真实实力，从业务那边切换过了5%的流量来捶打OB，最终还是抗住了，这5%就是靠着研发与业务的个人关系要过来的，如果没有这5%的试炼场，不能说OceanBase没有今天，但至少后续的推进与接入没有那么容易。

与业务保持良好关系这点作为数据负责人个人来说非常重要，用实际的价值产出拉高业务部门对数据部门的期待上限，保证数据团队有足够可以发挥的机会与空间，用良好的友谊关系降低业务部门对数据部门的容忍下限，保证数据团队大施拳脚的同时不会畏手畏脚。

如果与业务保持好关系呢？两个方面，

正常途径

重在事，我们作为承接需求的一方，承接需求时一定要有同理心，很多同学看到业务的想法就觉得是异想天开，敷衍了事，甚至觉得是在故意找茬，我自己见过数据和业务撕逼的太多了，但我个人一直与业务的管理处理的都很不错。在的职场中，数据与业务是互相成就的关系，没有人会认为你是故意搞他，人与人沟通时，需要了解它最忠实的目的，以最终解决问题为主，不能裹挟情绪，解决了业务的问题，关系自然就处好了。

聚焦到做什么事这里，第一次与新的业务协作要以用小的资源，博得最大的成果，通过MVP的形式纵向深入先看到成效，然后在横向拓展。业务部门推荐以销售，运营，推广等能直接和钱打交道的部门合作为主，先以某个活动，某个小场景为例，对齐业务认知（指标体系，标签体系），然后通过沉淀的数据做标签体系，辅助业务去做提高经营效率（DMP，用户运营）探索。

非正常途径

重在人，双方负责人平时多聊聊多沟通，一起聊聊公司，聊聊管理，从单纯的同事话题聊到行业，生活，能让彼此对彼此的印象互相深刻，互相是个什么样人都了解个大概，至少出现了问题会提前沟通，别直接投诉剑拔弩张。这方面没有成文规矩和套路，尺度就得自己把控。

结语

本篇文章偏向于纯理论篇的介绍，一是讲清楚数据团队的职责，二是职责对应的团队组成，三是讲清楚如何与业务协作成事，聚焦在数据团队前期搭建以及迅速做出业绩这个层面上。但是我们既要跑得快，也要跑得远，所以事情也还远不止于此。

数据团队的特殊性在于组建初期公司需要承担很多时间成本，也就是很多业务没了数据部门照样也能玩的转，搭建起数据团队以后你会发现管理起数据团队才是真正的挑战，要自己负责规划业务，定义价值及方向，让你的人有足够的发挥空间、负责吸引人（招聘及内转）、负责留住人（团建及影响），特殊时期还需要自己亲自下场解决问题，每一项工作都不好做。如果碰到上层领导能真正认可数据的价值就挺好，推进起事情就会比较顺利，同时也怕把数据和算法当做倚天屠龙刀一样的领导，会背负很多无法落地的任务。关于数据团队的管理，等我有幸一天能真正负责起数据团队后也会讲讲自己的心得。