[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对行业很熟，其实就是对通用流程，对特殊流程，特殊情况都很熟，可以在需求分析及设计阶段就能避免很多坑，所以在实际过程中遇到特殊案例其实并不可怕，这确确实实是我们对知识的积累。