談談如何像對待產品一樣對待資料

採用將資料視為產品的組織方法不僅僅是資料行業的流行趨勢，也是有意識的思維方式轉變，可以提高資料民主化和自助服務的能力，提高資料質量，從而可以準確地做出決策，並擴大資料在整個組織中的整體影響。

在過去的幾十年裡，大多數企業都將資料儲存在孤島中。資料分析團隊為業務部門服務，即使資料對決策變得越來越重要，資料團隊依然像是提供服務的角色，而不是合作伙伴。在數字經濟時代，資料對企業來說不再是次要角色。憑藉更好的工具、更多樣化的角色以及對資料潛力的更清晰理解，許多企業已經開始將整個資料生態系統視為公司技術堆疊中必要的元素。最具前瞻性的團隊正在採用一種新正規化：將資料視為產品。這是目前資料社群的熱門話題，幾位行業領導者討論了資料即產品並揭示了他們在現實世界中對資料的看法並將這種新方法帶入日常工作。

行業領導者如何將資料定義為產品

西雅圖的貨運市場 Convoy 的資料平臺產品負責人查德·桑德森：

圍繞將資料視為產品的定義，有兩種方法：第一種方法，有一個外部或內部的產品或服務來生成資料，這意味著資料包括整個管道是產品的一部分。因此它必須遵守與應用程式程式碼相同的嚴格級別。它需要 SLA，需要良好的測試，需要良好的監控和文件等等。第二種方法，可以將任何為客戶提供服務的程式碼庫的輸出視為產品。例如，資料倉儲實際上只是一個程式碼庫，主要由 SQL 組成，為使用該資料做出業務決策的其他分析師、資料科學家和產品經理等內部客戶提供服務。因此，任何被推送到公司可以訪問的“生產資料環境”的都是產品。因此，如果正在使用像 Mode 或 Metabase 這樣的儀表板工具，並且正在編寫 SQL 並將該儀表板推送到其他人可以訪問的公共環境，那麼這也是一種產品。因此，它也必須受到與任何其他產品相同的嚴格程度。這兩種方法都與過去 10 年或 20 年前對資料的思考方式截然不同。

Uber 資料平臺團隊前產品經理Atul Gupte對資料產品經理的定義：

“資料產品經理是專門負責回答以下問題的角色：

存在哪些資料?

誰需要這些資料?

這些資料流向哪裡/從哪裡流出?

這些資料有什麼用?

有沒有一種方法可以更輕鬆地使用/訪問這些資料?

該資料是否合規和/或可操作?

我們如何才能更快地讓資料對公司的更多人更有用?

資料產品經理透過為員工構建內部工具和平臺來回答這些問題。

一些資料產品經理支援資料分析師和資料科學家，另一些則支援運營團隊、軟體團隊或者高管。他們通常來自傳統 B2B 產品管理、內部工具產品管理、資料分析或後端工程等背景。但是，不是在與我們傳統上定義為“客戶”的人打交道，而是在與“資料消費者”打交道——換句話說，員工使用的產品可以理解公司的資料。

Retool 的資料負責人Justin Gage：

資料作為產品的概念可以幫助澄清資料團隊做什麼以及他們應該專注於執行什麼任務的問題。“資料即產品 (DaaP) 是最容易理解的模型：資料團隊的工作是提供公司所需的資料，無論出於何種目的，無論是制定決策、構建個性化產品還是檢測欺詐。這聽起來像是資料工程，但事實並非如此：資料科學家還提供資料作為產品，只是以不同的方式打包。

在 DaaP 模型中，公司資料被視為一種產品，資料團隊的作用是以促進良好決策和應用程式構建的方式向公司提供該資料。該模型的一些重要特徵：

• 資料具有來自整個資料團隊的 SLA

• 資料流是單向的，從資料團隊到公司

• 領域專業知識對資料團隊成員的作用

雖然這些定義中的每一個都有其自身的細微差別，但顯然有一些關鍵要點：將資料視為產品涉及服務內部“客戶”(資料消費者)，支援決策制定和其他關鍵功能，以及應用 SLA 等嚴格標準。

實現資料即產品方法的 5 種方法

從這些資料領導者和其他人的對話中，可以確定現代資料團隊可以將這種方法應用於他們自己的組織的五種關鍵方式。

1) 與利益相關者保持一致

當資料是產品時，內部客戶也是利益相關者。在制定資料產品路線圖、制定 SLA 並開始將資料視為產品時，優先與關鍵資料消費者合作。

這意味著產品經理將作為企業專門負責資料產品管理的角色——以充分了解內部客戶的需求、關注點和動機。

需要清楚地瞭解誰在使用資料、如何使用以及出於什麼目的。這將幫助瞭解需要構建哪些型別的資料產品來滿足這些需求。

這種理解還可以幫助我們採用資料講故事。軟體、產品和使用者體驗團隊使用講故事的做法，透過不同的視角來分享他們的工作背景，這將幫助利益相關者根據對他們最重要的事情來理解其價值。利益相關者資料應該被優先考慮，並證明將資料視為產品所需的投資是合理的。

例如，查德·桑德森 (Chad Sanderson) 將講故事描述為一種非常寶貴的工具，可以說服利益相關者投資於資料基礎設施，而不是更華麗的機器學習模型或有望產生數百萬美元的新功能。

“要扭轉這種說法並將資料質量置於同等地位需要做很多工作……在某些情況下，我透過關注我們公司的故事以及我們的資料科學家和分析師的故事來解決這個問題。當他們建立模型時，這些模型真的值得信賴嗎?我們在多大程度上信任構成驅動我們業務決策的機器學習基礎的資料?所以我試著講一個非常好的故事，一個緊湊的敘述，並附有來自公司的明確例子，這些例子實際上與產生收入有關。所以最終我們可以說，看，提高我們的資料質量可能對收入產生可觀察、直接、可衡量的影響。

2)應用產品管理思維

將產品管理思維應用於構建、監控和衡量資料產品的方式。因此，在構建管道和系統時，請使用與生產軟體相同的經過驗證的流程，例如建立範圍文件並將專案分解。

Ironclad 的首席資料分析師Jessica Cherny描述了她公司的敏捷工作流程。

“我們在內部將資料視為一種產品，這意味著將產品管理原則應用於資料和資料團隊。因此，當我們有一個需要資料的大型戰略專案時，我們會建立資料範圍文件，就像產品經理會建立規範一樣，並與合適的利益相關者一起。我們不斷與工程師和產品經理進行迭代，以確保它是跨職能的、與利益相關者保持一致的輸出——而不是讓資料人員在孤島中工作而不與任何人互動。”

與工程流程類似，資料團隊在構建管道時應考慮可擴充套件性和未來用例。根據 Chad 的說法，這可能代表著資料團隊過去處理工作方式的重大轉變。

“通常情況下，實際進入生產資料庫的資料只是工程師在沒有真正考慮的情況下丟擲的服務級別事件。因此，隨著公司的發展，資料模型變得如此混亂的一個重要原因是，我們通常首先專注於快速構建服務，然後批判性地思考資料。這種將資料作為產品的想法是一種開始改變這種狀況的持續轉變。”

SeatGeek 的高階資料和分析工程師Kyle Shannon說：由於資料團隊的快速增長，他的公司正專注於可擴充套件性。

“我們真的在努力瞭解如何更好地吸引新人加入，並制定更好的流程，使資料更容易被發現和訪問。在一家公司工作了很長時間的人知道去哪裡尋找資訊，但如果你一年僱用 20 或 30 名資料團隊成員，真的很難說。因此，在構建資料產品時，必須記錄所有內容並確保非常清楚——正在刪除冗餘或可能在此過程中發現的任何問題。”

要採用的另一種產品思維方式是在開始構建任何新資料產品之前設定與業務目標一致的 KPI。正如 Chad 之前所述，講故事有助於說明投資資料質量的潛在好處，但大多陣列織仍希望成熟的團隊能夠衡量其計劃的財務影響。

許多資料團隊正在採用與資料質量相關的 KPI，例如計算資料停機的成本，資料不完整、錯誤、丟失或其他不準確的時間，或者透過衡量資料團隊成員花費在故障排除或修復資料質量上的時間問題，而不是專注於創新或構建新的資料產品。

為資料設定基線指標將有助於量化資料計劃隨時間的影響。只需確保這些指標在所有用例中一致應用，尤其是擁有中央資料平臺的情況下。

3) 投資自助服務工具

為了讓資料脫離孤島並作為有價值的產品來處理，業務使用者需要能夠自助服務並滿足他們自己的資料需求。使非技術團隊能夠訪問資料的自助服務工具使資料團隊能夠專注於增加價值的創新專案，而不是作為滿足臨時請求的按需服務。

自助工具也是資料網格概念的主要原則之一——一種去中心化資料架構的新方法。Mammad Zadeh是 Intuit 資料平臺團隊的前工程副總裁認為自助服務工具是資料架構和資料產品不可或缺的一部分。如他所建議的那樣，“我們在中央資料團隊中，應該確保資料的生產者和消費者都可以使用正確的自助服務基礎設施和工具，以便他們可以輕鬆地完成工作。為他們配備合適的工具，讓他們直接互動。”

4)優先考慮資料質量

將資料作為產品處理的一個關鍵組成部分是將嚴格的標準應用於整個生態系統，從攝取到面向消費者的資料交付。正如我們之前在講故事的背景下所討論的那樣，這意味著在整個資料生命週期中優先考慮資料質量和可靠性。

公司可以透過根據資料可靠性成熟度曲線對映他們的進度來評估當前的資料質量狀態。簡而言之，該模型表明資料可靠性有四個主要階段：

#1 反應型，團隊將大部分時間花在響應消防演習和分類資料問題上——導致重要計劃缺乏進展，組織難以在其產品、機器學習演算法或業務決策中有效使用資料。

#2 主動型，團隊在工程、資料工程、資料分析師和資料科學家之間積極協作，開發手動檢查和自定義 QA 查詢以驗證他們的工作。例如可能包括在管道的關鍵階段驗證行計數或跟蹤時間戳以確保資料新鮮。當出現問題時，訊息或電子郵件警報仍然會彈出，但這些團隊確實透過他們的主動測試發現了許多問題。

#3 自動化，在這個級別，團隊透過提供更廣泛的管道覆蓋範圍的計劃驗證查詢來優先考慮可靠、準確的資料。團隊使用資料健康儀表板來檢視問題、排除故障並向組織中的其他人提供狀態更新。例如跟蹤和儲存有關維度和度量的指標以觀察趨勢和變化，或者在攝取階段監控和執行模式。

#4 可擴充套件，這些團隊利用經過驗證的 Dev Ops 概念來建立暫存環境、用於驗證的可重用元件或針對資料錯誤的硬警報和軟警報。透過大量覆蓋關鍵任務資料，團隊可以在影響下游使用者之前解決大多數問題。例如跨所有關鍵指標和工具的異常檢測，監控和跟蹤每個作業和表的質量。

達到資料成熟度並非一蹴而就。但是，透過開始設定衡量質量的明確資料 SLA、SLI 和 SLO，可以開始展示投資於自動化、可擴充套件的資料可靠性的價值。常見資料健康指標的包括特定資產的資料事件數量、檢測時間和解決時間。

如前所述，在設定 SLA 時讓資料利益相關者保持一致至關重要 — 確保“可靠性”對資料消費者意味著什麼、哪些資產最重要以及哪些潛在問題需要最直接的關注達成共識。

5)建立合適的團隊結構

當然，團隊結構會對組織日常與資料互動的方式產生巨大影響。是否有一個集中的資料團隊來處理資料管理和應用的各個方面;還是跨業務部門的分析師，滿足特定需求並獲得領域專業知識 –這種模式將遭受缺乏凝聚力治理的困擾。

不同的公司將根據其規模和業務需求需要不同的方法，但許多資料領導者已經透過聯邦模型找到了最佳結果。在這種結構中，一個集中的資料平臺團隊處理基礎設施和資料質量，而分散的嵌入式分析師和工程師處理語義層並將資料應用於業務。如果組織正在快速發展並需要快速行動，則此模型很有效，但也可能會導致嵌入式分析師部分重複和重複工作，而無法與集中資料團隊保持一致。

軟體 Toast 的商業智慧高階總監Greg Waldman帶領他的團隊完成了為期五年的組織演變，其中包括從集中式到分散式再到聯邦式模型的轉變。他建議成長型公司的資料領導者遵循產品管理的一個關鍵原則——保持敏捷。

“簡而言之，我對資料團隊的看法是，希望每個人都儘可能多地增加商業價值。我們一直非常樂於改變並嘗試不同的事情，並且理解什麼適用於 200 人、500 人和 1000 人是不同的答案，這沒關係。當達到這些拐點並需要嘗試新事物時，這可能會有些明顯。”

對於 Jessica Cherny 來說，分散的分析師和工程師的優勢在於他們能夠理解資料請求背後的真正業務需求。

“我想了解如何設計真正滿足他們需求的可交付成果。這是最近發生的，當時有人要求我在一項戰略計劃中立即獲取一組特定的資料。我說，‘等等，等等。我真的需要使用這種複雜的聚類方法來回答這個問題嗎?這樣做的實際需要是什麼——這樣我就不必放棄手頭的所有工作，並且可以及時有效地為您服務?我們最終完全重組了她的問題，因為我更好地理解了她問題背後的業務需求，以及如何以簡單易懂的方式回答這個問題。”

同樣，每家公司都有自己的文化背景和需要應對的挑戰，但聯邦式模型可以幫助成長中的團隊快速行動以滿足業務需求，而無需放棄資料質量和治理的所有權。

小結

採用將資料視為產品的組織方法不僅僅是資料行業的流行趨勢，也是有意識的思維方式轉變，可以提高資料民主化和自助服務的能力，提高資料質量，從而可以準確地做出決策，並擴大資料在整個組織中的整體影響。