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

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

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

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

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

一、临时需求对接

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

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

用户提交需求表样

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

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

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

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

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

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

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

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

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

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

二、项目需求对接

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

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

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

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

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

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

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

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

4. 与开发组协调资源，结果是只能给到一个开发同事承担这部分的开发工作，为了避免浪费开发资源，要求用户针对25张表给出日活承诺，同时根据日活承诺筛选出了8张高优先级的表，并与用户确认；

最终达成一致结论——先开发8张高优先级的表，试运行1个月后，根据每张表的使用情况与日活承诺对比后再考虑是否继续投入开发资源继续开发其他的表；

5. 与临时数据需求对接一致，沟通并梳理报表字段业务逻辑；但过程相比临时需求在时间上会大大拉长；

至此项目需求用户对接过程基本完成；

三、用户需求对接之痛

在经过多个用户需求满足实施过程之后，回过头来看一下，不禁有以下疑问：

需求要不要做，是由数据产品经理主观判断吗?事实上，我们确实很少有拒绝用户的时候；

能否做到可量化或者以某个更有说服力的方式去决定需求要不要做？

对于项目需求，数据产品经理完全是处于被动接需求状态，需不需要参与到内容设计层面呢， 如果参与到内容设计层面，数据产品经理能起到什么作用呢？或者说是以什么角色去决定内容层面呢？

难以形成标准去判断项目需求的合理性，只能主观判断，然后在开发资源限制状况下去对用户需求数量上做限制，甚至要求用户做日活承诺去倒逼用户主观上再去斟酌需求的量，这些都只是基于需求已经形成后的一种管控手段；

项目需求都是基于用户的某个业务管理的痛点， 去解决这个痛点，数据产品经理确实很能起到业务咨询顾问的角色，可能这就是我们一直处于被动接需求的状态的原因；这个问题应该怎么解开呢？

上述问题也确实是我所在组织目前最头疼的问题，我们也有尝试在跟用户去做沟通，让用户承诺日活，但是我觉得这可能不是一个特别好的方式，需求都做完了，开发资源已经全部投入进去了，事后追踪的意义是什么呢？

业务是多变的，这是难以改变的事实，按目前的情况来看，数据产品经理能做的更多的事情就是根据用户使用情况去追责，进而约束用户下一阶段的需求量；

以上就是我作为数据产品经理在承接用户需求的过程以及遇到的一些问题，这些问题其实一直都存在，但很多时候我们都在埋头接需求人后开发，占用了我们大部分的时间和精力，却没有抬头思考下如何去管控优化这些需求。

7 / 7