数据产品经理之用户需求对接.docVIP

PAGE2/NUMPAGES2

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

本文将数据产品经理用户需求对接分为两个方面：临时需求与项目需求，分别对其进行了介绍。

一个数据产品从无到有，经历的主要过程：

用户需求调研及分析——内容设计——数据产品设计——数据产品研发——产品测试及验收——产品运营——数据治理——产品优化迭代。

对于发展中的数据团队而言，用户需求调研及分析这个过程往往由于用户提报的需求过于具化而弱化，而变成直接与用户对接；今天仍然从两个方便解析与用户对接需求的过程及问题点。

一、临时需求对接

数据需求对比其他功能性需求最大的特点是很多情况下用户提报的需求已经相对明确——以报表的形式告知你报表要呈现什么指标、分析的维度，甚至每个指标的基本算法都给你写清楚了；

举个例子，商品管理部同事在OA流程上提报了一个需求，需要监控线下门店需要淘汰商品的销售清理进度，提交过来的报表格式如下：

用户提交需求表样

以下是作为数据产品经理跟用户对接的步骤及结果：

1.?调研用户需求的目标及价值点：根据用户阐述的需求目的价值判断需求是否需要进一步跟进；

需求背景：由于门店陈列空间限制或者商品策略调整原因会有部分商品需要淘汰，清理库存；在发布清理通知之后，需要针对商品清理进度进行监控后作出对应问题解决方案；

需求目标及价值：跟踪各门店淘汰商品清理进度，根据清理进度判断是否需要针对淘汰商品匹配相应的促销活动；

结合以上两点初步判断需求合理，需要进一步进行需求分析并进行开发。

2.?沟通并梳理报表字段业务逻辑：在业务层面确定报表数据内容，这一步需要更详尽的清楚用户数据需求每个字段对应的业务逻辑；可以分为两个块面:

数据范围及核算条件：按上图可以很清晰看到是要分析到每个门店的每个需要淘汰的商品，产品经理需要结合对于系统数据层面的了解进一步与用户沟通：商品分为零食、水果、辅料，需要展现所有的商品吗？（只展现零食）。需清理的商品需要怎么定义？（库存大于0且非选品商品）

指标计算规则：指标具体的计算公式，譬如期末库存金额=标准价*期末库存数量，这个时候数据产品经理同样需要结合自己对于系统数据基础结构了解进一步引导用户深挖他的需求——库存数量在业务系统里面分为非限制性库存、被冻结的库存、质检中的库存，这里的库存数量核算范围？（取业务系统中非限制性库存）；

经过上面两个环节的沟通后，已经确认了需求的重要性、价值点，及需求具体的业务层面的算法，数据产品经理已经掌握了业务层面的大部分信息，这个时候就可以对于需求进行开发排期，并进入产品设计及开发阶段了，但是由于临时需求相对比较单一简单，产品设计环节涉及到的很少，表样基本都不会有大的改变；

至此，临时需求对接工作基本完成；

二、项目需求对接

项目需求对接过程与临时需求对接过程基本一致；

我所在公司信息系统包括数据部门以及各业务信息系统服务部门（ERP系统开发部、ERP系统各产品部、电商技术部门等），在各业务系统相对稳定成熟的前提下，各业务系统产品部门起到业务变革创新主导的角色，用户在业务上存在某些痛点，将痛点反馈给到业务系统产品经理，业务系统产品经理发起项目，制定项目方案，规划项目内容及解决方案；在解决方案中会产生数据产品需要数据团队进行落地；上述即为数据产品项目需求产生的背景及过程；

需求到达数据产品经理手上已经完成项目立项报告、项目内容规划、项目里程碑阶段设计，数据产品经理承接数据需求实施部分的工作推进；在上述背景下，数据产品经理与用户的对接工作更多的体现在于对业务需求内容的理解上；

以我最近对接的一个项目——产销协同系统化为例，这个项目目标是为了解决商品销售部门、供应计划部门及采购部门之前产销协同合作的工作流程及机制，为了保证这个工作流程及机制的顺利运行，衍生出报表需求；项目经理与我对接的时候直接给了55张表我，告知我这是收集到的每个环节的关键用户的报表需求，且已经做了核对；

收到这个需求后，在跟用户对接过程中我做了以下几件事：

1.直接表明需求过多，开发资源难以匹配，要求用户对于需求进行再一次内部评审；

2.经过上一步后，业务将需求精简到25张报表提报给我到，并表示无法再精简，必须要开发出来；于是，我组织会议拉着项目负责人和关键业务用户开会，了解25张表的作用及价值点；

3.第2步沟通结束后，我针对这些报表做了初步分析和筛查，将其中8张处于总分结构的报表归纳为在一张看板层展现，7张同一纬度看单个指标趋势的报表归为一类自助分析工具去实现；最后25张报表变成一张看板、一个自助分析工具、10张表；并将用意反馈至用户，与用户统一了输出形式，在内容满足的情况下再次精简应用输出个数；

4.与开发组协调资源，结果是只