《灯》中的故事给予的启发

读书笔记<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

读《灯》中的故事有感

这是一本薄薄的书，我用了两个上班途中来看完，书是由一个个小故事组成，所以也适合用这种方式来阅读。书读起来非常轻松，仅仅120页，但却相当生动有内容，虽然有些地方读起来有点涩，比较难理解一些，但是全书读下来还是有不少的收获。

书的内容由多个幽默生动的小故事组成，每个小故事都有若干生动有趣而又有警戒意义的故事作为主线，通过对故事中实际问题的解决，引申出作者对于问题解决领域的重要观点。全书包括了55幅精美的线条画（风格有点像《谁动了我的奶酪？》），是一本制作精良的珍品。每个小故事都穿插着非常深刻的观点。

我将书里的几个故事我感触比较深的故事做了一下整理，并写了点感悟，与大家分享。

故事8：玩具公司的厂址

作为一家生产型企业，玩具公司需要对其各个生产厂的厂址进行规划。由于产品销售点分布全国各地，而各地的原料供应价格也有较大差异，因此，如何进行成本最小化是运筹学中的一个多元优化问题。考虑到产品原料价格、各个分销点和生产厂之间的运费、管理成本等等因素，该问题相对于时间和地理位置都非常复杂。

汤姆从玩具公司接到的任务就是去完成这个复杂的分析和编程问题。经过卓越的研究，汤姆最后给出了一个完美的解决方案，如果按照这套方案进行，玩具公司的成本会比以前低不少。

但是这个方案最终被否决了，因为在这种方案下董事长和总经理都必须搬到较远的地方去办公。

故事9：patience小姐和1分钱的故事

Patience小姐以耐性出名，但她却终于因为和财务员在一个1分钱地问题上失去了耐性。

故事发生在美国某州的计算机中心。Patience是程序员，她从财务员处受委托开发一个财务程序，最初的程序一个星期就开发完成了。但是，财务员发现，Patience小姐的程序在最后的总额上由于尾数的原因和实际发生总额不一致。

Patience小姐耐性地根据财务员的要求不断调整程序，3个月过去了，Patience小姐的程序算出来的结果和实际总额的误差为1分钱。财务员仍然不满意，他认为如果Patience小姐不能够把这1分钱的误差消除，他将不能启用这个程序，因为，因为这是他对纳税人的负责、也是对法律的负责。Patience小姐终于出离耐性了。

故事10：

A国国家安全部截获了其欧洲盟国B国从驻A国大使馆发回本国的外交电报。情报人员发现，该电报由一种神秘的编码方式加密。为了保卫国家的安全和机密，情报局专门成立了一个密码破解技术攻关小组秘密地对这批电报进行破解。该计划的代号为“JACTITATION”。

18个月过去了，技术人员开始肯定这份外交密文用的是一种“书码”(一种几乎无法破解的密码)，又经过了6个月的时间，破解专家终于找到了“书码”的来源，他们是在国家图书馆的间谍和阴谋藏书架上发现的，那是一本侦探小说，题为《贝娄娜俱乐部的争执》。

破译的结果出来了，这份外交密文是：“二十三瓶苏格兰威士忌，五十九瓶葡萄酒……”。所有截获得外交密文都是类似的开支帐目。原来这是B国驻A国大使馆使馆人员每天的支出帐单。JACTITATION计划就这样闹剧一般地结束了。

结果：技术专家因为这项工作获得了一个技术领先奖作为安慰。

故事8、9、10的启示：

故事8中我们看到了技术的无用――如果脱离了人的因素。所有的理论和技术都是为了解决人类现存的或者将要发生的特定问题的。技术一旦离开了现实意义，就变得一文不值。软件开发中，如果没有真正帮助用户解决问题（注意，是解决实际问题，而不仅仅是表面的技术问题），那么这样的软件注定是要失败的。

故事9说明软件系统不可能与现实社会一模一样，而这种微小的差距正是技术应用于社会的最大讽刺。理论科学家总会把完备性放在重要的位置，而应用技术人员则应该完全丢弃完备性等理想主义情绪。针对那些喜欢钻牛角尖的用户和领导，不要指望你的努力能够改变你的产品的命运，除非你能说服他们实用的重要性。幸好这些问题已经逐步被社会各界所认同。

在故事10中，我们发现，B国本身为A国的盟国，而这种这么容易截获得外交电报本身是很难承载机密信息的，那么A国安全部在确定JACTITATION计划之前是否可以考虑这个计划的必要性呢？或者说，技术专家在拿到问题的时候，是否可以问一句：我们是否真的需要这个解决方法吗？

在我们的现实生活中，也会遇到很多咋一看非作不可、至关重要的事情，而且我们一样往往是不分青红皂白着手解决问题，更为严重的是，在问题解决方法不断深入或者变难的时候，我们从来不会回过头来看一看是否真的需要解决这个问题。

开发更是如此。也许我们因为某个原因启动或承接了某一个项目，该项目最初的目的随着项目周期的推移和需求的不断扩展会逐渐走样，如果我们的技术负责人和项目经理只知道埋头技术问题，而不是常常回过头来反省这个项目的技术可行性和需求必要性，往往会将一个项目组拖垮，直到最后给公司带来不可挽救的损失。这对于软件的IS系统、ERP项目，企业内部体制改革项目等领域都有着很多现实的沉痛的例子。

本文内容来源：来自citizen。版权所有。转载请注明出处和作者。