经常有技术团队的小伙伴抱怨最烦的就是产品经理发起需求变更,才做了三周,改了八回需求......
其实这个故事,每天都在开发团队中上演,作为 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​​
图片


软件部长
43 声望6 粉丝

软件研发行业老司机,提供些踩坑的经验而已