数据产品经理,要如何接稳业务需求?

编辑导语:面对多线数据需求,数据产品经理要如何进行对接,保障后续业‌务的正常行进?本篇☏文章里,作者结合自身经验,总结了数∞据产品经理进行需求→对接时的一些注意事项,一起来看一下吧。

数据产品经理接到各个业务线提过来的数据需求时,如何高效推进?如何规避风险?如何保障交付质量?

今天,就来ν聊聊,谈一谈我经过多次实践后的理解。

一、明确业务方需ੌવ求

一般数据产品经理是和业务方产品经理对接,有些还会让业务提交需求申请单,所以收集到的需求会比较明确,但建议还是要按照下面的要点查漏补缺(业务不明确也可按照步骤从0-1),避免理解错需求:需求背景(原始story)、目标(数据化业务表现、异常监控等)、使用背景♡(使用人、关注人等)、涉及指标口径定义、维度定义、输出方式(报表、接口、邮件等)。

明确口径和维度时,建议拉个会议,除了和业务产品经理明确业务口径,还要邀请业务研发参与,业务研发和数据研发双方要根据业务口径把口径取数逻辑明确,因为数据研发对业务的落表规ૌ则是没有实际业务研发清楚的,ñ很可能漏掉某种要剔除的状态导致Š数据错误。

会议明确后,后进入开发环节,会更加高效,规避了后续口径争▥议的Ü风险,也是对报表准确性的保障(是整个需求对接最关键的部分,很多后续数据不准确的问题,都可能是这个环节没有做好,造成数据治理返工,而且数据研发过程中,可能还会遇到业务数据落存错误导致脏数据,后续大Φ家要基于本次会议讨论的取值逻辑,继续确定脏数据处理的方案)。

过程中,要避免口头上的约定,数据产品可帮助指标字典搭建,把确定的口径都落入,形成高复用高可靠的઩数据资产(要让研发参与进来,而不是个人的“资产”)。

二、原型输出

理解透彻需求后,就可以进入需求设计环节。ੑ

需求设计属于产Ζ品常规ઐ流程,就不展开说了,主要讨论和业务需求设计的差异。有时候,数据产品接到的需Ι求,业务产品已经设计好原型了,若对其设计进行改动,要和业务产品再明确(很多时候宁愿业务产品不要给原型,大家懂的)。

Í

常见的就是报表设计,可以根据经验总结报表设计功能清单、报æ表原型复用组件。

在原本需求基础上,要加入数据说明板块,对应步骤一的会议口径共识落地,把报表相关的指标口径(前一步明确好的),作为બ文档落存,同时归档到指标字典(前期整理较耗时,后期复用你也许会万分庆幸当初做了整理)。

下方用我常用的模板举例(假设需求是设计一个报表):

1)报表说明

背景、报表使用人、报表功能说明及价值、涉及指标、涉及维度、更新节奏&#256d;(实时or T+1)、备注。

2)指标说明

指标名称、业务口径、取数口径、取数说明、维度、单位、数据类型、备注。

三、原型确认

建议此环节不需要等文档全部写完,原型画完文档框架搭建完后就可与业务方碰一下,大家是一个公司的同事很方便,多沟通能避免理解歧义造成资源的浪费。

四、原型评审

数据部门内部的评审,参与方是数据产品经理、数据研发、数据测试。这个环节属于产品常规流程,细节就不展开说了。若前面两个环节,指标中઎取数口径这块前面没有补全(毕竟这块数据研发主导补充),可明确研发环节要补全。

五、验收需求

可以通过以下方式ઞ来验收Þ需求:

  1. 检查SQL逻辑,主要看是一×些where条件是否考虑异常场景。
  2. 造数,结合业务验证(同业务需求验收流程)。
  3. 自己根据指标字典整理的逻辑,写SQL和造数对比੖验证(有条件的话)。

六、结语

数据需求流程和业务需求流程相比:

1)增加了数据板块的处理说明,并要把宝贵的数据沉淀落地方便后期复用。

2)多角色参与后,业♨务和数据੘部门彼此协调的工作要牵头完成,后续研发测试环节还需Ņ要持续,帮助双方研发根据业务口径共识出准确的取数口径;帮Û助测试协调业务的产品或者研发,判断是否提缺陷等,持续推进问题的处理。

这块沟通成本高,但为了质量,需要全程护航。尽量和业务相关人员处好关系,业务模块分工很细时,建群是必要的,一定要把负责人拉入群帮助协调,最好慢慢摸索对应问题找谁处理(研发部门、产品部门、甚至测试部门模块分工),避免连续转好几个人才找到关键人。

3)同样需要业务需求设计扎实的基本功,当业务传达的需求不完整或者原型设计的有遗漏时,能自己上。±

我本身是业务产品转的数据产品,这块上手轻松,若有些研发或者数据分析师转岗的数据产品经理,这块能力要补齐(需求调研与收集、流程梳理、原型设计、文档撰写(尤其异常场景)、项目管理)。

 

本文由 @季月 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

Leave a comment

Your email address will not be published.