编辑导语：产品建模是对产品需求进行抽象、整理、建立数据、梳理工作流程的过程，对产品工作也非常重要。本文作者结合《燃料方案》的修订，分享一些对建模的理解。和对建模感兴趣的朋友一起来看看吧，希望对你有帮助。
前段时间复习了一波UML。除了复习一波基础语法和使用场景，还有一个很重要的目的：学习如何建模。。
关于建模，我看了《大象：Thinking in UML》的前两章，写了一篇读书笔记《一个掉头发的问题：什么是建模？》。我写完之后，感觉对建模的概念有了一点点的把握，但是过了一段时间，就开始有点生疏和模糊了。
所以最近我重温了这篇文章，同时把《大象：Thinking in UML》的前两章看了两遍。结合最近一个项目中遇到的一个小案例，我决定写一篇关于我建模实践经验的文章，就是这一篇。
首先，简单了解一下建模的定义。我就直接从书上摘抄解释了，因为我感觉这个定义挺准确简洁的。
建模是指建立一种抽象的方法来表示客观事物，并获得对事物本身的认识。同时将这种理解概念化，将这些逻辑概念组织起来，形成被观察对象内部结构和工作原理的可理解表达。
上面建模的定义本身就和建模工作一样非常抽象和难以理解。
我总结了一下自己的理解，然后借用一张图和几段略显通俗的语言总结了一下。
我们在产品的日常工作中需要用到建模，是因为我们需要对一些事物建立一些概念性的描述，然后让别人理解。
比如商家提出的需求是做一个“采购系统”，但是“采购系统”这个词是虚无缥缈的。
那么，具体是什么样子，有什么功能，怎么做呢？产品需要一步一步研究设计。
然后建模。最后，建立的模型会通过一些图形或文本的表达方式传达给开发人员和测试人员。最后大家达成一致后，推出符合业务需求的“采购系统”。
要完成建模，第一步是确认抽象角度，这其实是一个面向对象的分析过程。一个需求背后有很多人，很多事，很多事，很多规则。只是以“人”为例，会有不同的抽象角度。
比如按位置或功能抽象是很常见的。采购管理模块中的人分为“采购员”、“业务员”和“供应商”。
但如果按照使用系统的角色进行抽象，采购管理模块中的人可以分为“采购申请角色”、“采购处理角色”、“管理员”、“采购审批人”。
不同的抽象角度汇聚形成“问题区域”，问题区域中的重叠部分其实就是需要重点关注和解决的问题，因为问题可以从不同的抽象角度获得，也就意味着问题是高频的、核心的。
其次，确认业务用例。我们在第一步确定了几个抽象的角度之后，就要梳理出对应的场景，因为抽象的角度背后都有具体的场景。
例如，我们根据位置或功能进行抽象。这个抽象角度背后的场景是“在什么条件下，购买者应该怎么做才能达到什么目标？””在什么情况下，销售人员需要提出购买申请？”如何发起？“在采购过程中如何与供应商进行关联，关联后可以做些什么”。
业务建模概述，如果上面的白话还是让你对建模有点疑惑，那么我就拿我最近在做的一个实际案例来进一步解答你的疑惑。
二。为什么要做燃油计划？之前提到过，海外仓尾物流的成本一般包括两项基本运费附加费。附加费中有一项特殊的“燃油附加费”，其计算公式为(货运附加费)*燃油率。
1.由尾部物流成本构成的燃油率具有以下特点：
跟时间有关系，不同时间段费率不一样，所以费率更新频繁；和物流商有关。不同的物流供应商有不同的燃料方案(有效时间范围和费率)，但有些物流供应商有相同的燃料方案。费率是一个百分比(小数)，需要乘以基本成本才能得到具体的燃料成本；
来源：联邦快递官网
无论是从业务角度还是技术角度，燃料方案看起来都是一个非常简单的需求，容易理解，关键领域少，业务关联性不复杂。
一开始，我也不同意。感觉这是一个非常简单的要求。我差不多想了一下，然后找竞品，然后我输出一个产品设计方案，准备快速审核。
但其实我前后换了三个版本就是为了解决这个“小需求”。一度让我觉得自己是不是进入了“知识魔咒”，陷入了“死胡同”，出不来了。
第三，因为建模失败，改了三个版本。1.第一轮：参考竞争产品进行建模。参考了几款竞品，发现大家对燃料方案的设计都是最简单的平铺式设计，也就是把所有创造出来的燃料方案按时间排列。
燃油方案也是一个比较抽象的概念。为了让人们更好的理解它，我们在建模的时候需要先确认一个抽象的角度，因为确定角度会给我们一个目标。
“平铺”是一个建模角度。通过这个角度，我们得到目标：平铺式的展开所有的燃油方案，以便于更简单方便地对燃油方案进行管理。
而管理燃料方案会涉及多个场景，这是建模的第二步，————找出具体的场景。
我们需要创建、编辑、删除和应用燃料方案等。这些都是场景中的“物”，然后我们需要挖掘这个场景中的“人”和“规则”。
当我们确定了抽象的角度，找到了这个角度背后的场景，建模就完成了大部分。
最后要做的就是对这些场景进行梳理和推敲，是否能完全满足业务的需求，有没有漏点或者堵点等等。其实这也是UML中梳理用例的过程，所以我们在梳理用例的时候，本质上是在做建模。
如果一个抽象的角度不能完成建模，就要继续回到第一步，探索更多的抽象角度。从实际工作经验来看，简单的需求可能从一个抽象的角度建模，但复杂的需求往往需要多个角度、多个场景、多个用例同时构建才能完成建模。
让我们回到燃料方案建模的起点。首先要做的是探索它的抽象视角。从几款竞品的实现方案来看，平铺视角是使用最多的，所以我们第一版也采用了平铺视角进行建模，梳理业务用例，完成产品设计。
建模第一版：平铺。
确定视角后，下一步就是挖掘场景，从“人”、“事”、“物”、“规则”等方面来构造场景。然后，我们发现这个方案存在以下问题。
平铺后方案太多，会不断添加，使用不方便；燃油方案需要经常更新，有时会提前设定，过了时间点就生效。平铺燃油方案不利于更新，如果修改现有数据，将破坏有效的计费方案；如果增加新的燃油方案，必须对燃油方案进行重命名，用户操作失误的风险太大；
2.Round2:使用平铺状态约束建模。由于从平铺的角度会有一些难以解决的问题，所以我们经过短暂的讨论后决定调整方案，从另一个角度探索业务场景，试图找到更好的解决方案。
第二版建模：平铺状态。
在该方案的第二个版本中，我们引入了一个新的“状态”字段。大部分场景和第一版一样，只是通过状态做一些核心的业务逻辑判断。
燃料方案的名称可以重复。重复是指使用一个燃料方案后，只要名称能够匹配，就可以使用这个燃料方案进行计费。
那么，根据状态判断，“有效”的燃油方案不能同名，只能有一个，“无效”和“失效”的燃油方案可以同名，也可以有多个。
状态是通过每天的计划任务来判断的，要通过设定日期和当前日期的对比来判断状态。
最后，我们审查时通过了该方案，因为仍然存在一些风险点和不良体验，原因如下：
如果“无效”的燃料方案同名，且生效日期范围重叠，则自动生效后会同时导致两种“有效”状态。如果限制它不能重合，就要限制“无效”和“生效”不能重合，所以感觉和状态无关。引入这个概念没有太大意义，因为第一个方案就是限制。定时任务更新状态可能会失败，因此需要引入重试机制或备份机制；底层机制是每次使用时检查当前日期是否符合有效日期范围。如果每次都要检查，那么更新调度任务的状态是没有意义的。直接实时判断就够了。
3.第3轮：使用树形结构建模。因为第一个方案有一些漏洞或者不好的体验，所以想到了第二个方案，引入了一个状态。但是，实际处理这种状态时，发现很鸡肋，有用但不完全有用.
看似简单的要求，但设计出来的产品方案总有明显的漏洞和瑕疵。我感觉一开始的想法可能就错了。
也就是说：竞品们采用的从平铺型视角去建模，有可能本身就是错误的或不好用的。
意识到这一点后，我完全抛开了竞品的干扰，直接由最本质的需求和业务逻辑触发，重新发现了一个新的建模视角。最后，我发现采用树形结构是一种更合理的解决方案。
建模第三版：树结构。
首先，燃料方案的名称是一个指标，是一个外壳。
据说业务需要经常更新燃料。这里的更新只是更新了燃油方案中的细节，常见的是修改生效日期、失效日期和燃油率。一般来说，燃油方案的名称是不会修改的，也不能修改，因为该方案一直被计费规则使用。
其次，在燃料方案中有一个关键场景需要满足，就是在重新计算已经发生的物流成本时，需要使用物流当时的燃料明细进行计费，也就是历史燃料明细也很重要，需要留作后用。
最后，树形结构可以保持燃料方案的简洁。配置收费规则时，选择燃油方案的主档案信息。使用/调用燃料方案时，可以根据日期和时间查询该方案下的燃料明细。
当然，对于燃油明细，要保证有效日期范围不能重复，这样充电时才能查到一条数据。
四。总结最后回头看，燃料需求方案真的很简单，我们最后用的方案也没有什么特别的创新或者颠覆性的改造，但是整个体验很跌宕起伏，很触动我。
一个小小的方案，因为一开始错误的造型方向，导致不撞南墙不回头的局面，让我一直怀疑自己。为什么别人可以这样做，而我自己做的时候却不行？
通过三次建模，我特别惊讶于三种不同视角带来的差异。很多时候，我以为建模只是用在复杂的场景，其实简单的场景好像也可以。
只是场景太简单了。很多时候我们可以从第一反应的角度来达到最优解，所以不会对建模视角的选择有很深的记忆。
其次，对竞品的借鉴也让我有了一些顿悟。批判性思维在产品领域确实很新。
大家都在用的方案不一定是最优解。错误的观念和认识的传播，更多人的使用，都改变不了它是错误的性质。
这篇文章已经写了2周了，但是断断续续的写，没有灵感和动力。
一方面，工作节奏太紧，抽不出太多时间。
另一方面，在建模方面，我还只是个初学者，还在边写边找数据论证。我发现市面上优秀的教材还是太少了。
用这个案例来说明我对建模的理解可能没有我想象的那么恰当，或者有些理解可能还是错误的。如果你有这方面比较好的案例或者教程，欢迎随时和我交流。
#专栏作家#我叫维生素，微信微信官方账号：PM维生素。前PHPer，做在线教育产品和跨境仓储物流产品4年多，现任SaaS外贸领域供应链产品经理。主要关注WMS/OMS/TMS/BMS/ERP等领域，分享供应链相关产品知识。
本文由人人作为产品经理原创发布，未经作者允许，禁止转载。
题目来自Unsplash，基于CC0协议。
数学建模到底是什么
敢不敢给Courant 《什么是数学》做个序，说说我对数学的理解。
数学本质上是人类思维的高度抽象模型。通过数学(公式)将人类思维的过程高度压缩，完成知识和思维的折叠。就像y=f(x)一样，人们可以直接用f(x)来完成函数计算过程的折叠。
追根溯源，人类的思维模式可以分为三个层次：
第一，语境化，这是具体化的层面。在这个层面上，数和形是完全融合的，人类对数学的认知停留在对具体事物的描述上，此时还没有抽象的概念。所以有很多领域专家，在情景场景下解决问题的能力很强，但是换了场景后能力是不能转移的。参见《人是如何学习》的P55。
于是一些有智慧的人开始总结各种(第二)思维模式，也就是概念理解的层面。这些思维模型对具体事物表现出一定程度的抽象，但还没有达到数学这种纯抽象的程度。比如金融学中的复利模型，物理学中的飞轮模型等。人们开始尝试将这些模式应用到其他领域，完成知识和能力的转移。这在055-79000和《纳瓦尔宝典》中有描述。
第三个层次是纯抽象数学，这是策略的层次，研究如何解决问题。纯数学已经完全脱离了场景和对具体事物的依赖，可以转移到各个领域。
因此，数学的发展有两个典型的方向。第一个是从具体到抽象，从情境到纯数学。其次，恰恰相反，是从抽象到具体，从纯数学领域进行推理和拓展，然后将新拓展的知识应用到具体领域。数学的学习、理解和拓展，应该从这两个方面展开。这两个方向缺一不可。如果只从纯数学的角度去研究数据而不去语境化，最终可能会失去学习和研究数学的方向。当学生学习纯数学时，他们都应该学习新的思维模式。只是很多时候学生自己，甚至老师都没有意识到这种数学学习的本质。所以平时多注意积累各种心智模型(心智模型)，然后依次用数学方法描述，也是提高数学能力的好方法。
数学的领域是可以不断拓展的，因为人类的思维模式是不断发展的，因为我们有解决不断发展的情境问题的需求。(有时候抽象的纯数学会反过来跑在前面。)
最后请参考吴军《穷查理宝典》 p116《鸡兔同笼问题的不同解法》，体会三个层次的思维方式对数学学习和发展的影响。