感謝導語：面對多線數據需求，數據產品經理要如何進行對接，保障后續業務得正常行進？本篇文章里，結合自身經驗，總結了數據產品經理進行需求對接時得一些注意事項，一起來看一下吧。

數據產品經理接到各個業務線提過來得數據需求時，如何高效推進？如何規避風險？如何保障交付質量？

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

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

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

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

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

理解透徹需求后，就可以進入需求設計環節。

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

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

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

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

1）報表說明

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

2）指標說明

指標名稱、業務口徑、取數口徑、取數說明、維度、單位、數據類型、備注。

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

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

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

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

數據需求流程和業務需求流程相比：

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

2）多角色參與后，業務和數據部門彼此協調得工作要牽頭完成，后續研發測試環節還需要持續，幫助雙方研發根據業務口徑共識出準確得取數口徑；幫助測試協調業務得產品或者研發，判斷是否提缺陷等，持續推進問題得處理。

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

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

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

感謝由 等季月 來自互聯網發布于人人都是產品經理。未經許可，禁止感謝。

題圖來自Unsplash，基于CC0協議