1. 数据模型迭代的全局观：为什么业务驱动是核心？
做了十几年数据架构，我见过太多「完美的烂模型」。
什么叫完美的烂模型？就是表结构设计得规规矩矩，三范式用得滴水不漏，命名规范挑不出毛病。但业务方一看就摇头：「这不是我要的东西。」
为什么会这样？
说白了，你把数据模型当成了纯技术活。你坐在工位上等需求，需求来了就画 ER 图，画完就建表。你觉得自己干得挺好，但业务方觉得你根本不懂他们在做什么。
我个人习惯，接手任何一个数据模型之前，先问自己三个问题：
- 这个模型要解决谁的什么问题？
- 业务方拿到数据后，下一步动作是什么？
- 如果模型错了，最坏的影响是什么？
这三个问题问完，你基本就能判断：这个需求是「真需求」还是「伪需求」。
核心观点：数据模型不是数据库里的几张表，它是业务逻辑的数字化映射。模型迭代的本质，是业务认知的迭代。
从「接需求」到「懂业务」：思维转变的四个层次
我刚开始带团队时，组里有个小伙子，技术底子很好。每次接到需求，他第一句话就是：「字段类型是什么？主键怎么定？」
我说你先别急，咱们先聊聊业务。他很不理解：「需求文档不是写清楚了吗？」
嗯，这里有个常见的误区——需求文档写清楚的，只是业务方以为自己想要的。真正的业务逻辑，往往藏在文档的夹缝里。
我把这种思维转变分成四个层次，你对照看看自己在哪一层：
| 层次 | 典型表现 | 口头禅 |
|---|---|---|
| L1：需求翻译机 | 业务说什么就做什么，一字不改 | 「需求文档里这么写的」 |
| L2：需求优化师 | 能发现需求中的矛盾，提出改进建议 | 「这个字段是不是冗余了？」 |
| L3：业务合伙人 | 理解业务目标，主动设计模型支撑决策 | 「你们要分析的是这个指标吗？」 |
| L4：业务驱动者 | 通过数据模型反推业务流程优化 | 「这个流程本身可以改一改」 |
大多数数据工程师停留在 L1 和 L2 之间。我曾经也是。直到有一次，我按需求文档做了一个客户画像模型，上线后发现准确率不到 40%。
后来我去找业务方聊，才发现他们口中的「活跃客户」和我理解的「活跃客户」根本不是一回事。他们看的是近 30 天下单次数，我建模用的是近 30 天登录次数。
你看，一个定义没对齐，整个模型就偏了。
我的习惯：每次建模前，花 30 分钟和业务方过一遍核心指标的定义。用大白话写下来，双方签字确认。这一步省下来的返工时间，至少是建模时间的 3 倍。
业务驱动模型迭代的闭环
数据模型不是一次性交付的。它需要跟着业务一起长。
我见过最典型的反面案例：一个电商数据模型，上线两年没改过。业务从纯平台模式变成了自营+平台混合模式，模型还是老一套。结果就是，财务对账永远对不平，运营看数据永远觉得「哪里不对」。
业务驱动的模型迭代，应该是一个闭环：
这个闭环里，最容易被跳过的就是「验证模型效果」。你想想看，模型上线后，有多少人真正回去问业务方：「用起来怎么样？哪里不对？」
我自己的经验是，每次迭代后，至少跟踪两周的业务反馈。不是看系统日志，是直接找业务方聊。聊的时候别问「模型好不好用」，要问「这个数据帮你做了什么决策」。
避坑指南：我曾经在一个供应链项目中，模型迭代了 5 个版本，每次都是按业务需求改的。结果第 6 个版本上线后，业务负责人换了，新来的负责人说「这个模型完全不对」。为什么？因为前一个负责人关注库存周转率，新负责人关注缺货率。业务目标变了，模型就得跟着变。
业务驱动 vs 技术驱动：两种思维模式的对比
我见过很多团队，技术驱动做得很漂亮。他们追求最新的技术栈、最优雅的代码、最极致的性能。但数据模型最终是给业务用的，不是给技术秀的。
这里我列一个对比表，你可以看看自己团队更偏向哪种：
| 维度 | 技术驱动 | 业务驱动 |
|---|---|---|
| 模型设计起点 | 数据库范式、性能优化 | 业务场景、决策需求 |
| 字段定义依据 | 数据类型、长度规范 | 业务口径、计算逻辑 |
| 迭代触发条件 | 技术债务、性能瓶颈 | 业务变化、新需求 |
| 验收标准 | 查询速度、数据一致性 | 业务方是否用起来、是否辅助决策 |
| 团队协作方式 | 产品给需求，技术实现 | 技术和业务一起讨论，共同设计 |
不是说技术驱动不好。性能、一致性这些当然重要。但它们是「底线」，不是「天花板」。你模型跑得再快，业务方看不懂、用不上，那就是白做。
我记得有一次，一个运营同事跟我说：「你们那个报表，我每次都要导出到 Excel 重新算一遍。」
我问为什么？他说：「因为报表里的『转化率』是按点击算的，我们考核是按下单算的。」
就这么一个口径差异，导致他们每天多花两小时手工处理。而这个问题，如果建模时多问一句「你们考核口径是什么」，根本不会出现。
如何判断自己是否真正「懂业务」？
我给自己定了一个标准：能不能用一句话说清楚这个模型服务的核心业务场景。
如果你只能说「这是一个客户订单模型」，那说明你还在 L1。如果你能说「这个模型支撑的是大促期间客户从浏览到下单的全链路分析，重点监控各渠道的转化漏斗」，那说明你至少到了 L3。
这里有几个自检问题，你可以拿来问问自己：
- 这个模型的核心用户是谁？他们每天看什么数据？
- 模型里的每个字段，业务方是怎么定义的？和你的理解一致吗？
- 如果明天业务策略变了，这个模型需要改哪里？
- 业务方最近一次抱怨数据不准，是因为模型问题还是口径问题？
这些问题，没有一个能在需求文档里找到答案。你得走出去，和业务方坐在一起，看他们怎么工作，听他们怎么讨论。
一个小技巧：我每个月会花半天时间，坐在业务方旁边看他们用数据。不提问，不解释，就看。你会发现很多「我以为他们是这样用的」和「他们实际是这样用的」之间的差距。这些差距，就是模型迭代的方向。
好了，这一章我们聊了为什么业务驱动是数据模型迭代的核心。说白了，模型是业务的镜子。镜子脏了，照出来的人像就是歪的。而擦镜子的人，不是业务方，是你自己。