產品經理往往會跟很多需求方打交道，這是為了保證需求在后續開發的執行效率，減少來回溝通的成本，以及降低返工的風險。

日常工作里，數據產品經理往往會跟很多需求方打交道，在需求上跟各業務方「周旋」。目的都是為了讓需求本身變得更加具體、合理，讓需求的相關信息盡可能的透明、準確。保證需求在后續開發的執行效率，減少來回溝通的成本，以及降低返工的風險。

本篇具體聊一下，一個成熟的數據需求應該是什么樣的（文中所涉及內容也在公司內部給相關業務方做過分享）。

一、需求方提供

一個數據需求，主要由四部分關鍵點組成：業務背景、明確問題、形成指標、需求分類。

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協議