发一个功能强大的客户数据清理工具，通过工具可以自动识别出这些混乱的数据，并且提供一些合并、汇总、删除功能”。
随着这个功能的开发，项目的范围也不断扩展，针对这个功能的需求也层出不穷。这就是软件开发过程中的“充电站”，成本付出了，但真的对项目有好处吗？
这样做合适吗？似乎很多人会举手赞成，但是也付出了巨大的成本。如果我们细究一下，这个问题是怎么产生的呢？为什么数据会混乱呢？实际上根源问题是在用户输入数据时，系统对数据的校验不足，因此更科学的方法是加强输入时的数据校验，而不是开发一个大“充电站”来事后补救。
隐喻：
在万般无奈下，有人提出了一个蹩脚的主意：在出口立一个大牌，上面写上“如果是白天，并且车灯开着，请熄灭车灯；如果天色已晚，并且车灯没开，请打开车灯；如果是白天，并且车灯没打，就别打开它；如果天色已晚，并且车灯开着，请别关掉它”。
这样能够解决问题吗？显然不能呀，在汽车行驶过程中谁能够阅读完这么长的一段话呢？
有些时候，软件开发人员也会采用类似的提示语，例如安装过程中的向导就是这样的例子：明知道大家都是闭着眼睛点击“下一步”按钮的，那么为什么还要不断地重复这样的设计呢？这难道不就是这个蹩脚的标牌吗？
那么怎样才能够解决这个问题呢？关键在于对问题的定义，先确定这里到底存在什么样的问题？如果从这个角度来看，不难发现：
图4寻找问题的本源
表现出来的问题是车没电了，而为什么没电了呢？因为司机忘了关大灯。为什么会忘了关大灯呢？往往是没有人提醒他而造成了疏忽。通过这样的分析，我们就知道需要的解决方案是“提醒机制”，这时就不难得出有效的解决方案：
隐喻：
最后终于有一个清醒的人提出了一个有效的解决方案，那就是在出口出立一个标牌，上面写上“你的灯亮着吗？”。
我想这时让你给出类似的解决方案也并非难事，为什么前面会绕了一圈呢？关键就是没有正确地认识到什么是问题？这个案例诠释了“对问题进行了正确的定义，意味着成功解决了一半”的内涵。