产品经理往往会跟很多需求方打交道，这是为了保证需求在后续开发的执行效率，减少来回沟通的成本，以及降低返工的风险。

日常工作里，数据产品经理往往会跟很多需求方打交道，在需求上跟各业务方「周旋」。目的都是为了让需求本身变得更加具体、合理，让需求的相关信息尽可能的透明、准确。保证需求在后续开发的执行效率，减少来回沟通的成本，以及降低返工的风险。

本篇具体聊一下，一个成熟的数据需求应该是什么样的（文中所涉及内容也在公司内部给相关业务方做过分享）。

一、需求方提供

一个数据需求，主要由四部分关键点组成：业务背景、明确问题、形成指标、需求分类。

1.1 业务背景

介绍业务背景目的：核心是为了向数据团队产品或技术同学，同步需求背景。描述当前需求的业务背景，和想要利用数据解决的问题范围。因为从数据要解决的问题边界上，有些是数据没有办法能够解决的。

而需求在提出的时候也需要注意多从全局考虑问题，而不是局限于某个小业务模块，避免重复造轮子。

常见问题：需求没有业务背景描述，或背景描述空泛，这样造成的结果是：

1. 数据产品同学无法评估需求合理性，无法在需求池需求列表进行优先级排序；
2. 无法评估是否有更好，更优的解决方案。

1.2 明确问题

希望数据解决什么？

目的：为了更准确的明确需求本身是什么，希望数据来解决什么。

通常分为三点：

1. 业务形式：讲清楚业务方是什么业务，需求所属什么业务，例如订单相关，风控相关，供给相关，客服相关等；
2. 业务规模：业务自身的体量如何，产生的数据集合数据结果大概是什么量级。这有便于需求评估时候的技术选型做决策；
3. 业务周期：业务本身是长期业务还是试点的短期项目，是测试期内还是已经正式上线？这会决定需求的输出方式（邮件，报表，临时SQL提供等）。

常见问题：不提供业务的周期信息，造成原本应该用临时手段解决的需求转而用了资源消耗较高的方案，得不偿失。

1.3 构建指标、维度

「指标」指的是对业务量级描述的度量值，「维度」指的是观察度量值的视角。例如：“订单数，用户量，商品数”等属于指标；而“品类，省份城市，终端”等属于维度。

目的：如果是统计类型的需求，这一步可以将需求细化，具体到有哪些指标和哪些维度，这将直接决定技术同学在「实施」层面的标准。

一个合理明确的数据需求务必需要写清楚：

1. 指标：指标的业务描述，指标本身的统计逻辑；
2. 维度：从哪些视角观察度量值，维度在精不在多。同时维度的多少也将直接影响数据的计算和结果存储的成本，也是需求合理性的重要评判依据。

常见问题：

1. 没有维度，指标不全面。造成需求返工；
2. 指标无明确定义，计算规则。无法写计算逻辑。

1.4 需求分类：明确输出方式

目的：描述的需求的分类，即业务同学想要实现的输出效果。需求的输出方案会分为几类：赋能型，离线展示型，实时监控型，专题分析型，临时需求。

常见问题：1)原本临时的需求要做成线上离线报表或实时监控，资源消耗高2)可以一次得出结论的要求长期监控，投入产出回报率低。

（图1：需求分类表）

二、数据团队评估

业务团队按照需求规范提供了需求后，传递到数据团队手中。由数据产品统一把关，若在一些技术问题上不能明确给出解决方案的，则需要拉上技术同学共同评估。整体围绕两方面展开：

2.1 需求要素：有数据，可执行，数据能够解决

我们在评估数据需求的时候需要明确一点「数据需求!=需求」，数据需求三要素：1）有数据：有指标数据，且必须准确可靠2）可执行：数据能落地，技术手段可实现3）数据能够解决：数据需求所选指标可解决业务问题，考量需求落地性，产品最终结果是否可驱动业务动作

（图2：需求三要素）

2.2 执行角色：谁解决

在事情的执行上，通常会有一些需求边界不清晰，而在一个组织里会因为事情边界的不清晰带来诸多问题。需求边界不清晰的体现通常表现为：原本该业务团队自行实现的，转而采用了消耗资源较大的数据专业团队的能力实现，这是一类「大刀砍小树」的现象，会造成没必要的资源浪费。

因此我们在划分需求边界的时候通常有如下规则：

1. 数据团队：核心解决 “报表可视化、跨业务团队、基于 日志、量大” 类型需求；
2. 业务团队： 单一业务需求；线上实时数据需求 (接口)批量访问等场景 类型需求。

举例：临时数据、自动邮件、关系型接口

以上。

作者：蒋坤伟，数据产品经理，微信公众号@黑夜月

本文由 @蒋坤伟 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议