標題：資料產品管理的現狀

原文: An Introduction to the Data Product Management Landscape

來源: https://blog.insightdatascience.com/an-introduction-to-the-data-product-management-landscape-ef930afe6de5

導讀：

資料的規模化使用有利於降低成本（如資料中心執行管理的最佳化）、提高收入（如電子商務領域的交叉銷售與追加銷售）、推動技術進步（如自動汽車的深度學習功能）。
雖然每個資料用例都要求不同形式的技術理解和域理解（下文將會涉及），但就一般情況而言，專案管理技能仍然是成功的主要原因。
基礎設施專案經理來說，最終交付的產品應該是一個通用的資料基礎設施，它可以永久地收集、儲存、處理相關資料，從而降低用例。有了這個產品，團隊就能將重點放在原始資料的使用上，而不是收集和儲存。

原文翻譯：

資料產品的製作早在人工智慧初露鋒芒之前就已經開始了。但是，資料產品管理崗的設立與完善則是相對新近的事。這是直接發揮資料既是關鍵產品、又具備比較優勢的新職能。今天，資料的規模化使用有利於降低成本（如資料中心執行管理的最佳化）、提高收入（如電子商務領域的交叉銷售與追加銷售）、推動技術進步（如自動汽車的深度學習功能）。

在人工智慧的熱潮中，動物分類演演算法與Go-playing智慧體代表了資料產品管理的兩大基石。但演演算法只是整個資料產品生態系統中的一部分。在大部分商業場景下，演演算法模型可能只佔結果的極小部分。一家公司要想讓資料像水流一樣暢通無阻地流動，必須具備一個大型支援生態體系，並完成三大任務：

第一，收集和儲存於原始事件與交易行為併為之服務。
第二，與相關團隊共同處理、開發和分享資料。
第三，製作並部署演演算法模型，併在生產過程中加以監督。

這三項工作，最終都要有看得見、摸得著的商務成果。在數以萬計的方向裡，企業應該先做什麼，再做什麼？

Insight企業資料平臺已幫助上萬名員工成功轉型資料產業，找到各式各樣的崗位。在這個平臺上，業界對能為資料團隊掂量出輕重緩急、處理好協調問題的專案經理的需求增加。這篇文章試圖描述理想的行業專案經理的形象，並闡明其重要意義。

資料產品管理究竟有什麼用？

如果是小型專案團隊，沒有正式的專案經理，那麼像機會評估、技術路線圖、股東管理這些常規性的產品責任基本上是技術經理和個體工作者來做。放在大型團隊裡，這種分工就有很多不足，最主要的是以下四點：

其一，產品工作佔據所有個體工作者的時間
其二，不是每個個體工作者都有能力或者有意願從事規模性的產品工作。
其三，企業單元和技術團隊之間的距離越拉越大。
其四，個人技術團隊之間的距離越拉越大。

在這個拐點上，企業有兩條應對之道。一是把任務分解成若干個子專案，並確保個體工作者或小型技術團隊有能力全程跟進，不必涉及其他團隊，也就不用設立某種形式的總協調員。

第二條應對方案是建立一個正式的產品管理組織，專門負責維護資料源路線圖，併在各團隊與個體工作者之間協調任務的執行情況。這種方案對於電子商務和按需服務這種功能高度交叉的產品來說尤為普遍。

第一種方案要想發揮出全部威力，必須得是某個體工作者能夠對產品進行調整，迅速取得客觀的執行反饋，併在最差的情況下以不作大改為前提完成回滾。這種方案或許適用於免費的社交網路產品，但對於付費型、任務繁重的產品（如按需服務），基本上是毀滅性的。比來比去，大部分規模性的公司還是選擇了第二種方案，專門成立一個產品管理組織。

資料專案經理的角色發展到了哪個階段？

在資料演進的初期，像軟體工程、軟體資料、軟體建模這種無關的資料技能，都是同屬於資料科學的門類。現在，它們均已快速發展成為獨立的崗位，比如資料工程師、資料科學家、研究人員、機器學習工程師等等。

類似的潮流也正出現在產品管理業內部。在資料專案經理這一寬泛的崗位類別之下，出現了若干個子崗位，例如基礎設施、分析、應用機器學習/人工智慧、探索與標準化、平臺等。這些具體化的過程與技術專案崗曾經的演變如出一轍。不同的是，對資料專案經理崗來說，上述頭銜還沒有塵埃落定。其發生髮展，不過是反映了資料產品工作相對獨特的分工現象。

雖然每個資料用例都要求不同形式的技術理解和域理解（下文將會涉及），但就一般情況而言，專案管理技能仍然是成功的主要原因。我要強調這一點，因為一個資料專案經理每天的主要工作，還是處理優先順序、溝通、股東管理、設計以及規範。

基礎設施

規模條件下，個體專案團隊的用例和資料需求各不相同。但為了儘快啟動，這些團隊往往傾向於打造獨立的資料基礎設施。這種傾向會造成重覆勞動、資料孤島，最終各個團隊都會遭遇同樣的資料規模性問題。

對基礎設施專案經理來說，最終交付的產品應該是一個通用的資料基礎設施，它可以永久地收集、儲存、處理相關資料，從而降低用例。有了這個產品，團隊就能將重點放在原始資料的使用上，而不是收集和儲存。

基礎設施專案經理的關鍵績效指標是資料可用性、規模性與可靠性。基礎設施專案經理應該精通資料工程技術，例如資料接入、批次實時處理、檔案系統與傳送。

分析

當代職場，決策者越來越依靠資料。從戰略到產品和運營，從線下到實時，大量決策都是建立在分析的基礎上。如果說，基礎設施專案經理的職責是確保查詢任務能夠在海量資料背景下有效執行，那麼專案分析經理則專註於將這些原始資料轉化成可操作的見解，提供給經理、專案經理、運營團隊等決策方。除此之外，專案分析經理還積極投身於關鍵績效指標的認定工作與資料的探索工作，為商務決策建言。

在產品建造的語境下，一名專案分析經理的職責是建立一個自助分析、定製儀錶盤和報告工具的混合體，促進觀點在全公司層面的提煉與分享。專案分析經理涉及到多元化的相關方，既有睿智的資料科學家，也有經理這種“只讀型”的消費者。

專案分析經理的關鍵績效指標，主要是由查詢任務的執行數量，傳送的報告數量等證明該專案便捷性的因素。正是由於這種便捷性，資料使用者才能從原始資料中提煉出需要的觀點。

應用機器學習/人工智慧

某些產品和功能本身會自然而然地從機器學習/人工智慧中尋找解決方案，例如搜尋、推薦、詐騙檢測等。應用機器學習專案經理專註於把資料用在既有產品上——例如分析聊天記錄，使客戶服務路由實現自動操作，以及用高階人工智慧設計出一種全新體驗——例如照片分享軟體的篩選器。說到底，他們的工作就是為了直接改進面向客戶的功能的關鍵指標。

致力於上述功能的專案經理雖然並不總是冠以資料專案經理的名號，但他們一般都對資料科學的工作流及其機器學習模型有著深刻理解。他們天生就知道如何利用機器學習的力量，並且比起嚴守規則的職員，他們更懂得如何在極限邊緣設計產品，提供優質的使用者體驗。

平臺

公司規模越大，對標準化框架的需要也就越現實，特別是在實驗和機器學習方面。這兩個工作流程的用例往往與產品自身的本質緊密結合在一起。正是基於這個原因，開源方案才會這麼難以滿足眾人的需求。

考慮到這個背景，大公司的個體資料團隊會先著手建設專屬的一次性系統，從而導致重覆勞動和拖沓的生產週期。因此，谷歌、臉書、Uber之流已經正式把目光轉向平臺——以通用的框架來減少花在加工、呼叫、監視等普通任務上的精力。

之所以建立這些平臺，目的之一就是為了取消管理資料、呼叫和監視結果的必要性，讓資料團隊能夠把重心放在模型和實驗上。還有一個目的，就是因為有了這些平臺，所有使用者都可以獲取通用資料和特徵，從而增強了可重用性。

平臺專案經理的工作首先是證明平臺如何發揮用途，然後是讓早期使用者願意付出嘗試。一旦平臺到達拐點，專案經理的角色就轉變為找出舉有高回報率的公分母，並將其嵌入平臺。平臺專案經理的關鍵績效指標包括：平臺上執行的模型、實驗、投入市場所需的平均時間等。

標準化與探索

這也是規模團隊的一個問題。公司越大，個體團隊和人員所創造的資料量也會出現指數級的增長。資料的迅速輸出造成一個問題：遍尋公司上下，沒有一個中央場所可以檢視到全部資料。

如果缺少一個記載、整合、顯示海量資料的結構，那麼組織對於資料源的掌握情況就受制於資料擁有者。結果，資料真正意味著什麼，從何而來，有多可信，這些問題全都變得不確定。不僅如此，如果最熟悉那塊資料的員工離職，關於這些資料源的知識也將一同消失。第三個常見的問題是，使用了相同資料的團隊對於本質上一樣的指標往往會給出不同定義。例如，最後七天在這個組可能叫做“整整最後七天”。到了另一個組，就可能叫做“最後168個小時”。

資料標準化與探索專案經理的職責是確保整個公司意識到資料的存在，並且以一套固定的方式使用這些資料。這個崗位經常生產資料目錄和資料通道，為資料、儀錶盤和指標的探索與定義提供便利條件，同時也負責識別和聯絡資料所有者，以便建立進一步對話。

資料通道的一個高階版本是降低計算指標的獲取難度，並將其融合到建模、分析等各個用例中。

結語

資料產品管理依然在發展之中，本文也無意窮盡業界資料產品崗位的所有內容。資料專案經理可以是上述職責的混合體。至於是哪些職責，取決於公司發展階段和組織結構。分析可以是基礎設施的一部分，標準化與探索也可以是平臺的一部分。而應用機器學習專案經理也可能負責整合資源，以構築基礎設施和調配環境，為模型的生產提供必要條件。

說到底，這些崗位都要創造一場有價值的、以資料為基礎的使用者體驗，也要掃除所有障礙，確保團隊能夠提供這份價值。

「完」

本次轉自：品覺微信公眾號（pinjueche.com）