數據分析師轉數據產品，面試問什么？

編輯導語：數據分析師轉行數據產品的比例還是比較高的，由于專業知識的優勢，所以轉行融合的較快；本文作者分享了關于數據分析師轉數據產品時，面試需要注意的一些問題，我們一起來看一下。

找我溝通過的，想轉行做數據產品經理的同學中， 數據分析師是占比很高的一個群體，數量上僅次于C端產品經理 。

相比其他職位，數據分析師在基礎知識和能力方面比較有優勢，與數據產品經理的工作內容重合度很高，所以還是比較容易轉到數據產品經理領域的。

不過呢，畢竟數據分析師與數據產品經理的工作性質還是有點區別的，所以也才有了這次溝通的內容。

來溝通的同學，簡單說一下他的工作背景：目前在已在初創型公司工作，公司的主營業務是一個SaaS平臺，而這位同學做的是數據分析工作，之前還做過數據運營和部分增長運營工作；他想咨詢的問題，主要是目前想轉數據產品經理，但是之前沒有相關經驗，所以想咨詢一下有什么學習建議。

一、從“數據分析師”到“數據產品經理”

從數據分析師轉數據產品經理，我覺得有三個方面需要重點關注：

01

當然是產品經理的工作流程。每個職業都有自己的工作方法論和基本流程，產品經理當然也有自己的獨到之處。

經過這么多年的發展，產品經理在用戶管理、需求管理、設計管理、項目管理等方面，形成了一套比較完整的工作體系；這對于數據分析師來說是最欠缺的部分，畢竟數據產品經理也是產品經理。

其中幾個比較重要的點，包括：

• 產品需求文檔的編寫（Product Requirement Document，PRD）；
• 工具軟件和產品交互原型設計，比如畫原型用的Axure（跨平臺，包括Windows和macOS）和Sketch（僅包括macOS）；
• 研發項目管理，比如需求評審，項目排期，各階段測試，線上驗收等；
• 產品上線后的產品運營，比如收集用戶反饋，競品調研，產品版本迭代等；

02

是產品經理與分析師的工作目標的差異。數據產品經理雖然設計的是分析工具、提供的是分析服務，但是更關注尋找數據分析方法的共性，再把共性做成功能。

舉個例子，對于數據分析師來說，更關注如何完成一份數據分析。其中涉及到對于業務邏輯的理解、數據處理能力、分析總結能力等多方面能力；對于經驗豐富的數據分析師，會逐漸形成自己的 SOP （Standard Operating Process，標準作業流程）；通過SOP來規范團隊的數據分析過程，并實現控制數據分析成果的質量。

而對于數據產品經理，這方面的要求會稍微高一些；比如用戶分析、行為分析、留存分析、轉化分析 ，數據產品經理不僅要知道這些分析過程具體是怎么做的，還要具備總結和提煉的能力，找到這些分析方法中的共性和個性。

其中，共性的部分會變成技術上的一個通用服務 ，而個性化的部分就要根據具體要求分別定制了；最終，再把通用和定制的部分組合起來，就變成了分析工具。

這個過程說起來簡單，但是也有一些典型錯誤，包括：

1）抽象不足

抽象不足導致的結果，就是我們設計的數據產品不是覆蓋一類分析場景，而是只能覆蓋一個分析場景。

當分析需求變化時，我們又要去設計新的功能模塊來滿足需求；因此，當這個問題發生時，最明顯的表現就是整個研發團隊的工作完全沒有節奏，完全是“問題驅動”的到處救火而已。

例如：在用戶分析、行為分析等典型分析場景中，都有圈選人群的需要；如果不將這部分抽出來做成通用服務，那么每個模塊都需要單獨設計人群的計算，存儲等功能；不僅浪費研發資源，也會讓系統維護工作量翻倍。

2）抽象過度

研發出來的數據產品運營根本不會用，往往是對分析過程的過度抽象導致的；過度抽象之后，分析產品讓實際用戶感到有距離感，無法與自己的業務場景和分析思路對應起來。

例如：在圈選人群的功能中，如果我們沒有使用“用戶標簽”、“用戶屬性”這樣容易理解的業務概念，而是使用了“數據表”、“數據字段”這些技術詞匯，對于運營和業務同學就很難用的明白了。

3）發展不均衡

理想是美好的，但現實是殘酷的；抽離通用服務的本意是減少重復工作、降低維護成本、降低系統復雜度；但是，要想讓通用服務“立得起、扛得住、跑得穩”，需要投入更多人力、聘請經驗更豐富的工程師，進行充分地積累、總結和沉淀才能實現；不少企業或團隊，意識有了、系統也拆出來了，卻發現現有的資源和能力沉淀根本不足以應付多變的環境。

例如：還用全選人群的例子，本來是想把人群圈選作為一種通用服務，但是獨立出來之后才發現，圈人的條件有人口統計屬性、業務屬性、算法打標、外部數據 等很多種；憑著原來的團隊人力和能力儲備，根本無法一下支撐這么多類型。

那么問題來了，那些正在進行中的業務，是要切換到通用服務呢？還是繼續用自己的呢？

從2019年開始中臺的概念很火，其實中臺的設計理念，也是上面提到的抽離共性的理念；因此，在實施中臺的過程中，也經常會遇到上面提到的那些問題。

比如抽象不足，那么必定有些業務場景是不能覆蓋的，需要中臺團隊和業務團隊一同快速迭代；再比如，有些團隊在實施中臺之前發展較快，基礎水平已經超過其他業務，那么中臺的技術水平就得與之看齊，不然就要這部分業務做出犧牲。

最后再強調一下第二點的核心：抽離通用是為了減少重復工作、降低維護成本、降低系統復雜度；因此，數據產品經理的工作，需要十分關注短期/長期價值，以及投入產出比ROI。

03

是了解一下現有的各種數據產品怎么設計，也就是需要了解競品；這一點是數據產品經理的必修課，當然也是數據分析轉數據產品的必修課；相比前面的第二點，第三點的內容更具體。

比如，以下幾方面是數據產品經常遇到的困難：

1）如何拆解數據分析的拆解？

每種常見的數據分析，都有自己的標準步驟。經驗豐富的數據分析師會把自己工作整理為SOP，而數據產品經理則會根據按照這樣的標準步驟設計產品功能；在這一點上，數據分析是與產品經理有些相似。

例如，一個標準的用戶畫像分析，就包括人群圈選、確定分析維度、數據準備、數據看板/分析報告制作等基本步驟；如果做成系統功能，那么可能在數據看板上在增加一些其他功能，比如人群下鉆。

2）如何幫助用戶找到自己想要的數據？

這個問題看似簡單，其實還挺復雜；數據分析師在做分析的時候，都會自己做數據探查，了解要用到的數據庫、數據表和字段等；之后再使用數據的時候，就能得心應手了；但是，數據產品的用戶可不是都具備這樣的習慣和能力，因此，在數據產品中，通常都要設計輔助用戶選擇數據的工具。

如名稱搜索、展示數據表和字段的元數據、提供樣例數據等等；這些功能的設計，對于數據分析師角色是不需要考慮的，但對于數據產品經理來說是需要重點考慮的東西。

3）如何平衡大數據量與交互體驗？

數據產品需要處理和展示的數據量越來越大，日常處理的數據量動輒上TB，而產品頁面上的各種表格、列表、菜單中的內容也越來越多；如何讓用戶更方便地找到自己想要的東西變得越來越難，如何在頁面上增加導航、分組、搜索這些基本功能，就是數據產品經理在設計分析工具的時候需要考慮的問題了。

最常見的PV/UV數據來說，一個公司的核心App，至少幾十個頁面；如果還有各種臨時的活動頁面，加起來輕松破百。那么在眾多的頁面當中，如何讓用戶快速找到自己想要的頁面呢？這涉及到從頁面管理、數據采集管理和分析工具交互三個方面的配合。

類似這些問題，我們不必自己從頭思考解決方案，可以先參考市面上已有的數據產品；不過，更多的數據產品是不對外的，只服務公司內部，像神策分析、GrowingIO、友盟這種工具平臺，以及發布在阿里云、騰訊云等公有云平臺上的產品只占少數。

因此，學習和參考的過程確實會花費一些時間。除了直接參考公開產品提供的文檔和材料，還可以多參加一些行業峰會。

二、其他建議

前面通過比較數據分析師和數據產品經理，給出了一些轉行需要重點關注和補充的關鍵點。

除了上面的幾條，另外我建議，就是：如果能在公司內部轉崗，就盡量先在公司內部轉。

直接通過跳槽轉的風險更大。這種風險來自于幾方面：

第一，每家公司內的具體情況都不一樣，而且差異很大；前面總結的幾條問題，在各家公司的表現都不一樣；因此，即使你在上一家公司做得非常出色，換到下一家公司也未必做得好；所以，相比之下，還是在熟悉的環境中挑戰新的角色勝算更大。

第二，針對中小型互聯網公司，可能還沒有專門設立“數據產品經理”職位這種Title，這也是想要跳槽轉行的常見理由；但能否成功轉行，最核心的變化還是工作內容；因此，能夠最快上手做一些數據產品經理的工作，這才是轉行的最佳路徑；更何況，數據分析本身與數據產品經理的跨度已經不大了，應該多關注實際在做的事情。

第三，并不是到了所謂的“大廠”或者垂直領域的領頭公司，才有機會處理“數據問題”；大廠對于常見的數據問題，可能已經有很成熟的解決方案了，幾乎沒有從0到1的機會，這就導致能獲得的實戰經驗會很有限。

另外，大廠的數據問題可能更復雜，而小廠的問題則更聚焦，反而更適合剛轉行的同學上手；當然，如果能力足夠強，作為數據分析師的經驗也足夠豐富了，那么挑戰一下大廠的復雜狀況順便拿一下大廠的品牌背書，也是不錯的；這個門檻，一般4-5年經驗比較合適。

三、意外的突破

在交流的最后，這位同學突然想到自己的公司最近注冊用戶比較多，而他們做的又是toB的業務，所有銷售團隊對用戶試用產品的過程有大量數據分析需求；所以想到了，可以在今年年底的最后幾個月，做一個用戶畫像和RFM的數據產品，交給公司的銷售團隊使用。并以此來作為自己轉換角色的“跳板”。

應該說，這位同學還是很幸運的，這是一個非常好又非常難得的切入點；因為數據平臺本來就是很基礎性的平臺，不管大廠還是小廠，一旦基礎平臺穩定下來，就極少再做重大調整，更不要說推翻重來了，所以遇到針對某個團隊建設一個新平臺的機會真的不多。

 

作者：李陽，微信公眾號：數據有毒（shujuyoudu）

本文由 @李陽 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議