2.2 你的用户是谁：数据产品的“用户分析”
我们在这里用下面的结构来进行数据产品的“用户分析”。
·用户的特征：主要是他们对数据的认知程度、使用程度和使用方式。
·用户的问题：即他们在工作中面临的数据问题。
·对我们的输入：我们（数据产品经理）能从这类用户那里得到什么？
·我们的输出：我们（数据产品经理）能为他们做什么？
·沟通关注点：沟通过程中需要注意的问题。
2.2.1 数据角色相关用户
1．最重要的用户：数据分析师
（1）用户的特征
数据分析师是数据体系内最了解业务的人，同时也是业务体系内最懂数据的人——业务模型的数据化依赖他们对业务的理解。他们是数据产品的深度用户，且是学习门槛最低的用户。他们互为上下游，是天然的深度合作者。
（2）用户的问题
问题1：写报告3天，整理数据30天。
问题2：老板马上就要数据，报表里却没有。
问题3：数据定义解释成本高。
（3）对我们的输入
业务侧有一个好的数据分析师，对数据产品经理来说是非常幸福的事情。他们身上最重要的优势，就是他们和业务人员在一起，熟悉业务运营过程中的细节。基于这个特征，指标体系、报表体系的建立，离不开数据分析师的配合。包括好的可视化平台的搭建，数据分析师都是非常重要的合作方。
（4）我们的输出
更便捷的数据提取渠道和工具；建立起不断细化的报表体系；明确有效的指标库。
（5）沟通关注点
建立信息同步机制，关键的业务信息和针对数据产品的使用问题，很多都来自数据分析师。数据产品经理在平台视角发现的业务问题也需要与数据分析师随时同步。
2.最有趣的合作者：算法工程师
（1）用户的特征
这通常是一群非常聪明的人，也是有一些“偶像包袱”的人。大多数为数学和物理学相关专业。
（2）用户的问题
问题1：Database（数据库里的基础数据）不好用。
问题2：我是算数的，不是“算卦”的。
（3）对我们的输入
算法模型。
（4）我们的输出
提供框架更宽、更通用的数据采集方案，协助数据开发人员优化数据库。挖掘更多算法的业务应用场景。
（5）沟通关注点
尽量学习一些算法常识。
3.数据技术之数据开发：“相爱相杀”。
（1）用户的特征
他们不是可视化平台的“用户”，却是采集方案和系统信息数据的第一批“用户”，也是我们最紧密的战友。
（2）用户的问题
问题1：数据源的结构实现不了数据产品经理说的指标和维度。
问题2：一直在支撑临时项目，没有成就感。
（3）对我们的输入
不用多说，数据产品经理的产出落地80%以上都依赖数据开发者的数据逻辑。
（4）我们的输出
靠谱的PRD。数据PRD需要定义的内容与其他产品PRD差异较大，具体方式在第6章介绍。
（5）沟通关注点
彼此信任，随时同步信息，随时沟通，随时复盘。临时项目也要建立沉淀机制，获取最大价值。
4.数据运营：数据体系里的“蛋炒饭”——最简单也最困难
（1）用户的特征
重要的数据库供应商（Data Supplier），是数据仓库和基础工具的最高频使用者。说简单，是因为临时需求和报表需求的承接看起来只是跟需求方聊一聊，然后提供给需求方，是单纯的执行者。说困难，是因为这部分是很多人碰都不愿意碰的“脏活累活”，在多数公司里会由新人承接，导致这部分工作里包含的大量信息难以被提取和沉淀，这些人员也很难从工作中获得成就感。
（2）用户的问题
问题1：Database不好用。
问题2：永无止境的临时需求。
（3）对我们的输入
无论是临时需求的承接，还是对基础工具的可用性评价，数据运营角色对数据产品经理来说都是非常重要的输入。在我的经验里，当你养成定期深度复盘（Review）临时需求和报表需求的习惯时，得到的信息总能给你带来惊喜。与数据分析师输出数据报告相比，数据运营人员输出的临时需求和报表需求时效性更高，这部分工作是对一线运营变化最敏感、反应最迅速的。
（4）我们的输出
基础工具、逐步完善的指标库。
（5）沟通关注点
定期复盘需求，关注需求之间的关系；建立随时收集基础工具使用问题的渠道。
2.2.2 非数据角色相关用户
1.数据的最终受益者：一线运营人员
（1）用户的特征
对他们中的大多数人来说，数据只是辅助线。业务的特征和方法不同，一线运营人员的数据使用习惯和数据使用能力也会参差不齐。一些学习门槛过高的工具对一线运营人员确实非常不友好，如果你所在的是做To B（To Business，泛指企业）产品的乙方公司，那么面临的用户更多是甲方的一线运营人员。
（2）用户的问题
问题1：数据和我日常工作的关系是什么？数据需求怎么提？
问题2：我想要的数据真的那么难获取吗？我怎么判断这些数据的准确性？
问题3：数据产品经理是干什么的？（这个问题真实存在）
（3）对我们的输入
一线运营人员有着宝贵的实操经验，而数据产品经理的目标之一就是用数据去优化运营人员的工作流（数据赋能业务的一部分）。所以，业务的工作目标、方式、流程，都是对数据产品有效的输出。
（4）我们的输出
适用于一线运营人员的数据工具，适当降低数据使用门槛。必要时可以提供相应的培训。
（5）沟通关注点
沟通前，尽量提前理解业务模型，沟通过程需要避免过多地解释技术问题。需要使用较多的沟通技巧去定位真实需求和识别问题。尽量使用数据接口人机制，尤其在数据分析师角色缺失的场景下，需要和业务部门负责人达成共识，使用统一接口人，避免信息过于散碎。
2．项目经理：能深度理解数据业务的项目经理并不常见，通常需要磨合
项目经理不算数据产品的用户，我们只讨论两个问题。
（1）什么情况下需要主动引入项目经理？
除了多部门协作的大型项目，需要引入项目经理的通用答案大家都知道，是“跨团队沟通遇到困难的时候”，具体到数据项目，更多的场景是：需要和非数据角色深度合作时。非数据角色很难对数据的生产流程和产出难度进行直观的认知和评估，而项目管理能够有效地解决这个问题，前提是要和项目经理对一些内容达成共识。
（2）和项目经理重点共识什么？
①数据生产流程的大概环节，包括团队对数据源的依赖。
②不能使用基于功能列表的拆解方式管理项目（具体的需求管理方式在第4章介绍）。
③对于产品上线前不存在真实数据的项目（例如新的订单类型），在上线后需要约定校验期，在校验期产生的问题不按照故障处理。