如何從 0 到 1 建設一個數據平臺

注：這篇文章沒什麼技術內容，基本都是在談經驗。

爲什麼會寫這篇文章？是因爲做了一段時間的企業數字化工作，發覺不是所有的地方，都已經做好了一個數據平臺，等你來大展身手。

更多的時候，你是來到了一片荒漠之中，把過去那些已經做的比較成熟的事情，重新的再做一遍，就像遊戲開荒那樣。因此，如果快速度過 0-1 的過程，從 1 開始發揮自己的價值，就顯得很有必要，這是一個戰略問題。

其實，數據在沒有積累到一定程度時，是很難發揮出它的智能價值的，也就是數據平臺的發展，繞不過 “看數” 的階段。只要業務成熟到一定程度，數據才能發揮出它的增值潛力。

就像石油，我們都知道它是 “工業的血液”，但中古時期的人們，除了戰爭，就無法有效的利用石油。但數據積累到了一定程度，就不能只玩數據本身。還是石油，能夠分練出很多的有效產品，寫很多的論文，但如果不能用在汽車、飛機上，就不能發揮出它的最大價值。

因此，在戰略上，我們首先要重視 0-1 的過程，就要像軍事那樣籌備一場場的戰役：“打仗，打的就是錢糧；數據，比的就是人力和機器成本。” 如何在最短時間內，把石油精煉的體系給做出來，保證工廠能夠長期穩定運行，是首要的目標。

畢竟，不論是做數據行業的人，還是用到的大規模機器，都是一筆不小的開支。

其實大多數的從業者，都心心念的希望能夠做一個比較不錯的項目，能夠幫助客戶或者用戶挖掘出數據背後的價值，但現實卻是，我們面臨的往往是基礎性的工作：看數。

所謂的 “看數”，大體就是一個數據產品的雛形，包括非常多維的數據分析、下鑽等功能，再配合幾個簡單的分析模式，成型了。

但，做好一個數據平臺，僅僅依靠自己的力量是不夠的，還需要跟前端、運營、算法、分析師等崗位結合，把數據炮彈送給前方，仗纔有的打。

例如缺少了前端，平臺的體驗肯定是個問題；缺少了運營，平臺推廣不出去，直接價值就產出不來；缺少了分析師，指標體系做的就只是個空殼子；缺少了算法，智能肯定就談不上了…… 所以，數據平臺，更像是搭了個場子，歡迎大家都來使用，發揮羣策羣力的力量。

這就決定了，幾乎沒有什麼平臺，是一開始就做好了，都是先隨着業務跑起來，再逐步的把基建夯實。但因爲業務總是做不完的，平臺也不會覆蓋所有的 case，因此最後都將邁向做業務的終極目標：提效降本。

所謂：提效降本，簡單講，就是把儘可能多的業務過程，自動化掉，把人均能做的工作量、運營揹負的 KPI，用數據工程的力量，來提升一個檔次。同時，我們所消耗的資源，不論是人力還是機器，要儘可能的小。

既然所有的價值，都要回歸到 “提效降本” 上，其實是說明，這世界上本就沒有那麼多的價值去做，基礎科學不突破，地球艦隊再龐大，終歸不是水滴的對手。

講完了戰略，再講策略，就是我們到底要做什麼？

做什麼，最好要有個參照物，假如你是一家互聯網公司，阿里雲就提供了大數據三件套：Dataphin + Quick BI + Quick Audience，這個是官網能夠搜得到的。

這三件套中，Dataphin 用作數據開發與建模，Quick BI 用於報表產品搭建，Quick Audience 則是最基礎的用戶增長的產品化方案。

所以，既然是從 0-1，那麼這個參照物，就把數據從採集、加工、分析、應用的全過程，提煉的比較完整了。當然，如果是其他的行業，或者是策略有差異，那麼也可以參照一些其他的參照物。

早年我們把美國的商業模式搬到中國，稱之爲 “C2C”，今天的參照物，不過是進一步細化了 “C2C”，把商業模式的借鑑，下放到了產品設計中。

因爲產品設計，尤其是像數據產品，並不像商業模式那樣，能夠直接產生經濟價值，因此對軟件領域 PAAS 層的借鑑或者說是抄襲，就不會像 SAAS 那樣敏感，甚至樣子都可以一模一樣，基本上不會對外的。

有了參照物，接下來，就可以着手把數據平臺的樣子，畫一張草圖出來了。這張草圖裏，一定要有如下的這麼幾個部分：

• 開發工具；

• 研發規約；

• 協作流程；

• 質量保證；

• 報表工具。

五個注意事項 + 3 個參照物平臺，一個數據平臺的框架，就清晰可見了。掌握了這些能力，搭建出一個可靠好用的數據平臺，就只是時間問題了。

很多人會有一種誤區，即做數據，我們要把整個流程都自己做，其實不是的。就像維度建模理論，能夠把企業數據的 “總線架構” 給勾勒出來，但這並不代表你能夠應對種種其他類型的需求，業務性的邏輯，還是交給工程組更合適一些。

因此，給數據平臺劃定一個研發的邊界，是很有必要的，避免團隊資源投入到大量無效的需求中去。或許 1-100 的過程裏，個性化的需求需要去支持，但這絕對不是 0-1 應該考慮的。團隊的研發協作，是有慣性的，如果一開始就掉進了需求陷阱裏，就很難爬出來了，或者要退一層皮。

其實近年來，數據研發的崗位，招聘越來越難，一方面因爲數據分析 / 算法崗太火，喫掉了絕大多數的增量從業者；另一方面，也是因爲數據研發越來的越貼近業務，對於技術的要求有一種一言難盡的說法。要說面試造火箭吧，算法、架構都少不了，但實際的工作中，這些能力都被平臺 “賦能” 了。

因此，越往上走，就要求對業務的貢獻越大，對業務的理解也就要求越深，技術長期不用，能力自然會退化掉。

但這只是 1-100 過程中，所必須面臨的問題。在 0-1 的過程裏，需要的東西還是很多的。

講完了策略，也就是數據平臺目標的樣子，接下來就是具體做事的方法了。簡單講，就是 “輕重緩急” 的選擇。

如果我們畫出完整的架構圖，它大概是如下的樣子：

在輕重緩急上，大體遵循：離線 --> 實時；模型 --> 報表；鏈路流程 --> 穩定性保障；單一工具 --> 多工具服務整合…… 這麼幾個原則。先做出可以使用的成果，在此基礎上，再將架構圖中缺失的部分一點點補充上，直到完成平臺應有的樣子。

這個過程要做的事情，其實是很多的，對抗 “熵增” 的具體技巧，就是工作經驗所賦予我們的。

從這個角度上看，有兩個 “熵增” 的最重要影響因素，需要控制住，即開發過程中的規範、維護需求迭代的協作方法。如何把規範做好，減少後期需要返工的工作量，同時控制需求不能無序增長，就是平臺初建最重要的考量因素，而這些其實都與管理能力相關。

接下來，考量的是團隊的分工，從框架、質量和建模等不同的角度入手，把整體框架搭建起來。這時候技術能力就很重要，例如實時能力選擇什麼技術方法，例如建模如何評價好壞，例如穩定性和質量如何在高速迭代中保持，等等。

當然，做過的東西，都要有所沉澱和輸出，讓後人理解我們這麼設計的原因，同時遵循已經形成的規範，最好把影響力擴展到團隊之外，吸引更多的人才加入。

所以，數據開發人才的三種能力：管理能力、技術能力（包括架構、代碼能力）、溝通協作能力，就是具體需要學習的做事方法。

講了這麼多，從 “提效降本”，到 “參照物 + 規約工具流程”，再到需求的 “輕重緩急”，基本上把 0-1 的過程講述清楚了。

走完 1 之後，真正的挑戰剛剛開始。今天我們大多數人倒騰的事情，也許只有本公司能用一下，一些業務看上去有價值，做起來是一坨屎，維護的人更是不想管它。

但，這都是表象。大公司的探索，是企業發展過程中都會遇到的問題，就像維度建模、數據治理、企業數字化這些理念，都是從大公司開始，擴散到了中小公司，最後普及到全行業。

這也就是說，大公司的探索，會成爲日後小公司借鑑的經驗。從這個角度看，我們折騰的各種東西，各種不靠譜的產品，其實都是在爲這個行業的未來提供借鑑的經驗。

所以，與其把過多的精力放在需求合不合理上，不如多思考這些需求背後的考量。

比如做一款企業決策型產品，大多數人會抱怨領導需求多麼不靠譜、領導怎麼又變需求了。但如果深入進去，你會發現，企業決策產品，其實跟 “炒股軟件” 很像。

炒股軟件如何支持你做決策？大致有這麼幾個功能：資訊提供、交易功能、自選行情及實時變動。對應到數據平臺上，大體就是報表展示、自助分析、實時更新，以及一些管理功能，比如一鍵溝通對應的數據負責人。

所以，做企業決策平臺久了，轉向其他的決策類平臺，就很容易。

從這個角度上講，紮根一個業務場景，其實是數據從業者拔高自己的關鍵，也是對抗 35 歲陷阱的基礎能力。如果卷算法能力、編碼能力，我們也許永遠都卷不過年輕人，但要論行業經驗、專家解讀，這些小孩就稚嫩的很。

數據開發，只是我們從業的能力，而從業所積累的專業經驗，纔是我們的核心競爭力。

共勉。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/j8DjRrDL3-WZpH67Fn0zPw