数据智能 数据中台 大数据 产品规划 架构设计
2023-10-31 11:07:25 1 举报AI智能生成
数据智能 数据中台 大数据 产品规划 架构设计 大数据架构师必知必会系列 大数据产品经理必知必会系列 1、数据中台是什么？ 2、数据中台如何建设？ 3、数据中台日常干什么？
作者其他创作
大纲/内容
前言
数据中台是什么？
数据中台如何建设？
从产品经理和项目管理角度，数据中台在实际生产中如何运作？
数据中台应该有什么
数据应用<br><br>(数据中台给业务的赋能)
推荐引擎
埋点系统
画像系统
AB测试系统
业务大屏&报表系统
是什么？
监测核心业务状态的可视化工具
有哪些能力？
监控
集成数据信息，监控商业进程。
领导们监控大趋势，业务部门监控各细化指标，发布业务预警。
分析
各业务团队可通过拖拉拽的方式进行可视化分析，<br><br>进行业务复盘，深挖数据细节，分析原因，直击问题点。
协同
实时同步各部门的协作目标，促进交流与协作，共同解决业务问题。
数据平台<br><br>(数据仓库基础架构给数据中台的赋能)
数据开发平台
数据资产管理平
元数据管理平
数据安全合规平台
组织架构
技术架构
各类大数据组件必不可少
当然也不必过分求快
比方说实时计算能力对于一些企业来说并不是必须的
数据中台在做什么
数据中台主要内容
1）业务数据支持
业务的数据需求紧急且重要
2）中台建设统筹
数据中台建设初期，往往由于BI与各业务部门的目标协同不足，被迫投入过多人力支持业务数据需求。
而事实上两者应该是相辅相成的，<br><br>平台能力建设是为了业务部门可以更加自助地使用数据资产，<br><br>业务数据需求支持可以为中台积累业务认知，更好地洞察业务需求。
举个栗子
以报表为例子
在没有中台的时候，或者中台能力尚不强大时，<br><br>数据开发/数据分析的同事需要与业务部门对接，<br><br>必然经过多回合的“<font color="#ff0000">确认口径</font>-<font color="#00ff00">出报表验证</font>-<font color="#00ff00">修改口径</font>-<font color="#ff0000">定期批跑</font>-<font color="#ff0000">导出</font>-<font color="#00ff00">分析</font>”，<br><br>沟通成本高，节奏拖沓，往往拿到准确的报表已经是几天之后了，<br><br>而且后续的每一次调整都需要与数据开发同事沟通确认。
数据中台建设示例
平台能力建设可以归纳出常见的业务分析场景，将报表<font color="#00ff00">需求抽象化、模块化</font>，<br><br>赋能业务部门在平台上自行选择统计口径、渠道范围、时间区间、统计频率、汇总粒度等条件，<font color="#00ff00">分钟级自动生成报表</font>。<br><br>这样的中台建设显著<font color="#00ff00">增加了代码和服务的复用</font>，<font color="#ff0000">降低了沟通成本</font>，<font color="#00ff00">提升了各部门的工作效率</font>。
平台能力建设是一个宽泛的概念，应该视业务的需求而定，<br><br>准确来说将<font color="#00ff00">出现次数越多、消耗中台人力越多的场景</font>，越需要尽早建设为数据中台的能力。<br><br>包括<font color="#00ff00">报表、合规、AB测试、埋点、推荐</font>等等。
举个栗子
以报表和合规监管为例<br>
1）报表能力建设
各业务部门需要定期、不定期统计总结日活用户、客单价及各指标变化等数据指标，与画像提报情况相似。<br><br>在平台建设完成之后，使用者可以自助选择口径，定期回顾发送邮件，基于图表模块生成可视化图表，或进行异常情况监控。
2）数据安全合规能力建设
各监管对于用户隐私数据日益重视，需要进行各类加密处理，维护与监管机构的高效沟通。
打个比方，监管机构首次提出整改要求或者要求检查部分数据时，<br><br>各公司可能需要一两周的时间来“处理加工”数据（处理加工在这里是中性词，指从海量杂乱的数据中找出监管部门所需要的，并进行分类、归纳）。<br><br>后续监管机构再次拜访时，对接部门可以更早拿到数据进行查验，可以更加从容地应对，比友商更及时提交相关资料。
数据中台流程与运营实践
前言
这一部分主要介绍数据中台项目管理的重点工作内容
需求管理流程
需求预沟通
业务部门向数据中台中熟识的同事进行预沟通，<br><br>与业务部门接触的可能是数据中台的各个岗位的同事，<br><br>因此也需要培养数据开发、数据后台工程同事预沟通的习惯。
预沟通的目标
预沟通的首要目标是让业务部门的需求<font color="#f44336">进入既定流程，通过数据中台提供的指引完成提单</font>。<br>
预沟通的次要目标是在成本不高的情况下，帮助业务部门<font color="#f44336">明确需求</font>，<br><br>如果需求跨越团队较多，预沟通时难以明确，可在需求评审时讨论。<br><br>
需求聊不清楚怎么办？
我们经常会遇到业务部门的需求比较模糊的情况，<br><br>可能是刚接手的同事只有业务领导的一两句话指示尚<font color="#f44336">不清楚具体情况</font>；
可能是发现了一个问题想优化，但<font color="#f44336">没有明确的目标</font>，不清楚要改成什么样；
可能是业务部门想要一份数据，但<font color="#f44336">不清楚有没有这样的数据，或不清楚数据存放在哪里</font>。
提需求单
目标
为了更好地记录、回溯，必须要求业务部门进行提单。
包含的内容
需求单里应该包含的内容，视不同的公司的数据中台所承接的职能不同而有所不同，<br><br>较核心的内容包括<font color="#00ff00">需求背景、所需的能力支持、相关数据的口径定义、期望完成时间、验收标准</font>，<br><br>可能业务部门提单时无法全部写清楚，需要与数据中台各团队在评审会上确认，可以后续对需求单进行补充调整。
Q：如果业务同事太忙了，不愿意写需求单，只写一句话需求单，怎么办？
A：需求单必须由业务部门发起，<br>业务部门最了解需求背景、验收标准，<br><br>业务部门所不太了解的部分（比如数据源、口径、时效等）可以由中台同事进行补充。
提需求单的原则是什么
提单的原则在于“<font color="#00ff00">谁需要，谁提单</font>”，<br><br>如果需求方不愿意花个把小时把需求梳理清楚并记录下来，如何要求响应方花上几天来实现呢。<br>
而且事实上大家会发现，提单时偷懒省的时间，会在后面的<font color="#00ff00">需求讨论、数据探查、数据校验、交付调整</font>的时候加倍还回去。
需求分类
前言<br>
通常业务部门提单时，参照中台所提供的指引，大致知道这个需求归属于哪个团队，或者这是一个跨团队的复合型需求。
需求分类的原则
对于归属明晰的需求，由团队直接对接、明确需求owner
对于复合型需求，可以有项目经理组织定期评审，<br><br>拉上各团队负责人、业务部门产品&开发对接人，<br><br>讨论后明确数据中台侧的需求owner，后续由此owner主导提供解决方案
举个栗子
最初的流程<br>
因而，我们将各需求类型固化出一套分类指引，<br><br>业务方只需要回答3-4个 “Yes or No” 的简单问题，<br><br>便可自动判断出需求owner，或判断为复合型需求移交PM。
优化流程
分类指引的原则
由开发主力团队leader担任
由最终交付团队leader担任
分类指引的好处
这一个看起来不大的优化，在实施1个月后，<br><br>积压需求减少了70%，<br><br>周交付需求数量提升30%，<br><br>单个需求交付时间平均减少了约25%。<br><br>
可行性分析与解决方案
目标
这个环节主要是由需求owner主导完成，<br><br>需要<font color="#00ff00">明确需求的参与人和职责</font>，<br><br>比如数据产品的探查工作，数据开发的编译与调优等，<br><br>同时<font color="#00ff00">给出排期计划</font>，与各方同步。
数据合规安全判断与审批
哪些内容需要合规<br>
需求owner需要判断所提供的数据是否需要数据合规审批，如果需要，则发起数据合规审批
同时也需要把控数据的加密、解密、跨法律主体使用、是否明文处理、传输链路中的风险等细节。
本着谨慎性的原则，数据合规审批一般由中台的同事发起，<br>这是因为中台是这批数据的提供方，也是可能的责任方，<br><br>与此同时也更熟悉数据来源、数据分布、数据主体归属，更了解其中蕴含的风险。
数据合规安全审批涉及的环节
直面反垄断监管的大体量集团企业
掌握用户较多隐私数据的机构
通信基础设施型企业
承担反赌反诈反洗钱责任的机构
需求交付验收
目标是什么
在开发过程中遇到问题，及时给业务部门反馈，避免交付时才暴露问题，被迫推倒重来。<br><br>在交付之后，需求owner和项目经理的一个重要工作是推动需求方尽快验收。
尽快验收的原则是什么
我们在需求提单的环节会要求需求方<font color="#00ff00">明确“高-中-低”的优先级</font>，<br><br>对于高优先级的需求，要求需求方1天内启动验收，2天内完成验收或提出修改；
对于低优先级的需求，时间要求可适当放开，但也不宜超过一周。
回顾并沉淀能力
目标
这个环节其实与上述几个流程没有强烈的前后因果关系。<br><br>核心在于定期回顾业务需求，选择其中<font color="#00ff00">高频、高耗时的进行抽象沉淀</font>。
当然最优解是在业务之前，预测未来一段时间的业务重心，提前建设相关能力。
总结
数据中台的运营与迭代的过程也是各模块<font color="#00ff00">相互推进、相互制约</font>从而螺旋式上升的过程，<br><br>从来不是一蹴而就的，是一个长期的过程。
数据中台的发展离不开领导层和leader们清晰的认知，<br><br>以及平台开发、数据开发、产品经理、项目管理各个角色的密切配合。
收藏
0 条评论
下一页
