又快到年底了， 一個好友換了一份新的工作，負責數據團隊。和他聊了很多，收獲滿滿。經他同意， 將我們討論的內容整理成文，希望對更多的朋友有所幫助。

當許多數據工程師、分析師和科學家被推到數據團隊負責人或主管的崗位時，并沒有得到太多的指導或建議。因此，這里想整理一份清單，列出要成為數據團隊的領導者，你需要知道和做的事情。

1.了解業務

如果你按照某種優先順序做這些事情，了解業務應該是第一位的。

人們常常談論業務團隊需要如何變得更加“數據驅動”或“數據流暢”，但很少有人關注反向的問題：數據專業人員也需要變得“業務流暢”。換句話說，僅僅掌握技術是不夠的，真正能夠發揮價值的數據從業者，必須理解他們所服務的業務本質。

要構建出真正滿足業務需求的數據產品或分析體系，數據人員不能只停留在數據層面，而應主動去了解和研究所在行業的運作邏輯、關鍵流程以及核心指標。比如，銷售漏斗是如何運轉的？醫院又是如何管理病人流程的？這些業務活動最終都會以某種形式反映在數據中。如果你只是盯著數據本身，而忽略了它背后的業務含義，那么你看到的只是現實世界的間接投影。

在這個過程中，數據團隊其實承擔了一個橋梁的角色——連接業務與技術、事實與決策之間的紐帶。而這個角色的最佳承擔者，往往是數據團隊的負責人或核心成員。如果沒有這樣一個人或機制來打通兩者，那么即使擁有最先進的基礎設施和模型，也很難構建出真正推動業務發展的系統。

如果希望構建完整的數據空間體系，可以參考林建興老師的大作——

當然，我們也不能忽視一個現實：企業整體確實需要具備一定的數據素養，比如基本的圖表解讀能力、對數據質量的理解等。但這并不意味著業務團隊能完全理解復雜的數據架構或算法邏輯。相反，作為數據專業人士，我們需要用他們能理解的方式溝通，并將數據轉化為可操作的見解。

“當數據團隊投身于公司最關鍵的戰略項目時，他們才真正變得不可替代。”這句話道出了一個核心觀點：如果你想成為公司核心決策的一部分，而不是一個被動響應查詢的支持角色，就必須深入理解業務正在發生的事情，并主動參與其中。

歸根結底，業務不會關心你的數據管道是如何搭建的，他們關心的是你能為他們的目標帶來什么價值。而你，作為數據從業者，只有先理解了他們在做什么，才能讓數據真正發揮作用。

2.沒人在乎你如何解決問題

不要與數據團隊以外的人談論數據技術、基礎設施或查詢ーー他們根本不在乎。

在與業務團隊溝通時，重點不在于使用技術術語或供應商名稱（如 Snowflake、Kafka、AWS、S3、Airflow 等），而在于用他們能理解的方式描述你所構建的功能——比如“數據倉庫”、“流式事件處理”、“流程調度”或“數據管道”。這樣做的目的是為了讓業務方清晰地理解你工作的價值和復雜性，而不是被技術細節所困擾。

例如，為什么整合一條新的產品線到每日報告中需要整整一個月？業務人員可能不需要了解底層的ETL流程是如何優化的，但他們需要理解其中涉及的關鍵功能步驟：數據接入、清洗、轉換、加載以及最終呈現。這種表達方式既能傳達工作量，又不會讓他們感到迷失。

第一步，確保術語一致。很多時候，項目推進困難僅僅是因為大家對同一個術語的理解不同。比如當你說“Postgres 實例”，有人以為是操作型數據庫，有人卻理解為ODS或數據倉庫。并不是所有系統都能完美歸類，因此關鍵在于提前定義清楚每個術語的大致功能定位，哪怕它只是粗略劃分。只要大家在一個共同的語言基礎上溝通，就能避免很多誤解，讓協作更順暢。

第二步，注意溝通的對象和場合。如果你曾在與C-suite高管的會議中打開IDE，試圖解釋一個查詢為何執行緩慢，那很可能已經偏離了正確的溝通軌道。這不是他們關心的問題，也不符合他們的決策視角。高層關注的是結果、影響和進度，而不是技術實現的細枝末節。

在談論業務時，核心不是你的技術挑戰，而是你如何推動業務目標的達成。

如果希望參考數據驅動業務的案例，可以閱讀馮天馳老師的《數字要素驅動供應鏈金融》——

業務部門真正想知道的是：你在做些什么來幫助他們推進項目、達成預期成果、在老板或股東面前交出好成績。他們并不關心你用了什么調度工具，除非你提到的內容直接影響到他們的目標。只有當你所做的事情與他們的優先級產生關聯時，他們才會進一步追問技術細節。

總的來說，與業務溝通的目標不是讓他們變成數據專家，而是讓他們理解你所做的工作如何服務于業務目標。這意味著你要聚焦于功能組件和業務結果之間的聯系。與此同時，你也希望管理層能夠自信地提出問題、參與討論，而不必掌握所有的技術背景。真正的溝通藝術，在于把復雜的技術轉化為清晰、可理解、有影響力的業務語言。

3.糟糕的數據質量會讓你付出代價

缺乏數據質量會導致其他部門將數據孤立起來，因為沒有任何高管相信這些數據，而且每個部門都拿出了自己的數據。

數據的準確性至關重要。今天少計算1元，可能意味著明天就會少賺10萬元。這些看似微小的細節，在實際業務中往往具有深遠的影響。你可能會驚訝地發現，當首席財務官查看一份報告時，僅僅注意到銷售數量或某個賬戶的總支出少了5元，就足以讓他們對整個數據體系產生質疑。這種信任一旦動搖，后續想要重建將異常艱難。

如果希望了解如何構造良好的數據以滿足制造業的業務需求，可以參考王曉華老師的《一本書講透數據體系建設：方法與實踐》——

而更嚴重的問題在于，這種不信任往往會引發連鎖反應。為了獲得“他們想要看到”的結果，其他部門可能會開始建立自己的數據流程和報表系統，形成所謂的“影子數據團隊”或“分散式分析流程”。這不僅導致數據口徑不一致、重復建設，還會削弱中心數據團隊的權威性和影響力。

因此，確保數據源的真實、準確，以及在構建數據分析存儲層時保持嚴謹的態度，是避免這些問題的關鍵。你越是在前期重視數據質量，后期因數據錯誤帶來的爭議和修正成本就越低。數據工作的價值，往往就藏在這些細節之中。

4.對供應商的說法持保留態度

關于如何構建最佳數據基礎設施的話題，一直是行業討論的熱點。但值得注意的是，很多觀點背后其實有其來源和動機，理解這一點對于判斷其適用性至關重要。

比如，曾有一段時間，不少文章大力推崇“schema-on-read（讀時建模）”作為一種減少洞察延遲的有效方式。其核心理念是：與其花大量時間在數據倉庫中預先定義 schema，不如將數據先以原始形式存儲在數據湖中，在需要時再進行解析和處理。這種思路一度讓人覺得，也許我們不再需要傳統意義上的數據倉庫了，一切都可以在湖上完成。

然而，現實情況卻有所不同。如今我仍然看到很多組織在使用數據湖，但它們的角色已經發生了變化。大多數情況下，數據湖更像是一個低成本、高容量的初始處理平臺，用于對原始數據進行清洗、轉換，然后再加載到結構更清晰的數據倉庫或分析系統中。換句話說，它成為了整個數據架構中的“前置步驟”，而非替代方案。

關于數據產品的開發與運營， 可以參考錢勇等老師的《數據產品開發與經營》一書——

回想2015至2016年間，幾乎所有人都在熱烈討論 schema-on-read，并將其視為一種最佳實踐。但實際上，這種趨勢背后既有技術演進的推動，也有供應商推廣 Hadoop 生態系統的商業考量。當時我們剛剛開始探索如何有效利用這一新范式，而一篇來自 Google 的相關論文似乎進一步驗證了它的可行性——于是大家紛紛嘗試讓它“工作起來”。

當然，這并不是說 schema-on-read 沒有價值或者已經過時。事實上，Hadoop 及其生態系統至今仍在許多大規模數據處理場景中扮演著重要角色。只是隨著時間推移和技術的發展，我們逐漸意識到，schema-on-read 并非萬能，也并非適用于所有場景。

技術和最佳實踐往往需要經歷一段時間的沉淀，才能找到真正適合它的定位。因此，如果你感覺某個供應商正在推動某種新的、尚未經過充分驗證的方法，僅僅是為了推銷他們的產品——那么很可能，事實正是如此。保持理性判斷，結合自身業務需求來選擇合適的技術路徑，才是構建可持續數據架構的關鍵。

5.有意識地使用數據團隊中的角色

數據工程師和數據架構師的目標，往往與數據科學家和分析師存在顯著差異。這種差異不僅體現在工作職責上，也深刻影響了我們在構建數據管道和數據集時的出發點和側重點。

正因為如此，核心數據層的建設通常更適合由數據工程師和架構師主導。這一層數據承載著企業最關鍵的業務實體與關系，是整個數據分析和決策體系的基礎。盡管不同組織可能會用不同的術語來描述它——比如“核心實體”、“關鍵關系”或“黃金數據源”——但其本質是一致的：它是所有后續分析、報表、機器學習模型所依賴的基石。

當然，并非每家公司都具備這樣的團隊結構。在一些規模較小或資源有限的組織中，可能只有一名數據分析師承擔多項職責，因此這種分工未必適用。但對于擁有一定數據能力的企業來說，將核心數據層視為基礎設施來建設和維護，是非常必要的。無論是一個獨立的數據團隊，還是每個項目組中的數據角色，這層數據都應該被統一管理、持續優化，并作為其他所有工作的基礎。

理想情況下，在核心數據層構建完成后，上層的應用開發就可以更加靈活。例如，分析工程師可以根據這些高質量的數據構建自己的模型，由分析師或業務用戶完成所謂的“最后一英里分析”（last-mile analytics）。這種模式不僅能提升效率，也能釋放數據團隊的潛力。

如果對多模態的數據分析感興趣，可以參考巴川老師的《多模態數據分析》——

當核心數據足夠穩定、清晰、可信時，數據工程師就可以專注于打造可靠的數據資產，而分析師則能夠更自由地探索業務需求，構建定制化的報告、儀表板以及臨時性分析場景。這種分工不僅提升了整體協作效率，也讓數據真正成為驅動業務的核心力量。

6.小結

許多數據團隊在實踐中確實面臨挑戰，但這并不意味著大多數數據團隊注定會失敗。問題的根源在于，我們在構建可靠、可信的數據系統這一核心目標上，已經開始有所偏離。

如今，越來越多的新晉數據經歷被推上關鍵崗位，但他們往往缺乏足夠的經驗或明確的指導來調整角色、制定清晰的戰略方向。在這種情況下，團隊容易陷入戰術層面的忙碌，卻忽略了數據工作的本質——即建立一個穩定、可擴展、值得業務信賴的基礎體系。

真正的問題可能不是“數據團隊是否會失敗”，而是我們是否還在堅持那些構建高質量數據系統所必需的原則。當組織更關注工具堆棧的迭代速度，而忽視數據治理、架構設計和質量保障時，失敗的風險才會真正顯現。因此，我們需要重新聚焦于那些經得起時間考驗的實踐方法，并為數據領導者提供足夠的支持，幫助他們順利過渡到更具戰略性的角色中。