2.1　角色之间的关系和他们面对的问题

2.1.1　数据业务结构和相关角色

在正式讨论数据角色之间的关系之前，我们先来明确数据角色通常有哪些，以及数据业务通常包含哪些模块。数据角色的作用就是按照一定的结构和顺序实现并持续迭代这些模块，即首先明确整个数据业务的建立需要哪些角色一起合作，以及完成什么样的产出。

表2-1-1中“数据业务”列粗略地展示了数据业务包含的模块。

这些模块里有些内容并不是必需的，具体组合方式需要根据不同的业务特征和公司发展阶段而定，其中很大比例可以由乙方公司提供技术方案和服务。我们暂且假定一个公司的数据业务产出目标是表2-1-1“数据业务”列的这些内容。从广义来看，表2-1-1“数据业务”列描述的全集，可以被称为“数据产品”，最终产出的目标是数据化的运营决策体系；从狭义来看，数据产品则只包括基础应用产品中的工具类产品、可视化平台等带有前端页面的产品。

通常一个数据项目需要由其中的多个模块组合形成。例如，一家网站要做一个流量平台产品，就需要网站采集方案、指标库、数据清洗方案、离线/实时数据存储和计算、API、可视化平台等多个模块组合才能得出目标产出，也就需要所有对相应模块有产出的角色介入项目。

表2-1-1中“数据目标”列表示在数据业务中承担的目标。

表2-1-1中右侧展示的是每个角色对各模块的关注情况。这些角色也不是完全必需的，比如一些公司还不到引入算法工程师的阶段，一些公司没有明确出数据运营的角色——各种情况都是正常的。角色也不等于人，在不同的阶段或不同类型的公司，同一个人很可能同时身负多个角色的职责，当然也会有多个人对应同一种角色的情况。除此之外，角色之间的具体沟通和合作方式还会受到组织架构的影响。

表2-1-1右侧的标记说明：颜色标记的部分，是对应角色关心的数据业务范围；“√”标记的是对应角色的产出；“*”标记的是“参与”。这些标记体现的是在我的经验里相对理想的状态——并不是规则，只是一种情况。不同类型、不同阶段的公司通常会面临的情况我们在第3章讨论，这里先基于这种情况讨论角色。

这里提到了几个角色。

（1）一线运营：把一线运营人员放入这张表格中，是因为数据体系的存在形式是以业务为起点且以业务为终点的闭环——数据来源于业务并最终应用于业务。数据对于他们来说是工作中重要的辅助项。从这个角度考虑，一线运营人员的数据解读能力和使用方式，在一定程度上决定了我们定义数据产品的方式。

（2）数据分析师：这里我们将数据分析师统一定义为把特定业务作为定量研究对象的角色。一些公司会独立出一个数据分析部门，一些公司会给每一个业务部门都设置相应的数据分析师角色。数据分析师再进行细分，通常包含关注具体业务的业务分析师，关注整体和外部宏观环境的战略分析师、竞品分析师，关注C端用户的用户分析师，关注某个产品的产品分析师，等等。在本书接下来的内容里只要提到“数据分析师”，都是指这个范畴。需要特指某个细分领域时会单独说明。

（3）数据技术人员：主要包含数据仓库技术（主要是指处理离线数据的传统ETL）、实时数据技术、数据后台技术（Hbase开发之类的）、数据测试，以及工具可视化平台的前端工程师等人员。

（4）算法工程师：技术发展到今天，算法工程师成了一个比较独立的存在，也逐渐成为数据产品经理的重要合作方，所以在这里也进行一定程度的说明。

（5）数据运营：很多组织，尤其是初创公司和传统行业的公司，并没有明确出数据运营的角色，通常由BI工程师或初级数据产品经理、初级数据分析师来执行这部分职能。这一角色的职能可以简单地认为是“处理临时需求和报表”。表面看来，这些人员“SQL写得好，生活没烦恼”，在这里必须强调的是，数据运营这一职能看似简单，却非常重要。

（6）数据产品经理：随着细分程度越来越高，数据产品经理可以分为可视化平台产品经理、数仓建设产品经理、数据中台产品经理、策略产品经理、AI产品经理（这个比较特殊，有时候也不算数据产品经理）等。对数据展示效果有强需求的公司还会细分出专门的“数据可视化产品经理”。具体细分的角色和各公司的业务状态强相关，所需要的技能侧重点也不同，我们在这里讨论的更多是一些通用于这些细分角色的方法。

除此之外，还有一个重要的角色，是项目经理。在什么情况下必须引入项目经理，项目经理在面对数据项目时会面临什么问题，怎么才能更好地和项目组协作，我们会在2.1.2节中进行初步的讨论。

2.1.2　角色之间的输入/输出

图2-1-1描述了一个以数据产品经理为中心的，与数据体系相关的输入/输出关系。左侧的5个角色是数据体系内的核心角色，右侧的角色属于非数据角色。横向来看，第一排是业务系统，第二排是产品经理和产品运营，第三排是技术系统。每一个“→”（箭头）都表示一个角色向另一个角色的输出，箭头上标注了具体的输出内容。当其中一个角色缺失时相邻的角色就要去补充缺失的内容，但是需要输出的内容不会有什么太大变化。

例如，一些团队会使用数据分析师团队来补充数据运营的角色，数据分析师本应该专注的报告类输出就自然会被削弱，加之这部分工作的工作量和价值总是被低估，这种补充便会带来一系列的“蝴蝶效应”。所以即使在资源匮乏阶段，单个人员需要承担多个角色，也不能否认某些必要的输出存在的意义。

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

我个人更喜欢把数据产品经理的目标定义为“用数据方法或产品方法解决数据相关角色的数据使用问题”，而不仅仅是提供某个工具。数据的方法和产品的方法都是数据产品的方法（本书惊现绕口令）。所谓数据的方法，是通过数据分析、量化定义等方式来帮助非数据角色解决工作中遇到的问题；而产品的方法，则更倾向于提供流程和工具。重要的一步，就是了解每个角色面对数据时的问题。这关系到数据产品经理在面对不同角色时的沟通方式和输出方式：这在产品方法论里经常被称作用户思维。