2019-08-12
上一篇文章讲了《数据中台实战入门篇：双中台战略》，主要解决了什么是中台、什么是数据中台、业务中台、什么公司适合搭建双中台体系这几个问题。本篇文章讲一下数据中台的人员构成、内部如何合作、数据中台的项目管理、数据中台如何与运营部门合作这几个问题。
数据中台人员构成
架构师：架构师是整个数据中台团队的技术负责人。涉及到大的模块比如标签平台、推荐，要拿到业界比较成熟的架构设计，这样有个参考，能避免我们踩很多坑。另外包括技术选型比如大数据常用的计算框架spark、handoop等用那个比较合适，还有一些需要攻关的技术难题都需要协调他来解决。
项目经理：项目经理要和架构师一起排团队的开发计划。保证让每个任务在时间节点完成，他要更加了解团队的每个成员的特点，最大的发挥团队成员的优势。另外关于项目的质量、风险都需要项目经理制定合理的流程来保证。
产品经理：数据中台的产品经理对外要和运营的同事混熟，了解整个产品现在的策略，节奏是什么，这个时期关注的最核心的指标有那些。对内要将产品的方向、功能用偏技术的语言和开发沟通清楚，保证产品价值的最大化。
模型设计师：模型设计是数据中台比较重要的一环，底层模型的好坏直接决定数据中台数据指标的质量和可扩展性。一个好的模型设计师需要对产品业务流程比较熟悉，对每条产品线的数据存储比较熟悉，需要和产品配合，一起摸清每个指标的开龙去脉，并将模型的思路，计算的方式清晰的告诉数据开发。全方面、多维度的建模是数据中台的基础，数据模型设计师是相对来说数据中台中比较核心的职位。
数据开发工程师：他们主要和模型设计师打交道，模型设计师把业务口径转化为技术口径，告诉他们每个指标应该从那里提取数据，怎么计算。他们将计算的结果一层一层汇总，最终要和后端工程师定义数据显示的接口。另外需要配置计算任务，每天每个指标应该什么时候计算，那些需要实时计算，那些需要离线计算，都是他们来处理。
后端开发工程师：数据中台的后端开发工程师和传统项目的后端开发工程师有点不同，他做的更多的是数据指标接口，与他打交道的是数据开发和产品经理、测试。他要对内的分析产品提供接口，还要将一部分数据以接口的形式输出给其他业务线。
前端开发工程师：前端开发工程师主要和’后端工程师、测试打交道、UI打交道，他需要特别熟悉前端的一些技术比如js、h5等。一些可视化的图表组件也需要比较熟悉如echart等，他需要做的是如何把我们的数据指标，以更合适的图表显示给我们数据中台的用户去用。
UI会根据产品经理的原型设计效果图，一旦效果图通过，UI设计师会出切图（功能的标注），然后前端开发工程师基于切图完成前端界面的开发。前端工程师和UI对审美还是有一定的要求，因为视觉和交互直接决定了产品的用户体验。
测试工程师：数据中台的测试工程师和普通项目的测试有点不同，他更多的是测试数据的准确性，数据中台数据的准确性决定产品价值的80%。
测试工程师需要理解指标的计算逻辑，数据开发会进行自测，是保证数据准确性的第一道门槛，测试工程师是保证数据准确性的第二道门槛，产品功能上线初期会让运营的同事先试用，他们的是保证数据准确性的第三道门槛。当功能运营了一段时间比如二个月或者三个月，测试工程师会组织功能的回测，就形成了第四道门槛。
数据中台内部如何合作
可以看到要完成一个指标的开发还是需要很多角色的配合的，怎么保证这些角色高效的沟通、配合完成项目呢？
我们总结了一套比较规范的流程：
第一步要确定指标的业务口径。
业务口径应该由数据中台的产品经理来主导，找到提出该指标的运营负责人沟通。接下来要问清楚这个指标有什么用，给谁用。
不是所有的指标都有开发的意义，因为数据中台前期每做一个指标都会花费大量的人力资源，所以一定要考虑这个指标的性价比，我们投入这么多资源，能够给公司带来什么，要么直接和交易额相关，要么就是能节省运营同事大量的工作时间，节省人力成本也是为公司省钱嘛。
第二步要确定指标的技术口径。
技术口径是由建模工程师主导，此时模型设计师要和产品经理沟通整个指标的业务逻辑，另外就是产品经理需要要协调业务方的技术开发人员和建模工程师一起梳理数据库层面需要用到表结构和字段。一定要精确到字段级别。
这些字段都确定好后，就能初步定下来这个指标能不能统计，如果不能统计产品经理应该主动告知运营并且还要告诉运营同事做了哪些功能才能统计这些指标，接下来就是协调业务方产品经理讨论是不是要做这些功能。
第三步是原型设计和评审。
这部分还是产品经理来主导，基于需求设计原型。原型设计完后要进行内部评审和外部评审。内部评审要拉上我们的架构师、建模工程师、数据开发工程师、后端开发工程师、前端开发工程师、UI、测试工程师，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。
接下来产品经理要和运营基于原型做一个外部评审，把有歧义的地方一并解决。比较重要的功能产品经理需要发邮件让我们的运营进一步确认，并同步给所有的运营同事保证大家的口径一致。
第四步是模型设计。
此时主导的是我们的模型设计工程师，模型设计会采用三层建模的方式把数据更加科学的组织存储。分为 ODS（操作数据层），DWD(明细数据层)、DWS（汇总数据层）、ADS （应用数据层），这是业界对数据分层常用的模型。模型设计工程师要清楚的知道数据来源自那里，要怎么存放。
第五步是数据开发。
此时主导的是大数据开发工程师。首先要和数据建模工程师沟通好技术口径明确好我们计算的指标都来自于那些业务系统，他们通过数据同步的工具将数据同步到ODS层，然后就是一层一层的通过SQL计算到DW*层，一层一层的汇总，最后形成可为应用直接服务的数据填充到ADS层。
另外大数据开发工程另外一个比较重要的工作就是设置调度任务，简单来讲就是什么时候计算提前写好的计算脚本如T-1每天凌晨处理上一天的数据。随着业务的增长，运营会对实时数据的需求越来越大，还有一些实时计算任务的配置也是由大数据开发工程师完成。
第六步是后端开发。
此时由后端开发工程师主导，后端开发工程师基于产品经理的功能定义输出相应的接口给前端开发工程师调用，由于ADS层是由数据开发工程师已经将数据注入常规的关系型数据库（如MYSQL等），此时后端开发工程师更多的是和产品经理沟通产品的功能、性能方面的问题，以便给使用者更好的用户体验。
第七步是前端开发。
此时主导的是前端开发工程师。原型出来后产品经理会让UI设计师基于产品功能的重点设计UI，UI设计师经过反复的设计，UI最终定型后，会给我们的前端开发工程师提供切图，前端开发工程师基于UI的切图做前端页面的开发。
第八步是联调。
此时数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。一般来说需要大数据开发工程师基于历史的数据执行计算任务，数据开发工程师承担数据准确性的校验，前后端解决用户操作的相关BUG保证不出现低级的问题。
第九步是测试。
此时由测试工程师来主导。测试工程师在完成原型评审后就要开始写测试用例，那些是开发人员自己要自测通过才能交上来测试的，那些是自己要再次验证的都在测试用例写清楚。此时有经验的产品经理会向运营人员要历史的统计数据来核对数据，不过运营人员的数据不一定准确，只是拿来参考。
最终测试没问题后，产品经理可以协调运营人员试用，试用中发现的一些问题再回炉重新修改，此时整个研发过程就结束了。
第十步是上线。
运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器，此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要每过一个周期内部再次验证，从而保证数据的准确性。
数据中台内部迭代计划
每月制定月度计划，设定月度目标
每个月我们会组织和每条产品线的运营、产品同事做一个常规沟通，主要沟通他们目前使用数据中台遇到的一些问题，他们下个月的计划是什么。
基于运营的反馈，我们会制定下个月的迭代计划。产品经理基于运营的反馈定义下个月要做的内容和优先级，架构师和项目经理基于需求的工作量排开发计划，这个开发计划是精确到每两周一个迭代完成月度目标。
一个月的迭代时间太长，一个功能要很久才能看见效果，互联网产品的开发要求短平快，我们也采用短平快的模式将一个月的任务分为2个迭代完成。
第一个迭代主要做一些优化的功能和一些需求已经十分明确的功能，在第一个迭代产品经理需要完成第二个迭代的需求调研，当完成了需求调研会在第二个迭代的第一周进行需求评审。评审完成后技术的同事就可以进行第二个迭代的开发。
到了第三周因为和运营开了一次月度会议，那下个月的需求也基本确定下来。产品经理就可以继续去调研下个月第一个迭代的内容，产品经理的需求会比技术同事的工作提前两周，这样就形成了一个良性的循环。
数据中台如何与其他部门合作
先看下和其他部门的依赖关系。数据中台作为一个独立的部门要支撑起N条产品线的数据化运营，一般和我们打交道的有每条产品线的运营和产品经理。运营人员会有一些数据指标的需求，各个产品线的产品经理需要协助我们完成数据指标的技术口径，因为产品的功能都是业务线的产品经理开发的，所以他们是最清楚产品线的业务流程是数据流。
业务口径和原型确认
当有运营的同事有一个新的数据指指标需求，怎么告诉我们呢？
需要有一个规范的流程。我们制定可一个表格来让运营的同事去填，这个表格主要解决是谁，那条产品线，指标的名称是什么，指标的业务口径是什么、统计周期是什么。
这个表格首先要提交到数据中台的产品经理，产品经理需要和需求方再次沟通确定指标的定义和价值。当产品经理觉得没问题就可以提交给乔峰，让乔峰协调数据开发来看指标的技术口径。当技术口径都没问题，就会进入产品设计阶段。
当产品经理把原型输出后，首先要和运营去再次确认，保证功能没有问题，此时最好是让运营回复下邮件确认。
接下来就进入开发阶段，当开发完成后有个技巧，可以问运营的同事要一些历史手工统计的数据，这个数据会对我们有一定的参考意义。当功能上线后运营人员需要对这个指标负责，有一个试用期比如一周内，他们需要在这个周期内反馈数据的问题。接下来就是数据指标的迭代。
与各条产品线建立月度沟通机制
刚才提到月度沟通的会议十分重要，这是数据中台比较强大的反馈闭环之一。这个会议一方面知道运营那边的节奏，保证数据中台和运营部门的节奏是一致的。
另外一方面我们能收集到大量的用户反馈，因为数据中台的用户主要就是运营人员，解决他们的数据化运营问题。基于这些反馈数据中台可以更加有针对性的优化现有的功能。
建立日常沟通微信群
需要与每条线的运营同事、产品同事建立微信群，日常的数据难免会有一些问题，当有问题时运营要有十分便捷的反馈渠道。运营群里的反馈数据中台要第一时间去处理，因为正是由于这些反馈，数据中台的功能才会变得更加有价值。
规范的取数流程
我们制定了一套规范的取数流程，业务人员要写清楚自己取数的目的，指标的业务口径、统计周期等
。这个需要经过运营负责人的审核，数据中台产品经理的审核。产品经理审核主要确定这个数据的意义和目前的系统是否有这样的数据，如果真的需要帮他们取数，要进一步确认业务口径。尽量做到，让开发看到业务口径就知道该怎么计算那些指标，不浪费开发的时间。
作者：Wilton（董超华），曾任职科大讯飞，现任富力环球商品贸易港大数据产品经理。微信公众号：改变世界的产品经理。
本文由@华仔 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash, 基于CC0协议。
