最近，我在阅读阮一峰老师的《科技爱好者周刊》第 373 期时，看到一个非常深刻的观点：数据模型，才是新产品的核心。

文中提到了 Pascal 语言之父、著名计算机科学家沃斯（Niklaus Wirth）那句振聋发聩(kuì)的名言：“算法 + 数据结构 = 程序”。

在他老人家看来，数据结构和算法一样，是整个软件的灵魂，反倒是我们日常纠结的编程语言，其实没那么重要。

为什么？

因为如果你的数据结构一开始就设计错了，那程序十有八九全是毛病；反过来说，只要数据结构是对的，解法往往就像拨云见日一样，自然而然就浮现出来了。

所以说，数据模型不仅是程序的核心，它更是我们每一个新产品的核心。

业务与技术，“共进”而非“单行”

其实，数据结构的设计，远比我们要想象的重要太多太多。

很多人习惯从业务出发来谈价值，这当然没错。但我一直坚持一个观点：数据结构和业务，应该是“共进”的。

什么样的数据结构，决定了你能做出什么样的产品设计；反过来，什么样的业务形态，也决定了底层必须支撑什么样的数据结构。

我们常说的“从业务出发”，绝不应该只是单纯地盯着业务需求看。我们得看数据的可行性、看结构的优良性，甚至要看实现的代价大不大。

现在的企业里，我们经常看到一种很痛心的冲突：

产品经理提了一个天马行空的需求，程序员两手一摊说实现不了。

为什么？往往就是因为当前的数据结构根本满足不了这个需求。

产品与业务、技术与实现、数据管理与结构化存储，这几者之间如果对不上号，项目就会陷入僵局。

所以，无论你身处哪个职位，千万不能只盯着自己的一亩三分地看问题。

Office 与 Notion 的本质差异

我们来看一个具体的例子，大家就能明白不同的数据结构，是如何决定产品的命运的。

拿我们最熟悉的文档管理来说。

宏观上看，大家都是写文档，对吧？

传统的有 Office、WPS；
新概念的有语雀、飞书；
更有创意的像 Notion、Obsidian。

它们都能写字，都能排版，但在交互体验和使用场景上，简直是天壤之别。为什么？
本质就在于“结构”。

Office 和 WPS，它们的底层是“篇幅结构”，就像一张白纸，你是在纸上画画；
而 Notion 和语雀，它们的底层是“块结构（Block）”。

正因为是“块”，Notion 的内容才可以随意组合、随意关联，它的灵活性远高于 Office 这种单一的文档结构。这种差异，不仅仅是因为业务想做成这样，更是因为底层的结构允许它做成这样。

这是业务和结构深度融合、互相成就的产物。

为什么不能只做“单向思考者”？

说到这儿，我想请大家停下来思考一个问题。

既然一个优秀的产品，比如 Notion，需要业务和结构如此紧密地配合才能诞生。那么，创造这些产品的我们，如果只懂业务或者只懂技术，能做出来吗？

显然不能。

这就引出了我想进一步聊的话题：在这个时代，我们绝对不能只从当前的职业本位出发，去单向地思考问题。

为什么这么说？

举个最简单的例子。

如果你是一位非常有才华的 UI 设计师，界面画得美轮美奂，但你对 UX（用户体验）一窍不通。那么，你设计出来的产品可能只是一个“好看的花瓶”，用户根本不知道怎么用，甚至很难接受。

再比如，在现在的企业里，分工越来越细。这本意是好的，专业的人做专业的事。

但也恰恰是因为这种过度的细分，导致了思维的“多维度割裂”。

人与人的思想，如果缺乏共同的认知基础，是无法完全共享的。

如果你完全不了解交互设计，那么交互设计师再好的想法，你也听不懂，更传达不出来；
如果你对数据结构的重要性没有深刻的认识，那么即使架构师给了一份天才般的结构设计，作为程序员的你，可能也无法有效地利用起来，甚至会把好东西做烂。

所以，我想说的是：

我们在学习、思考和设计的时候，都应该是多维度出发的。

不懂技术的 PM 哪怕多了解一点数据结构，不懂设计的开发哪怕多看一点交互原理。

只有这样，我们才能打破职业之间的厚障壁，才能真正融合其他角色的思想。

这不仅仅是为了沟通顺畅，更是一个团队能够共同落地好项目、做出好产品最牢固的根基。