书名：写给数据产品经理新人的工作笔记
出版时间：2020年10月

本书以数据产品经理角色的定位和合作关系为切入点，站在整个数据体系的视角，从工作流程的角度剖析数据需求沟通和判断的过程、指标体系搭建的过程，同时介绍了部分通用工具，并详细剖析这些工具和对应的数据体系要解决的问题之间的关系。

点评：作者数据分析师转数据产品经理。本书凝聚了作者10年工作经验与思考。

摘录：

第1章

（一）数据分析师与数据产品经理的异同

相同点：知识体系相对接近
不同点：
①视角和专注对象不同。
“如果数据产品经理的研究对象是“数据产品”，那么除了产品本身的逻辑，还要关注用户需求，并且要在满足用户需求、产品自身逻辑、后续的延展性、落地的成本和可行性之间，找到一个各方都可以接受的方案，并详细地定义它。”
②研究方法和工具不同。
数据分析：多维拆解发现问题。“不细分，无洞察”
产品经理：抽象和创造。抽象出满足业务场景的产品框架。寻找平衡，忍受不完美。在一定范围内达成共识并接受。
③工作目标不同。

第2章

（二）数据产品经理与其他角色的关系

（1）从广义来看，下表中“数据业务”列描述的全集，可以被称为“数据产品”，最终产出的目标是数据化的运营决策体系；从狭义来看，数据产品则只包括基础应用产品中的工具类产品、可视化平台等带有前端页面的产品。

当其中一个角色缺失时相邻的角色就要去补充缺失的内容，但是需要输出的内容不会有什么太大变化。

（2）下图描述了一个以数据产品经理为中心的，与数据体系相关的输入/输出关系。

（3）随着细分程度越来越高，数据产品经理可以分为可视化平台产品经理、数仓建设产品经理、数据中台产品经理、策略产品经理、AI产品经理（这个比较特殊，有时候也不算数据产品经理）等。对数据展示效果有强需求的公司还会细分出专门的“数据可视化产品经理”。

（4）如果你认为“中台”只是一种精神，充分考虑高效、复用性，那似乎没什么问题。可是，多数时候**“高复用性”和“实现成本高”**几乎是同一个意思。越是简单的业务，定制化反而是最合适的。只有当多个业务并存，规模化到一定程度时，使用“**中台战略”**才是值得的。这部分成本可以被规模效应消化掉，即复用次数足够多，搭建中台的边际成本才可以递减到一个可以接受的水平。

第3章

（三）需求沟通
先学习对方领域的常识，再沟通；先回顾相关方案，再写PRD；阶段性复盘。
请相信我，当你坚持下来时，会收获非常大的惊喜。这样做不仅不是效率太低了，而恰恰是一条通往高手之路的最短路径：永远不要放弃思考和“温故知新”。

第4章

（四）指标体系

（1）指标体系存在4个阶段。
①客观描述：客观描述业务。
②发现问题：建立监控并从中发现问题，辅助运营。
③沉淀：记录指标变化和业务决策之间的关系。
④数据驱动：发现业务决策的规律，并实现一定程度的系统化和自动化决策。
（2）统一的指标定义和口径定义是一个基础，其中就包含：数据源的统一、公式的统一、限制条件的统一。
（3）宽表：字段较多的数据库表。和某一主题业务相关的所有维度信息、相关指标等都可以放进同一张宽表。
（4）宽表在指标体系和指标库的基础上搭建，可以对部分已有统一口径的内容提前做出处理，方便使用者做到使用较少的限制条件即可提取和定义一致的数据。

（5）报表主题划分原则：与业务结构一致。这里是业务结构，不是组织架构，一家公司的组织架构可以频繁调整，而业务结构，以及业务结构背后的商业模式则相对稳定。

（6）名词库

第六章

（六）可视化平台设计
PowerBI和 TableauBI的比较（详见原文）

对此类工具的选择，还是要结合自己的实际资源情况和技术特点而定。
如果你有足够的技术资源支撑数据源开发，去充分适应数据接口的要求，或者对统一数据出口有强需求，则可以选择使用Tableau。
如果你的团队的数据使用者是以数据分析师和数据运营为主，需要自己对数据源做一些处理，或者非常熟悉Excel，那么Power BI是一个好选择。

第9章

（九）数据平台基础架构

Flume像个情报员，负责把情报（日志）拿到手交给负责接头的信息员Kafka运送回来，处长HDFS负责接收这些数据，指挥NameNode给它们起好名字并贴上标签，交给档案馆Hbase存起来；这些数据还可以通过情报分析站MapReduce去做复杂的深度加工，加工好的结论也可以交给Hbase存起来。

而想要使用MapReduce需要通过工具Hive去实现。虽然Hbase是个超大的档案馆，MapReduce也能为这个超大的档案馆提供更多结果，但若是急需这些情报采取行动（需要实时输出这些数据），它们的效率就显得有点慢。

这时Kafka可以使用应急流程，把数据直接交给独立调查员Storm做实时分析，分析好了交给临时档案馆Redis存起来，领导（前端页面）可以去找Redis查阅结果。可惜的是，Storm和Redis虽然效率很高，却没有Hbase这个档案馆那么庞大和稳定，工资**（成本）又太高**，至今只能打一打下手，做一些补充工作。