“数据中台”需要什么样的产品经理?

发表于 讨论求助 2020-06-16 16:16:55

游戏中心接入说起中台的意义,笔者认为在于:快速的响应需求,整合资源,在复用原有能力的同时,发现新机会。 图片来自“网”

中台,一个火热到发烫的词汇。

附耳细听,到处都在喊中台,似乎不知道中台就差了意思,张嘴闭嘴说中台才算OG老炮儿。

但是,时至今日,中台仍然是一个被定义中的概念,大家对这个词汇都有感觉,但又很难具象与明确出来。

说起中台的意义,笔者认为在于:快速的响应需求,整合资源,在复用原有能力的同时,发现新机会。

关于中台的实际落地,有这样的分类:技术中台、业务中台、组织中台,或者直接分为:业务中台与数据中台。

本文将简单剖析一下数据中台,并尝试着明确数据中台到底需要什么样的产品经理。

数据中台:打哪来,往哪去?

到底,什么是数据中台?

首先,数据中台是为了汇总与融合企业内的全部数据(甚至企业外的数据),打破数据隔阂,解决数据标准与口径不一致的问题。

举个例子,多个系统中都有“包子”这个字段,但定义不同:

A:有皮有馅就是包子

B:有荤有素就是包子

C:吃了解饿就是包子

不同定义的最终产物是:同样的“包子”,却有不同的指代物。

这就是数据标准与口径的不一致的弊端,也正是数据中台需要解决的问题。

解决了上述问题,做好了数据治理后,数据中台还需要成为对外提供统一的数据服务接口的数据集成平台。

在这个过程中,不断完善的数据体系,会不断的丰富各类场景所需的数据。

这也是数据中台都在推行 One Data(一个数据管理体系),One ID(打通的用户体系),One Service(一个服务平台)的原因。

再举个例子,公司多个系统或产品都有用户“石头”的使用记录:

A-租房App:石头最近在关注北京海淀区的房子

B-求职App:石头最近投递了海淀多家公司的岗位

C-外卖App:石头点餐配送地址都在朝阳

根据上述内容,如果数据的打通的,且遵循One ID(其实就算注册账号不同也有很多办法来进行关联判断),我们得出的结论是什么?

大致的结论:石头计划从朝阳跳槽到海淀,正在找海淀的房子。

我们可以再细致一点:根据石头点餐的习惯,可以判断ta的日常饮食习惯,结合石头浏览的租房内容可以判断ta的消费档次,再结合投递职位的薪资,我们可以计算出ta的基本收入……

然后呢?一个完整的用户画像跃然纸上。

但是,数据融通带来了新的问题:“数据隐私”。

从技术层面来看,数据中台是“数据仓库与数据服务中间件”的组合,因为海量的数据,所以需要分布式计算平台和存储平台,而且技术是中性的,没有善恶。

从数据应用来看,数据中台汇聚了企业内外部的各种数据,除了企业自身数据,还有大量的用户数据,根据这些内容去挖掘商机是企业商业化的有效途径,但“隐私”的门锁,握于谁手?

数据中台的价值是从正规渠道获取数据,应用到阳光下,数据资产是黑是白,就在于此。

但,不可否认的是:数据中台极具使用价值。

在极具价值的数据中台里,产品经理会扮演什么的角色呢?或者说,数据中台到底需要什么样的产品经理?

通过数据中台项目内容与最终输出物来看,数据中台需要的产品经理分为两类:数据产品经理与数据平台产品经理。

“天条”制定者:数据产品经理

关于数据产品经理,知乎大V何明科大大有这样的描述:

“不写程序的数据工程师不是好产品经理”,从某种程度说明数据产品经理的部分定义,数据产品经理这个职位,其实很跨界:需要懂程序,做数据收集及清洗;需要懂产品,了解内外部用户需求和理解市场;需要懂数据,用数据的方式证明、证伪及发现问题。

简单说,数据产品经理既要完成数据体系设计,让原本无序或庞杂的数据变得“规矩”,又要根据业务场景的变化,不断调整项目内容,推进项目进度。

不得不说,在推进数据中台项目的过程中,开发难度所带来的压力,要远小于数据资产的盘点与整合。

以“包子”的内容为例,数据产品经理需要给“包子”明确出最终的定义,并让各个系统执行。

问题在于:不同的系统归属于不同的部门,你凭什么让别人配合,甚至修改人家用了很久的系统,而且修改内容可能并不会给所属部门带来直接的收益,直白说,这样的工作内容不在KPI范围内。

怎么办?

数据产品经理就像一个“天条”的制定者,却没有执行天条的权力。

如果项目有一把手坐镇,倒可以“挟天子以令诸侯”,但其中苦楚,不足为外人道也。

所以数据中台需要更具沟通能力的数据产品经理,能够在与多个业务线,需求、背景、想法各不相同的相关方一起,推动完成相关功能的实现,有效的达成沟通目的,这一点,不仅重要,而且很重要。

结合数据中台的特性,我们发现:

数据中台的数据产品经理,需要不计一地一城的得失,得有战略思维,也需要缜密的逻辑思维能力。

数据中台所含数据内容庞杂,数据来源之多,远胜单业务线的数据体系,如何完成这一庞大数据体系的设计,是个极大的考验。

数据产品经理,作为数据建设的推动者,需要强大的战略思维和逻辑思维能力,不仅可以判断出当下业务当中的关键流程,更可以不受限于现有业务规模,理解业务接下来的发展方向,做好数据体系扩展性设计。

数据产品经理的基本能力当然更不能丢,业务逻辑梳理、维度指标体系设计、数据建模、数据可视化设计等等。

归纳一下数据产品经理的技能点:

语言:SQL、R语言、Python等;

可视化工具:Tableau、FineBI、Cogons等;

硬实力:熟悉Hadoop集群,数据挖掘与数据分析;

软实力:沟通、行业认知、深度思考

需要说明一下,数据产品经理不是数据分析师。

简单来说,数据分析师更多的是在解决业务线具体的问题,而数据产品经理是在进行业务抽象,通过产品化的方式输出数据。

“方舟”打造者:数据平台产品经理

数据平台产品经理,就是广义上的产品经理,只不过这些产品经理在做数据类产品的相关设计。

他们天天与数据打交道,但不用进行数据分析与数据体系设计。

他们的工作是为数据分析师与数据产品经理打造更多的平台工具,然后把数据分析的成果通过产品化的方式展示给用户。

前者包括:调度平台、实时处理平台、Hadoop生态组件等。

后者包括:可视化报表平台、BI系统、移动BI系统、用户画像平台等,如果有面向用户或者To B的需求,还可以打造如淘宝指数、百度指数这类的数据产品。

浩瀚的数据宛若汪洋,数据产品经理给这片汪洋制定了“洋流与风向”等“天条”规则,但是出航远行还是需要一艘巨舰方舟,这样才能更快的到达各个目的地,数据平台产品经理就是这样一艘方舟的打造者。

数据平台产品经理这位“方舟”打造者,是在用产品化的方式,让内外用户更便捷的使用与查看数据。

所以数据平台产品经理,在满足广义产品设计能力的基础上,还需要以下能力:

数据可视化能力,了解数据平台功能框架基本逻辑;

具备基本的SQL能力,了解数据生命周期;

权限设计能力,尤其是数据权限的管控设计能力;

野望,要有平台商用的野望,并做好准备;

数据平台的起点是企业内部应用,商用也可能只是发展进程中的一站。但过程中,数据平台产品会历经很多“磨难”,比如:内部推广的压力、业务方对数据资产价值的质疑,商用的切入点难以找寻……

耐得住寂寞,有大刀雕花的技巧,才会水到渠成。

数据平台产品经理与数据产品经理在工作的分界线,存在融合,存在很多的交集。不少公司是将两个岗位进行了二合一,一人分饰两角,这倒也未尝不可。

有个前提,数据产品经理更侧重数据体系的建设,而数据平台产品经理更侧重工具与平台的设计,这一点值得了解。

至于数据中台对人才的需求标准,仁者见仁,智者见智吧。

最后的结语

可能中台是“新贵”,数据中台是“风口”,除了尚未解答的数据隐私问题(可能短时间也难以找到答案),还有一件事需要大家了解。

搜索内容是大把的培训机构在追风口,各种数据类岗位的培训广告赫然在列……

说句实话,虽然数据相关的岗位薪酬不错,但是数据相关的岗位需求量真的很小。

理论上说,中台是一种产品设计思路,或者系统架构思路,并不受限于公司的规模。

但是小公司没那么多的数据,不大不小的公司有第三方的数据工具,大公司呢,往往很难通过培训公司,培训一下就可以拿到offer。

所以,与其急于

发表
26906人 签到看排名