数据团队怎么搭，先招谁、配几个人、看什么能力

 

招错一个人的成本是这个岗位年薪的三到五倍，还包括团队里其他人陪着返工的时间。这篇讲招人顺序、岗位配比和能力模型，一个踩过所有坑的老兵的答案。

---

上周有个做汽车配件的老板在微信上问我，公司要搞数字化，数据团队怎么搭，先招什么人，招几个。

我反问他一句，你现在最痛的是什么。

他说报表慢，财务月底出经营分析要等三天，等数据出来还不敢直接用，几个部门对不上。

我说那你先别急着招大数据架构师。

他愣了一下，说大家都说要先搭平台啊。

这事儿我见过太多次了。数据团队搭错方向的，比搭慢的要多得多，而且错了很难掉头，因为人已经招进来了，工资已经在发了，你不好意思说这个岗位先不要。

今天把招人顺序、岗位配比、能力模型这三件事一次说清楚。

三种搭法，我见过都死了

第一种，先招大数据开发。

Hadoop、Spark、Flink一套整，团队很快铺到十来号人。干了半年发现没东西可算，业务系统之间的数据根本没打通，数仓里就躺着几张从ERP抽过来的订单表。最后这个团队的活变成了给业务部门做定制开发，谁要什么接口就写一个，彻底沦为内部外包队。

不是这些人不行，是活还没到他们手上。

第二种，招一群数据分析师。

想着先出报表让老板看到效果，这个思路本身没错，但没人建模、没人管口径，分析师每天干的是接需求拉数。张三要上月华东区销量，李四要上月华东区销量，两个人拉出来差了三百万，开会吵一下午。

半年以后这些人大概率离职，简历上写不出像样的项目。

第三种，先买平台再招人。

平台一两百万买回来了，厂商实施团队撤了，招来的人不会用那个平台，也不知道该往里面放什么。最后平台上就跑着几个演示用的看板，年费照交。

说白了我的理解是，数据团队不是按技术栈搭的，是按能力闭环搭的。技术栈只是工具，闭环才是目的。什么叫闭环，从业务提出一个需求，到这个需求变成一张能用的表或者一个能看的指标，中间所有环节都有人负责，这就叫闭环。

人数多少不重要，闭环有没有才重要。

搭之前，先分清你要的是哪种团队

同样是建数据团队，目标不一样，招的人完全不一样。判断办法很简单，你去看老板最常问的那句话是什么。

问「这个数什么时候出来」，那是报表型团队，当前痛点是慢，先把交付速度做起来。

问「这个数到底准不准」，那是平台型团队，当前痛点是乱，先把口径和模型统一。

问「下一步我们该往哪打」，那是分析型团队，当前痛点是没洞察，需要真正懂业务的人。

三种团队的第一个人都不一样。报表型先要能干活的手，平台型先要能建模的脑，分析型先要懂业务的人。

我问那个老板「最痛的是什么」，就是在判断这个。他答报表慢，那他要的是报表型，第一个人应该招能马上把交付周期从三天压到三小时的那种人，不是招个架构师来画半年架构图。

很多团队建不起来，不是钱不够，是目标错位。老板想要的是快，招的人擅长的是稳，两边都不满意，一年后项目黄了还互相埋怨。

招人顺序，第一个人最关键

第一个人，要招能扛需求的人。

不是架构师，不是算法工程师，是那种既懂业务又会写SQL，还能跟业务部门拍桌子的人。title叫什么无所谓，数据产品经理、数据BP、业务分析师都行，关键看这三条能力。

为什么会是这个。因为数据团队必须尽快拿出被业务用起来的东西，哪怕只是一张准的销售日报。团队能不能活过第一年，取决于老板有没有在数据上尝到甜头，而不是平台搭得多漂亮。

这种人去哪找。我见过最好的来源有两个，一个是业务部门里自己写Excel写到崩溃的那个人，一个是乙方做过实施的顾问。前者懂业务缺方法，后者有方法缺业务，都能补。

第二个人，招数仓工程师。

这个人决定你后面三年累不累。看建模能力，不看组件熟练度。

面试的时候我一般问一句，你们公司销售额这个指标是怎么定义的。能把这个讲清楚的人，比能背出Spark十种调优参数的人值钱得多。我之前写过一篇架构师面试的文章，里面提到过两份简历，技术栈列了两屏，问到口径就开始打转，这种人招进来是要还债的。

第三、第四个人，招数据开发。

干ETL、写调度、做接口，这部分要求不用太高，但工程习惯要好。任务命名有规范，SQL有注释，失败有告警，交接有文档。这四条做不到，人一走就是灾难。

第五个人往后，看方向了。

报表型就补开发和前端，平台型就补建模和治理，分析型就补业务分析。

大数据平台工程师放最后招，甚至可以不要。

现在云上的托管服务已经很成熟了，集群运维、组件升级、容量扩容这些活，云厂商做得比你招的人好。把这部分钱省下来招一个懂建模的人，划算得多。我自己做过的项目里，从本地搬到云上之后，专门管集群的岗位确实就没必要单独设了，云厂商的工单比自己人响应还快。

岗位配比，给几个档位参考

三个人，最小闭环。

一个扛需求，一个做建模，一个做开发。这个配置能跑起来，前提是三个人都不太弱，尤其是建模那个。三个人以下我建议别建团队，找乙方做项目更实在。

五到八个人，最常见的档位。

需求一到两个，建模一到两个，开发两到三个，剩下的补一个治理或者分析。这个规模能支撑一个中等企业的完整数据体系，从入湖到建模到看板到治理全覆盖。

十个人以上，开始分小组。

按业务域分，销售一组、售后一组、营销一组，每组都有自己扛需求的人和建模的人。这时候要设一个横向的架构或者治理角色，不然各组的模型会长成互不相认的样子。

我在V企赶上过一次敏捷转型，那次让我印象最深的不是什么方法论，是他们对角色职责的划分细到什么程度。每条业务线上都有明确的需求负责人、流程引导者、需求转化的人、架构把关的人、质量控制、发布运维，每个角色的责任边界写得清清楚楚，谁对什么负责、谁参与什么评审，落到纸面上。

那次转型真正起作用的不是敏捷两个字，是角色清晰。人还是那些人，把职责划清楚以后，扯皮少了一大半。

反过来说，人再多，角色糊在一起，一样乱。我见过十五个人的数据团队，出了数据问题找不到负责人，因为谁都参与了一点，谁都没负全责。

能力模型，四类人考四件事

这块是最容易被忽略的，很多团队招完人就撒手了，考核还用一套通用的绩效模板，结果逼着所有人往一个方向卷，越卷越歪。

扛需求的人，考采纳。

看他提的需求方案，业务最后有没有真的用起来。考需求数量会出问题，数量多说明他在批量接单，不是在筛选。真正好的需求负责人会砍掉一半需求，因为他知道哪些做了也没人看。

建模的人，考收敛。

同一个指标在全公司被算了几遍，这是最硬的指标。理想状态是一遍，如果你发现「月活跃客户」在三个部门有三套算法，说明建模这个岗位没起作用。另一个可看的数是模型复用率，下游有多少张表是从他建的明细层长出来的。

做开发的人，考稳定。

任务按时完成率、失败率、凌晨告警的次数。这里有个坑，单纯考任务数量会逼着人把大任务拆成小任务刷数据，要考的是SLA，就是答应的时间有没有兑现。

做分析的人，考被引用。

这个最难考也最该考。分析报告被决策引用过几次，提出的建议有没有被执行。考报告产出数量是最糟糕的做法，我见过一年写两百份分析报告的团队，业务部门一份都不看，因为没人信那个数。

C企那个项目做完之后，让我最有成就感的一条数据不是建了多少标签，是业务人员的客群筛选效率从数天提到了分钟级，对数据团队的依赖大幅下降。很多人觉得这是把自己干失业了，我觉得这才是分析师该有的样子，你的价值是让业务自己会干活，不是让业务离不开你。

做治理的人，别考文档。

考元数据覆盖率，考质量问题从发现到闭环的平均时长，考标准落地率。这三条都跟实际效果相关，考文档页数只会得到一堆没人打开的Word。

还有一句提醒，治理这个岗位千万别让人兼职。我做过一个治理项目，前半年的教训就是业务部门不配合，你说标准他说你不懂业务，最后真正推动起来是从管理层切入开始，拿到授权之后才谈得下去。这不是那个治理专员能力不行，是这个岗位没有授权就推不动任何事。所以如果要设治理岗，就得给它配上能上报到管理层的通道，不然就是摆设。

另外几个提醒

别让一个人既做需求又做开发又做治理。 小团队没办法可以理解，但至少要让治理这块有明确的时间投入，哪怕只占两成，也得有人真去干。

外包可以做开发，不要做建模和口径。 口径是一家公司的数据资产，外包出去等于把定义权交给别人，将来换供应商的时候你会发现没人说得清当初为什么这么算。

警惕只写技术栈的简历。 这一条我在面试那篇里说过，这里再提一次，因为招错一个人的成本，是这个岗位年薪的三到五倍，还包括团队里其他人陪着返工的时间。

数据团队最好有直接向业务汇报的通道。 放在IT下面当二级科室不是不行，但如果所有需求都要经过IT负责人转一道，业务那边的变化你永远是最后一个知道的。

写在最后

数据团队不是按人数算的，是按闭环算的。三个人能跑起来的团队，比十个人跑不起来的强得多。

我最怕听到的一句话是「我们先把人招齐再想干什么」。人招齐了，每个月的成本就在那儿，你不得不给他们找活干，于是开始做没人用的看板、建没人用的模型、写没人看的规范，最后用忙碌证明团队存在的价值。

反过来想，先想清楚最痛的那个点在哪，招一个能解决它的人，让他做出点东西给老板看，拿到信任再往下加人。慢是慢一点，但每一步都踩得实。

那句「降低对数据团队的依赖」，我一直当成数据团队的目标。团队做大了不值得骄傲，让公司自己会用数据才值得。

---

作者 凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。

完整系列目录和资料包在公众号「凌波微数」，微信搜一搜就能找到。