1. 普及資料質量
1.1. 隨著企業攝取越來越多的資料，資料分析也逐漸成為企業戰略的重要組成部分，對高質量資料的需求只會不斷增加，這給資料工程師、分析工程師，甚至資料分析師都帶來了壓力，要求他們承擔起這個重要但富有挑戰性的任務
1.2. 只有整個公司都認為資料是可信的，才能實現資料信任
- 1.2.1. 和一共執行了多少資料質量測試沒什麼關係
1.3. 幾乎所有團隊都是由資料驅動的，但在追蹤、執行和擴充套件資料質量計劃方面，承擔大部分工作的往往還是資料團隊
1.4. 資料質量不僅僅是構建更可靠的資料管道併為資料新鮮度設定(SLA)
-
1.4.1. 資料質量既是技術方面的流程，也是文化方面的流程
-
1.4.2. 其關鍵並不在於擁有完全準確的資料，而是在於理解我們能在多大程度上信任資料
1.5. 在資料質量的推廣和普及方面，讓使用資料變得儘可能地簡單和可迭代會很有幫助
1.6. 像對待產品級軟體一樣來認真對待你的資料
2. 將資料視為產品
2.1. 在過去幾十年中，大多數公司將資料儲存在組織的資訊孤島中
2.2. 分析團隊服務於業務部門，即使資料在決策制定和產品路線圖方面變得更為關鍵，負責資料管道的團隊也多被視為管道工人，而非合作伙伴
2.3. 資料已經不再是二等公民了
2.4. 將資料視為一種產品
2.5. 成果
-
2.5.1. 提高資料的可訪問性（在人們需要時，將資料呈現出來）
-
2.5.2. 加大資料的推廣和普及（讓人們更容易運算元據）
-
2.5.3. 讓資料產生更快的投資回報率（更快地獲得洞察）
-
2.5.4. 為資料團隊或資料消費者節省時間
-
2.5.5. 更精確的洞察（即實驗平臺）
2.6. 重要特徵
-
2.6.1. 可靠性和可觀測性
-
2.6.2. 可規模性
- 2.6.2.1. 隨著組織和需求的增長，資料產品應該具有規模上的彈性
-
2.6.3. 可擴充套件性
-
2.6.4. 易用性
-
2.6.4.1. 優秀的SaaS產品注重提供出色的使用者體驗
-
2.6.4.2. 易於學習、便於使用並能快速完成工作
-
-
2.6.5. 安全性和合規性
- 2.6.5.1. 資料洩露是昂貴而痛苦的，違反監管規定的罰款也是如此
-
2.6.6. 釋出規程和路線圖
-
2.6.6.1. SaaS產品會持續演變和改進
-
2.6.6.2. 在構建路線圖時至少要展望一年後的情況，並採用強有力的質量保證流程進行更新
-
3. 將資料視為產品的經驗
3.1. 資料驅動著產品路線圖，支援著高層決策，併為付費營銷活動提供了資訊
3.2. 來自公司內部和外部的資料不斷流入和流出
3.3. 沒人負責開發資料解決方案，使資料分析具有可操作性、可擴充套件性和可訪問性
3.4. 資料質量是頭等大事，而達成這個目標的方式在很大程度上源於將資料視為產品
3.5. 資料即服務或輸出
-
3.5.1. 由職能團隊和團隊中的分析師來負責確保資料質量、資料可用性和效能
-
3.5.2. 將資料視為不斷演變的跨學科實體的過程和工作流將成為行業標準
-
3.5.3. 資料以兩種不同的方式被視為產品：作為服務或輸出
-
3.5.4. 任何推送到公司內部可訪問的“生產資料環境”的東西都是產品
-
3.5.5. 據不再是一個孤立的實體，而是一項微服務
-
3.5.5.1. 不同的業務功能會在多個用例中利用相同的資料，並且資料團隊之外的更多使用者實際上也會訪問這些資料
-
3.5.5.2. 據也經常被用在公司決策之外的用例中：為金融產品賦能，向使用者展示相關廣告，甚至生成線上觀看的電影和電視節目列表
-
-
3.5.6. 在任何一種用例下，團隊都需要優良的資料測試、清晰的SLA、SLI和SLO，以及全面的文件記錄和監控
-
3.5.7. 期待資料是可靠的，而如果它不可靠，我們應當通知資料團隊和利益相關方，並提供解決問題的工具
3.6. 資料產品經理的崛起
-
3.6.1. 資料作為其競爭優勢，並利用資料為使用者提供更可靠、更量身定製的使用體驗
-
3.6.2. 從構建實時定價模型的資料科學家到建立預報模型以預測司機需求的業務分析師等不同職位
-
3.6.3. 將資料視為生產軟體：它可以被公司內的多個團隊使用，而非一組僅能支援分散用例的分散服務
- 3.6.3.1. 在傳統的軟體公司中，產品經理負責管理軟體解決方案從構思到實現的全過程
-
3.6.4. 資料產品經理負責資料的推廣普及和增加資料本身的價值
- 3.6.4.1. 設計、構建和管理資料平臺或一套特定資料工具的跨職能開發，以服務於多個使用者
-
3.6.5. 問題
-
3.6.5.1. 存在哪些資料？
-
3.6.5.2. 誰需要這些資料？
-
3.6.5.3. 這些資料從哪裡來，流向哪裡？
-
3.6.5.4. 這些資料的目的是什麼？
-
3.6.5.5. 是否有一種方法能更簡單地處理或訪問這些資料？
-
3.6.5.6. 這些資料是否合規並可操作？
-
3.6.5.7. 如何讓資料更快、更有效地為公司內的更多人提供幫助？
-
3.6.5.8. 主要目的是確保上述問題得到解答，並由此生成可靠、新鮮、可用的資料，將其交付給需要的人
-
-
3.6.6. 資料產品經理需要滿足利益相關方（資料分析師、資料科學家和運營團隊等）和公司高管的需求
3.7. 採用“資料即產品”的方法
-
3.7.1. 儘早並經常與利益相關方達成共識
-
3.7.1.1. 當資料是你的產品時，你的內部使用者也是你的利益相關方
-
3.7.1.2. 有助於你進行資料敘事
3.7.1.2.1. 軟體、產品和使用者體驗團隊使用敘事來透過不同視角分享他們的工作情境，從而幫助利益相關方從其最關心的方面出發，理解他們的工作價值
3.7.1.2.2. 資料敘事是非常有價值的工具，它能幫助你說服利益相關方著力於資料基礎設施的建設，而不是選擇光鮮亮麗的機器學習模型，或者某種承諾能產生數百萬美元的新功能
-
3.7.1.3. 資料質量與營收之間的聯絡總是不太明顯
3.7.1.3.1. 資料被獨立管理，而利益相關方不得不接受他們只能訪問少量資料的無奈
-
-
3.7.2. 應用產品管理思維
-
3.7.2.1. 將產品管理思維應用於構建、監控和評估資料產品中
-
3.7.2.2. 在構建資料管道和系統時，你也應該使用與產品級軟體相同的經過驗證的流程
-
3.7.2.3. 資料模型變得混亂的主要原因之一就是我們通常首先專注於快速構建服務，而沒有仔細地對資料進行思考
-
3.7.2.4. 在開始構建任何新的資料產品之前，建立與業務目標相匹配的KPI
3.7.2.4.1. 資料敘事可以幫助說明對資料質量進行投資的潛在好處，但大多陣列織仍然希望成熟的團隊可以評估其資料計劃的財務影響
-
-
3.7.3. 投資於自助式工具
-
3.7.3.1. 為了讓資料擺脫資訊孤島併成為一種有價值的產品，業務使用者需要能夠使用自助式工具來滿足自身的資料需求
-
3.7.3.2. 自助式工具可以為非技術型團隊賦能，幫助他們自主訪問資料，這樣你的資料團隊就可以專注於增加價值的創新專案，而不是作為按需服務的團隊來滿足各種臨時請求
-
3.7.3.3. 自助式工具也是資料網格概念的主要原則之一
3.7.3.3.1. 資料網格是一種新的去中心化資料架構方法
3.7.3.3.2. 自助式工具是資料架構和資料產品不可或缺的組成部分
-
-
3.7.4. 優先考慮資料質量和可靠性
-
3.7.4.1. 將資料視為產品的一個關鍵組成部分是將嚴格的標準應用於整個生態系統，從資料攝取到面向使用者的資料交付
-
3.7.4.2. 主要階段
3.7.4.2.1. 響應階段
3.7.4.2.1.1. 團隊在響應緊急情況和處理資料問題上花費了大量時間，從而導致在重要專案上沒有進展，進而讓整個組織都難以有效地利用資料來建立更好的產品、訓練機器學習模型或者進行業務決策
3.7.4.2.2. 積極主動階段
3.7.4.2.2.1. 在包括工程師、資料工程師、資料分析師和資料科學家的團隊之間積極合作，開發手動檢查和定製的質量保證查詢來驗證他們的工作
3.7.4.2.3. 自動化階段
3.7.4.2.3.1. 透過預定的驗證查詢來優先考慮可靠、準確的資料，從而可以更廣泛地覆蓋整個資料管道
3.7.4.2.3.2. 使用資料健康儀表板來檢視事故情況，進行故障排除並向組織中的其他人提供資料狀態更新
3.7.4.2.4. 規模化階段
3.7.4.2.4.1. 借鑑了已被驗證的DevOps理念，建立了臨時的執行環境、可重複使用的驗證元件，以及對資料錯誤的強弱警報機制
3.7.4.2.4.2. 對關鍵任務資料的大範圍覆蓋，團隊可以在資料事故影響到下游使用者前就解決大多數問題
-
-
3.7.5. 為你的資料組織找到合適的團隊結構
-
3.7.5.1. 集中式資料平臺團隊負責基礎設施和資料質量
-
3.7.5.2. 分散的、嵌入式分析師和工程師處理語義層並將資料應用於業務
-
3.7.5.3. 輪輻模型可以幫助不斷壯大的團隊快速地滿足業務需求，而無須放棄對資料質量和治理的所有權
-
3.8. 將資料視為產品不是一時的跟風
-
3.8.1. 一種有意識的思維轉變，能夠帶來有意義的結果
-
3.8.2. 增加資料的推廣普及和自助式服務的能力，提高資料質量，讓人們能夠準確、自信地做出決策，從而提升資料在整個組織中的影響力