|0x00 軟件行業看數據
從傳統軟件行業的視角，來看待互聯網人搞數據的方式，感覺像是時代的倒退。
過去搞了很多的軟件開發模型，例如瀑布、螺旋、敏捷等，都是以用戶的需求作爲出發點，將一個大型項目，按照迭代的方式，拆解成子項目，並對每個具體的單元進行成果測試，從而實現快速開發的目的。可以說，採用項目管理的方式做需求，可以對產出結果的質量、週期進行比較精準的卡控。但並不是每個人都會按照統一的方式做開發，因此後續又提出了“設計模式”的概念，用於對開發中難以標準化的地方，做理念上的指導。在長達三十年的實踐過程中，這套理論經受了時間的檢驗，至今仍在偏傳統的軟件開發模式中，非常的通用。
過去的經驗告訴我們，技術的意義，在於能夠在前人的成果上，實現經驗與技術的“可疊加性”。也就是，我們成果，要“可複用”。
但互聯網模式下，數倉搞了好多年，除了成熟的維度建模與分層模型以外，其實我們一直在原地轉圈。需求調研怎麼搞、實現方案如何設計、開發過程如何把控質量、交付階段如何驗證結果、上線後如何保障品控，這一系列的過程，並沒有系統化的理論來保障。當然，在業務高速發展的階段，滿足需求是第一優先級，但當獨角獸不斷成長，最終形成超大規模公司後，過去那一套模式，就不適用於全部的場景了。例如互聯網公司要去做一些行業數字化、企業數字化的工作，會猛然發現，自己的模型並不適用了。最典型的例子，人工數據的結構化，就是一項難以定義清楚的事情。因此，我們又不得不向傳統的軟件開發吸取經驗，在現有模型的基礎上修修補補，看起來，非常像“時代的倒退”。
|0x01 速度是變更的內涵
然而，往細了看，還是有一些本質的區別。例如傳統的軟件開發，會有交付週期的概念，以月爲交付週期很正常。但現在的企業數據中臺，這個速度要精簡到周，甚至是天。
從月到天，看起來結果沒有變化，但過程就完全不同了。
作爲一個軍迷，我最爲津津樂道的，是轟6K這個轟炸機型號。作爲前蘇聯1955就設計好的型號，我們一直將它的氣動外形沿用至今，以至於很多人吐槽這個型號“太老土”了。但它核心的子系統，例如發動機、雷達、電子化水平，卻已經完全替換成了最新的技術產品。可以說，除了外形，轟6K已經不再是那個1955年代的產品了。
數據中臺也是如此，從誕生的第一天起，互聯網人做數據的思路，就是要“快”。如果從企業數字化的能力來看，互聯網依舊擺脫不了數據庫+後臺+前端的模式。過去的人，看現在的產品，下意識中，會認爲這還是舊時代的產物，無非是技術選型換了而已。但其實，不論是Hive走到交互式，還是ETL走到流批一體化，產品下的技術底子，已經完全不同了。就連自動化的BI報表工具，其數據源也已經支持數十種不同的數據源，而不是侷限於數據庫一種。
因此，面向企業做數據，思路還是舊的那一套，但內涵已經完全不同了。
|0x02 快的意義，不止於速度
快，不僅僅指開發速度快，而是指基於一套成熟的模式，將精力集中到核心事情上，通過降低無關事情的投入，變相提高需求開發速度。
試想一下，一個傳統的需求開發週期，大約是21天，涉及到了PRD設計、需求評審、功能模塊開發、測試、聯調、上線等。雖然每個人在工作經驗和協作流程上，能夠實現經驗的積累，但開發的速度，卻不會有本質的提升，因爲技術是沒有積累的。
那麼如果我們把精力都投入到工具的開發上呢？先拋開實現的成本，假設我們目前有完善的報表開發工作、完善的流程開發工具及完善的數據模型，那麼產品甚至可以不用設計PRD，直接基於現有成熟的數據模型，就在報表工具和流程工具上把原型搭建出來，可能只需要1-2天，這個過程甚至不需要開發的介入。如果工具的功能不完善，那麼技術就補全工具能力。這樣開發同學做的每一件事情，都可以疊加生產效率，最終實現開發速度的質變。
數據倉庫、數據分析模型，其本質，也在於通過自動化的流程，將過去的經驗積累起來。後人能夠在前人的基礎上，實現開發效率的躍升。當然，場景再複雜下去，就是另外一回事了。
那麼傳統的軟件行業能夠做到這種速度嗎？能。但是，它在內涵上，就不是爲了“快”，而是爲了“持續穩定的交付”。在設計思想上存在了差異，那麼實現的方式和手段，也就自然而然不同了。
|0xFF 存量市場競爭，更需要速度
或許有人會問了，現在市場已經進入了存量競爭，不會有那麼多高速發展的業務了，所以我們做需求的速度會逐步下降。
我個人的理解，如果互聯網思維的核心，還是“用戶思維”或者“快速迭代”，那麼“快”的本質，就不會變化。因爲，試錯是必要的，大量的試錯是必要的，這個過程裏，“速度”決定了一切。
