本文將數(shù)據(jù)產品經(jīng)理用戶需求對接分為兩個方面：臨時需求與項目需求，分別對其進行了介紹。

一個數(shù)據(jù)產品從無到有，經(jīng)歷的主要過程：

用戶需求調研及分析——內容設計——數(shù)據(jù)產品設計——數(shù)據(jù)產品研發(fā)——產品測試及驗收——產品運營——數(shù)據(jù)治理——產品優(yōu)化迭代。

對于發(fā)展中的數(shù)據(jù)團隊而言，用戶需求調研及分析這個過程往往由于用戶提報的需求過于具化而弱化，而變成直接與用戶對接；今天仍然從兩個方便解析與用戶對接需求的過程及問題點。

一、臨時需求對接

數(shù)據(jù)需求對比其他功能性需求最大的特點是很多情況下用戶提報的需求已經(jīng)相對明確——以報表的形式告知你報表要呈現(xiàn)什么指標、分析的維度，甚至每個指標的基本算法都給你寫清楚了；

舉個例子，商品管理部同事在OA流程上提報了一個需求，需要監(jiān)控線下門店需要淘汰商品的銷售清理進度，提交過來的報表格式如下：

用戶提交需求表樣

以下是作為數(shù)據(jù)產品經(jīng)理跟用戶對接的步驟及結果：

1.?調研用戶需求的目標及價值點：根據(jù)用戶闡述的需求目的價值判斷需求是否需要進一步跟進；

• 需求背景：由于門店陳列空間限制或者商品策略調整原因會有部分商品需要淘汰，清理庫存；在發(fā)布清理通知之后，需要針對商品清理進度進行監(jiān)控后作出對應問題解決方案；
• 需求目標及價值：跟蹤各門店淘汰商品清理進度，根據(jù)清理進度判斷是否需要針對淘汰商品匹配相應的促銷活動；

結合以上兩點初步判斷需求合理，需要進一步進行需求分析并 進行開發(fā)。

2.? 溝通并梳理報表字段業(yè)務邏輯：在業(yè)務層面確定報表數(shù)據(jù)內容，這一步需要更詳盡的清楚用戶數(shù)據(jù)需求每個字段對應的業(yè)務邏輯；可以分為兩個塊面:

• 數(shù)據(jù)范圍及核算條件：按上圖可以很清晰看到是要分析到每個門店的每個需要淘汰的商品，產品經(jīng)理需要結合對于系統(tǒng)數(shù)據(jù)層面的了解進一步與用戶溝通：商品分為零食、水果、輔料，需要展現(xiàn)所有的商品嗎？（只展現(xiàn)零食）。需清理的商品需要怎么定義？（庫存大于0且非選品商品）
• 指標計算規(guī)則：指標具體的計算公式，譬如期末庫存金額=標準價*期末庫存數(shù)量，這個時候數(shù)據(jù)產品經(jīng)理同樣需要結合自己對于系統(tǒng)數(shù)據(jù)基礎結構了解進一步引導用戶深挖他的需求——庫存數(shù)量在業(yè)務系統(tǒng)里面分為非限制性庫存、被凍結的庫存、質檢中的庫存，這里的庫存數(shù)量核算范圍？（取業(yè)務系統(tǒng)中非限制性庫存）；

經(jīng)過上面兩個環(huán)節(jié)的溝通后，已經(jīng)確認了需求的重要性、價值點，及需求具體的業(yè)務層面的算法，數(shù)據(jù)產品經(jīng)理已經(jīng)掌握了業(yè)務層面的大部分信息，這個時候就可以對于需求進行開發(fā)排期，并進入產品設計及開發(fā)階段了，但是由于臨時需求相對比較單一簡單，產品設計環(huán)節(jié)涉及到的很少，表樣基本都不會有大的改變；

至此，臨時需求對接工作基本完成；

二、項目需求對接

項目需求對接過程與臨時需求對接過程基本一致；

我所在公司信息系統(tǒng)包括數(shù)據(jù)部門以及各業(yè)務信息系統(tǒng)服務部門（ERP系統(tǒng)開發(fā)部、ERP系統(tǒng)各產品部、電商技術部門等），在各業(yè)務系統(tǒng)相對穩(wěn)定成熟的前提下，各業(yè)務系統(tǒng)產品部門起到業(yè)務變革創(chuàng)新主導的角色，用戶在業(yè)務上存在某些痛點，將痛點反饋給到業(yè)務系統(tǒng)產品經(jīng)理，業(yè)務系統(tǒng)產品經(jīng)理發(fā)起項目，制定項目方案，規(guī)劃項目內容及解決方案；在解決方案中會產生數(shù)據(jù)產品需要數(shù)據(jù)團隊進行落地；上述即為數(shù)據(jù)產品項目需求產生的背景及過程；

需求到達數(shù)據(jù)產品經(jīng)理手上已經(jīng)完成項目立項報告、項目內容規(guī)劃、項目里程碑階段設計，數(shù)據(jù)產品經(jīng)理承接數(shù)據(jù)需求實施部分的工作推進；在上述背景下，數(shù)據(jù)產品經(jīng)理與用戶的對接工作更多的體現(xiàn)在于對業(yè)務需求內容的理解上；

以我最近對接的一個項目——產銷協(xié)同系統(tǒng)化為例，這個項目目標是為了解決商品銷售部門、供應計劃部門及采購部門之前產銷協(xié)同合作的工作流程及機制，為了保證這個工作流程及機制的順利運行，衍生出報表需求；項目經(jīng)理與我對接的時候直接給了55張表我，告知我這是收集到的每個環(huán)節(jié)的關鍵用戶的報表需求，且已經(jīng)做了核對；

收到這個需求后，在跟用戶對接過程中我做了以下幾件事：

1. 直接表明需求過多，開發(fā)資源難以匹配，要求用戶對于需求進行再一次內部評審；

2. 經(jīng)過上一步后，業(yè)務將需求精簡到25張報表提報給我到，并表示無法再精簡，必須要開發(fā)出來；于是，我組織會議拉著項目負責人和關鍵業(yè)務用戶開會，了解25張表的作用及價值點；

3. 第2步溝通結束后，我針對這些報表做了初步分析和篩查，將其中8張?zhí)幱诳偡纸Y構的報表歸納為在一張看板層展現(xiàn)，7張同一緯度看單個指標趨勢的報表歸為一類自助分析工具去實現(xiàn)；最后25張報表變成一張看板、一個自助分析工具、10張表；并將用意反饋至用戶，與用戶統(tǒng)一了輸出形式，在內容滿足的情況下再次精簡應用輸出個數(shù)；

4. 與開發(fā)組協(xié)調資源，結果是只能給到一個開發(fā)同事承擔這部分的開發(fā)工作，為了避免浪費開發(fā)資源，要求用戶針對25張表給出日活承諾，同時根據(jù)日活承諾篩選出了8張高優(yōu)先級的表，并與用戶確認；

最終達成一致結論——先開發(fā)8張高優(yōu)先級的表，試運行1個月后，根據(jù)每張表的使用情況與日活承諾對比后再考慮是否繼續(xù)投入開發(fā)資源繼續(xù)開發(fā)其他的表；

5. 與臨時數(shù)據(jù)需求對接一致，溝通并梳理報表字段業(yè)務邏輯；但過程相比臨時需求在時間上會大大拉長；

至此項目需求用戶對接過程基本完成；

三、用戶需求對接之痛

在經(jīng)過多個用戶需求滿足實施過程之后，回過頭來看一下，不禁有以下疑問：

• 需求要不要做，是由數(shù)據(jù)產品經(jīng)理主觀判斷嗎?事實上，我們確實很少有拒絕用戶的時候；
• 能否做到可量化或者以某個更有說服力的方式去決定需求要不要做？
• 對于項目需求，數(shù)據(jù)產品經(jīng)理完全是處于被動接需求狀態(tài)，需不需要參與到內容設計層面呢， 如果參與到內容設計層面，數(shù)據(jù)產品經(jīng)理能起到什么作用呢？或者說是以什么角色去決定內容層面呢？
• 難以形成標準去判斷項目需求的合理性，只能主觀判斷，然后在開發(fā)資源限制狀況下去對用戶需求數(shù)量上做限制，甚至要求用戶做日活承諾去倒逼用戶主觀上再去斟酌需求的量，這些都只是基于需求已經(jīng)形成后的一種管控手段；
• 項目需求都是基于用戶的某個業(yè)務管理的痛點， 去解決這個痛點，數(shù)據(jù)產品經(jīng)理確實很能起到業(yè)務咨詢顧問的角色，可能這就是我們一直處于被動接需求的狀態(tài)的原因；這個問題應該怎么解開呢？

上述問題也確實是我所在組織目前最頭疼的問題，我們也有嘗試在跟用戶去做溝通，讓用戶承諾日活，但是我覺得這可能不是一個特別好的方式，需求都做完了，開發(fā)資源已經(jīng)全部投入進去了，事后追蹤的意義是什么呢？

業(yè)務是多變的，這是難以改變的事實，按目前的情況來看，數(shù)據(jù)產品經(jīng)理能做的更多的事情就是根據(jù)用戶使用情況去追責，進而約束用戶下一階段的需求量；

以上就是我作為數(shù)據(jù)產品經(jīng)理在承接用戶需求的過程以及遇到的一些問題，這些問題其實一直都存在，但很多時候我們都在埋頭接需求人后開發(fā)，占用了我們大部分的時間和精力，卻沒有抬頭思考下如何去管控優(yōu)化這些需求。

作者：王小涂? 公眾號：數(shù)據(jù)產品經(jīng)理進階之路（ID：DATAPMZL）

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

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