;
图3 路线指引牌示例
我对此深有感触，回来之后与一位做嘉年华游乐场的朋友谈起这个事情。可以他的回应却是：“吃饱了没事干呀，有必要管到这么细吗？”
……
我接下来告诉他：“我当时用手表掐了一下时间，每换一船人花掉的时间是2分50秒以内，我们现在到你那掐一下”。
当我们用秒表掐了一下时间，就发现在他这里，每换一船人花掉的时间都在5分钟上下。
我就趁热打铁地说到：“你看看，你这一天要少赚多少钱呢？”这时这位朋友说：“我马上去做一些这样的牌子……”。
为什么这位朋友前后判若两人呢？因为前面的沟通听起来是“管理的成本”，后面的沟通则提到了“经营的效益”。信息系统很多时间都给人一种“管理成本”的印象，因此如果能够多从“经营效益”的角度来沟通，一定会达到更好的效果，这也是高层管理层真正有兴趣的角度。
抓住问题的本质
问题经常会被表象所掩盖，如果不能在问题定义时揭开这个表象，那么经常会给解决方案带来问题。而对此类技巧阐释得最完美的当属温伯格先生的大作《你的灯亮着吗？—发现问题的真正所在》，在这本书中收录了十余个很有意思的故事，而书名正是其中最有代表性的一个。
下面我们就简要地回顾一下这个故事，看看它背后的哲理对日常的软件开发工作有什么样的启示：
隐喻：
话日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。针对这个问题，大家提出了解决方案：“警告！前有隧道请打开车头灯” 。
但不久之后，路政部门接到了一些反馈与投诉：隧道出口风景很美，返回时发现汽车没电，原来是忘了关车头灯！！
这个问题看起来并不难解决，有人马上提出了一个解决方案：在出口处立一个标牌，写上“关掉车灯”。
这样问题解决了吗？当然没有！如果夜行车经过这个隧道时，看到写着这个“关掉车灯”的标题应该作何处理？难道真的关掉车灯，那是多么危险的行为呀！在软件开发过程中，经常也会出现类似的“惯性思维”，看上去解决了问题，实际上将会产生更麻烦的问题。
案例&场景：
小林在一次电子政务项目中遇到了这样一个问题，用户要求对每个政务申请的各种处理都需要记录时间。由于他们选择的是C/S结构，因此取时间时就遇到问题，每台机器上的时间都不尽相同。
“不就是时间不统一吗，让所有客户端登录时先从时间服务器上取一个时间就搞定了！”。
但这个方案在实际的运行时却带来了不小的麻烦，由于时间服务器写得不够稳定，经常会自动退出，当这种情况出现时客户端软件就根本无法进入，严重影响了客户的正常使用。
其实解决这个问题的方法有很多，例如在数据库存储时来处理，即取数据库服务器的当前时间。而且即使采用这种方法，也不应该在时间服务器同步失败时阻止用户登录系统。
隐喻：
既然“关掉车灯”的解决方案是不可行的，那么就换个思路吧：前面的思路是事前预防，那就改成事后补救吧。因此就有人提出一个新的解决方案，那就是建设一个充电站。
但是建充电站也有问题，不仅维护开支很大，而且本身也会出故障。要解决这个矛盾，又有人提出是否将充电站交给私人经营，但这又不符合当地的法规。
“用一个成本很大的解决方案去弥补自己的错误”是很常见的问题，原本不是什么大问题，却花费了巨大的成本。这种现象在软件开发过程中也不少见：
案例&场景：
在小陈负责的一个客户关系管理系统项目中，用户在使用了一段时间之后提出了这样一个问题：客户数据库的数据比较乱，有重名、同客户多条记录等现象。
小陈毫不犹豫地说：“没关系，我可以为你们开