1. 尾程物流费用构成
燃油费率具有以下几个特点：
- 和时间有关系，不同的时间段，费率不一样，所以费率的更新比较频繁；
- 和物流商有关系，不同的物流商，燃油方案（生效时间范围和费率）不一样，但是也有一些物流商的渠道是相同的燃油方案；
- 费率是一个百分数（小数），需要乘以基础费用才能得出具体的燃油费；
图源：FedEx官网
无论是从业务的角度，还是从技术的角度，燃油方案看起来都是一个很简单的需求，容易理解，关键字段也很少，业务关联性也不复杂。
起初的时候我也不以为然，感觉就是一个很简单的需求，差不多想了一下，然后找竞品也看了下，就输出了一个产品设计方案，准备到时候快速评审一下。
但是实际上我前后改了三个版本才解决这个“小需求”，期间还一度让我感觉自己是不是进入了“知识诅咒”，陷入了“死胡同”出不来了。
三、因为建模失败，改了三个版本1. Round1：参考竞品来建模
参考了好几个竞品之后，我发现大家对燃油方案的设计都是最简单的平铺型的设计，也就是把所有创建好的燃油方案按时间排列。
燃油方案也是一个比较抽象的概念，为了让大家更好地理解它，所有我们在对其进行建模的时候，需要先确认一个抽象角度，因为确定了角度就会让我们有一个目标。
“平铺型”就是一个建模的角度，通过这个角度，我们得到了目标：平铺式的展开所有的燃油方案，以便于更简单方便地对燃油方案进行管理。
而管理燃油方案就会涉及到多个场景，这就是建模的第二步———找出特定的场景。
我们需要创建燃油方案，编辑燃油方案，删除燃油方案，应用燃油方案等，以上这些是场景中的“事情”，然后借此我们还需要去挖掘这个场景中的“人”和“规则”。
当我们确定了抽象角度，找到了这个角度背后的场景之后，建模也就完成了大半。
最后要做的就是对这些场景进行梳理和推敲，是否能够完全满足业务的需求，有没有遗漏的点或者阻塞的点等。这其实也是UML中梳理用例的过程，所以当我们在梳理用例的时候，本质上也是在做建模这件事。
如果一个抽象角度不能完成建模，那就要继续回到第一步，发掘更多的抽象角度，从实际的工作经验来看，简单需求可能一个抽象角度就可以完成建模，但是复杂需求往往需要多个角度，多个场景，多个用例同时构建才能完成建模。
让我们再回到燃油方案建模这件事的起点时刻，首先要做的就是去发掘它的抽象角度，从多个竞品的实现方案上来看，平铺型的视角是用的最多的，所以我们第一版也采用了平铺型的视角去建模，去梳理业务用例，去完成产品设计。
第一版的建模：平铺型。
确认了视角之后，接下来就是挖掘场景，从“人”，“事”，“物”，“规则”几个方面去构建场景，然后发现了这种方案有以下几个问题。
- 方案平铺后数量太多，会不断新增，使用的时候不太方便；
- 燃油方案需要经常更新，而且有些时候会提前设置，等到时间点后生效，平铺型的燃油方案不利于更新，如果修改已有数据，则破坏了正在生效的计费方案；如果追加新的燃油方案，则必须要求燃油方案重名，用户操作出错的风险太大；
2. Round2：使用平铺型 状态限制来建模
鉴于平铺型的视角会有一些问题难以解决，我们在短暂的讨论后决定要调整一下方案，换一个视角来发掘业务场景，试图找到更好的解决方案。
第二版的建模：平铺型 状态。
在第二版的方案中，我们引入了一个新的“状态”字段。大多数场景还是和第一版一样，只是通过状态来做一些核心业务逻辑的判断。
燃油方案名可以重复，重复意味着使用一个燃油方案后，当后续不断的新增/修改燃油方案后，只要名称是可以匹配的，就可以使用这个燃油方案来计费。
然后通过状态来判断，“生效中”的燃油方案不能重名，只有一个，“未生效”和“已失效”的燃油方案可以重名，可以有多个。
状态是通过每天的定时任务来判断的，根据设置的日期和当前日期进行比较，判断应该在什么状态。
这个方案最后还是被我们评审的时候Pass掉了，原因是还是有一些风险点和体验不好点，原因如下：
- “未生效”的燃油方案如果重名且生效日期范围有重合，则会导致当自动生效的之后，“生效中”的状态可能会同时有两条；如果限制了不能重合，则又要限制“未生效”和“生效中”的也不能重合，这样感觉和状态又无关了，引入这个概念没多大的意义，因为方案一就是限制了不能重合；
- 定时任务更新状态可能会失败，需要引入重试机制或者兜底机制；兜底的机制是每次用的时候再去查当前的日期是否满足生效日期范围，如果每次都要查，那么定时任务更新状态也没意义了，直接实时用时间去判断就够了；
3. Round3：采用树状结构来建模
因为方案一有一些漏洞或者体验不好的点，所以才想到了方案二，引入了一个状态，但是实际在处理这个状态的时候，发现很是鸡肋，有用但是又不完全有用……
看似一个简单的需求，但是设计出来的产品方案总是有明显的漏洞和瑕疵，我感觉可能一开始的思路就错了。
也就是说：竞品们采用的从平铺型视角去建模，有可能本身就是错误的或不好用的。
意识到这一点之后，我完全抛开了竞品的干扰，直接从最本质的需求和业务逻辑触发，重新发掘新的建模视角，最后发现采用树状结构才是更合理的解决方案。
