最近一段时间角色发生了转变，从专业岗位升级了管理岗位，在负责自己产品线的同时兼顾管理 3 个数据产品组，工作范围更大，工作内容也带来不小挑战，变得更忙。年初很多文章只是写了个开头，没有继续，从 9 月开始持续性的保持更新，也算是对自己的一个鞭策。

本篇文章是 8 月初对外公开做的一次直播访谈，这里简单做个记录，给自己数据产品的从业经历做个小总结

Q1、分享一下从 BI 工程师到高级数据产品经理，这个过程的一些经历和经验吗？

职业发展：由技术视角变为产品视角。当有了足够多的技术知识积累以后，进入产品角色会有豁然开朗的感觉，由纵向深入，到横向发展，从【怎么做】→【为什么】的转变，能更多的理解到商业层面的策略和经营思考，对行业和领域有了更加全面的认识

个人规划：工程师角色如果要发展，会对编码要求很高，要对架构设计能力要求很高，可以根据个人兴趣决定是否转，如果偏向于业务发展，就可以转型成为数据分析师，或者数据产品。

因为之前在咨询公司担任的是 BI 工程师职位，后续逐渐转数据产品经理岗位。从刚开始的初级、中级到现在的资深数据产品经理，有两个方面可以聊一下，首先从职业发展来说，因为我原来从工程师的视角转化到了一个产品视角，实际上有了足够多了技术积累之后，转变了这个产品视角，会有一种豁然开朗的感觉。

之前做技术是做一个一个的点，做了足够的点后，恰好又转成产品经理，就会经历由纵向深入到横向的这样一个发展。可以了解到每一个需求它是怎么做的，这个需求为什么做了这样一个转变，能更多的带来一种商业层面的策略，经营层面的一些思考，对这个行业和领域有一些更加全面的认识。

第二个就是个人的规划。因本身个人的规划，对于工程师角色，要发展，对编码要求是比较高的，而且对设计的能力也会要求比较高。如果你对这种专业的技术领域的确是有比较高的追求，可以继续选择在编码层面去做深入探究，走专家路线；如果你是偏向于这个业务发展路线，你就可以转型成为这个数据分析师或者说产品等。

Q2.从 BI 工程师到数据产品经理一个转变过程中，当时有遇到什么就困难点吗？

第一个困难点就是工作不好找，之前没有产品经历和分析经验，开始可能不是分析师，不是产品经理，别人会质疑你，过往的经历是不是和目前公司所需要的这个岗位是匹配的，这是一个点，就是可能工作不太好找，那怎么去破局呢？

实际上你要对你过往的经历去做一些优化提炼，以及对目标岗位契合经历的丰富。偏向于产品也好，偏向于分析也好，但是如果你去求职分析，你就不能写工程师的一些资源。你要向你的目标岗位去做相应的经历的一些包装，但包装不是欺骗，而且突出你在数据业务上的专业。

这第二个困难点是思维的转变。刚开始从这个工程师转到产品经理，我当时印象特别深刻，我在成为第一个产品经理岗位过试用期答辩的时候，我的导师就提给我一个非常好以至于现在都记得的建议：工程师思维的人，比较会关注这个需求怎么去做，但是可能不太会考虑这个需求，为什么会去做。也就是说在你收到技术思维的框架思想之后，会限制你的产品设计的能力。在你设计的时候你会想到这个功能如果说开发设计不了，没时间怎么办？我都做不了怎么办？可能有一个好的 idea 在你这里，因为你这样的一个思考可能就丧失了推进的一个能力。

我之前也是这样，所以说不能用工程师的思维去思考产品，也就是说你要从“怎么去做”转变为“为什么去做”，这是第二个困难的点。

第三个困难的点就是对管理能力要有一定的要求，你可能到时候会带领着你的开发团队、测试团队以及对于上级做一些汇报。对大局观、对结果有一定的要求，不能说是我干完这个活儿就完了。产品经理的工作不是这样，干完这个活儿要考虑第一阶段输出什么，第二阶段输出什么，第三阶段持续迭代是什么。

Q3、一个企业从数据储存到数据应用，这个过程涉及的工作内容和角色有哪些，可以给我们分享一下吗？

需求分析阶段（确认最终业务想要做什么，达成什么目标）：数据分析师，数据产品经理，业务需求人员

数据开发阶段（确认数据模型的形态，最终输出表的关系）：数据开发工程师（大数据开发工程师负责数据平台搭建、数据仓库工程师负责数据表模型搭建、ETL 工程师数据任务调度、BI 工程师负责数据应用报表）

数据测试阶段（保证数据质量，数据标准 &规范）：数据测试工程师，数据开发工程师

数据应用阶段（应用什么场景，提高多少收益）：数据产品经理，数据分析师

一般会分为以下这样一个过程。

首先是数据需求分析。数据需求过来之后，会经历到需求分析阶段。那这个时候我们要干的主要事情是确认最终业务想要什么。也就是说我们最终的目标是要达成什么样的成果。这里就相应的一些角色可能就会有业务部门的数据分析师，或者说中后台的一些数据分析师，他们基于业务视角提出一些业务目标，然后在数据上做的一些支持工作，可能还包含了数据产品经理以及业务部门的一些运营人员，这是第一个阶段。

第二个阶段落地实施、数据开发阶段。这里我们要确认的一个最终目标，是说你要确认最终开发出来的这个数据模型是怎么样的一种形态，你最终输出各种各样的表是怎么样一种关系，时效性是怎么样，是实时性的还是离线的。我们在招聘看大数据开发工程师，有数据仓库工程师、ETL 工程师、BI 工程师等。当然他们统称一个 title，就叫数据开发工程师。

数据开发工程师。又分为两个方向，方向 1 数据平台，负责数据平台搭建，基础环境搭建，做好相关的数据容器以及计算数据的引擎；方向 2 数据应用，负责数据任务的调度，以及整个数据任务当中的清洗规则，数据仓库中数据表模型的一些搭建，其中侧重做报表的会叫 BI 工程师，侧重做宽表和数据清洗数据质量的叫、ETL 工程师，侧重做数据模型的叫数据仓库工程师

第三个阶段就是到数据测试阶段。数据已经开发好了，我要把它用起来，数据就跟语言一样，如果你语言不交流，是产生不了价值的。数据不使用它也是产生不了价值的。这里的目标是保证数据质量，同时又满足一定的规范和标准，是符合数据仓库设计模型规范的。那这里的角色就会有专职的数据测试工程师去做。但是一般情况下，大家可能不会看到有这样的一种专门数据测试工程师的岗位放出来招聘，他们一般都会叫测试工程师-大数据方向。

最后一个阶段也最重要的阶段属于产品经理该出场了，就是这个数据要运用到什么场景，能够提高多少收益，能降低多少损失，而这个损失可能包含了我降低多少成本，或者说降低一些、提高一些效率和这样的一个成本。这里就会有数据产品经理和数据分析师把最终报告的数据应用到具体的场景当中。

这是一共 4 个阶段。

Q4、这四个流程当中，在实际工作开展中，遇到的难点可以给我们分享一下吗？

就在具体工作实际场景当中，其实难点还是比较个性化的。但是可以有一些通用的点可以跟大家分享一下。我们很常见的一个阶段是在第一个阶段，数据需求分析阶段很有一个比较明显的特点，就是业务方很可能也不知道他们自己想要什么，比如是说需求可能会变，导致的一个问题是我们这个团队的目标感和使命感不会很强。

我们不知道我们干这个事情最终有什么样的目的，这是第一个造成的后果。第二个后果就是我们干着干着，忽然需求变了，忽然需求增加了，导致我们项目周期的可持续性、交付迭代的周期可能就会被打乱。

比如说：说好了我们这周五就要上线，忽然新增了或者改版了，导致我们可能中午就上不了线了，就会有这样一种风险，这是一个。

关于解决方案，首先第一个关于需求不明确这一块就是需要我们数据产品经理要主动去了解业务，这也就是我一直提的，数据业务不分家，运营策略两手抓，数据和业务是不能分开的。

你要了解业务，要去主动去帮你业务梳理需求。如果业务不知道他想要什么，那你就要告诉业务，我知道你想要什么，我能帮助到你，这是第一个。我们要主动去了解业务的需求。

第二个刚才提到的问题，就是关于需求迭代不明确这个方式就是项目管理的工作。比如说我们每天早上都要开早会和晨会，有什么问题会及时更新。虽然有各种各样的问题也没关系，但我们及时暴露，及时解决，不要走最后一天上线的之后才暴露问题。这是在第一个阶段。

第二个阶段在数据开发阶段这一块可能问题就相对而言比较个性化了。这里就是比如说我们有一些数据不怎么好取等，这里就是具体的细节可能不够通用，就直接略过了。

第三个在数据测试阶段，这里有一个比较通用的点，就是说对于测试人员，首先他不是专职，一般情况下，公司不会给你专门配一个专职的数据测试，所以说对于数据人才的储备，以及我们对于整个测试人员，对于大数据这一块的一个技术上的一个理解，可能还需要持续性的培养和数据意识的灌输。

不能说测试是属于测试的，一直就跟着测试走，那么就不归大数据这边管，实际上如果你要决定开始在大数据这边配一个测试，你需要全权进入大数据的工作的。

第四个就是应用阶段。应用阶段也不能算难点，就是待优化的一个点，一般人可能不太会想起来，就是在数据应用阶段之后，相关的数据收集工作，自己本身作为数据产品经理，自己的产品就都应该有数据意识，比如埋点，以及相关的数据标注。

还有，有很多数据需求可能支持完一版之后就会属于临时性的工作，不会有长远的一些规划。但实际上对于一个有价值的数据需求，它一定是不断持续迭代的。不是从 0 到 1 就是数据产品，它的价值在于从 1 到 100，100 到 1000 。

Q5、谈谈您对数据产品概念的理解？

在面试的时候也去问数据产品的一些候选人，很多人他们都对这个岗位比较感兴趣，但是他们很多人不知道这个岗位在做什么，以及他们对这个岗位的理解并不是很明确。

我们在书上肯定会看到关于名词上面的理解。比如说数据产品经理，首先数据是一个形容词，核心还是产品经理。那这样的理解方式是没有问题的，但是我希望提供另外一种视角，这个视角可能会帮助你对于在数据产品经理的这个岗位，对于整个数据部门核心定位有一个非常清晰的认知，就是我们可以先假设这个团队他们没有数据产品经理，那么这个时候业务需求一个一个的进来，他都是一个一个的点。

这些点碎片化、零散化，不确定性非常高。这个时候你如果直接让开发来做，可能就是点对点的来做这个，来一个做一个，再来一个做一个，过了一个月，领导问你，你的数据部门产生了什么价值？好，你说我支撑了多少多少需求，那这样的汇报肯定这个负责人十有八九过段时间就那被调岗，或者说可能要被离任。

因为你一直做的是支撑性的工作，你没有做主导性的工作的价值感，使命感并不大。那这个时候就需要有数据产品经理过来。因为数据需求是一个一个的点，这些点碎片化和离散化，不确定性会去很高，需要团队里面有这样一个人把这样一个一个的点串起来，抽象成为一些数据体系的一些需求，沉淀成一些数据资产。

这个角色可能会是数据部的负责人，也有可能是数据产品经理。但一般情况下足够强的公司，或者说有这种产品意识的公司，他都会让数据产品经理去做。举个例子来说，他能做什么呢？我把这一个一个点给串联起来，抽象成为体系，比如说会有数据指标体系设计，比如说会有数据仓库模型的设计，比如说会有关乎用户画像的事情等等这一系列的这种体系化的需求，一旦建设起来之后，不仅可以将我们之前离散的需求，零散的需求串起来，而且还可以应对以后未来日常的一些碎片化的需求问题，更重要的是，可以将我们数据部门的价值放大，成体系化的解决业务的问题，点→体。