争做行业中最懂数据的,数据中最懂行业的。
大家好！我是风在成长的风一
而风一最近也在看一本《写给数据产品经理新人的工作笔记》,看技术类的书籍有一个习惯,喜欢先通读一遍,然后再挑选个人觉得实用的做一个笔记及相应的总结，因此今天分享的就是有关数据产品经理这个角色相关的读书笔记、由于目前积累的此方面知识不多,不便于对整体的总结、只对知识点进行一个分享,欢迎大家讨论及指导；具体书籍分享内容、业可转至微信公众号进行查看：写给数据产品经理新人的工作读书笔记。
总是接收零散的信息、无法整合，似乎无法从中学到技能
疲于应对外部的压力而无法像其他类型的产品经理一样进行一些"设计"
第一章成为数据产品经理：角色创建和角色转变
数据产品和数据产品经理概念的广义说明数据产品是可以发挥数据价值去辅助用户更优地做决策的一种产品形式，本质是发挥数据价值的工具；数据产品经理，则是实现这一工具，用数据产品去满足特定数据使用需求的一个职业。
底层琐碎的工作、也会蕴含大量的信息；需要多去思考之间的关联。
对新人来说、专业基本功决定了你在这个游戏中的技能点初始值。代码基础、Excel/SQL/SPSS/R等工具的使用、沟通能力、产品思维、对技术的理解，则是要锻炼的方向；在实际的工作中，需要从各简单的任务中主动去积累、总结、归纳一些特征，识别看似不同的任务之间的关系。
沟通技巧和需求判断
1沟通技巧：技术出身、很容易在设计还没完成阶段，就一头陷入实现过程的细节里；有时需求还没聊完，需求分析和产品设计都还没做，满脑子已经是"这个SQL怎么写"了；甚至是直接告诉对方，这个实现不了。2需求判断：首先需求本身是否合理，其次是现状下是否可实现；对需求的判基于对业务的充分理解，因此挖掘业务的真正需求就成了数据产品最大的目标之
数据产品技能树
1产品设计：包含产品经理通用的方法和数据相关产品的设计方法；2统计学与数据分析：描述统计、相关和归因是数据分析的基础内容，通常可以应用于多数需求场景；3业务理解、技术理解、需求沟通4相关工具的使用、如：Excel、SQL、Axure、Tableau、Python等；5数据安全、风险控制等意识
第二章数据产品经理和其他角色关系
数据业务结构和相关角色
数据团队最重要的目标都是对内的量化服务——通过一系列的表格和数据的交叉、比较，来为管理者和一线运营角色提供量化的描述。
数据需要为企业解决什么问题1支撑数据产品而存在的服务和工具2数据本身面向业务逻辑上的输出
第三章需求沟通过程
数据需求类型
1按时效区分a、临时需求：通常是一次性的数据提取，常出现于汇报场景和探索性分析场景中；特征通常是逻辑简单明确、但要求快速响应；b、项目需求：项目需求的支撑周期一般为几天到几个月，常出现于类似专题活动、大促、改版、效果评估等场景；c、长期需求：主要包括运营报表、财务报表等情况，另外还有通用工具等功能类需求，这类数据通常是业务日常使用的。2按使用场景区分a、汇报：汇报可能会以临时需求的形态出现，这种情况需要注意对计算口径达成共识；b、运营效果监控：运营报表、关键指标监控等类型数据需求；c、探索性分析：在业务出现变化，或者长期稳定寻求突破时，才可能出现。
需求类型是需要判断的；尤其是由业务人员主动发起的需求，通过你的需求判断，也许会从一个临时需求变成一个报表需求，也可能会从一个需求拆解成多个需求，为的是更高效地帮助业务人员使用数据。
数据产品经理、面对数据需求的自我三连问？
1业务究竟遇到了什么问题需要解决？2数据怎么定义和描述这个问题？3这个问题是通过数据能直接解决的，还是数据能够提供一些佐证？
之所以要问这三个问题，而不是直接问需求方，是因为并不是每一个需求方都能把问题直接对应到数据模型；因此、需要在沟通的过程中，通过一系列的提问和需求文档的填写，来逐步回答上述三个问题；回答了这三个问题，再考虑执行：是否实现？怎么实现？在哪儿实现？
问题识别的三个层级
1原始需求完全描述了业务问题和业务目标，而且有明确的可实现的指标定义和维度定义2原始需求讲明白了业务问题和业务目标，但是数据定义缺失或者有偏差这类情况是多数情况，一个非数据角色无法明确数据定义是很正常的事情。将业务的问题和目标进行准确的量化，并给出明确定义，便是数据产品经理在需求沟通中需要做的。3原始需求中业务目标缺失
需求沟通中的提问技巧、SPIN
需求沉淀通过看似散碎又杂乱的需求，挖掘足够的信息，并建立一种机制，使业务需求充分沉淀进数据产品；
1信息互通、数据闭环：很多信息，数据使用过程、结果反馈等是需要通过建立合作关系，由合作方主动同步——这也是合作关系的建立；2需求管理方式：对不同类型的需求的响应周期和实现特征达成共识，流程、需求池和资源要公开透明；3项目合作方式：项目合作的特征通常是需要跨部门，因此数据产品经理需要从方案确定初期就介入项目，为的是保证评估项目效果使用的数据均可追踪。4不停地回顾1复盘过程的几个基本原则：a、明确复盘不是为了追责；b、尽量选择轻松愉快的环境和语言；c、每个人都要有均等的讲话机会，提出自己的问题；d、最好有一个项目经理角色帮助主持和引导；e、完整记录并对结论达成共识。2记录的主要内容：需求类型/需求描述/问题类型/问题描述/需求描述对象/相关核心指标/需求部门/需求方角色/首次记录日期/更新日期/当前解决方案
第四章指标体系搭建
什么是指标体系百度百科：指标体系指的是由若干个相互联系的统计指标所组成的有机体。评价指标体系是指由表征评价对象各方面特性及相互联系的多个指标，所构成的具有内在结构的有机整体。指标体系为公司战略和业务运营提供的是一种【方向感】：有指向、有诊断。
制定指标体系的基本方法
1确认描述的目标2选择描述这个目标的核心指标3除了描述"量"的指标，还要选择至少一个描述"质量"的指标4确保选择的指标具有可执行性：可追踪、可比较5指标之间具有一定的独立性：具有高相关性的指标，只选择一个即可
第六章不同的工具解决不同的问题
在数据治理的框架下，保证数据质量和数据安全是核心目标，而元数据是核心工具；某研究公司将元数据定义为：用于描述数据、内容、业务流程、服务、业务规则以及组织信息系统的支持政策，或为其提供上下文的信息。
常见的数据质量问题
1表内a、非法值：不符合正则定义、空值、NULL、0值、乱码等格式异常值；b、ID之间的关系异常：1对1对多、多对多等关联异常数据；c、出现维表不存在的值;d、数据不完整;e、字段之间的逻辑异常2表间a、ID生成规则不一致b、同一指标计算结果不一致3清洗a、不同规则下被清洗的数据记录比例异常或波动剧烈b、风控规则对应的分级及其影响日志的比例异常或波动剧烈
可视化是数据的表达方式，而不是目的，为了可视化而可视化，其实是很愚蠢的做法
第9章必须了解的数据技术基础知识
做好数据的搬运工，我们不是数据的创造者，用户和业务才是
数据同步的方法可以分为以下三种：
1API同步：准备一个约定好的接口，使用数据的一方直接调取这个API读取自己需要的内容。数据中台对外输出数据通常使用这种形态，因为每个开发好的接口都可以被高度复用；2文件传输：把数据源变成一个文本文档，上传到服务器，由需要这些数据的服务器去读取。或者在目标服务器上建一张相同结构的表，把源数据里的内容直接写入新表；3协议传输是指提前约定一个判断规则，对数据源系统的日志进行监控，击中判断规则时进行数据传输。这种方式主要用于数据源出现变更时更新接入的数据。
维度建模，从ODS到数据集市
1第一层：1地接入。完整地接入，不考虑可用性，这一层的目标仅仅是全；2第二层：加入一些规范，进行清洗。把不符合规则的、对后续分析没有意义的部分去掉。这一层的目标是干净；3第三层：拼接、修补。把分开的、细碎的多个事实表合并起来，变成一份相对完整的事实表。这一层的目标是打通、可用；4第四层：整合信息，形成大宽明细表。把描述特定的ID的维度信息和指标，合并进同一张表。这就是"主题宽表"。这一层对应用来说最关键，目标是统完备；5第五层：高聚合计算结果。目标是准确、应用。
对于数据技术人员来说，SQL就像蛋炒饭，最简单也是最困难
在生命的旅途中，即便我们不能成为一轮明月，也要努力成为一颗星星，在漫天中安静的发光、发亮。保持着内心的清宁与干净，温暖与明媚—风一
文章为作者独立观点，不代表股票交易接口观点
股民评论