前两周，我分别通过两篇文章《测试人员参与需求评审的价值是什么？》和《需求评审之实战演练》对需求评审阶段要做的事情做了大概的说明，今天是第三篇，主要想说说需求评审过程中对隐形需求挖掘的重要性。
一
我们先来看一个例子：
「爸爸，我想吃面条。」
「现在太晚了，饭店已经关门了，明天我带你去吃好不好？」
「不好不好，我就要吃面条。」
「你这孩子，这都 11 点了，哪还有面条？快给我睡觉去。」
「哇……」
脑补下宝宝大哭的画面。
来，我们现在换一个爸爸来对话：
「爸爸，我想吃面条。」
「今天太晚了，饭店已经关门了，明天我带你去吃好不好？」
「不好不好，我就要吃面条。」
「闺女是不是肚子饿了？我给你拿你最爱吃的面包好不好？」
「好呀好呀。」
虽然只是一句话的差别，但是得到的结果却是天壤之别。
上面例子中这句话如果按我们测试的行话说，就是发现了用户的隐性真实需求。
我闺女是想吃面条，但是因为饿才想吃，而不是单纯的想吃，那么只要解决饿的问题就好了，她爱吃意大利面我是知道的，她同样也爱吃吐司，我也是知道的，所以就可以通过吐司来解决她饿的问题了。
道理看起来很简单，但如果想不到这个点，就解决不了问题，还有可能造成负面影响。
这里我想说的是，隐性需求，就是真实的原始需求。
二
我们继续拿之前那个简易计算器的需求作为第二个例子，重新描述下需求：
现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。
看过之前文章的同学都知道，这是我经常用的一道写测试点的面试题。
从我面试的结果看，大部分在写功能测试点的时候都能覆盖到三个参数的正常和异常情况，一半的人能考虑到参数个数的正常和异常情况，一小半的人能考虑到数字参数的最大值情况，非常少的人能考虑到参数分隔符的正常和异常情况。
参数类型、参数个数这些都是需求里面明确写出来的，这些我们可以称为显性需求，所以能考虑到这部分用例的人很多，特别是参数的正常和异常，不管是否知道等价类划分法，都能考虑到。
但是参数个数和数字最大值，又可以算到边界值分析法里面，如果不知道边界值分析，可能不会考虑到参数个数所有异常的覆盖情况，如果不懂编程，可能问不出来数字使用什么类型这样的问题，当然也就不知道所谓的最大值要怎么构造了，所以这个也可以算到隐性需求的范畴。
最后一个很少人考虑到的参数分隔符，肯定是我们要说的隐性需求了，这种没有明确说明的地方，有时候开发会按照自己自以为的方式给实现了，比如默认空格分割，但是测试后期发现很多人也会用逗号去分割，修改的话会造成新的修改成本，其实这么简单的地方，需求评审的时候提一下，就可以把需求明确了，难的是谁能想的到。
这里我想说的是，隐性需求，就是把习惯性思维明确化。
三
第一个关于原始需求的例子，如果拿我们实际项目的情况来对应的话，可以找出来很多，比如某用户嫌某个软件的功能太多，其实他可能只是说他常用的功能入口太深而已，比如某用户嫌软件广告太多，其实可能只是推送的这些广告都不是他的关注点而已。
第二个关于习惯性思维的例子，实际项目中也经常发生，而且特别坑人，有个专有名词叫「经验主义」特别适合这个地方，这里我又想起来另一个例子，可以说一说。
我高中时的数学还不错，最喜欢上的就是数学课，对各种数学题比较感兴趣。
记得有一次课间休息，我不知道怎么就坐到一位成绩不太好的同学的座位上了，然后看到他桌子上放着还没做完的数学作业，一时兴起，就顺手给做完了，本来想着这同学回来该感谢我的，可是等到的却是责怪，责怪我不该把他作业给做了，确实是我的错，我一时无语。
事后我仔细想了想，这件事纯粹就是我自己的一厢情愿了，我以为不爱学习的同学都不爱写作业，我以为帮别人写了作业别人会高兴，所有这些都是「我以为」，或者说是我的经验主义在作祟，让我没能从实际情况去做出正确的判断。
这种事在需求评审过程中很常见，有一些貌似「不言自明」的逻辑，每个人都以为自己明白，别人也肯定能明白，并且和自己理解的一致，其实每个人可能理解的都不一样。
这件事之后，我对自己的经验就总是持怀疑态度了，不过这是另外的话题了，这件事带给我的一个好处就是，每件事我都尽可能的去把它明确了，我听别人说的话，就算很明白，我也尽量复述一遍让他确认，别人听我说的话，我也尽量让他复述一遍，我再确认。
其实需求评审就是这么个明确显性需求、挖掘隐性需求，然后相互确认理解一致的过程。
这里我想说的是，隐性需求，就是避免经验主义。
四
一不小心又啰哩啰嗦的写了这么多，几个例子无非都想说明的是，隐性需求很重要，有时候，正确挖掘过的隐性需求会直接推翻现有的需求方案。
不知道你的项目中是否出现过这些情况，欢迎留言讨论。
