阿里巴巴數據產品經理工做(總結篇)

PD（指產品經理，下同）自己就是在作牛作馬，關係圈異常複雜。數據PD也不例外。並且打交道的人更多。如下是我用PPT繪製的數據產品經理關係圈。

　　科普：

　　PD：對於WEB產品設計人員而言，它的意思是「產品設計人員」，即produce designer。

　　PD：在IT企業中，通常是Product Director(產品主管)或Project Director(項目主管)的意思

　　

　　一. 如何作一個好的數據產品經理？

　　PD（指產品經理，下同）自己就是在作牛作馬，關係圈異常複雜。數據PD也不例外。並且打交道的人更多。如下是我用PPT繪製的數據產品經理關係圈。若是你也作過數據產品的產品經理（好拗口），相信也有同感。既然要和這麼多人打交道，要推進數據產品的上線，數據產品經理天然有着必定的要求。

　　

　　個人體會以下——也藉此去鞭策本身在朝這個方向努力：

　　1.要極其熟悉公司業務及動向。因此要了解公司的商業模式、戰略、以及業務流程、要考覈的各類指標，以及指標背後的業務含義等。這一點，再瞭解都不夠。

　　2.要了解數據分析。好的數據PD，即便不作數據PD，也應該是個數據分析師。數據PD的一大要務就是將數據分析作成可複製，可自動運轉的系統。雖然有數據分析師們圍繞在本身周圍，可是本身也要清楚業務的問題，分別要看什麼數據，或者當數據出現後，意味着業務出現了什麼問題或者會出現什麼問題。這一點，要向最好的數據分析師們看齊。

　　3. 要了解數據倉庫及商務智能。

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

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

　　4. 要精通數據產品開發流程。數據開發+產品開發。

　　數據PD的最終目的是要作數據產品。這裏要拆開看，其一，數據產品自己也是在線可供用戶實現的產品，既然是產品，產品的整套研發思路和普通的產品沒有太大區別，用戶是誰，他們需求是什麼，知足需求須要什麼feature list，每一個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. 數據產品交付物

　　

　　來源：阿里巴巴PD