《数据分析师转数据产品,面试问什么？.docx》由会员分享，可在线阅读，更多相关《数据分析师转数据产品,面试问什么？.docx（8页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、据分析师转嵋产品，面试问什么？找我沟通过的，想转行做数据产品经理的同学中，数据分析师是占比 很高的一个群体，数量上仅次于C端产品经理。相比其他职位，数据分析师在基础知识和能力方面上匕较有优势，与数据 产品经理的工作内容重合度很高，所以还是比较容易转到数据产品经理 领域的。无非呢，毕竟数据分析师与数据产品经理的工作性质还是有点区别的， 所以也才有了这次沟通的内容。来沟通的同学，简单说一下他的工作背景：目前在已在初创型公司工作, 公司的主营业务是一个SaaS平台，而这位同学做的是数据分析工作， 之前还做过数据运营和部份增长运营工作；他想咨询的问题，主要是目 前想转数据产品经理，但是之前没有相关经验
2、，所以想咨询一下有什么 学习建议。一、从数据分析师到数据产品经理从数据分析师转数据产品经理，我觉得有三个方面需要重点关注：01固然是产品经理的工作流程。每一个职业都有自己的工作方法论和基本 流程，产品经理固然也有自己的独到之处。经过这么多年的发展，产品经理在用户管理、需求管理、设计管理、项 目管理等方面，形成为了一套比较完整的工作体系；这对于数据分析师 来说是最欠缺的部份，毕竟数据产品经理也是产品经理。其中几个比较重要的点，包括：.产品需求文档的编写（Product Requirement Document , PRD ）;.工具软件和产品交互原型设计，比如画原型用的Axure（跨平台, 包括
3、 Windows 和 macOS ）和 Sketch （仅包括 macOS ）;研发项目管理，比如需求评审，项目排期，各阶段测试，线上验 收等；.产品上线后的产品运营，比如采集用户反馈，竞品调研，产品版 本迭代等；02是产品经理与分析师的工作目标的差异。数据产品经理虽然设计的是分 析工具、提供的是分析服务，但是更关注寻觅数据分析方法的共性，再 把共性做成功能。举个例子，对于数据分析师来说，更关注如何完成一份数据分析。其中 涉及到对于业务逻辑的理解、数据处理能力、分析总结能力等多方面能 力；对于经验丰富的数据分析师，会逐渐形成自己的SOP （ StandardOperating Process
4、,标准作业流程）;通过SOP来规范团队的数据 分析过程，并实现控制数据分析成果的质量。而对于数据产品经理，这方面的要求会稍微高一些；比如用户分析、行 为分析、留存分析、转化分析，数据产品经理不仅要知道这些分析过 程具体是怎么做的，还要具备总结和提炼的能力，找到这些分析方法中 的共性和个性。其中，共性的部份会变成技术上的一个通用服务，而个性化的部份就 要根据具体要求分别定制了；最终，再把通用和定制的部份组合起来, 就变成为了分析工 这个过程说起来简单，但是也有一些典型错误，包括:1 ）抽象不足 抽象不足导致的结果，就是我们设计的数据产品不是覆盖一类分析场 景，而是只能覆盖一个分析场景。当分析需求
5、变化时，我们又要去设计新的功能模块来满足需求；因此， 当这个问题发生时，最明显的表现就是整个研发团队的工作彻底没有节 奏，彻底是问题驱动”的到处救火而已。例如：在用户分析、行为分析等典型分析场景中，都有圈选人群的需要;如果不将这部份抽出来做成通用服务，那末每一个模块都需要单独设计人群的计算，存储等功能；不仅浪费研发资源，也会让系统维护工作2 ）抽象过度 研发出来的数据产品运营根本不会用，往往是对分析过程的过度抽象导 致的；过度抽象之后，分析产品让实际用户感到有距离感，无法与自己 的业务场景和分析思路对应起来。例如：在圈选人群的功能中，如果我们没有使用用户标签、用户 属性”这样容易理解的业务概念
6、，而是使用了 数据君、数据字段 这些技术词汇，对于运营和业务同学就很难用的明白了。3 ）发展不均衡理想是夸姣的，但现实是残酷的；抽离通用服务的本意是减少重复工作、 降低维护成本、降低系统复杂度旦是,要想让通用服务立得起、扛 得住、跑得稳，需要投入更多人力、礼聘经验更丰富的工程师，进行 充分地积累、总结和沉淀才干实现；不少企业或者团队，意识有了、系 统也拆出来了，却发现现有的资源和能力沉淀根本不足以对付多变的 环境。例如：还用全选人群的例子，本来是想把人群圈选作为一种通用服务， 但是独立出来之后才发现，圈人的条件有人口统计属性、业务属性、算 法打标、外耀酶等不少种；凭着原来的团队人力和能力储备，
7、根本 无法一下支撑这么多类型。那末问题来了，那些正在进行中的业务，是要切换到通用服务呢？还是 继续用自己的呢？从2022年开始中台的概念很火，其实中台的设计理念，也是上面提到 的抽离共性的理念；因此，在实施中台的过程中，也时常会遇到上面提 到的那些问题。比如抽象不足，那末必然有些业务场景是不能覆盖的，需要中台团队和 业务团队一同快速迭代；再比如，有些团队在实施中台之前发展较快， 基础水平已经超过其他业务，那末中台的技术水平就得与之看齐，不然 就要这部份业务做出牺牲。最后再强调一下第二点的核心：抽离通用是为了减少重复工作、降低维 护成本、降低系统复杂度；因此，数据产品经理的工作，需要十分关注短期
8、/长期价值，以及投入产出比ROIo03是了解一下现有的各种数据产品怎么设计，也就是需要了解竞品；这一 点是数据产品经理的必修课，固然也是数据分析转数据产品的必修课； 相比前面的第二点，第三点的内容更具体。比如，以下几方面是数据产品时常遇到的艰难：1 ）如何拆解数据分析的拆解？每种常见的数据分析，都有自己的标准步骤。经验丰富的数据分析师会 把自己工作整理为SOP ,而数据产品经理则会根据按照这样的标准步骤 设计产品功能；在这一点上，数据分析是与产品经理有些相似。例如，一个标准的用户画像分析，就包括人群圈选、确定分析维度、数 据准备、数据看板/分析报告制作等基本步骤；如果做成系统功能，那 么可能在
9、数据看板上在增加一些其他功能，比如人群下钻。2 ）如何匡助用户找到自己想要的数据？ 这个问题看似简单，其实还挺复杂；数据分析师在做分析的时候，都会 自己做麴E探查，了解要用到的数据库、数据表和字段等；之后再使用 数据的时候，就能得心应手了 旦是，数据产品的用户可不是都具备这 样的习惯和能力，因此，在数据产品中，通常都要设计辅助用户选择数 据的工具。如名称搜索、展示数据表和字段的元数据、提供样例数据等等；这些功 能的设计，对于数据分析师角色是不需要考虑的，但对于数据产品经理 来说是需要重点考虑的东西。3 ）如何平衡大数据量与交互体验？ 数据产品需要处理和展示的数据量越来越大，日常处理的数据量动辄
10、上 TB ,而产品页面上的各种表格、列表、菜单中的内容也越来越多；如何 让用户更方便地找到自己想要的东西变得越来越难，如何在页面上增加 导航、分组、搜索这些基本功能，就是数据产品经理在设计分析工具的 时候需要考虑的问题了。最常见的PV/UV数据来说，一个公司的核心App ,至少几十个页面；如果还有各种暂时的活动页面，加起来轻松破百。那末在众多的页面当 中，如何让用户快速找到自己想要的页面呢？这涉及到从页面管理、数 据采集管理和分析工具交互三个方面的配合。类似这些问题，我们不必自己从头思量解决方案，可以先参考市面上已 有的数据产品；无非，更多的数据产品是不对外的，只服务公司内部， 像神策分析、G
11、rowinglO.友盟这种工具平台,以及发布在阿里云、腾 讯云等公有云平台上的产品只占少数。因此，学习和参考的过程确实会花费一些时间。除了直接参考公开产品 提供的文档和材料，还可以多参加一些行业峰会。二、其他建议前面通过比较数据分析师和数据产品经理，给出了一些转行需要重点关 注和补充的关键点。除了上面的几条，此外我建议，就是：如果能在公司内部转岗,就尽量 先在公司内部转。直接通过跳槽转的风险更大。这种风险来自于几方面：第一，每家公司内的具体情况都不一样，而且差异很大；前面总结的几 条问题，在各家公司的表现都不一样；因此，即使你在上一家公司做得 非常出色，换到下一家公司也未必做得好；所以，相比之
12、下，还是在熟 悉的环境中挑战新的角色胜算更大。第二，针对中小型互联网公司，可能还没有专门设立数据产品经理 职位这种Title ,这也是想要跳槽转行的常见理由旦能否成功转行， 最核心的变化还是工作内容；因此，能够最快上手做一些数据产品经理 的工作，这才是转行的最佳路径；更何况，数据分析本身与数据产品经 理的跨度已经不大了，应该多关注实际在做的事情。第三，并非到了所谓的大厂或者垂直领域的领头公司，才有机会 处理数据问题；大厂对于常见的数据问题，可能已经有很成熟的解 决方案了，几乎没有从0到1的机会，这就导致能获得的实战经验会很 有限。此外，大厂的数据问题可能更复杂，而小厂的问题则更聚焦，反而更适
13、合刚转行的同学上手；固然，如果能力足够强，作为数据分析师的经验 也足够丰富了，那末挑战一下大厂的复杂状况顺便拿一下大厂的品牌背 书，也是不错的；这个门坎，普通4-5年经验比较合适。三、意外的突破在交流的最后，这位同学蓦地想到自己的公司最近注册用户比较多，而 他们做的又是toB的业务，所有销售团队对用户试用产品的过程有大量 数据分析需求；所以想到了，可以在今年年底的最后几个月，做一个用 户画像和RFM的数据产品，交给公司的销售团队使用。并以此来作为 自己转换角色的“跳板。应该说，这位同学还是很幸运的，这是一个非常好又非常难得的切入点;因为数据平台本来就是很基础性的平台，不管大厂还是小厂，一旦基础 平台稳定下来，就极少再做重大调整，更不要说推翻重来了，所以遇到 针对某个团队建设一个新平台的机会真的不多。