数据产品经理之用户需要对接

luchangmei

本文将数据产品经理用户需要对接分为两个方面：暂时需要与名目需要，分别对其进行了引见。


一个数据产品从无到有，阅历的次要进程：
用户需要调研及剖析——内容设计——数据产品设计——数据产品研发——产品测试及验收——产品经营——数据治理——产品优化迭代。
关于开展中的数据团队而言，用户需要调研及剖析这个进程往往因为用户提报的需要过于具化而弱化，而变为间接与用户对接；明天依然从两个便利解析与用户对接需要的进程及问题点。


一、暂时需要对接
数据需要比较其余功用性需要最大的特征是得多状况下用户提报的需要曾经相对于明白——以报表的方式告诉你报表要呈现甚么目标、剖析的维度，乃至每个目标的根本算法都给你写分明了；
举个例子，商品办理部共事在OA流程上提报了一个需要，需求监控线下门店需求淘汰商品的销售清算进度，提交过去的报表格局如下：


用户提交需要表样
下列是作为数据产品经理跟用户对接的步骤及后果：
1. 调研用户需要的指标及价值点：按照用户论述的需要目的价值判别需要是不是需求进一步跟进；
需要配景：因为门店陈列空间限度或者商品战略调剂缘故会有部份商品需求淘汰，清算库存；在公布清算通知之后，需求针对商品清算进度进行监控后作出对应问题解决计划；需要指标及价值：跟踪各门店淘汰商品清算进度，按照清算进度判别是不是需求针对淘汰商品婚配相应的促销流动；结合以上两点初步判别需要公道，需求进一步进行需要剖析并 进行开发。
2. 沟通并梳理报表字段业务逻辑：在业务层面肯定报表数据内容，这一步需求更详实的分明用户数据需要每个字段对应的业务逻辑；能够分为两个块面:
数据规模及核算前提：按上图能够很明晰看到是要剖析到每个门店的每个需求淘汰的商品，产品经理需求结合关于零碎数据层面的理解进一步与用户沟通：商品分为零食、瓜果、辅料，需求展示一切的商品吗？（只展示零食）。需清算的商品需求怎么定义？（库存大于0且非选品商品）目标计算规定：目标详细的计算公式，譬如期末库存金额=规范价*期末库存数量，这个时分数据产品经理一样需求结合本人关于零碎数据根底构造理解进一步疏导用户深挖他的需要——库存数量在业务零碎外面分为非限度性库存、被解冻的库存、质检中的库存，这里的库存数量核算规模？（取业务零碎中非限度性库存）；通过下面两个环节的沟通后，曾经确认了需要的首要性、价值点，及需要详细的业务层面的算法，数据产品经理曾经掌握了业务层面的大部份信息，这个时分就能关于需要进行开发排期，并进入产品设计及开发阶段了，然而因为暂时需要相对于对比繁多简略，产品设计环节波及到的很少，表样根本都不会有大的改动；
至此，暂时需要对接任务根本实现；
二、名目需要对接
名目需要对接进程与暂时需要对接进程根本统一；
我所在公司信息零碎包罗数据部门以及各业务信息零碎办事部门（ERP零碎开发部、ERP零碎各产品部、电商技术部门等），在各业务零碎相对于不乱成熟的条件下，各业务零碎产品部门起到业务改革翻新主导的角色，用户在业务上存在某些痛点，将痛点反馈给到业务零碎产品经理，业务零碎产品经理发动名目，制订名目计划，布局名目内容及解决计划；在解决计划中会发生数据产品需求数据团队进行落地；上述即为数据产品名目需要发生的配景及进程；
需要抵达数据产品经理手上曾经实现名目立项讲演、名目内容布局、名目里程碑阶段设计，数据产品经理承接数据需要实行部份的任务推动；在上述配景下，数据产品经理与用户的对接任务更多的体当初于对业务需要内容的了解上；
以我比来对接的一个名目——产销协同零碎化为例，这个名目指标是为理解决商品销售部门、供给方案部门及推销部门以前产销协同协作的任务流程及机制，为了包管这个任务流程及机制的顺利运转，衍生出报表需要；名目经理与我对接的时分间接给了55张表我，告诉我这是采集到的每个环节的症结用户的报表需要，且曾经做了核查；
收到这个需要后，在跟用户对接过程当中我做了下列几件事：
1. 间接标明需要过量，开发资源难以婚配，要求用户关于需要进行再一次外部评审；
2. 通过上一步后，业务将需要精简到25张报表提报给我到，并表现无奈再精简，必需要开收回来；因而，我组织会议拉着名目担任人和症结业务用户散会，理解25张表的作用及价值点；
3. 第2步沟通完结后，我针对这些报表做了初步剖析和筛查，将其中8张处于总分构造的报表归结为在一张看板层展示，7张同一纬度看单个目标趋向的报表归为一类自助剖析工具去完成；最初25张报表变为一张看板、一个自助剖析工具、10张表；并将意图反馈至用户，与用户一致了输入方式，在内容知足的状况下再次精简运用输入个数；
4. 与开发组协调资源，后果是只能给到一个开发共事承当这部份的开发任务，为了不挥霍开发资源，要求用户针对25张表给出日活许诺，同时按照日活许诺筛选出了8张高优先级的表，并与用户确认；
终究达成统一论断——先开发8张高优先级的表，试运转1个月后，按照每张表的使用状况与日活许诺比较后再斟酌是不是持续投入开发资源持续开发其余的表；
5. 与暂时数据需要对接统一，沟通并梳理报表字段业务逻辑；但进程比拟暂时需要在时间上会大大拉长；
至此名目需要用户对接进程根本实现；
三、用户需要对接之痛
在通过多个用户需要知足实行进程之后，回过头来看一下，不由有下列疑难：
需要要不要做，是由数据产品经理客观判别吗?事实上，咱们的确很少有回绝用户的时分；能否做到可量化或者以某个更有压服力的形式去抉择需要要不要做？关于名目需要，数据产品经理彻底是处于主动接需要形态，需不需求参预到内容设计层面呢， 假如参预到内容设计层面，数据产品经理能起到甚么作用呢？或者说是以甚么角色去抉择内容层面呢？难以造成规范去判别名目需要的公道性，只能客观判别，而后在开发资源限度情况上来对用户需要数量上做限度，乃至要求用户做日活许诺去倒逼用户客观上再去考虑需要的量，这些都只是基于需要曾经造成后的一种管控伎俩；名目需要都是基于用户的某个业务办理的痛点， 去解决这个痛点，数据产品经理的确很能起到业务征询参谋的角色，可能这就是咱们始终处于主动接需要的形态的缘故；这个问题应该怎么解开呢？上述问题也的确是我所在组织目前最头疼的问题，咱们也有尝试在跟用户去做沟通，让用户许诺日活，然而我感觉这可能不是一个特别好的形式，需要都做完了，开发资源曾经整个投入进去了，预先追踪的意义是甚么呢？
业务是多变的，这是难以改动的事实，按目前的状况来看，数据产品经理能做的更多的事件就是按照用户使用状况去追责，进而束缚用户下一阶段的需要量；
以上就是我作为数据产品经理在承接用户需要的进程以及遇到的一些问题，这些问题其实始终都存在，但得多时分咱们都在埋头接需要人后开发，占用了咱们大部份的时间和精神，却没有低头思考下如何去管控优化这些需要。
作者：王小涂 大众号：数据产品经理进阶之路（ID：DATAPMZL）