一、如何做一個好的資料產品經理？

PD（指產品經理，下同）本身就是在做牛做馬，關係圈異常複雜。資料PD也不例外。而且打交道的人更多。以下是我用PPT繪製的資料產品經理關係圈。如果你也做過 資料產品的產品經理（好拗口），相信也有同感。既然要和這麼多人打交道，要推動資料產品的上線，資料產品經理自然有著一定的要求。

我的體會如下——也藉此去鞭策自己在朝這個方向努力：

1.要極其熟悉公司業務及動向。

所以要了解公司的商業模式、戰略、以及業務流程、要考核的各種指標，以及指標背後的業務含義等。這一點，再瞭解都不夠。

2.要了解資料分析。

好的資料PD，即使不做資料PD，也應該是個資料分析師。資料PD的一大要務就是將資料分析做成可複製，可自動運轉的系統。雖然有資料分析師們圍繞在自己周圍，但是自己也要清楚業務的問題，分別要看什麼資料，或者當資料出現後，意味著業務出現了什麼問題或者會出現什麼問題。這一點，要向最好的資料分析師們看齊。

3. 要了解資料倉庫及商務智慧。

這 兩個關鍵詞背後都是龐大的體系，恐怕我短短半年的轉崗時間太短，雖然能夠對別人講解一通商務智慧產品的架構。嘴裡雖然會丟擲若干個類似於彙總，鑽取，度 量，指標，維度，緩慢變化維，層次，屬性，儀表盤等等術語，但是也不支援多幾層的知識鑽取，遇到異常問題，也不知道該從什麼地方分析原因。幸而身邊有資料 倉庫的同事，可以多多學習。這一點，沒有天花板。

而商務智慧，做為一門學科，起源於20世紀90年代，它的出發點是幫助使用者更好地獲取決策資訊，最初商務智慧的動機是為使用者提供自助式的資訊獲取方式，這 樣，使用者就可以不用依賴於IT部門去獲取定製的報表。（引自《資訊儀表盤》一書P41）。而如今，商務智慧除了提供資訊，更主要的是降低使用者獲取資料的門 檻，提升資料的實時性等方面。從降低使用者獲取資料的門檻一個方向，我們就可以做很多事情，比如如何設計資訊儀表盤（designing of information dashboard）？如何讓資料以更親和的更直觀的方式展示（資料視覺化）？如何能夠讓使用者離線訪問？如何能夠實現警戒資料的主動傳送？這一點上，花多少功夫都不多。

4. 要精通資料產品開發流程。資料開發+產品開發。

資料PD的最終目的是要做資料產品。這裡要拆開看，其一，資料產品本身也是線上可供使用者實現的產品，既然是產品，產品的整套研發思路和普通的產品沒有太大區別，使用者是誰，他們需求是什麼，滿足需求需要什麼featurelist，每個feature list的資源評估以及優先順序如何，產品的生命週期如何？這是產品開發。然後他是個資料產品，意味著這比普通的產品，多了更多的要求。在資料這個核心之外，它需要各種feature list，如訂閱，搜尋，自定義，簡訊介面，郵件介面等。但是資料這個核心，也需要一套資料開發流程。

比如：

資料來源——是否足夠，是否穩定

資料PD需要足夠了解目前的業務處理系統建設情況，以及資料來源的積累程度，用以判斷資料產品的建設時間是否合適。不合適的時機會導致專案組的重複勞動和殘缺 的資料產品誕生。資料產品是用以支援監控，分析，決策的，而業務處理系統的定位在於提升工作效率，解放工作人員手腳。業務系統採集的資料未必滿足所有分析 需要。比如或許領導要分析大量攀升的退換貨的詳細原因，而業務系統目前並沒有要求使用者在申請退換貨的時候選擇原因或只有輸入而非標準化選項，負責退換貨出 力的員工也只有在excel裡登記原因，而不是錄入到系統裡。所以可能會導致需求方要看的資料提供不出來，那麼資料pd就有必要反向驅動資料來源得以採集。

分析模型的設計—— 分析模型的好與不好，其實決定了資料產品的成敗。

在 專案中，可以由BI的資料分析師們擔綱此職責，也可以由資料PD擔綱，更多則由雙方一起確認，內容以資料分析師們為主，功能評估及優先順序、專案計劃和協 調、統籌以資料PD為主。所以資料PD要更加清楚資料分析師們所需要的需求是否能夠實現，背後的商業價值如何，並與資料開發、產品開發保持比資料分析師們 更加通暢的合作關係，能夠借力進行可行性和資源的評估。

有的時候，我們不是沒有資料，而是有了太多的資料，不知道怎麼去看。如果只是拋給使用者一堆資料，很難想象使用者會如何去解讀它。以前做互動設計的時候，我們流行一句話：把使用者當成傻瓜。

而資料平臺，因為可能本身就要求有一定的使用門檻，所以想成不會網際網路的傻瓜不太現實，那麼我們就要想成“使用者是不懂資料的傻瓜”。他們或許也能通過一串串 資料體悟到什麼，但是如果是一條上升的退款率趨勢線，或許他們會體悟到更多——畢竟，上和下本身就是直觀的。然後再想一下，如果將這條線上加上一條警戒點 的線，他們會知道從什麼時候開始資料是異常的。再然後，就要設想，當他發現從7月12日資料上升後，想幹什麼？他會不會想了解是哪個行業上升了？他會不會 想了解是那個渠道上升了？那麼，就要提供行業和渠道的選項或者對比給他。

再然後，當他過問了這個行業的負責人後，負責人想不想再瞭解是哪個供應商或者哪類商品上升了？那麼要如何將這些維度、層次都融合在一起，同時又能將使用者非常 方便地去用呢？分析模型的建設至關重要，也可以說，分析模型是前期需求分析的最有價值的產物。分析模型應該會包含幾點：

主題的劃分：

整塊分析會劃分成什麼主題，比如銷售可能會分成銷售走勢及構成分析，行業排名，商品排名等

度量及指標:

分析主題會涉及到的度量及指標的演算法、定義等（這通常會產生一份指標以及維度的定義及描述文件）

維度：

要分別從什麼維度去看這些指標和度量，如時間，渠道，這些維度是要篩選還是要對比

鑽取：

這些維度本身有沒有層次，需要不需要進行鑽取，如渠道可鑽取到渠道型別，行業可鑽取到子行業，商品類目可鑽取到商品葉子類目等

輸出：

分析需要用何種圖表進行展現

資料的ETL開發

資料的清洗，轉換，裝載流程佔用了資料產品開發的大半資源，不規範的資料來源會導致這一塊的資源更大程度的佔用。比如同樣是供應商編碼，系統之一稱為供應商編 碼，系統二命名為供貨商編碼，系統三命名為供應商ID，這三個系統同時是公司的系統，這種情況雖然想起來匪夷所思，但是現實情況卻也存在。雖然ETL開發 是DW開發工程師在做，但是作為資料PD，焉能對這些工作缺乏瞭解，對ETL工程師反饋的問題，缺乏認知，不理解對於專案的潛在風險是什麼？而且更多時 侯，當遇到資料不規範，不統一的問題，資料PD需要反向驅動業務系統進行資料規範性建設，無論是功能上，還是驅動直接的使用方——如負責錄入資料的行業小 二，建立一套錄入規範。這些工作看似和資料PD無關，我們大可以推脫說：那沒辦法，這是資料來源的問題，不是我們功能的問題。但是，使用者是有權利選擇使用不 使用你的資料產品的，當資料產品提供的資料不值得信賴的話，無疑是自取滅亡。一旦使用者對資料不信任，再想挽留他們，是很難的。即使有很多“無能為力”的借 口,我們也不能坐觀其變。

前端互動與體驗的優化

雖然內容定義好了，但是那麼多度量、指標、維度、鑽取，如何劃分資訊層級，如何劃分欄目，如何設計使用者的行為路徑？這些就不是資料分析師們的重要工作範疇。 而是互動設計師？鑑於很多資料產品專案可能會沒有互動設計師，所以資料PD應該對內容進行封裝，進行資訊架構、頁面佈局以及圖表各種功能設計。設計，然後 撰寫詳細的功能需求文件，交付給產品開發，前端開發以及資料開發，以及前端展現開發四種類型的開發人員。

資料產品的功能描述文件，除了產品開發部分，其他的就是在描述“內容”，即分析模型，除了主題、度量、維度、鑽取、篩選、輸出圖表型別，有些內容還需要詳細定義到
“排序方式” 等等細節，這就case by case來看了。

環境，技術，工具

或許做一個普通的產品，你把需求描述清楚，與產品開發工程師確認好可行性，接受資源評估就OK了。但是資料產品，受制於所部署的環境，所選型的工具，如Oracle，IBM的Cogos，以及SQL Server。其他的產品我不知道怎麼樣，我們用的是Oracle BIEE。那麼作為資料PD，是否需要了解BIEE能夠提供的功能是哪些呢？看文件，請教別人，不能知其不可而為之。另外，也需要逐漸摸透BIEE的壞脾氣，實現不了的功能，無法克服的難點等。這一點，也需要繼續瞭解，繼續學習。

二、心得總結篇

下面，談幾點我的心得總結，或許還顯得稚嫩，但是自己所得，要遠遠比看別人文章或者看書得來的深刻，記錄下來，以便於後續校驗。

1. 資料產品的價值

2. 資料產品的使用者

3. 資料產品架構

4. 資料產品風險

5. 資料產品VS業務系統

6. 資料產品專案流程

7. 資料產品交付物

原文來自產品經理沙龍，歡迎關注。