數(shù)據(jù)產品經理,要如何接穩(wěn)業(yè)務需求?

0 評論 4780 瀏覽 20 收藏 8 分鐘

編輯導語:面對多線數(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é)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!