数据产品经理，要如何接稳业务需求？
数据产品经理接到各个业务线提过来的数据需求时，如何高效推进？如何规避风险？如何保障交付质量？
今天，就来聊聊，谈一谈我经过多次实践后的理解。
一、明确业务方需求
一般数据产品经理是和业务方产品经理对接，有些还会让业务提交需求申请单，所以收集到的需求会比较明确，但建议还是要按照下面的要点查漏补缺（业务不明确也可按照步骤从0-1），避免理解错需求：需求背景（原始story）、目标（数据化业务表现、异常监控等）、使用背景（使用人、关注人等）、涉及指标口径定义、维度定义、输出方式（报表、接口、邮件等）。
明确口径和维度时，建议拉个会议，除了和业务产品经理明确业务口径，还要邀请业务研发参与，业务研发和数据研发双方要根据业务口径把口径取数逻辑明确，因为数据研发对业务的落表规则是没有实际业务研发清楚的，很可能漏掉某种要剔除的状态导致数据错误。
会议明确后，后进入开发环节，会更加高效，规避了后续口径争议的风险，也是对报表准确性的保障（是整个需求对接最关键的部分，很多后续数据不准确的问题，都可能是这个环节没有做好，造成数据治理返工，而且数据研发过程中，可能还会遇到业务数据落存错误导致脏数据，后续大家要基于本次会议讨论的取值逻辑，继续确定脏数据处理的方案）。
过程中，要避免口头上的约定，数据产品可帮助指标字典搭建，把确定的口径都落入，形成高复用高可靠的数据资产（要让研发参与进来，而不是个人的“资产”）。
二、原型输出
理解透彻需求后，就可以进入需求设计环节。
需求设计属于产品常规流程，就不展开说了，主要讨论和业务需求设计的差异。有时候，数据产品接到的需求，业务产品已经设计好原型了，若对其设计进行改动，要和业务产品再明确（很多时候宁愿业务产品不要给原型，大家懂的）。
常见的就是报表设计，可以根据经验总结报表设计功能清单、报表原型复用组件。
在原本需求基础上，要加入数据说明板块，对应步骤一的会议口径共识落地，把报表相关的指标口径（前一步明确好的），作为文档落存，同时归档到指标字典（前期整理较耗时，后期复用你也许会万分庆幸当初做了整理）。
下方用我常用的模板举例（假设需求是设计一个报表）：
1）报表说明
背景、报表使用人、报表功能说明及价值、涉及指标、涉及维度、更新节奏（实时or T+1）、备注。
2）指标说明
指标名称、业务口径、取数口径、取数说明、维度、单位、数据类型、备注。
三、原型确认
建议此环节不需要等文档全部写完，原型画完文档框架搭建完后就可与业务方碰一下，大家是一个公司的同事很方便，多沟通能避免理解歧义造成资源的浪费。
四、原型评审
数据部门内部的评审，参与方是数据产品经理、数据研发、数据测试。这个环节属于产品常规流程，细节就不展开说了。若前面两个环节，指标中取数口径这块前面没有补全（毕竟这块数据研发主导补充），可明确研发环节要补全。
五、验收需求
可以通过以下方式来验收需求：
- 检查SQL逻辑，主要看是一些where条件是否考虑异常场景。
- 造数，结合业务验证（同业务需求验收流程）。
- 自己根据指标字典整理的逻辑，写SQL和造数对比验证（有条件的话）。
六、结语
数据需求流程和业务需求流程相比：
1）增加了数据板块的处理说明，并要把宝贵的数据沉淀落地方便后期复用。
2）多角色参与后，业务和数据部门彼此协调的工作要牵头完成，后续研发测试环节还需要持续，帮助双方研发根据业务口径共识出准确的取数口径；帮助测试协调业务的产品或者研发，判断是否提缺陷等，持续推进问题的处理。
这块沟通成本高，但为了质量，需要全程护航。尽量和业务相关人员处好关系，业务模块分工很细时，建群是必要的，一定要把负责人拉入群帮助协调，最好慢慢摸索对应问题找谁处理（研发部门、产品部门、甚至测试部门模块分工），避免连续转好几个人才找到关键人。
3）同样需要业务需求设计扎实的基本功，当业务传达的需求不完整或者原型设计的有遗漏时，能自己上。
我本身是业务产品转的数据产品，这块上手轻松，若有些研发或者数据分析师转岗的数据产品经理，这块能力要补齐（需求调研与收集、流程梳理、原型设计、文档撰写（尤其异常场景）、项目管理）。
本文作者 @季月 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
