数据中台实战:手把手教你搭建数据中台
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

1.5 数据中台内外合作机制

在搭建中台的过程中,特别是在数据中台与其他部门合作时,数据中台团队经常被各条产品线问到以下两个问题。

● 为什么要接入业务中台?

● 产品线的数据为什么要提供给数据中台?

中台是一个中心化的组织结构。中心化就意味着你要和其他部门合作才能完成中台的搭建工作。掌握如何与其他部门合作、如何管理数据中台团队的能力是非常重要的。

1.5.1 数据中台如何与其他部门合作

先看下数据中台和其他部门的依赖关系。如图1-8所示,数据中台作为一个独立的部门要支撑起公司内部多条产品线的数据化运营。一般来说,各条产品线的运营人员和产品经理常常会和数据中台打交道。产品线的运营人员经常会有一些关于数据指标的需求。产品线的产品经理需要协助数据中台完成数据指标涉及的业务流程,技术口径的确认也需要业务部门的产品经理协调他们的开发人员一起完成,因为产品的功能都是产品线的产品经理开发的,所以他们是最清楚产品线的业务流程和数据流转的。

图1-8 数据中台与其他部门的依赖关系

数据中台与其他业务部门的合作主要包括以下几方面。

1.业务口径和原型确认

当运营人员有一个新的数据指标要开发时,如何将这些指标清晰地告诉数据中台呢?这就需要有一个规范。

一个指标的开发需求列表如图1-9所示。可以用这个表格统一指标的业务口径:是谁需要查看这个指标、这个指标属于哪条产品线、指标的名称是什么、指标的业务口径是什么、统计周期是什么。

图1-9 运营人员需求列表

这个表格首先要提交给数据中台产品经理,其应该和需求方再次沟通以确定指标的定义和价值。经数据中台产品经理确定后,就可以将表格提交给数据中台的技术负责人,让技术负责人协调模型设计师、数据开发工程师来初步确定指标的技术口径。在技术口径确认后,数据指标开发就会进入产品设计阶段。

产品经理在输出原型后,第一件事就是和需求方再次确认,保证功能没有问题。此时最好让运营人员回复邮件确认。之后会进入开发阶段。在完成开发后,产品经理可以向运营人员要一些历史手工统计的数据,这个数据对于数据中台团队来说,有一定的参考意义。在功能上线后,运营人员需要对这个指标负责,可以设定一个试用期(比如一周),他们需要在这个周期内反馈数据的问题。之后就是数据指标的迭代阶段。

2.与各条产品线建立月度沟通机制

数据中台团队与其他业务部门的定期沟通十分重要。在企业内部,业务部门是数据中台的主要使用方,在使用数据中台的过程中一定会遇到比较多的问题,业务方的反馈对数据中台团队不断优化自己的产品十分重要。通过月度沟通机制,数据中台团队一方面可以知道业务部门的运营节奏,保证数据中台和运营部门的节奏是一致的,另一方面可以调研运营人员的数据需求,获得问题反馈,帮助他们进行数据化的运营。数据中台的主要用户就是产品/运营人员,基于这些反馈,数据中台可以更有针对性地优化现有的功能。

3.建立日常沟通微信群

需要与每条产品线的运营同事、产品同事建立微信群。日常的数据难免会有一些问题,当有问题时运营人员需要十分便捷的反馈渠道。针对微信群里的反馈,数据中台团队要在第一时间内处理,因为正是这些反馈,能令数据中台的功能变得更加有价值。

4.建立规范的取数流程

一般来说,数据中台研发的相关指标不可能满足产品/运营人员的全部需求。数据中台可能会遇到其他部门的很多特殊的取数需求。针对这些取数需求,数据中台需要制定一套规范的取数流程,制作取数申请表格,如图1-10所示,业务人员要对自己要提取的数据进行详细描述,包括指标的定义、业务口径、统计周期和计算方式,写清楚自己取数的用途。这个表格首先需要经过业务人员所在部门负责人的审核,然后还要经过数据中台产品经理的审核。数据中台产品经理审核该表格主要是为了确定这个数据的意义和目前的系统是否拥有这样的数据。如果确定帮助业务人员取数,则要进一步确认业务口径,尽量让开发人员一看到业务口径就知道该怎么计算相关指标,避免浪费开发人员的时间。

图1-10 业务人员取数申请表格

1.5.2 数据中台内部项目管理流程

数据中台的指标开发流程涉及多个角色,花费的时间比较长,因此,如何让运营人员、产品人员、开发人员、测试人员高效地配合来完成数据中台的目标,是一件非常重要的事情。在这里,笔者推荐一个名为“双周迭代计划”的数据中台内部项目管理流程,如图1-11所示。

图1-11 双周迭代计划

数据中台项目在立项时是需要对各条产品线进行大量调研的。这时候,数据中台需要和运营部门一起确定一个总的目标,比如以一年为一个周期,数据中台要将这一年里要做的功能,按照需求的优先级、性价比,把关键任务拆解到各个阶段,从而分阶段完成。我们可以按季度分阶段,每个季度完成一个小目标,当小目标都一一实现时,大目标的实现也不会出现大的纰漏。接下来,这个季度小目标还可以拆解到每个月的计划中,每个月完成相应内容。

如果以一个月作为一个迭代周期,那么迭代周期会显得有些长,因为等到数据中台一个月后把指标开发完成,运营人员的关注点可能就已经改变了,开发的功能可能已经脱离了当前的运营目标。所以笔者所在的公司采用“月度目标、双周计划”的机制——也就是说,每个月都会基于目标设定阶段性任务,再将阶段性任务分为两个迭代周期来完成。

接下来我们具体看看“月度目标、双周计划”怎么运转。

(1)每月制订月度计划,设定月度目标。

每个月数据中台都会组织每条产品线的产品/运营人员做一次常规沟通,一般安排在第三周,主要讨论他们目前使用数据中台所遇到的一些问题,另外弄清楚产品线下个月的计划是什么。基于运营人员的反馈,数据中台可以制订下个月的迭代计划,包括下个月工作的优先级、在什么时间节点完成什么内容,这样就能保证数据中台和产品线的节奏一致、目标一致。

(2)每两周迭代一次,完成月度目标。

数据中台可以将一个月的任务分为两个迭代周期完成。一般来说,第一个迭代周期是上半个月,第二个迭代周期是下半个月。

在第一个迭代周期里主要做一些优化的功能和一些需求已经十分明确的功能。

在第一个迭代周期里,产品经理需要完成第二个迭代周期的需求调研,在需求都明确下来后,会在第一个迭代周期的第二周进行需求评审,在需求评审完成后,技术人员就可以准时在第三周进行第二个迭代周期的开发工作。

到了第三周,需要和运营人员开一次月度会议,从而确定下个月的需求—也就是步骤(1),产品经理就可以继续完成下个月第一个迭代周期的需求调研,并在第四周进行需求评审。这样,产品经理的需求调研工作会比技术同事的开发工作提前两周完成,这就形成了一个良性的迭代循环。


[1]注:ETL即Extract-Transform-Load,指数据从来源端经过抽取(extract)、转换(transform)、加载(load)等步骤至目的端的过程。