案例&场景：

    小林在一次电子政务项目中遇到了这样一个问题，用户要求对每个政务申请的各种处理都需要记录时间。由于他们选择的是C/S结构，因此取时间时就遇到问题，每台机器上的时间都不尽相同。

    “不就是时间不统一吗，让所有客户端登录时先从时间服务器上取一个时间就搞定了！”。

    但这个方案在实际的运行时却带来了不小的麻烦，由于时间服务器写得不够稳定，经常会自动退出，当这种情况出现时客户端软件就根本无法进入，严重影响了客户的正常使用。

    其实解决这个问题的方法有很多，例如在数据库存储时来处理，即取数据库服务器的当前时间。而且即使采用这种方法，也不应该在时间服务器同步失败时阻止用户登录系统。

    隐喻：

    既然“关掉车灯”的解决方案是不可行的，那么就换个思路吧：前面的思路是事前预防，那就改成事后补救吧。因此就有人提出一个新的解决方案，那就是建设一个充电站。

    但是建充电站也有问题，不仅维护开支很大，而且本身也会出故障。要解决这个矛盾，又有人提出是否将充电站交给私人经营，但这又不符合当地的法规。

    “用一个成本很大的解决方案去弥补自己的错误”是很常见的问题，原本不是什么大问题，却花费了巨大的成本。这种现象在软件开发过程中也不少见：

    案例&场景：

    在小陈负责的一个客户关系管理系统项目中，用户在使用了一段时间之后提出了这样一个问题：客户数据库的数据比较乱，有重名、同客户多条记录等现象。

    小陈毫不犹豫地说：“没关系，我可以为你们开发一个功能强大的客户数据清理工具，通过工具可以自动识别出这些混乱的数据，并且提供一些合并、汇总、删除功能”。

    随着这个功能的开发，项目的范围也不断扩展，针对这个功能的需求也层出不穷。这就是软件开发过程中的“充电站”，成本付出了，但真的对项目有好处吗？

    这样做合适吗？似乎很多人会举手赞成，但是也付出了巨大的成本。如果我们细究一下，这个问题是怎么产生的呢？为什么数据会混乱呢？实际上根源问题是在用户输入数据时，系统对数据的校验不足，因此更科学的方法是加强输入时的数据校验，而不是开发一个大“充电站”来事后补救。

    隐喻：

    在万般无奈下，有人提出了一个蹩脚的主意：在出口立一个大牌，上面写上“如果是白天，并且车灯开着，请熄灭车灯；如果天色已晚，并且车灯没开，请打开车灯；如果是白天，并且车灯没打，就别打开它；如果天色已晚，并且车灯开着，请别关掉它”。

    这样能够解决问题吗？显然不能呀，在汽车行驶过程中谁能够阅读完这么长的一段话呢？

    有些时候，软件开发人员也会采用类似的提示语，例如安装过程中的向导就是这样的例子：明知道大家都是闭着眼睛点击“下一步”按钮的，那么为什么还要不断地重复这样的设计呢？这难道不就是这个蹩脚的标牌吗？

    那么怎样才能够解决这个问题呢？关键在于对问题的定义，先确定这里到底存在什么样的问题？如果从这个角度来看，不难发现：

    
    图4寻找问题的本源

    表现出来的问题是车没电了，而为什么没电了呢？因为司机忘了关大灯。为什么会忘了关大灯呢？往往是没有人提醒他而造成了疏忽。通过这样的分析，我们就知道需要的解决方案是“提醒机制”，这时就不难得出有效的解决方案：

    隐喻：

    最后终于有一个清醒的人提出了一个有效的解决方案，那就是在出口出立一个标牌，上面写上“你的灯亮着吗？”。

    我想这时让你给出类似的解决方案也并非难事，为什么前面会绕了一圈呢？关键就是没有正确地认识到什么是问题？这个案例诠释了“对问题进行了正确的定义，意味着成功解决了一半”的内涵。