編輯導語：面對多線數(shù)據(jù)需求，數(shù)據(jù)產品經理要如何進行對接，保障后續(xù)業(yè)務的正常行進？本篇文章里，作者結合自身經驗，總結了數(shù)據(jù)產品經理進行需求對接時的一些注意事項，一起來看一下吧。

數(shù)據(jù)產品經理接到各個業(yè)務線提過來的數(shù)據(jù)需求時，如何高效推進？如何規(guī)避風險？如何保障交付質量？

今天，就來聊聊，談一談我經過多次實踐后的理解。

一、明確業(yè)務方需求

一般數(shù)據(jù)產品經理是和業(yè)務方產品經理對接，有些還會讓業(yè)務提交需求申請單，所以收集到的需求會比較明確，但建議還是要按照下面的要點查漏補缺（業(yè)務不明確也可按照步驟從0-1），避免理解錯需求：需求背景（原始story）、目標（數(shù)據(jù)化業(yè)務表現(xiàn)、異常監(jiān)控等）、使用背景（使用人、關注人等）、涉及指標口徑定義、維度定義、輸出方式（報表、接口、郵件等）。

明確口徑和維度時，建議拉個會議，除了和業(yè)務產品經理明確業(yè)務口徑，還要邀請業(yè)務研發(fā)參與，業(yè)務研發(fā)和數(shù)據(jù)研發(fā)雙方要根據(jù)業(yè)務口徑把口徑取數(shù)邏輯明確，因為數(shù)據(jù)研發(fā)對業(yè)務的落表規(guī)則是沒有實際業(yè)務研發(fā)清楚的，很可能漏掉某種要剔除的狀態(tài)導致數(shù)據(jù)錯誤。

會議明確后，后進入開發(fā)環(huán)節(jié)，會更加高效，規(guī)避了后續(xù)口徑爭議的風險，也是對報表準確性的保障（是整個需求對接最關鍵的部分，很多后續(xù)數(shù)據(jù)不準確的問題，都可能是這個環(huán)節(jié)沒有做好，造成數(shù)據(jù)治理返工，而且數(shù)據(jù)研發(fā)過程中，可能還會遇到業(yè)務數(shù)據(jù)落存錯誤導致臟數(shù)據(jù)，后續(xù)大家要基于本次會議討論的取值邏輯，繼續(xù)確定臟數(shù)據(jù)處理的方案）。

過程中，要避免口頭上的約定，數(shù)據(jù)產品可幫助指標字典搭建，把確定的口徑都落入，形成高復用高可靠的數(shù)據(jù)資產（要讓研發(fā)參與進來，而不是個人的“資產”）。

二、原型輸出

理解透徹需求后，就可以進入需求設計環(huán)節(jié)。

需求設計屬于產品常規(guī)流程，就不展開說了，主要討論和業(yè)務需求設計的差異。有時候，數(shù)據(jù)產品接到的需求，業(yè)務產品已經設計好原型了，若對其設計進行改動，要和業(yè)務產品再明確（很多時候寧愿業(yè)務產品不要給原型，大家懂的）。

常見的就是報表設計，可以根據(jù)經驗總結報表設計功能清單、報表原型復用組件。

在原本需求基礎上，要加入數(shù)據(jù)說明板塊，對應步驟一的會議口徑共識落地，把報表相關的指標口徑（前一步明確好的），作為文檔落存，同時歸檔到指標字典（前期整理較耗時，后期復用你也許會萬分慶幸當初做了整理）。

下方用我常用的模板舉例（假設需求是設計一個報表）：

1）報表說明

背景、報表使用人、報表功能說明及價值、涉及指標、涉及維度、更新節(jié)奏（實時or T+1）、備注。

2）指標說明

指標名稱、業(yè)務口徑、取數(shù)口徑、取數(shù)說明、維度、單位、數(shù)據(jù)類型、備注。

三、原型確認

建議此環(huán)節(jié)不需要等文檔全部寫完，原型畫完文檔框架搭建完后就可與業(yè)務方碰一下，大家是一個公司的同事很方便，多溝通能避免理解歧義造成資源的浪費。

四、原型評審

數(shù)據(jù)部門內部的評審，參與方是數(shù)據(jù)產品經理、數(shù)據(jù)研發(fā)、數(shù)據(jù)測試。這個環(huán)節(jié)屬于產品常規(guī)流程，細節(jié)就不展開說了。若前面兩個環(huán)節(jié)，指標中取數(shù)口徑這塊前面沒有補全（畢竟這塊數(shù)據(jù)研發(fā)主導補充），可明確研發(fā)環(huán)節(jié)要補全。

五、驗收需求

可以通過以下方式來驗收需求：

1. 檢查SQL邏輯，主要看是一些where條件是否考慮異常場景。
2. 造數(shù)，結合業(yè)務驗證（同業(yè)務需求驗收流程）。
3. 自己根據(jù)指標字典整理的邏輯，寫SQL和造數(shù)對比驗證（有條件的話）。

六、結語

數(shù)據(jù)需求流程和業(yè)務需求流程相比：

1）增加了數(shù)據(jù)板塊的處理說明，并要把寶貴的數(shù)據(jù)沉淀落地方便后期復用。

2）多角色參與后，業(yè)務和數(shù)據(jù)部門彼此協(xié)調的工作要牽頭完成，后續(xù)研發(fā)測試環(huán)節(jié)還需要持續(xù)，幫助雙方研發(fā)根據(jù)業(yè)務口徑共識出準確的取數(shù)口徑；幫助測試協(xié)調業(yè)務的產品或者研發(fā)，判斷是否提缺陷等，持續(xù)推進問題的處理。

這塊溝通成本高，但為了質量，需要全程護航。盡量和業(yè)務相關人員處好關系，業(yè)務模塊分工很細時，建群是必要的，一定要把負責人拉入群幫助協(xié)調，最好慢慢摸索對應問題找誰處理（研發(fā)部門、產品部門、甚至測試部門模塊分工），避免連續(xù)轉好幾個人才找到關鍵人。

3）同樣需要業(yè)務需求設計扎實的基本功，當業(yè)務傳達的需求不完整或者原型設計的有遺漏時，能自己上。

我本身是業(yè)務產品轉的數(shù)據(jù)產品，這塊上手輕松，若有些研發(fā)或者數(shù)據(jù)分析師轉崗的數(shù)據(jù)產品經理，這塊能力要補齊（需求調研與收集、流程梳理、原型設計、文檔撰寫（尤其異常場景）、項目管理）。

本文由 @季月 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議