vr全景网站开发制作,手机网站建设价钱,wordpress docker安装,wordpress 文章太多一、如何做一个好的数据产品经理#xff1f; PD#xff08;指产品经理#xff0c;下同#xff09;本身就是在做牛做马#xff0c;关系圈异常复杂。数据PD也不例外。而且打交道的人更多。以下是我用PPT绘制的数据产品经理关系圈。如果你也做过 数据产品的产品经理#xff…一、如何做一个好的数据产品经理 PD指产品经理下同本身就是在做牛做马关系圈异常复杂。数据PD也不例外。而且打交道的人更多。以下是我用PPT绘制的数据产品经理关系圈。如果你也做过 数据产品的产品经理好拗口相信也有同感。既然要和这么多人打交道要推动数据产品的上线数据产品经理自然有着一定的要求。 我的体会如下——也借此去鞭策自己在朝这个方向努力 1.要极其熟悉公司业务及动向。 所以要了解公司的商业模式、战略、以及业务流程、要考核的各种指标以及指标背后的业务含义等。这一点再了解都不够。 2.要了解数据分析。 好的数据PD即使不做数据PD也应该是个数据分析师。数据PD的一大要务就是将数据分析做成可复制可自动运转的系统。虽然有数据分析师们围绕在自己周围但是自己也要清楚业务的问题分别要看什么数据或者当数据出现后意味着业务出现了什么问题或者会出现什么问题。这一点要向最好的数据分析师们看齐。 3. 要了解数据仓库及商务智能。 这 两个关键词背后都是庞大的体系恐怕我短短半年的转岗时间太短虽然能够对别人讲解一通商务智能产品的架构。嘴里虽然会抛出若干个类似于汇总钻取度 量指标维度缓慢变化维层次属性仪表盘等等术语但是也不支持多几层的知识钻取遇到异常问题也不知道该从什么地方分析原因。幸而身边有数据 仓库的同事可以多多学习。这一点没有天花板。 而商务智能做为一门学科起源于20世纪90年代它的出发点是帮助用户更好地获取决策信息最初商务智能的动机是为用户提供自助式的信息获取方式这 样用户就可以不用依赖于IT部门去获取定制的报表。引自《信息仪表盘》一书P41。而如今商务智能除了提供信息更主要的是降低用户获取数据的门 槛提升数据的实时性等方面。从降低用户获取数据的门槛一个方向我们就可以做很多事情比如如何设计信息仪表盘designing of information dashboard如何让数据以更亲和的更直观的方式展示数据可视化如何能够让用户离线访问如何能够实现警戒数据的主动发送这一点上花多少功夫都不多。 4. 要精通数据产品开发流程。数据开发产品开发。 数据PD的最终目的是要做数据产品。这里要拆开看其一数据产品本身也是在线可供用户实现的产品既然是产品产品的整套研发思路和普通的产品没有太大区别用户是谁他们需求是什么满足需求需要什么featurelist每个feature list的资源评估以及优先级如何产品的生命周期如何这是产品开发。然后他是个数据产品意味着这比普通的产品多了更多的要求。在数据这个内核之外它需要各种feature list如订阅搜索自定义短信接口邮件接口等。但是数据这个内核也需要一套数据开发流程。 比如 数据源——是否足够是否稳定 数据PD需要足够了解目前的业务处理系统建设情况以及数据源的积累程度用以判断数据产品的建设时间是否合适。不合适的时机会导致项目组的重复劳动和残缺 的数据产品诞生。数据产品是用以支持监控分析决策的而业务处理系统的定位在于提升工作效率解放工作人员手脚。业务系统采集的数据未必满足所有分析 需要。比如或许领导要分析大量攀升的退换货的详细原因而业务系统目前并没有要求用户在申请退换货的时候选择原因或只有输入而非标准化选项负责退换货出 力的员工也只有在excel里登记原因而不是录入到系统里。所以可能会导致需求方要看的数据提供不出来那么数据pd就有必要反向驱动数据源得以采集。 分析模型的设计—— 分析模型的好与不好其实决定了数据产品的成败。 在 项目中可以由BI的数据分析师们担纲此职责也可以由数据PD担纲更多则由双方一起确认内容以数据分析师们为主功能评估及优先级、项目计划和协 调、统筹以数据PD为主。所以数据PD要更加清楚数据分析师们所需要的需求是否能够实现背后的商业价值如何并与数据开发、产品开发保持比数据分析师们 更加通畅的合作关系能够借力进行可行性和资源的评估。 有的时候我们不是没有数据而是有了太多的数据不知道怎么去看。如果只是抛给用户一堆数据很难想象用户会如何去解读它。以前做交互设计的时候我们流行一句话把用户当成傻瓜。 而数据平台因为可能本身就要求有一定的使用门槛所以想成不会互联网的傻瓜不太现实那么我们就要想成“用户是不懂数据的傻瓜”。他们或许也能通过一串串 数据体悟到什么但是如果是一条上升的退款率趋势线或许他们会体悟到更多——毕竟上和下本身就是直观的。然后再想一下如果将这条线上加上一条警戒点 的线他们会知道从什么时候开始数据是异常的。再然后就要设想当他发现从7月12日数据上升后想干什么他会不会想了解是哪个行业上升了他会不会 想了解是那个渠道上升了那么就要提供行业和渠道的选项或者对比给他。 再然后当他过问了这个行业的负责人后负责人想不想再了解是哪个供应商或者哪类商品上升了那么要如何将这些维度、层次都融合在一起同时又能将用户非常 方便地去用呢分析模型的建设至关重要也可以说分析模型是前期需求分析的最有价值的产物。分析模型应该会包含几点 主题的划分 整块分析会划分成什么主题比如销售可能会分成销售走势及构成分析行业排名商品排名等 度量及指标: 分析主题会涉及到的度量及指标的算法、定义等这通常会产生一份指标以及维度的定义及描述文档 维度 要分别从什么维度去看这些指标和度量如时间渠道这些维度是要筛选还是要对比 钻取 这些维度本身有没有层次需要不需要进行钻取如渠道可钻取到渠道类型行业可钻取到子行业商品类目可钻取到商品叶子类目等 输出 分析需要用何种图表进行展现 数据的ETL开发 数据的清洗转换装载流程占用了数据产品开发的大半资源不规范的数据源会导致这一块的资源更大程度的占用。比如同样是供应商编码系统之一称为供应商编 码系统二命名为供货商编码系统三命名为供应商ID这三个系统同时是公司的系统这种情况虽然想起来匪夷所思但是现实情况却也存在。虽然ETL开发 是DW开发工程师在做但是作为数据PD焉能对这些工作缺乏了解对ETL工程师反馈的问题缺乏认知不理解对于项目的潜在风险是什么而且更多时 侯当遇到数据不规范不统一的问题数据PD需要反向驱动业务系统进行数据规范性建设无论是功能上还是驱动直接的使用方——如负责录入数据的行业小 二建立一套录入规范。这些工作看似和数据PD无关我们大可以推脱说那没办法这是数据源的问题不是我们功能的问题。但是用户是有权利选择使用不 使用你的数据产品的当数据产品提供的数据不值得信赖的话无疑是自取灭亡。一旦用户对数据不信任再想挽留他们是很难的。即使有很多“无能为力”的借 口,我们也不能坐观其变。 前端交互与体验的优化 虽然内容定义好了但是那么多度量、指标、维度、钻取如何划分信息层级如何划分栏目如何设计用户的行为路径这些就不是数据分析师们的重要工作范畴。 而是交互设计师鉴于很多数据产品项目可能会没有交互设计师所以数据PD应该对内容进行封装进行信息架构、页面布局以及图表各种功能设计。设计然后 撰写详细的功能需求文档交付给产品开发前端开发以及数据开发以及前端展现开发四种类型的开发人员。 数据产品的功能描述文档除了产品开发部分其他的就是在描述“内容”即分析模型除了主题、度量、维度、钻取、筛选、输出图表类型有些内容还需要详细定义到“排序方式” 等等细节这就case by case来看了。 环境技术工具 或许做一个普通的产品你把需求描述清楚与产品开发工程师确认好可行性接受资源评估就OK了。但是数据产品受制于所部署的环境所选型的工具如OracleIBM的Cogos以及SQL Server。其他的产品我不知道怎么样我们用的是Oracle BIEE。那么作为数据PD是否需要了解BIEE能够提供的功能是哪些呢看文档请教别人不能知其不可而为之。另外也需要逐渐摸透BIEE的坏脾气实现不了的功能无法克服的难点等。这一点也需要继续了解继续学习。 二、心得总结篇 下面谈几点我的心得总结或许还显得稚嫩但是自己所得要远远比看别人文章或者看书得来的深刻记录下来以便于后续校验。 1. 数据产品的价值 2. 数据产品的用户 3. 数据产品架构 4. 数据产品风险 5. 数据产品VS业务系统 6. 数据产品项目流程 7. 数据产品交付物 原文来自产品经理沙龙欢迎关注。转载于:https://www.cnblogs.com/fanglijiao/p/8384965.html
