【引】又快到年底了， 一个好友换了一份新的工作，负责数据团队。和他聊了很多，收获满满。经他同意， 将我们讨论的内容整理成文，希望对更多的朋友有所帮助。
当许多数据工程师、分析师和科学家被推到数据团队负责人或主管的岗位时，并没有得到太多的指导或建议。因此，这里想整理一份清单，列出要成为数据团队的领导者，你需要知道和做的事情。
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.小结
许多数据团队在实践中确实面临挑战，但这并不意味着大多数数据团队注定会失败。问题的根源在于，我们在构建可靠、可信的数据系统这一核心目标上，已经开始有所偏离。
如今，越来越多的新晋数据经历被推上关键岗位，但他们往往缺乏足够的经验或明确的指导来调整角色、制定清晰的战略方向。在这种情况下，团队容易陷入战术层面的忙碌，却忽略了数据工作的本质------即建立一个稳定、可扩展、值得业务信赖的基础体系。
真正的问题可能不是"数据团队是否会失败"，而是我们是否还在坚持那些构建高质量数据系统所必需的原则。当组织更关注工具堆栈的迭代速度，而忽视数据治理、架构设计和质量保障时，失败的风险才会真正显现。因此，我们需要重新聚焦于那些经得起时间考验的实践方法，并为数据领导者提供足够的支持，帮助他们顺利过渡到更具战略性的角色中。
【关联阅读】