起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據產品經理之用戶需求對接
本文將數據產品經理用戶需求對接分為兩個方面：臨時需求與項目需求，分別對其進行了介紹。
一個數據產品從無到有，經歷的主要過程：
用戶需求調研及分析——內容設計——數據產品設計——數據產品研發——產品測試及驗收——產品運營——數據治理——產品優化迭代。
對于發展中的數據團隊而言，用戶需求調研及分析這個過程往往由于用戶提報的需求過于具化而弱化，而變成直接與用戶對接；今天仍然從兩個方便解析與用戶對接需求的過程及問題點。
一、臨時需求對接
數據需求對比其他功能性需求最大的特點是很多情況下用戶提報的需求已經相對明確——以報表的形式告知你報表要呈現什么指標、分析的維度，甚至每個指標的基本算法都給你寫清楚了；
舉個例子，商品管理部同事在OA流程上提報了一個需求，需要監控線下門店需要淘汰商品的銷售清理進度，提交過來的報表格式如下：
用戶提交需求表樣
以下是作為數據產品經理跟用戶對接的步驟及結果：
1.?調研用戶需求的目標及價值點：根據用戶闡述的需求目的價值判斷需求是否需要進一步跟進；
- 需求背景：由于門店陳列空間限制或者商品策略調整原因會有部分商品需要淘汰，清理庫存；在發布清理通知之后，需要針對商品清理進度進行監控后作出對應問題解決方案；
- 需求目標及價值：跟蹤各門店淘汰商品清理進度，根據清理進度判斷是否需要針對淘汰商品匹配相應的促銷活動；
結合以上兩點初步判斷需求合理，需要進一步進行需求分析并 進行開發。
2.? 溝通并梳理報表字段業務邏輯：在業務層面確定報表數據內容，這一步需要更詳盡的清楚用戶數據需求每個字段對應的業務邏輯；可以分為兩個塊面:
- 數據范圍及核算條件：按上圖可以很清晰看到是要分析到每個門店的每個需要淘汰的商品，產品經理需要結合對于系統數據層面的了解進一步與用戶溝通：商品分為零食、水果、輔料，需要展現所有的商品嗎？（只展現零食）。需清理的商品需要怎么定義？（庫存大于0且非選品商品）
- 指標計算規則：指標具體的計算公式，譬如期末庫存金額=標準價*期末庫存數量，這個時候數據產品經理同樣需要結合自己對于系統數據基礎結構了解進一步引導用戶深挖他的需求——庫存數量在業務系統里面分為非限制性庫存、被凍結的庫存、質檢中的庫存，這里的庫存數量核算范圍？（取業務系統中非限制性庫存）；
經過上面兩個環節的溝通后，已經確認了需求的重要性、價值點，及需求具體的業務層面的算法，數據產品經理已經掌握了業務層面的大部分信息，這個時候就可以對于需求進行開發排期，并進入產品設計及開發階段了，但是由于臨時需求相對比較單一簡單，產品設計環節涉及到的很少，表樣基本都不會有大的改變；
至此，臨時需求對接工作基本完成；
二、項目需求對接
項目需求對接過程與臨時需求對接過程基本一致；
我所在公司信息系統包括數據部門以及各業務信息系統服務部門（ERP系統開發部、ERP系統各產品部、電商技術部門等），在各業務系統相對穩定成熟的前提下，各業務系統產品部門起到業務變革創新主導的角色，用戶在業務上存在某些痛點，將痛點反饋給到業務系統產品經理，業務系統產品經理發起項目，制定項目方案，規劃項目內容及解決方案；在解決方案中會產生數據產品需要數據團隊進行落地；上述即為數據產品項目需求產生的背景及過程；
需求到達數據產品經理手上已經完成項目立項報告、項目內容規劃、項目里程碑階段設計，數據產品經理承接數據需求實施部分的工作推進；在上述背景下，數據產品經理與用戶的對接工作更多的體現在于對業務需求內容的理解上；
以我最近對接的一個項目——產銷協同系統化為例，這個項目目標是為了解決商品銷售部門、供應計劃部門及采購部門之前產銷協同合作的工作流程及機制，為了保證這個工作流程及機制的順利運行，衍生出報表需求；項目經理與我對接的時候直接給了55張表我，告知我這是收集到的每個環節的關鍵用戶的報表需求，且已經做了核對；
收到這個需求后，在跟用戶對接過程中我做了以下幾件事：
1. 直接表明需求過多，開發資源難以匹配，要求用戶對于需求進行再一次內部評審；
2. 經過上一步后，業務將需求精簡到25張報表提報給我到，并表示無法再精簡，必須要開發出來；于是，我組織會議拉著項目負責人和關鍵業務用戶開會，了解25張表的作用及價值點；
3. 第2步溝通結束后，我針對這些報表做了初步分析和篩查，將其中8張處于總分結構的報表歸納為在一張看板層展現，7張同一緯度看單個指標趨勢的報表歸為一類自助分析工具去實現；最后25張報表變成一張看板、一個自助分析工具、10張表；并將用意反饋至用戶，與用戶統一了輸出形式，在內容滿足的情況下再次精簡應用輸出個數；
4. 與開發組協調資源，結果是只能給到一個開發同事承擔這部分的開發工作，為了避免浪費開發資源，要求用戶針對25張表給出日活承諾，同時根據日活承諾篩選出了8張高優先級的表，并與用戶確認；
最終達成一致結論——先開發8張高優先級的表，試運行1個月后，根據每張表的使用情況與日活承諾對比后再考慮是否繼續投入開發資源繼續開發其他的表；
5. 與臨時數據需求對接一致，溝通并梳理報表字段業務邏輯；但過程相比臨時需求在時間上會大大拉長；
至此項目需求用戶對接過程基本完成；
三、用戶需求對接之痛
在經過多個用戶需求滿足實施過程之后，回過頭來看一下，不禁有以下疑問：
- 需求要不要做，是由數據產品經理主觀判斷嗎?事實上，我們確實很少有拒絕用戶的時候；
- 能否做到可量化或者以某個更有說服力的方式去決定需求要不要做？
- 對于項目需求，數據產品經理完全是處于被動接需求狀態，需不需要參與到內容設計層面呢， 如果參與到內容設計層面，數據產品經理能起到什么作用呢？或者說是以什么角色去決定內容層面呢？
- 難以形成標準去判斷項目需求的合理性，只能主觀判斷，然后在開發資源限制狀況下去對用戶需求數量上做限制，甚至要求用戶做日活承諾去倒逼用戶主觀上再去斟酌需求的量，這些都只是基于需求已經形成后的一種管控手段；
- 項目需求都是基于用戶的某個業務管理的痛點， 去解決這個痛點，數據產品經理確實很能起到業務咨詢顧問的角色，可能這就是我們一直處于被動接需求的狀態的原因；這個問題應該怎么解開呢？
上述問題也確實是我所在組織目前最頭疼的問題，我們也有嘗試在跟用戶去做溝通，讓用戶承諾日活，但是我覺得這可能不是一個特別好的方式，需求都做完了，開發資源已經全部投入進去了，事后追蹤的意義是什么呢？
業務是多變的，這是難以改變的事實，按目前的情況來看，數據產品經理能做的更多的事情就是根據用戶使用情況去追責，進而約束用戶下一階段的需求量；
以上就是我作為數據產品經理在承接用戶需求的過程以及遇到的一些問題，這些問題其實一直都存在，但很多時候我們都在埋頭接需求人后開發，占用了我們大部分的時間和精力，卻沒有抬頭思考下如何去管控優化這些需求。
作者：王小涂? 公眾號：數據產品經理進階之路（ID：DATAPMZL）
本文由 @王小涂 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
大家期待已久的《數據產品經理實戰訓練營》終于在起點學院（人人都是產品經理旗下教育機構）上線啦！
本課程非常適合新手數據產品經理，或者想要轉崗的產品經理、數據分析師、研發、產品運營等人群。
課程會從基礎概念，到核心技能，再通過典型數據分析平臺的實戰，幫助大家構建完整的知識體系，掌握數據產品經理的基本功。
學完后你會掌握怎么建指標體系、指標字典，如何設計數據埋點、保證數據質量，規劃大數據分析平臺等實際工作技能～
現在就添加空空老師（微信id：anne012520），咨詢課程詳情并領取福利優惠吧！
深有體會，我是業務部門的數據支持，對內對接數據需求，并將成型的報表輸出給大部門的數據產品側。因為我具有數據處理能力，會將多數內部的臨時取數需求自我消化，固化下來的指標提給產品側。然而，在提交給產品側的時候，產品仍然承接得非?？酥?，表示資源非常非常緊張。需求對接之痛，來自多方面：1.業務在變，指標在變；2. 業務缺乏抓手，使得探索性的臨時查詢多，擠占資源。
另外我覺得，上文中的臨時查詢需求，感覺應該作為后臺產品的一部分，比如商品管理系統，應該有商品盤點功能并提供明細才對
感謝作者！寫得好詳細！感覺是回顧、提煉了自己的實際工作內容所得的經驗！很感謝作者的分享！受教了～
如果對接好需求，確定好報表字段的業務邏輯之后，能再傳授一些后續的工作內容就更感謝了?。?br /> 我今年剛畢業，現在銀行后臺做報表開發，但是想做數據產品經理，特別是偏向分析甚至智能決策的數據產品（如推薦系統）。
希望能向作者學習更多！
在我看來，想要解決總是被動接受收需求的問題，必須首先自己要對現場的業務比較熟悉才行，這樣才能主動的站在使用者的角度，發現問題，確定優先級，并解決痛點