1. 前言
需求分析师(或)产品经理,作为业务与技术的桥梁,需要和所有的项目/产品干系人沟通,确保大家对功能的认知在同一个维度上。之前处理比较多的是如何用业务的语言向客户解释系统的逻辑,但这个例子却是相反,是用IT的语言解释业务需求的合理性,好了,下面案例分析开始:
2. 需求模型背景
整个需求其实非常大,这里简化一下需求模型:
- 系统业务背景:校外教育培训机构的教务管理软件
- 功能点:判断一个学生是否是一个新生
2.1 需求模型
- 判断条件1:这个学生首次来机构报名上课,计算为新生
- 判断条件2:这个学生在机构上过课,但是半年前已经结课(结课条件:课程已经上完,该生在课程的钱也用完)
- 不是新生的,都是老生
2.2 IT设计模型
根据需求模型,IT设计的判断条件如下:
- 这个学生在系统里从来没有过完款合同
- 这个学生在系统里有完款的合同,但是最近半年内没有上课记录,并且该完款合同资金已用完
- 满足条件1或2,这个学生都算新生,不满足这两个条件的,都算老生
3 实际情况中发现的问题
根据IT设计模型中,正常的学生报名,判断新生老生,正常的案例都已经验证过没有问题。
但客户反馈了几个案例,说是这几个学生换班转课之后,又被系统判定为新生,这是怎么一回事呢?
经测试查证,发现这几个学生,在报读了A课程之后,没有上过任何课,就在系统上把A课程给退了,然后报了B课程。系统根据逻辑,180天内无课消,历史合同资金为0,就把这个学生判断为新生了。
4 测试对需求的理解
测试小妹妹在嘟囔了:“需求文档上不是定了180天内无课消,历史合同资金用完,再报读就算新生嘛,这几个案例完全满足啊”
5 解释原因背景
我对测试小妹妹说:“如果我们作为IT的人,把一个需求,看成一个冷冰冰的逻辑关系,而不去了解事情背后的原因,那我们是无法成长的。”(【画外音】为什么很多人说IT男/IT女很难沟通呢,我估计就是常年仅关心需求逻辑,而不去关心需求背后的含义)
见测试小妹妹不是很明白,我用现实中的真实案例来做解说:
无人车的案例:
我记得特斯拉的无人车之前在美国发生过一个案例,就是一两私家车,无法在天气晴朗的情况下中辨认白色货车,全速撞上货车。
相关报道:特斯拉无人车酿死亡车祸
我这里大胆猜测一下,假设需求是需要辨认周围的物体,如果是物体则不能装上去。那换成技术设计是什么呢?技术不可能简单的写:
If (前面物体 == true) then {
停车
}
因为摄像头捕捉到的都是图片,要从图片中分辨车,马路,路边的草,斑马线,下水道盖子,就需要用到图片分析,那图片分析会不会根据色差来划分物体?比如色差大过多少,算一个物体(臆想的,如果实际技术不是这样判断,请告知详细)。用这个案例来说,可能技术的列举是辨认黑色,蓝色,绿色等有颜色的物体,但唯独和晴朗天气或周围物体颜色很接近的白色车便辨认为非物体(比如地上的指示白线?),然后开发,测试也按照技术需求的颜色都过了一遍,测试案例通过,皆大欢喜。但这不能代表实际需求就是这样,结果导致了悲剧发生。
另一个例子是前段时间发生的波音737MAX8的坠毁事件,网络文章很多,自行百度即可。事后的分析中,说到了波音给飞机加上了一个仰角控制系统,使飞机机头自动下坠的夺命系统MACS。如果这个系统出现故障,电脑会认为飞机失速,于是激活MCAS,强行将机头下压。这个可能确实是需求这么写的,但需求设计也有可能是错的,结果导致了飞机的坠毁。
举例了上述两个例子,我跟测试小妹妹说,为什么说一个开发团队,不是说一个厉害的项目经理,一个厉害的需求分析师,厉害的架构师和程序员,就一定能开发出完美的应用的。我们要充分理解:
- 客户的真实需求
- 实际可能出现的边界情况
- 实际可能出现的例外情况
特别是第3点,要靠整个团队对业务的理解,才能在之前尽可能的想到边界情况并加以在程序中判断。(画外音,windows那么多漏洞,不就是因为很多例外或边界情况被黑客抓到了来攻击的嘛,但不影响Windows是很优秀的软件。)
这个案例中,就是需求分析之后,对逻辑的设计出现了偏差,没有考虑到一个学生报读了课程,完全没有上课的情况下,又转到了新的课程上。想想,从客户的角度上看,第二个合同肯定不是新生嘛。
所以我们要改之前的设计,判断这类条件。需求增加了以下字眼:
如果本合同为转费合同的,做以下判断:
- 新合同都为续费合同
判断结束终止
原因:转费合同意味着之前必然有一个剩余实收金额不为0的合同,新合同才可在原合同上做转费操作
至于将来会不会有特殊案例出现,我现在不敢打包票,但一旦出现了新的特例,我们也不要慌张或急于撇清关系,和客户解释清楚,一起从客户的角度上看如何判别即可。
测试小妹妹表示理解,并接受了将来会不断完善产品的这个事实。
6 引出的思考
一个软件,无论整体团队是多么的优秀,总会有考虑不到的情况,这也是为什么软件发布,验收通过之后,常年的维护是必须的,bug也是必然存在的。因为总有考虑不到的情况出现。
当特殊案例发生的时候,一是有必要和客户沟通为什么会发生,获得客户的理解。一个是和技术及测试分析逻辑设定是否有问题,如何在最小的改动情况下解决。
7 题外话
对一个BA的评价,为什么说一个BA对行业很熟,其实就是对通用流程,对特殊流程,特殊情况都很熟,可以在需求分析及设计阶段就能避免很多坑,所以在实际过程中遇到特殊案例其实并不可怕,这确确实实是我们对知识的积累。