【成功项目解析】数据产品经理小白的入门第三课

大家好，我是Justina，欢迎来看数据产品经理小白的入门系列的第三课。

2019年毕业至2022年期间我一直在某互联网大厂担任数据产品经理的岗位，去年8月我跳槽来到某传统行业，在适应国企氛围和认识数字化转型的过程中，这半年的工作学习让我对自己的工作也有了一些新的认识，再结合之前三年在互联网的经验，后续我会逐步给大家分享数据产品经理的内容，刚刚接触数据产品经理这个岗位的同学们顺利入门，也帮助大家了解互联网和国企的不同。

今天主要是以数据产品经理最基础的数据看板项目为例，给大家做一个成功项目解析，帮助大家学习如何做好一个项目。

一、项目背景

A业务部门主要负责手机品类的销售，某天A部门来了一位新老板，新老板入职后第一件事就是要每天早晚都要看自己部门的销售数据，过往都是A部门的数据分析师手工excel跑数发给老板，但老板经常出差用手机看excel多有不便且无法查看今日实时数据，因此A部门找到了数据产品经理Justina的团队，希望对方能做一套移动端数据看板产品，方便老板实时进行数据监控。

二、项目目标

Justina的团队调研分析了业务需求，认为这个需求非常有必要：短期可以实现降本增效，统一数据口径的价值，长期也可以拓展至更多业务部门使用，提供用户使用率，随着业务成熟也可以开发更多智能化的功能，比如智能洞察智能预警等等，都是可以直接帮助到业务。

三、项目过程

1、用户调研：Justina先和A部门的数据分析师Candy进行了详细的沟通，看了Candy日常出数的excel表，对Candy的日常工作有了个大致的了解，并了解了老板看数的目的以及关注的指标，以及老板看了数之后会有哪些业务策略等等，Justina心里对需求有了个大致的蓝图。

2、方案输出：产品方案的两大要点，一是指标体系，二是原型效果。指标体系的建立一定要大而全，毕竟长期目标是拓展更多部门使用，那就不能只局限于A部门，要摒弃一些太过定制化的个性需求，也不能完全照搬数据分析师的字段，要有自己的业务洞察在里面，根据老板的业务目标和策略去定指标。原型效果也不要求多高保真，重点在于图表的选择，什么时候用条形图，什么时候用折线图，这里可以去看麦肯锡的那边数据图表的书，形成自己的方法论。

3、方案评审：有了完整的产品方案后，要先和业务方Candy达成一致，然后再去和研发进行需求评审，这个需求Justina会对接到UI、前端、后端、数据开发、测试等多名同学，所以评审过程不是件容易的事情，但只要对需求了然于心，对自己的方案足够自信，那就不怕被质疑。

4、项目排期：评审完成且研发同学们都没有异议之后，就可以去催排期了，一般大项目有项目经理去催排期，但如果公司人员紧凑一些小项目是不会有项目经理了，这就需要数据产品经理去兼任项目经理了，排期出来后一定也要周知业务方，最好邮件通知且抄送双方领导，以免出现信息不对称的情况。

5、测试验收：在开发过程中，Justina作为产品经理必须时刻追着进度，随时回答研发疑问，有的研发评审时一声不吭但开发过程中会有源源不断的问题，每周进行项目进度的追踪就格外重要。最后测试同学测试完成之后，Justina也会进行产品自测，自测无误之后再让业务同学Candy进行验收，验收完成最终才能正式上线。

6、项目上线：项目上线的前一天往往是最手忙脚乱的，熬夜加班也是最正常不过的，因为研发同学一般都要花时间合代码，前端后端陆续上，上完测试还得继续测，难免某个环节会出问题。但上线完也不是就万事大吉了，Justina要给业务方发送上线通知的邮件，还得提供产品手册，可能还需要给业务方培训如何使用，以及后续数据看板使用过程中的各种答疑都需要Justina来处理。

四、困难点

1、对数：对数是每个数据产品经理逃不开的噩梦，数据看板的验收难点不在功能，在于数据准确性的验证，就算Justina的团队和业务Candy都是从数据中台同一套数据源取数，但是可能会因为口径的细微差异，开发的代码习惯，难以预料的技术问题等等，都会导致数不对上。数是不可能对上的，所以只要弄清楚对不上的原因能解释清楚就好。

2、需求变动：业务改需求是很正常的，数据驱动本来就是个不断探索的过程，可能开发到一半了业务找过来说想改个指标的口径，但这个时候就要拒绝，不能养成业务爱改需求的习惯，不然以后每次提需求他们都会摇摆不定，而且改需求也会打断研发的开发节奏，如果业务坚持要改，必须提醒他延迟上线的风险。