日常工作里，数据产品经理往往会跟很多需求方打交道，在需求上跟各业务方「周旋」。目的都是为了让需求本身变得更加具体、合理，让需求的相关信息尽可能的透明、准确。保证需求在后续开发的执行效率，减少来回沟通的成本，以及降低返工的风险。
本篇具体聊一下，一个成熟的数据需求应该是什么样的（文中所涉及内容也在公司内部给相关业务方做过分享）。
一、需求方提供
一个数据需求，主要由四部分关键点组成：业务背景、明确问题、形成指标、需求分类。
1.1 业务背景：介绍业务背景
目的：核心是为了向数据团队产品或技术同学，同步需求背景。描述当前需求的业务背景，和想要利用数据解决的问题范围。因为从数据要解决的问题边界上，有些是数据没有办法能够解决的。而需求在提出的时候也需要注意「多从全局考虑问题，而不是局限于某个小业务模块，避免重复造轮子」。
常见问题：
需求没有业务背景描述，或背景描述空泛，这样造成的结果是：
1）数据产品同学无法评估需求合理性，无法在需求池需求列表进行优先级排序
2）无法评估是否有更好，更优的解决方案
1.2 明确问题：希望数据解决什么？
目的：为了更准确的明确需求本身是什么，希望数据来解决什么。通常分为三点：
1）业务形式：讲清楚业务方是什么业务，需求所属什么业务，例如订单相关，风控相关，供给相关，客服相关等
2）业务规模：业务自身的体量如何，产生的数据集合数据结果大概是什么量级。这有便于需求评估时候的技术选型做决策
3）业务周期：业务本身是长期业务还是试点的短期项目，是测试期内还是已经正式上线？这会决定需求的输出方式（邮件，报表，临时SQL提供等）
常见问题：
1）不提供业务的周期信息，造成原本应该用临时手段解决的需求转而用了资源消耗较高的方案，得不偿失
1.3 形成指标：构建指标*维度
「指标」指的是对业务量级描述的度量值，「维度」指的是观察度量值的视角。例如：“订单数，用户量，商品数”等属于指标；而“品类，省份城市，终端”等属于维度。
目的：如果是统计类型的需求，这一步可以将需求细化，具体到有哪些指标和哪些维度，这将直接决定技术同学在「实施」层面的标准。一个合理明确的数据需求务必需要写清楚：
1）指标：指标的业务描述，指标本身的统计逻辑
2）维度：从哪些视角观察度量值，维度在精不在多。同时维度的多少也将直接影响数据的计算和结果存储的成本，也是需求合理性的重要评判依据
常见问题：
1）没有维度，指标不全面。造成需求返工
2）指标无明确定义，计算规则。无法写计算逻辑
1.4 需求分类：明确输出方式
目的：描述的需求的分类，即业务同学想要实现的输出效果。需求的输出方案会分为几类：赋能型，离线展示型，实时监控型，专题分析型，临时需求
常见问题：
1)原本临时的需求要做成线上离线报表或实时监控，资源消耗高
2)可以一次得出结论的要求长期监控，投入产出回报率低
二、数据团队评估
业务团队按照需求规范提供了需求后，传递到数据团队手中。由数据产品统一把关，若在一些技术问题上不能明确给出解决方案的，则需要拉上技术同学共同评估。整体围绕两方面展开：
2.1 需求要素：有数据，可执行，数据能够解决
我们在评估数据需求的时候需要明确一点「数据需求!=需求」，数据需求三要素：
1）有数据：有指标数据，且必须准确可靠
2）可执行：数据能落地，技术手段可实现
3）数据能够解决：数据需求所选指标可解决业务问题，考量需求落地性，产品最终结果是否可驱动业务动作
2.2 执行角色：谁解决
在事情的执行上，通常会有一些需求边界不清晰，而在一个组织里会因为事情边界的不清晰带来诸多问题。需求边界不清晰的体现通常表现为：原本该业务团队自行实现的，转而采用了消耗资源较大的数据专业团队的能力实现，这是一类「大刀砍小树」的现象，会造成没必要的资源浪费。
因此我们在划分需求边界的时候通常有如下规则：
1）数据团队：核心解决 “报表可视化、跨业务团队、基于 日志、量大” 类型需求
2）业务团队：
2.1)单一业务需求
2.2)线上实时数据需求 (接口)批量访问等场景 类型需求；举例:临时数据、自动邮件、关系型接口
以上
本文作者：蒋坤伟，数据产品经理，公众号@黑夜月
关注公众号，在后台留言「数据产品」，我拉你进微信群一起学习，共同成长