1.2 数据产品经理的日常工作

1.2.1 一切从业务出发

大概在10年前，产品经理这个职位就已经出现了，随着互联网的不断发展，产品经理越来越热，更是喊出了“人人都是产品经理”的口号，已经成为各个互联网公司的标配。随着2007年乔布斯发布第一款iPhone，以及iPhone的大卖，很多互联网公司的CEO开始号称自己是公司的第一产品经理。然而，数据产品经理却是近几年随着大数据的爆发才出现的，很多公司越发意识到数据的重要性。于是，数据产品经理应运而生。产品经理随着行业发展逐渐被细分，数据产品经理成为产品经理的一个分支。

小王作为一名互联网公司的数据产品经理，为我们展现了数据产品经理的日常工作：

早上9∶15到公司，打开Tower（任务管理工具，有些公司也会用JIRA等），查看自己本周的需求计划，昨天研发工程师更新了哪些任务，哪些任务已经完成需要关闭，有没有延迟的任务，会不会影响项目进度，今天应该重点完成哪些需求任务，并把今天要重点完成的需求做优先级排序。

10∶00，召集各部门用户，组织召开需求收集会，收集各个用户对数据产品的需求，整理汇总，准备进行下一版本迭代。

11∶00，完成会议用户访谈，整理需求列表和会议纪要，明确会议结论和接下来要做的事情，整理邮件发送给大家。

11∶30，与老板一起讨论需求情况，并评估需求优先级。

12∶00，讨论完需求后发现已经到吃饭的时间了，已经饿得肚子咕咕叫了，于是匆匆去吃午饭。

13∶30，根据需求优先级，整理下一版本的需求文档，明确产品功能和需求细节，以便尽快定稿。

14∶00，做原型设计，设计功能页面及交互情况，以便数据产品研发工程师更容易理解需求。

14∶30，跟进另一个产品项目，协调测试和UI资源，促使研发工程师高质量完成相关功能，确保项目能够按照预期顺利交付。

15∶00，被老板叫过去，老板指出上线的产品需要修改的地方，并希望能尽快给出迭代方案和原型图。

15∶30，预订会议室，组织大数据分析平台产品PRD需求评审会，与各个研发工程师、测试工程师、设计师讨论需求，明确需求需要修改的地方，会后完善需求。

16∶30，写会议纪要，落实会后要做的事项，然后确认后发送给大家。

17∶00，看数据产品的用户使用数据情况，分析各个功能的用户转化和留存情况，汇总迭代方向。

18∶00，去吃晚饭，边吃晚饭边思考项目遇到的问题。

19∶00，吃完饭回到公司，想起老板交代的需求还没完成，于是整理老板要求的方案，检查没有问题之后发给老板，老板很快对方案给予了一些建议和答复。

20∶00，打开印象笔记，整理汇总一天的工作日报，找出影响项目进度的问题，寻求解决办法，然后收拾东西，打卡下班。

就这样，小王结束了数据产品经理的一天。当然，有时候会因为项目上线等原因下班更晚，用很多产品经理同行经常说的话来总结这一天，是忙得“飞”起来的一天，然而，又是充实的一天，特别是在晚上复盘整理问题的时候，感觉每一天的收获都很大。

1.2.2 离不开的产品原型与需求文档

产品经理的日常工作离不开产品原型与需求文档，光靠一张嘴就能够跟研发工程师讲清楚实在是不现实的，而产品需求基本上首先都由资深产品经理或者老板确定大方向和要做的功能，然后由数据产品经理新人落地产品原型和需求文档。以下是数据产品经理新人小王的需求文档与产品原型的日常工作。

老板：小王，为了配合业务实现×××，我们要做一个×××功能，你梳理一下，把这个功能再细化和落地吧。

小王：好的，这个功能是不是要具备A、B、C这些功能啊？

老板：是的，最好还要有一个D功能，这样用户就可以更方便地使用产品了。

小王：好的，我先梳理一个需求文档（PRD）出来。

老板：写文档时别忘了5W2H的应用哦。

小王：必须的。

5W2H会在1.3节“数据产品经理的思维方式”中介绍，对于定义问题非常有帮助，也有助于弥补考虑问题的疏漏。需求文档主要是围绕5W2H写的，只要明确了这些问题，就是一个不错的需求文档。

小王：老板，需求文档我写完了，用邮件发给你了，请你看一下。

老板：好的，A这个功能有些不太合理，我们的业务场景是×××，所以最好能够……这样来做。

小王：我当时这样写的目的是……我觉得……嗯，有些功能我确实考虑得不够全面，我再完善一下。

老板：好的，完善一下后我们进行需求评审。

于是，小王就约研发工程师一起进行需求评审。在会议上，小王开始眉飞色舞地给研发工程师讲需求背景、需求意见、功能，研发工程师开始在技术上对小王设计的功能进行一一点评。

研发工程师甲：A这个功能在前端实现的成本太高了，当前选型的控件不支持，如果要做就要改源码，恐怕赶不上上线时间啊！

研发工程师乙：B这个功能是可以实现的，可是性能不能保证，查询这么大的数据量，接口的访问速度必然会受到影响。

研发工程师七嘴八舌地说了一堆，把小王弄糊涂了，对于一个没有技术背景的产品新人来说，理解技术细节确实有难度，还好小王的老板在会上对研发人员提出的问题一一解决，能换方案的换方案，务必保证的需求让研发人员做详细的技术调研，总算把这个需求评审通过了。

会议开完后，老板对小王说：“写一个会议纪要吧，没有结论和行动事项的会议都是浪费大家时间的。”

于是，小王就对会议进行总结，明确了哪些功能要做，哪些功能需要修改方案，哪些技术细节需要再进一步调研，接下来每个人应该做什么，下次会议应该交付什么结果。

小王刚把会议纪要发出去，老板就走过来对小王说：“根据需求文档画一下产品原型吧。”

小王：产品原型？这怎么做？

老板：Axure和墨刀都可以做需求文档，要以页面的形式让研发工程师知道系统的功能和如何操作交互，更易于研发工程师开发系统，减少沟通成本和降低理解误差。来，我给你演示一下应该怎样画。

小王看完老板演示后，不由自主地说：“哇，原来还有这种东西，做出来的简直就和系统的原型差不多嘛，我好好研究研究。”

老板：做数据产品经理，除了要懂一些数据分析的知识之外，需求文档和产品原型也是离不了的，这两个方面也是数据产品经理经常要面对的。

小王赞同地点了点头，回到工位继续自己的原型设计工作。

1.2.3 与研发工程师做朋友

数据产品经理大约有50%左右的时间都在和研发工程师打交道，无论是前端研发工程师、后端研发工程师，还是数据仓库研发工程师，需要组织一切可以组织的研发力量，让项目尽快交付满意的产品。当在开发过程中遇到方案里一些细节不明确的地方时，数据产品经理要主动与研发工程师一起解决这些问题。

前端研发工程师小张：这个数据下钻功能圈选数据以后应该怎么操作呢？下钻的维度应该从哪里来啊？

数据产品经理小王：下钻的维度应该以在创建数据源时选择的那些指标作为维度，直接读取配置表中的这些维度应该就行。

小张：我们再找后端研发工程师对一下吧，看他以什么方式返回给我比较合适。

小王：好的。

于是，小王又跑到后端研发工程师小李那里，向他讲明了情况，三个人找了一个小会议室，在小黑板上开始画了起来。

小王：如果要实现数据下钻的功能，那么现在需要从小李那儿返回维度给前端，数据源配置的时候保存了维度选项，应该返回这些维度的数据比较合适。

小李：我看了一下，确实有这些字段标识，用户在前端触发选择维度的时候我来返回这些维度的数据吧。

小张：嗯，我拿到你传给我的值之后会在前端进行展现，让用户选择。可是用户可以无限下钻吗？一个维度被选择之后还会再次出现吗？

小王：一个维度应该只会被选择一次，对于同样的数据，你选择以这个维度来看它，那么相当于你已经对这个数据做过一次操作了，以后也就不需要再选择这个维度了，太多的选项反而容易让用户比较迷惑。

小张：那就是做减法是吧？后端是不是需要再记录一下？

小李：嗯，对于已经选择下钻的维度我这边会做一个标记，给你的接口都是没有选择的维度数据。

小张：好的，就这么愉快地决定了。

小王和前后端研发同事把事情梳理清楚后，刚坐到工位上，这时候，数据仓库研发工程师小孙又跑过来找小王。

小孙：小王，数仓项目的工作流依赖检测好像有些问题，在这种情况下，我捕获不到系统的这个状态。所以这个功能实现起来有点问题。

小王：这个功能在数仓工作流这个系统中很重要，如果获取不到，我们就很难实现这个工作流，有没有其他方式能拿到呢？

小孙：以当前的方式确实拿不到，我回去再查一下看看有没有其他方式吧。

小王：好的，这个功能确实很重要，如果实现不了，那么项目只能延误，这个功能没有替代方案？

小孙：好吧，我再调研看看。

大约过了两个小时，小孙跑过来对小王说，我查资料找到了一个可实现的方案，但是可能要多花一天的时间。

小王：那我们一起找老板，让他评估一下吧。

于是，小王和小孙又来到了老板这里，把情况都说了一下，让老板做决定。

老板：小王的判断是正确的，这个功能是核心点，小孙可以尝试用后一种方式实现，多花费一天的时间来实现也在工程可接受的时间范围内，你就尽快实现这个功能吧，小王一会儿发邮件告知大家项目风险和延误原因。

小王：好的，我回去就整理邮件。

小王一天的时间就这样在和研发工程师的讨论中度过了。

1.2.4 多和用户聊聊

在数据产品上线以后，数据产品的目标用户主要是公司里各个部门的同事。数据产品有给数据分析师用的，有给各个业务线的同事用的，所以，要听一听用户的声音，基于用户需求规划下一个版本的迭代路径。

数据分析师小张：我能吐槽一下×××这个功能吗？这个功能简直太难用了，操作起来极不方便，刷新之后还不能保存之前的配置，这样导致我每次都要重新配置。

小王：嗯，这个功能确实操作不太方便，我把它列入后期的优化列表中吧，我再重新设计一下，然后让大家一起再评估。

数据分析师小张：好的，辛苦了。

于是，小王又针对用户的吐槽重新设计了这个功能的交互及方案，并拿给技术团队评估，技术团队觉得可以实现，最后组织了数据分析师一起评估，大家都觉得这个优化可以提高数据分析的效率，于是小王把这个优化加进了产品排期中。

数据分析师小钱：我在使用×××这个功能的时候遇到了Bug（漏洞或者缺陷），点击保存按钮没有反应，能帮我看一下吗？

小王：好的，我看一下。你能描述一下你具体是怎么操作的吗？

数据分析师小钱：首先，把A、B、C、D这些指标拖到指标栏，然后把维度选择时间，把筛选条件选择城市和平台，把指标A设置成趋势线，把指标B设置成按照色阶显示，然后……

小王：好的，我试一下。

可是，在小王试了很多次以后，依然不能复现问题，于是……

小王：小钱，我还是不能复现你的问题啊，要不我找你当面看一下吧。

小钱：好的，我问其他同事好像也没有这个问题，你过来看一下吧。

于是，小王找到了小钱，当面确认了问题，他那里确实有问题，但是用自己的电脑这么操作就没有问题。于是，小王不得不找前端研发工程师小赵和后端研发工程师小李帮忙。

小王：小赵，小钱在使用×××这个功能时遇到了问题，他的操作是×××，可是我按照他的操作在我的电脑上是好的，你能看一下吗？

小赵：好的，我先在我的电脑上看一下是否能复现，稍等……我这里能正常使用。

小李：我这里功能也可以正常使用，我们过去找你们一起现场看一下吧。

小钱周围围了研发工程师、产品经理等四五个同事一起查找问题，最后发现是因为浏览器版本太低，对一个控件的功能不支持，导致报错，在小钱更新了浏览器版本之后顺利解决了这个问题。

产品运营主管小丁：我在使用用户行为路径这个功能的时候发现选择×××这些条件后结果好像和业务这边的常识有些冲突，A路径的点击量应该没有B路径的点击量高，能帮我看一下吗？

小王：这个A路径就是在App上先点击××，再点击××，然后再点击××吗？

小丁：是的，你可以在App上看一下，B路径的入口还是很明显的，A路径会稍微隐蔽一些。

小王：嗯，确实是，好的，我们确认一下数据的准确性。

于是，小王又找到了研发工程师，从数据仓库到底层日志，最后到埋点，一层层开始查，终于找到了问题，是因为前端研发工程师在埋点的时候忘记埋了一个点，导致B路径的数据量不够，从而出现了上面的问题。

小王：问题找到了，是因为前端埋点漏掉了一个，已经让负责埋点的同事加上了，明天应该就能看到数据了。

小丁：好的，多谢哈，数据的准确性还是很重要的。

小王：中午一起吃饭吧，我还想了解了解你们业务上×××这方面的事情。

于是，小王和业务同事经常“混”在一起，了解业务同事正在做的事，以及如何从数据角度帮助他们，同时向业务同事分享了自己对数据方面的认识，以及从数据角度看业务还可以实现的改进和尝试方案。