起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據產品經理，要如何接穩業務需求？
編輯導語：面對多線數據需求，數據產品經理要如何進行對接，保障后續業務的正常行進？本篇文章里，作者結合自身經驗，總結了數據產品經理進行需求對接時的一些注意事項，一起來看一下吧。
數據產品經理接到各個業務線提過來的數據需求時，如何高效推進？如何規避風險？如何保障交付質量？
今天，就來聊聊，談一談我經過多次實踐后的理解。
一、明確業務方需求
一般數據產品經理是和業務方產品經理對接，有些還會讓業務提交需求申請單，所以收集到的需求會比較明確，但建議還是要按照下面的要點查漏補缺（業務不明確也可按照步驟從0-1），避免理解錯需求：需求背景（原始story）、目標（數據化業務表現、異常監控等）、使用背景（使用人、關注人等）、涉及指標口徑定義、維度定義、輸出方式（報表、接口、郵件等）。
明確口徑和維度時，建議拉個會議，除了和業務產品經理明確業務口徑，還要邀請業務研發參與，業務研發和數據研發雙方要根據業務口徑把口徑取數邏輯明確，因為數據研發對業務的落表規則是沒有實際業務研發清楚的，很可能漏掉某種要剔除的狀態導致數據錯誤。
會議明確后，后進入開發環節，會更加高效，規避了后續口徑爭議的風險，也是對報表準確性的保障（是整個需求對接最關鍵的部分，很多后續數據不準確的問題，都可能是這個環節沒有做好，造成數據治理返工，而且數據研發過程中，可能還會遇到業務數據落存錯誤導致臟數據，后續大家要基于本次會議討論的取值邏輯，繼續確定臟數據處理的方案）。
過程中，要避免口頭上的約定，數據產品可幫助指標字典搭建，把確定的口徑都落入，形成高復用高可靠的數據資產（要讓研發參與進來，而不是個人的“資產”）。
二、原型輸出
理解透徹需求后，就可以進入需求設計環節。
需求設計屬于產品常規流程，就不展開說了，主要討論和業務需求設計的差異。有時候，數據產品接到的需求，業務產品已經設計好原型了，若對其設計進行改動，要和業務產品再明確（很多時候寧愿業務產品不要給原型，大家懂的）。
常見的就是報表設計，可以根據經驗總結報表設計功能清單、報表原型復用組件。
在原本需求基礎上，要加入數據說明板塊，對應步驟一的會議口徑共識落地，把報表相關的指標口徑（前一步明確好的），作為文檔落存，同時歸檔到指標字典（前期整理較耗時，后期復用你也許會萬分慶幸當初做了整理）。
下方用我常用的模板舉例（假設需求是設計一個報表）：
1）報表說明
背景、報表使用人、報表功能說明及價值、涉及指標、涉及維度、更新節奏（實時or T+1）、備注。
2）指標說明
指標名稱、業務口徑、取數口徑、取數說明、維度、單位、數據類型、備注。
三、原型確認
建議此環節不需要等文檔全部寫完，原型畫完文檔框架搭建完后就可與業務方碰一下，大家是一個公司的同事很方便，多溝通能避免理解歧義造成資源的浪費。
四、原型評審
數據部門內部的評審，參與方是數據產品經理、數據研發、數據測試。這個環節屬于產品常規流程，細節就不展開說了。若前面兩個環節，指標中取數口徑這塊前面沒有補全（畢竟這塊數據研發主導補充），可明確研發環節要補全。
五、驗收需求
可以通過以下方式來驗收需求：
- 檢查SQL邏輯，主要看是一些where條件是否考慮異常場景。
- 造數，結合業務驗證（同業務需求驗收流程）。
- 自己根據指標字典整理的邏輯，寫SQL和造數對比驗證（有條件的話）。
六、結語
數據需求流程和業務需求流程相比：
1）增加了數據板塊的處理說明，并要把寶貴的數據沉淀落地方便后期復用。
2）多角色參與后，業務和數據部門彼此協調的工作要牽頭完成，后續研發測試環節還需要持續，幫助雙方研發根據業務口徑共識出準確的取數口徑；幫助測試協調業務的產品或者研發，判斷是否提缺陷等，持續推進問題的處理。
這塊溝通成本高，但為了質量，需要全程護航。盡量和業務相關人員處好關系，業務模塊分工很細時，建群是必要的，一定要把負責人拉入群幫助協調，最好慢慢摸索對應問題找誰處理（研發部門、產品部門、甚至測試部門模塊分工），避免連續轉好幾個人才找到關鍵人。
3）同樣需要業務需求設計扎實的基本功，當業務傳達的需求不完整或者原型設計的有遺漏時，能自己上。
我本身是業務產品轉的數據產品，這塊上手輕松，若有些研發或者數據分析師轉崗的數據產品經理，這塊能力要補齊（需求調研與收集、流程梳理、原型設計、文檔撰寫（尤其異常場景）、項目管理）。
本文由 @季月 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
