经常有技术团队的小伙伴抱怨最烦的就是产品经理发起需求变更，才做了三周，改了八回需求......
其实这个故事，每天都在开发团队中上演，作为 IT的 leader 来透视这个问题，要辩证的看待，其实80% 的可能性都是如下2个方面之一，那么搞定下面两个方面就搞定80%的需求变更，这个都是妥妥的开发成本或者项目利润。
1、人的问题：需求人员说不清楚、产品经理无法抽象，简单成为二传手，到技术人员手中的需求肯定会持续更改，那么这总结为人的问题，如果是需求方的人说不清楚，那么就需要升级，找到能够说清楚，能够排版的人，否则无法解决；如果是产品经理的问题，每天摸鱼划水，那么做“传声筒”，没有对需求进行理性的分析抽象，那么赶紧裁掉 ，及时止损才是正道。
2、业务本身的问题：比如风控规则，所谓道高一尺魔高一丈，每天都在较劲寻找对方的突破点；又例如员工考核 ，每个岗位可能都是不一样的考核方式，而且很可能领导一句话就增加一种考核模式，那么这种常常变化的业务，就需要采用规则引擎去做抽象判断。
那么对于上述的第一条我就不过多做赘述，针对第二条，我们自己实现的方式给大家讲讲，算是抛砖引玉。
我们应该把经常变化的场景转化为产品技术考虑的业务因子、判断条件、决策模型， 举例说明下， 例如在做“行政机构合规性执法的判断”的场景中，会把执法人员执法结果纳入到决策判断模型中， 这个过程是不断持续扩展的，如下图所示：
那么这种判断，就不适合写 if... else... then.... 多层的判断嵌套 ，因为业务需求可能会经常发生变化，那么就应该把业务和判断解耦。
那么这里如何解耦这个过程，我们以软开企服的 jvs-rules的规则引擎举例说明，大致分为四个大的步骤：
一、判断的数据来源
在我们的业务场景中，判断数据的来源大致有几个方面： a.入参（通过业务系统调用的时候传入进去）；b.本地的数据库（内网自有数据）；c.三方API数据（外部系统数据）
- 入参可以通过jvs-rules 的入参设置去解决，一旦配置入参，在自动生成API时，会自动添加这项需要传入的数据；
设置入参后，系统会自动更新API调用的 接口要求：
- 本地数据库数据接入，在业务执行中，除了出参以外，还常常用到了 本地的数据的数据，那么就可以在数据源中配置对应数据库的接入，解决调用本地数据来源的问题；
动态直连访问业务数据库：
这里数据库的接入提供多种数据库的方式：
- 三方外部系统的接入，可以通过API 、甚至离线文件等方式接入
API接入界面配置化：
二、判断因子的挖掘加工
在解决了数据接入的问题，就需要考虑数据与真实的业务判断有差异的情况下，如何搞定数据挖掘的问题，例如上文提到的行政执法的结果是一个文本，需要解析出来里边的执法金额，用于决策判断，那么如何实现呢？
系统提供了函数式 加工数据的方式（类excel 数据加工），可以提供系统自带的很多函数 对各种数据进行加工（入参、本地数据库、三方api 获取），得到我们想要的业务结果，例如上图，就是通过入参执法的结果，其中包括了大写的执法金额，需要把这些数据解析出来，转换成小写，得到最后可以判断的 “处罚金额”的变量。
这种数据加工包括“函数式”加工取数、“SQL脚本”取数据、“任务式”加工取数，如下图所示：
三、业务规则的拼装与仿真（详见后续章节）
四、规则的部署与业务调用（详见后续章节）
总结
JVS-Rules，是对用户比较友好的规则引擎解决方案，可以有效降低配置门槛和开发工作量，JVS提供基础性开源方案，支持商用与源码开放。
https://gitee.com/software-minister
https://gitee.com/software-minister/jvs-rules
