数据产品读书笔记——数据产品经理和其他角色的关系

news2024/9/27 15:18:53

🍊上一节我们初步对数据产品经理的角色有了初步的了解，今天我们继续学习数据产品经理与其他角色之间的关系。上一期的内容如下👇:

链接: 数据产品读书笔记——认识数据产品经理

🍀当我们处在一个组织中，就一定会有与其他角色之间的关系问题，比如与其他角色的边界，合作方式等。

1. 数据业务中的角色

在介绍与各角色之间的关系之前，我们需要了解数据业务中有哪些角色：

一线运营同学（业务方）：一线运营人员放入数据业务，是因为数据体系的存在形式是以业务为起点且以业务为终点的闭环——数据来源于业务并最终应用于业务。数据对于他们来说是工作中重要的辅助项。从这个角度考虑，一线运营人员的数据解读能力和使用方式，在一定程度上决定了我们定义数据产品的方式。
数据分析师：这里我们将数据分析师统一定义为把特定业务作为定量研究对象的角色。一些公司会独立出一个数据分析部门，一些公司会给每一个业务部门都设置相应的数据分析师角色。数据分析师再进行细分，通常包含关注具体业务的业务分析师，关注整体和外部宏观环境的战略分析师、竞品分析师，关注C端用户的用户分析师，关注某个产品的产品分析师，等等。在本书接下来的内容里只要提到“数据分析师”，都是指这个范畴。需要特指某个细分领域时会单独说明。
数据技术人员：主要包含数据仓库技术（主要是指处理离线数据的传统ETL）、实时数据技术、数据后台技术（Hbase开发之类的）、数据测试，以及工具可视化平台的前端工程师等人员。
算法工程师：技术发展到今天，算法工程师成了一个比较独立的存在，也逐渐成为数据产品经理的重要合作方，所以在这里也进行一定程度的说明。
数据运营：很多组织，尤其是初创公司和传统行业的公司，并没有明确出数据运营的角色，通常由BI工程师或初级数据产品经理、初级数据分析师来执行这部分职能。这一角色的职能可以简单地认为是“处理临时需求和报表”。表面看来，这些人员“SQL写得好，生活没烦恼”，在这里必须强调的是，数据运营这一职能看似简单，却非常重要。
数据产品经理：随着细分程度越来越高，数据产品经理可以分为可视化平台产品经理、数仓建设产品经理、数据中台产品经理、策略产品经理、AI产品经理（这个比较特殊，有时候也不算数据产品经理）等。对数据展示效果有强需求的公司还会细分出专门的“数据可视化产品经理”。具体细分的角色和各公司的业务状态强相关，所需要的技能侧重点也不同，我们在这里讨论的更多是一些通用于这些细分角色的方法。
项目经理：在面对数据项目时会面临什么问题，怎么才能更好地和项目组协作。

各角色具体职能如下：
在这里插入图片描述

2. 各个角色之间的输入/输出

在这里插入图片描述
在上图中可以看出数据产品经理的输出以方案和工具为核心，这是符合“产品经理”的整体“人设”的。但需要注意的是，这些输出的背后，都是在“指标体系”的逻辑基础之上。上图表达的是以数据产品经理为核心的输入/输出关系，一个人（甚至一组人）或一个成熟的团队的职能可能只会覆盖一组输出；在一个团队创建初期，职能没有细分这么多，一个数据产品经理可能还要完成相邻角色的职能，并且只选择最重要的部分落地。所以在这里不得不再次强调：角色≠人。这里描述的是“数据产品经理”这个角色和各角色之间相互的输入/输出关系，而不是某个个人要同时完成这些工作。

数据产品：用数据方法或产品方法解决数据相关角色的数据使用问题

3. 数据产品的合作角色

数据分析师
特点：最了解业务、最懂数据。
缺点：取数困难、要数着急、数据定义解释成本高
输入：更便捷的数据提取渠道和工具；建立起不断细化的报表体系；明确有效的指标库。
算法工程师
特点：算法专业、数学能力强、预测
缺点：基础数据脏乱、预测效果不一定好
输入：提供框架更宽、更通用的数据采集方案，协助数据开发人员优化数据库。挖掘更多算法的业务应用场景
数据开发
特点：数据同步、数据的加工者
缺点：数据结构与产品要的有差异、临时需求多，无成就感
输入：专业的数据需求文档，理解业务方需要的数据
数据运营
特点：数据仓库和基础工具的最高频使用者
缺点：对数据源不了解、需求无止境
输入：基础工具、逐步完善的指标库，方便他们查数。
一线运营同学
特点：使用数据的能力参差不齐
缺点：数据需求不会提，数据如何获取，不了解数据产品的职责
输入：适用于一线运营人员的数据工具，适当降低数据使用门槛。必要时可以提供相应的培训。
项目经理
特点：对数据的生产流程和难度进行把控
缺点：缺少对业务的理解
输入：多沟通和交流，达成共识