天下数据，唯快不破
|0x00 软件行业看数据
从传统软件行业的视角，来看待互联网人搞数据的方式，感觉像是时代的倒退。过去搞了很多的软件开发模型，例如瀑布、螺旋、敏捷等，都是以用户的需求作为出发点，将一个大型项目，按照迭代的方式，拆解成子项目，并对每个具体的单元进行成果测试，从而实现快速开发的目的。可以说，采用项目管理的方式做需求，可以对产出结果的质量、周期进行比较精准的卡控。但并不是每个人都会按照统一的方式做开发，因此后续又提出了“设计模式”的概念，用于对开发中难以标准化的地方，做理念上的指导。在长达三十年的实践过程中，这套理论经受了时间的检验，至今仍在偏传统的软件开发模式中，非常的通用。
过去的经验告诉我们，技术的意义，在于能够在前人的成果上，实现经验与技术的“可叠加性”。也就是，我们成果，要“可复用”。
但互联网模式下，数仓搞了好多年，除了成熟的维度建模与分层模型以外，其实我们一直在原地转圈。需求调研怎么搞、实现方案如何设计、开发过程如何把控质量、交付阶段如何验证结果、上线后如何保障品控，这一系列的过程，并没有系统化的理论来保障。当然，在业务高速发展的阶段，满足需求是第一优先级，但当独角兽不断成长，最终形成超大规模公司后，过去那一套模式，就不适用于全部的场景了。例如互联网公司要去做一些行业数字化、企业数字化的工作，会猛然发现，自己的模型并不适用了。最典型的例子，人工数据的结构化，就是一项难以定义清楚的事情。因此，我们又不得不向传统的软件开发吸取经验，在现有模型的基础上修修补补，看起来，非常像“时代的倒退”。
|0x01 速度是变更的内涵
然而，往细了看，还是有一些本质的区别。例如传统的软件开发，会有交付周期的概念，以月为交付周期很正常。但现在的企业数据中台，这个速度要精简到周，甚至是天。
从月到天，看起来结果没有变化，但过程就完全不同了。
作为一个军迷，我最为津津乐道的，是轰6K这个轰炸机型号。作为前苏联1955就设计好的型号，我们一直将它的气动外形沿用至今，以至于很多人吐槽这个型号“太老土”了。但它核心的子系统，例如发动机、雷达、电子化水平，却已经完全替换成了最新的技术产品。可以说，除了外形，轰6K已经不再是那个1955年代的产品了。
数据中台也是如此，从诞生的第一天起，互联网人做数据的思路，就是要“快”。如果从企业数字化的能力来看，互联网依旧摆脱不了数据库+后台+前端的模式。过去的人，看现在的产品，下意识中，会认为这还是旧时代的产物，无非是技术选型换了而已。但其实，不论是Hive走到交互式，还是ETL走到流批一体化，产品下的技术底子，已经完全不同了。就连自动化的BI报表工具，其数据源也已经支持数十种不同的数据源，而不是局限于数据库一种。
因此，面向企业做数据，思路还是旧的那一套，但内涵已经完全不同了。
|0x02 快的意义，不止于速度
快，不仅仅指开发速度快，而是指基于一套成熟的模式，将精力集中到核心事情上，通过降低无关事情的投入，变相提高需求开发速度。
试想一下，一个传统的需求开发周期，大约是21天，涉及到了PRD设计、需求评审、功能模块开发、测试、联调、上线等。虽然每个人在工作经验和协作流程上，能够实现经验的积累，但开发的速度，却不会有本质的提升，因为技术是没有积累的。
那么如果我们把精力都投入到工具的开发上呢？先抛开实现的成本，假设我们目前有完善的报表开发工作、完善的流程开发工具及完善的数据模型，那么产品甚至可以不用设计PRD，直接基于现有成熟的数据模型，就在报表工具和流程工具上把原型搭建出来，可能只需要1-2天，这个过程甚至不需要开发的介入。如果工具的功能不完善，那么技术就补全工具能力。这样开发同学做的每一件事情，都可以叠加生产效率，最终实现开发速度的质变。
数据仓库、数据分析模型，其本质，也在于通过自动化的流程，将过去的经验积累起来。后人能够在前人的基础上，实现开发效率的跃升。当然，场景再复杂下去，就是另外一回事了。
那么传统的软件行业能够做到这种速度吗？能。但是，它在内涵上，就不是为了“快”，而是为了“持续稳定的交付”。在设计思想上存在了差异，那么实现的方式和手段，也就自然而然不同了。
|0xFF 存量市场竞争，更需要速度
或许有人会问了，现在市场已经进入了存量竞争，不会有那么多高速发展的业务了，所以我们做需求的速度会逐步下降。
我个人的理解，如果互联网思维的核心，还是“用户思维”或者“快速迭代”，那么“快”的本质，就不会变化。因为，试错是必要的，大量的试错是必要的，这个过程里，“速度”决定了一切。
