阿里巴巴数据产品经理工做(总结篇)

PD（指产品经理，下同）自己就是在作牛作马，关系圈异常复杂。数据PD也不例外。并且打交道的人更多。如下是我用PPT绘制的数据产品经理关系圈。

　　科普：

　　PD：对于WEB产品设计人员而言，它的意思是“产品设计人员”，即produce designer。

　　PD：在IT企业中，通常是Product Director(产品主管)或Project Director(项目主管)的意思

　　

　　一. 如何作一个好的数据产品经理？

　　PD（指产品经理，下同）自己就是在作牛作马，关系圈异常复杂。数据PD也不例外。并且打交道的人更多。如下是我用PPT绘制的数据产品经理关系圈。若是你也作过数据产品的产品经理（好拗口），相信也有同感。既然要和这么多人打交道，要推进数据产品的上线，数据产品经理天然有着必定的要求。

　　

　　个人体会以下——也借此去鞭策本身在朝这个方向努力：

　　1.要极其熟悉公司业务及动向。因此要了解公司的商业模式、战略、以及业务流程、要考核的各类指标，以及指标背后的业务含义等。这一点，再了解都不够。

　　2.要了解数据分析。好的数据PD，即便不作数据PD，也应该是个数据分析师。数据PD的一大要务就是将数据分析作成可复制，可自动运转的系统。虽然有数据分析师们围绕在本身周围，可是本身也要清楚业务的问题，分别要看什么数据，或者当数据出现后，意味着业务出现了什么问题或者会出现什么问题。这一点，要向最好的数据分析师们看齐。

　　3. 要了解数据仓库及商务智能。

　　这两个关键词背后都是庞大的体系，恐怕我短短半年的转岗时间过短，虽然可以对别人讲解一通商务智能产品的架构。嘴里虽然会抛出若干个相似于汇总，钻取，度量，指标，维度，缓慢变化维，层次，属性，仪表盘等等术语，可是也不支持多几层的知识钻取，遇到异常问题，也不知道该从什么地方分析缘由。幸而身边有数据仓库的同事，能够多多学习。这一点，没有天花板。

　　而商务智能，作为一门学科，起源于20世纪90年代，它的出发点是帮助用户更好地获取决策信息，最初商务智能的动机是为用户提供自助式的信息获取方式，这样，用户就能够不用依赖于IT部门去获取定制的报表。（引自《信息仪表盘》一书P41）。而现在，商务智能除了提供信息，更主要的是下降用户获取数据的门槛，提高数据的实时性等方面。从下降用户获取数据的门槛一个方向，咱们就能够作不少事情，好比如何设计信息仪表盘（designing of information dashboard）？如何让数据以更亲和的更直观的方式展现（数据可视化）？如何可以让用户离线访问？如何可以实现警惕数据的主动发送？这一点上，花多少功夫都很少。

　　4. 要精通数据产品开发流程。数据开发+产品开发。

　　数据PD的最终目的是要作数据产品。这里要拆开看，其一，数据产品自己也是在线可供用户实现的产品，既然是产品，产品的整套研发思路和普通的产品没有太大区别，用户是谁，他们需求是什么，知足需求须要什么feature list，每一个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了。可是数据产品，受制于所部署的环境，所选型的工具，如Oracle，IBM的Cogos，以及SQL Server。其余的产品我不知道怎么样，咱们用的是Oracle BIEE。那么做为数据PD，是否须要了解BIEE可以提供的功能是哪些呢？看文档，请教别人，不能知其不可而为之。另外，也须要逐渐摸透BIEE的坏脾气，实现不了的功能，没法克服的难点等。这一点，也须要继续了解，继续学习。

　　二. 心得总结篇

　　下面，谈几点个人心得总结，或许还显得稚嫩，可是本身所得，要远远比看别人文章或者看书得来的深入，记录下来，以便于后续校验。有的先插个图，周末补充内容。

　　1. 数据产品的价值

　　2. 数据产品的用户

　　3. 数据产品架构

　　4. 数据产品风险

　　5. 数据产品VS业务系统

　　6. 数据产品项目流程

　　

　　7. 数据产品交付物

　　

　　来源：阿里巴巴PD