[BA][案例分享][教培行业]如何用IT的语言解释业务需求-系统判断新生/新客户

1. 前言

需求分析师(或)产品经理,作为业务与技术的桥梁,需要和所有的项目/产品干系人沟通,确保大家对功能的认知在同一个维度上。之前处理比较多的是如何用业务的语言向客户解释系统的逻辑,但这个例子却是相反,是用IT的语言解释业务需求的合理性,好了,下面案例分析开始:

2. 需求模型背景

整个需求其实非常大,这里简化一下需求模型:

  • 系统业务背景:校外教育培训机构的教务管理软件
  • 功能点:判断一个学生是否是一个新生

2.1 需求模型

  • 判断条件1:这个学生首次来机构报名上课,计算为新生
  • 判断条件2:这个学生在机构上过课,但是半年前已经结课(结课条件:课程已经上完,该生在课程的钱也用完)
  • 不是新生的,都是老生

2.2 IT设计模型

根据需求模型,IT设计的判断条件如下:

  1. 这个学生在系统里从来没有过完款合同
  2. 这个学生在系统里有完款的合同,但是最近半年内没有上课记录,并且该完款合同资金已用完
  3. 满足条件1或2,这个学生都算新生,不满足这两个条件的,都算老生

3 实际情况中发现的问题

根据IT设计模型中,正常的学生报名,判断新生老生,正常的案例都已经验证过没有问题。

但客户反馈了几个案例,说是这几个学生换班转课之后,又被系统判定为新生,这是怎么一回事呢?

经测试查证,发现这几个学生,在报读了A课程之后,没有上过任何课,就在系统上把A课程给退了,然后报了B课程。系统根据逻辑,180天内无课消,历史合同资金为0,就把这个学生判断为新生了。

4 测试对需求的理解

测试小妹妹在嘟囔了:“需求文档上不是定了180天内无课消,历史合同资金用完,再报读就算新生嘛,这几个案例完全满足啊”

5 解释原因背景

我对测试小妹妹说:“如果我们作为IT的人,把一个需求,看成一个冷冰冰的逻辑关系,而不去了解事情背后的原因,那我们是无法成长的。”(【画外音】为什么很多人说IT男/IT女很难沟通呢,我估计就是常年仅关心需求逻辑,而不去关心需求背后的含义)

见测试小妹妹不是很明白,我用现实中的真实案例来做解说:

无人车的案例:
我记得特斯拉的无人车之前在美国发生过一个案例,就是一两私家车,无法在天气晴朗的情况下中辨认白色货车,全速撞上货车。
相关报道:特斯拉无人车酿死亡车祸
我这里大胆猜测一下,假设需求是需要辨认周围的物体,如果是物体则不能装上去。那换成技术设计是什么呢?技术不可能简单的写:

If (前面物体 == true) then {
   停车
}

因为摄像头捕捉到的都是图片,要从图片中分辨车,马路,路边的草,斑马线,下水道盖子,就需要用到图片分析,那图片分析会不会根据色差来划分物体?比如色差大过多少,算一个物体(臆想的,如果实际技术不是这样判断,请告知详细)。用这个案例来说,可能技术的列举是辨认黑色,蓝色,绿色等有颜色的物体,但唯独和晴朗天气或周围物体颜色很接近的白色车便辨认为非物体(比如地上的指示白线?),然后开发,测试也按照技术需求的颜色都过了一遍,测试案例通过,皆大欢喜。但这不能代表实际需求就是这样,结果导致了悲剧发生。

另一个例子是前段时间发生的波音737MAX8的坠毁事件,网络文章很多,自行百度即可。事后的分析中,说到了波音给飞机加上了一个仰角控制系统,使飞机机头自动下坠的夺命系统MACS。如果这个系统出现故障,电脑会认为飞机失速,于是激活MCAS,强行将机头下压。这个可能确实是需求这么写的,但需求设计也有可能是错的,结果导致了飞机的坠毁。

举例了上述两个例子,我跟测试小妹妹说,为什么说一个开发团队,不是说一个厉害的项目经理,一个厉害的需求分析师,厉害的架构师和程序员,就一定能开发出完美的应用的。我们要充分理解:

  1. 客户的真实需求
  2. 实际可能出现的边界情况
  3. 实际可能出现的例外情况
    特别是第3点,要靠整个团队对业务的理解,才能在之前尽可能的想到边界情况并加以在程序中判断。(画外音,windows那么多漏洞,不就是因为很多例外或边界情况被黑客抓到了来攻击的嘛,但不影响Windows是很优秀的软件。)

这个案例中,就是需求分析之后,对逻辑的设计出现了偏差,没有考虑到一个学生报读了课程,完全没有上课的情况下,又转到了新的课程上。想想,从客户的角度上看,第二个合同肯定不是新生嘛。

所以我们要改之前的设计,判断这类条件。需求增加了以下字眼:

如果本合同为转费合同的,做以下判断:

  • 新合同都为续费合同
    判断结束终止
    原因:转费合同意味着之前必然有一个剩余实收金额不为0的合同,新合同才可在原合同上做转费操作

至于将来会不会有特殊案例出现,我现在不敢打包票,但一旦出现了新的特例,我们也不要慌张或急于撇清关系,和客户解释清楚,一起从客户的角度上看如何判别即可。

测试小妹妹表示理解,并接受了将来会不断完善产品的这个事实。

6 引出的思考

一个软件,无论整体团队是多么的优秀,总会有考虑不到的情况,这也是为什么软件发布,验收通过之后,常年的维护是必须的,bug也是必然存在的。因为总有考虑不到的情况出现。

当特殊案例发生的时候,一是有必要和客户沟通为什么会发生,获得客户的理解。一个是和技术及测试分析逻辑设定是否有问题,如何在最小的改动情况下解决。

7 题外话

对一个BA的评价,为什么说一个BA对行业很熟,其实就是对通用流程,对特殊流程,特殊情况都很熟,可以在需求分析及设计阶段就能避免很多坑,所以在实际过程中遇到特殊案例其实并不可怕,这确确实实是我们对知识的积累。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值