案例：一个系统功能实现方式引发的隐形需求

场景：

前几天，在公司的图书馆里找书看书，无意中听到某项目组同事们的讨论。他们在讨论一个系统功能的实现方式，说的是功能F需要短讯提醒，按要求，执行功能F时申请人和审批人都需要收到短信功能提醒，但是他们收到的短信内容是不一致的。

同事W讲到了一种解决方法，说准备采用数据权限配置的方法来实现功能F，通过不同角色的客户获得不同的权限信息的方法来取到不同处理人的提示信息。我无意中听到他们的讨论，我就插了一把嘴，说：假设我日常就是一个审批角色的人员，但是在某个时期上，我刚好就是一个申请者，那么在这种情况下，我会收到什么信息呢？W同事，你这个解决方法可行吗？

同事思考了一两分钟后，给我回复，说你这种情况有两种解决办法：

1. 如果申请人是审批者角色，那么业务流程处理到审批步骤时，系统自动跳过，无需再经过功能F；
2. 如果不优化流程，那么可以在发送短讯的接口功能，不重复发生短讯，只收到审批的短讯；

我说，你再思考一下，看你这两种解决方法还有没有漏洞？等我转了一大圈回来后，重新碰到项目组同事W，我问他思考得如何，W说他选择方法2，并且和发送短讯接口的同事M联系了，同事M告诉他通用短讯组件不处理这个功能，需要W在业务系统中实现。

分析：

其实一个IT系统最重要的基础就是要忠实地反映实际的情况，我刚才的提问只是一个陷阱，假如我就是申请者又是审批者，那么按照规则，我就是收到了两条短讯也是完全合理，并且可以解释的。读者，你看到这里应该也会觉得没有问题啊，讨论的问题很简单啊，没有继续讨论下去的必要啊！

呵呵，其实创作IT系统，当你遇到“别扭”的情况下，往往是代表有些问题的，最好的方法一定是停下来思考，从业务角度出发去寻找答案。

功能F是一个处理期权申请的功能，放到这个业务场景下，假如我就是一个企业的高管（例如CFO），我做了一个期权申请，然后我自己审批了自己的期权申请（或者如同事W所说跳过了审批步骤），那么我想问问谁应该为“金融”危机负责呢？！从这个角度上，从一个技术问题转化为需要问题了，这个需求是一个没有被挖掘漏洞。

朋友，你看到了吗？不了解业务，只从技术的角度去思考问题、处理问题，很可能你得到的解决方法是很荒谬的。