可是后来发现原来真相不止是一个，而是有很多，从各个角度看到的真相，可能都是真相——或者说都是事实。只是，还有一个更大的真相是我们看不透的。

或许我们永远都无法知道到底什么才是真正的真相。

　　预测显示，在今后50年时间里，人类将会实现载人火星探测、在月球定居、建太空工厂、在小行星上采矿、擦除记忆、大脑移植，甚至还能远离死亡获得永生。而人们目前经常使用的烟灰缸、邮局、钱包和台式电脑等，则很可能会永远的消失。

　　以下为科学家们对未来50年的预测：

　　2010年

　　将消失：手写书信；“正常气候”的概念；个人隐私；烟灰缸；挤奶工。

　　将出现：真假识别器；穿在身上的计算机；梦机器。

　　2015年

　　将消失：迷路；感谢信；陆上电话。

　　将出现：人类在月球上定居；可以随便使用的移动电话；智能化妆品；专门用来睡觉的宾馆。

　　2020年

　　将消失：帕丽斯-希尔顿(明星)；邮局；免费停车；第一次世界大战的幸存者；没有隔离栏的海滩；秘书；DVD；俄罗斯民主；电话薄；“彻底退休”的概念；政府退休金。

　　将出现：机器人外科手术；人造眼球。

　　2025年

　　将消失：正确的拼写；在免费的道路上驾车；台式电脑；周末不工作；马尔代夫。

　　将出现：氢燃料充注站；海上监狱；记忆擦除器；感官互联网。

　　2030年

　　将消失：高清电视；大堤礁(珊瑚礁的一种)；工会；遗产税；进食午餐；皱纹；整容手术。

　　将出现：机器人照料婴儿；虚拟假日；伸向太空的梯子；人工记忆增强器；自动驾驶的汽车；人造细菌。

　　2035年

　　将消失：儿童在没有监管的情况下玩耍；硬币；石油；微软；中产阶级；廉价旅行；孟加拉国。

　　将出现：可自我修复的道路；根据个人基因定制的食谱；3D打印机；虚拟窗户。

　　2040年

　　将消失：钞票和钱包；汽油发动机；成瘾和耳聋均可治愈；本国货币；免费的公共空间；“对不起”这一概念；欧盟。

　　将出现：在太空中建造工厂；单一的全球货币；可以播放电视的墙纸；将一些国家完全用作监狱。

　　2045年

　　将消失：垄断；鞋带；英国的君主制；自然分娩。

　　将出现：根据你的污染排放总量来征收个人所得税；隐身外衣；人类前往火星。

　　2050年

　　将消失：家务劳动；比利时作为一个统一的国家；永久性失明；Google；第二次世界大战的幸存者；“丑陋”这一概念；联合国；死亡--除非你想死。

　　将出现：控制害虫的微型机器人；大脑移植；记忆下载；全球身份证；选举和缴税；反常驾驶；机器人警察；人造大脑；在小行星上采矿；Web 4.0；可监测并控制你压力的衣服。

作者：陈雷 (Jackei)

邮箱：jackeichan@gmail.com

Blog：http://jackei.cnblogs.com

这本书是1997年10月由Prentice Hall 出版社出版，2002年2月电子工业出版业引进的。作者Robert L.Glass是40年IT行业经验的“老ITer”，从20世纪80年代开始，就专门收集和研究IT行业中那些知名的、重大“失控”项目，并努力从中抽取一些规律和经验，供同行参考。虽然书中研究和讨论的17个案例都发生在20世纪80年代中后期至1997年之间，从时间上看显得有些“过时”，但是鉴于国内跟美国之类的发达国家在工程学和软件项目管理方面都还存在着巨大的差距，并且书中的项目都算得上一些“超大型”项目，相信国内绝大多数同行都没有接触过，所以这本书在今天开来，仍然是非常非常有价值的。

不过，如果只是在一些项目中做过开发工作，而没有做过一些大型的、复杂的项目，也没有尝试去思考如何让一个IT项目成功，甚至没有切身的体会过完整的“IT行业”是一个什么概念，那么这本书就显得有些太深了。

另外，作者写这本书的目的也并不是为了系统的讲解IT项目管理，所以不能指望看过这本书后就能学会做项目；但是如果你已经有了一些项目管理的经验，那么倒是很容易通过这本书来重新系统的总结和提升已有的知识和经验，想想如果自己以后遇到类似的项目该怎么办，如何尽量避开这些问题和风险。

*********************************************************************

托尔斯泰说过，“幸福的家庭都相似,不幸的家庭各有各的不幸”，但IT项目刚好相反——成功的项目可能各有各的原因，但“失控”的项目，却总是有些相似的问题。

在本书中，作者引用了KPMG在1989年和1995年进行的两次调查的报告，而两份调查报告的核心，是对英国250家软件企业的“失控”项目进行的统计、分析和“失控根源”分类。根据KPMG的报告，这些项目最终“失控”的原因，归咎于没有指定完整的项目目标（特别是需求）、拙劣的计划和评估、采用新技术、缺乏或根本不具备项目管理方法、团队中缺少资深人士、硬件/软件供应商的低劣表现；而本书的作者在最后又附加了一条“系统无法满足性能和可靠性要求”。下面就对这7大根源先做一个整理。

1. 没有指定完整的项目目标

在KPMG的报告中，有51%的项目失控被认为与“没有指定完整的项目目标”，而核心又是我们在IT项目中最常见的一个问题——需求。作者也列出了几个常见的需求问题，包括：

1）需求过多，系统过于庞大：似乎注定了越庞大的项目需求就越复杂，也越容易失败；

2）需求不稳定，用户无法决定他们真正想要解决的问题；

3）需求模棱两可

4）需求不完整

作者在书中也用占整本书1/3的篇幅讲述了2个很典型的案例，来说明需求突然发生重大变更和项目目标定位过高导致的“失控”案例。可如何做好需求管理，控制好需求变更，这在今天仍然是一个难题。

2. 拙劣的计划和评估

在这一节里，作者提到的关键，是对项目的难度和工作量评估不准确，导致项目的进度永远达不到schedule的要求，并且被无限期的拖延下去。这的确是我们在IT项目中遇到的第二个难题，似乎所有的项目的完成时间都要比预定计划推后一些，虽然不能说一定是计划和评估做的差导致的——因为项目经理还要承担着监控和控制项目进度的职责——但在我们身边的很多项目中，的确存在对项目难度和工作量估计不足，或缺少科学的度量方法的问题；而这又最终导致我们在项目的初期就已经处于“两难境地”，并逐渐进入“死亡行军”的状态。（关于“两难境地”和“死亡行军”的论述，请参见“软件开发的滑铁卢----重大失控项目的经验与教训（之一）”）。

3. 采用新技术

新的技术、框架、平台、方法论、解决方案、术语缩写的推出，相对于10年前（本书第一次出版的时候）越来越频繁，而且貌似这些新东西更新换代的速度越来越快，生命周期越来越短。曾经有做开发的朋友说自己很羡慕那些做C或者C++的人，因为可以“沉下去”，不受外界这些“新东西”的干扰，积累下真正的技术和经验；相对来说，软件测试也占有类似的优势，毕竟我们现在所使用的方法和技术，大多也都是20年前或者10年前发明并流传下来的——当然，那些沉迷于自动化框架开发或者尝试各种新工具的人会不同意我的看法。

新技术的采用，有时的确可以极大的提高生产率，并解决一些棘手的问题，帮助项目最终成功。但是技术的选型就成了最大的问题，因为新东西推出的太快，而我们的IT行业中真正的技术专家、资深人士又总是少数，大多数ITer或者说开发人员，要么只有2-3年的开发经验，对核心技术和行业应用的把握能力有限；要么迫于项目进度的压力，很少有机会去深入的研究和实践这些技术。

当然，还有另外一个关键的额问题，就是技术本身的成熟度问题——新技术是否已经被类似行业或者规模的项目检验过。

4. 缺乏或根本不具备项目管理方法

MSF（Microsoft Solution Framework，微软解决方案框架）对于项目成功的关键，归结于人、流程和技术的完美结合。技术，高价聘请外援可以解决的干脆利索；流程，需要长期积累，但总也是个相对稳定的“风险”；唯有人，或者说PM，是没有办法的，即使有一个优秀的团队，也没法把一个不称职的PM变得称职起来。而这个，反倒是在万事俱备后剩下的最大的风险。

5. 团队中缺少资深人员

其实这个就不用多说了，就如比尔.盖茨先生的那段话所说，“坦白地说，微软所面临的挑战之一是它的很多员工还没有遭遇过多少失败。很多人从未遇到过失败的项目。结果是，人们把成功视为理所当然的事，这是很危险的。。。人们遭遇失败时，将被迫发挥出创造性，不分昼夜地深入探索并冥思苦想。每个公司都需要有过这种经历的人。”

资深人员，就是那些经历坎坷，被各种痛苦的“两难境地”项目折磨过，从一次次“死亡行军”中走过来，有着丰富的经验，知道一个完整的IT项目需要经历那些过程，能够帮助项目尽早识别和规避风险，并解决各种突发事件的人。

6. 硬件/软件供应商的低劣表现

这条分类也是来源于KPMG的调查报告，作者说他手上并没有这方面的案例。不过实际上，可以在本书的17个案例中看到一些端倪。特别是最近我所接触的一些项目，也越来越多的涉及到与外包商的合作——而这也是目前IT行业的趋势。所以我会在今后的项目中留意这一类问题，也许在不久的将来就能有一些身边的案例可以拿出来讨论。

7. 系统无法满足性能和可靠性要求

这一条是本书的作者加的，并不在KPMG的报告中。也许有人会说10年前作者关心的那些性能问题，现在通过更好的硬件、网络以及新的平台和技术都已经可以解决或避免了，已经不再需要担心。可是我们也要看到，10年后的今天，计算机系统所需要处理的业务和需求也在变得日益复杂，而开发人员却并不是个个都关心系统性能的；最终，过于复杂、混乱而低效的代码，仍将导致性能、可靠性和并发性问题。

在本书中，作者也提供了一个案例，讲述了一个存在性能缺陷的系统，如何给用户带来巨大的损失，并险些使一家企业因此而倒闭。

另外，作者也提到了KPMG报告中一些有趣的结论。

1. 许多失控项目都是（或曾经是）“野心过大”的项目；
2. 失控项目可能有一个主要原因，但总是由多个原因导致的；
3. 50%的项目在开发过程中显示可能会失控，而25%的项目在初始的计划阶段就已经显示出将来可能会失控；
4. 72%的失控项目，最初是由项目团队成员发现的；而只有19%的项目失控是最先有管理层意识到的；
5. 1989年只有7%的企业认为技术问题是导致项目失控的主要原因，但1995年这个数字上升到了45%；
6. 有55%的被调查项目根本没有实行过任何风险管理，而38%的实行了风险管理的项目中，又有50%的项目在启动后没有识别到任何风险；

最后，作者结合自己对失控项目的研究和分析，又给出了另外3条结论。

1. 那些一开始就被牵涉到“政绩”和某些其他的商业利益，并被大肆宣扬的项目，大多最终会失控——根据国内的经验来看，这类项目常见的问题是项目目标定位模糊而经常发生变化，或者根本就没有人关心项目真正的成败与否；
2. 越来越多的系统要求用来处理实时交互操作，这导致性能问题越来越成为影响项目的最终成功的问题；
3. 大型的涉及到复杂集成的行业应用，越来越容易成为失控的项目。

*********************************************************************

作者：陈雷 (Jackei)

邮箱：jackeichan@gmail.com

Blog：http://jackei.cnblogs.com

 

“坦白地说，微软所面临的挑战之一是它的很多员工还没有遭遇过多少失败。很多人从未遇到过失败的项目。结果是，人们把成功视为理所当然的事，这是很危险的。。。人们遭遇失败时，将被迫发挥出创造性，不分昼夜地深入探索并冥思苦想。每个公司都需要有过这种经历的人。”

——比尔.盖茨

“犯错的重要性”，《美国航空杂志》，1995年7月

上面这段话是摘自《软件开发的滑铁卢——重大失控项目的经验与教训》一书的，两个月前第一次看到这段话，那时刚好经历了一个让我印象无比深刻的项目，对这段话也特别有感触，就第一时间放到了blog上。

两个月过去了，又重新找出这本书来看，对作者提到的一些现象有了更深的共鸣。鉴于这本书目前尚没有中文电子版，所以决定把其中一些值得反复体会的文字，以及自己在读书过程中的一些思考记录下来， 与大家一起分享。

**************************************************************************

所谓的“软件失控项目”，是指在创建系统所需的软件时遇到困难，从而导致大大超出可控制范围的项目。“项目失控”暗示着项目变得无法管理，从而无法达到最初的目标，甚至无法接近目标——这里所指的目标，包括进度目标、成本目标以及满足功能性和非功能性需求的目标。

但软件项目未能达到成本和进度的目标，常常是因为这些目标本身就是错误的，而软件从业人员辛辛苦苦的工作，其实是不断的耗费时间去迎合不可实现的目标；而这些目标通常是由营销人员或客户指定的，其次是由管理人员来制定，很少有实际完成项目的技术人员涉足其中。

书中作者引用了三个词来说明软件项目所处的不同情形：两难境地（crunch mode），死亡行军（death march），和 失控。我特别喜欢作者对“两难境地”和“死亡行军”项目的描述，很生动很形象的这样两种项目对软件从业人员的影响。

处于“两难境地”的项目面临着无法达到最初目标的威胁，而项目团队在努力想要跨越该困境。软件专家会在办公室给家人打电话说：“我们正处于两难境地，在半夜之前我是不会回家的”。家人也不会吃惊。两难境地的状况可能会持续几天、几周，甚至几个月，这取决于项目本身持续的时间以及它偏离目标的程度。

“两难境地”这个词源自John.Boddie在1987年出版的《Crunch Mode》一书，而这个词并不是Boddie发明的，而是由发现自己被迫完成项目的软件从业者们发明的，通常用来描述进度表极其紧迫的项目，说明项目参与者感受到的压力。

而“死亡行军”项目简单的说，就是当你发现不得不参与到一个项目中，又不得不通过超常的努力和超长时间的工作才能完成那些不合理目标时，你所参与的这个项目就是一个“死亡行军”的项目。

“死亡行军”这个词源自Ed.Yourdon在1997年出版的《Death March》一书，而这个词也同样是由那些被迫在“死亡行军”项目中行走的人们发明的，通常用来描述进度表几乎不可能完成的项目，说明项目参与者的周围弥漫着的是难以忍受的潜在的失败气味。

在我们现实的世界中，通常是因为有人对项目结果期望太高，时间要求太紧，所以从项目开始就呈现出“两难境地”；随着项目的进行，项目参与者很快发现自己在进行“死亡行军”，正在设法实现越来越不可能实现的目标；当项目明显成功无望、多个方面都已失败时，改项目就成为“失控”项目了。

大多数人，如果让他们选择的话，都不愿意加入到死亡行军，不想让自己处于两难境地，而且永远不想处于失控的项目中。可因为系统项目通常受到进度表的支配，管理者根据项目预先确定的进度表来检查项目进度，而进度表总是由那些没有能力精确估算的人来确定——比如营销人员或者客户——所以总是时间紧迫，不合情理。

有意思的是，“两难境地”的提出是在1987年，“死亡行军”的提出是在1997年，两者相隔10年；而我们再反观又过了10年后的今天，2008年，20年过去了，可似乎我们身处的软件行业、软件项目管理并没有出现太明显的改善。虽然真正“失控”的项目只是极少数，而且也并不是所有的死亡行军项目都会失败，但我们可以发现自己要么处于“两难境地”，要么正在“死亡行军”，总是难以逃脱。

**************************************************************************

风险主要是指可能会对项目的进度,质量和成本产生影响的因素,事件——尚未发生的叫风险，已经发生的叫问题. 例如

1. 内部风险

a) 团队内部分工定位不明确，信息沟通不透明

b) 需求变更：包括客户提出新需求、原有需求发生变更、原有需求不够清晰

c) 系统变更：包括平台核心功能升级、已上线系统的升级、新模块上线

d) 技术变更：包括核心技术的更换，或者新技术、新工具的引入

e) 制定计划时有部分任务或事项被遗漏

f) 相关任务或事项没有被具体细化，或相关技术方案尚未被验证通过，或存在尚未明确的任务

g) 资源不足——人员变动，或者工作量超过实际人员的负荷能力，或对某项工作难度估计不足

h) 相关任务的进度推迟，或质量无法满足阶段性要求，需要返工或调整计划，或测试不完整、不充分

i) 系统性能无法满足需求

j) 无原则的对客户要求作出承诺

k) 。。。

2. 外部风险

a) 与项目有关的客户方组织架构发生变动，例如换了项目的主管部门，或者项目经理

b) 客户对系统或需求重新定位

c) 相关计划或方案与客户沟通不充分，或尚未通过评审

d) 与客户或用户沟通不及时，或信息不完整，或客户内部对相关工作理解不统一

e) 需要客户配合的相关工作缺少相关的指导或规范，做法不统一

f) 客户系统环境或用户使用环境复杂，不统一

g) 。。。

暂时想到这么多，供参考。

一个人，呆在酒店里，notebook放着钢琴曲，四周一片寂静，即使做完了所有的工作，还是不想去睡。一遍遍翻着自己一年、两年、三年前写的随笔和邮件，记忆中的一幕幕就那么涌出来，有些不堪回首，有些依然向往。

沉浸其中。

一年，一个项目，一个轮回，一言难尽。

这简直就是《X战警》+《哈利波特》+《黑客帝国》+《黑衣人》+《终结者2》+《魔戒》。。。比《见龙卸甲》还烂！

2008年2月17日

20:59

在图书馆溜达了半天，想借的书没找到，想想又不能白跑一趟，就挑了一本比较轻松的介绍美国生活和文化的书来看。书拿在手上挺厚的，不过读起来很轻松。作者是一位中国女性，嫁到德国，后来又随她的德国丈夫搬到美国生活了两年。书中讲的就是她到美国后所观察和感受到的美国生活，包括了从入境开始到日常生活的衣、食、住、行、乐，以及风俗习惯、社会状况等。对于有兴趣了解一下美国，或者准备去美国的人来说，可以花点时间看看。

P.S. 看过之后最大的感受就是那完全是另外一个世界，我们已有的各种生活常识、习惯完全派不上用场，而且中国人在美国的确是面临着各种不公、歧视。现在国内正在高速发展，没啥事就别跑去那边刷盘子了。。。

贴个目录吧:D

目录

美国初体验
美国签证受歧视
紧张的机场安检
住在纸糊的房子里
社会安全卡的重要性
汽车轮子上的国家
买车的门道
轻松考驾照
免费的高速公路
停车位和汽车一样多
开车的人
和警察过招
租车自由行
银行开户
必不可少的医疗保险
有病不吃药
有钱买不到手机
网络情人
不要相信邮局
购物之乐
休闲的美国时装
情迷洗衣
美容理发
买枪防身
冷漠邻剧
恐怖的市中心
寂寞的乡村生活
一个星期倒一次拉圾
图书馆——人类的头颅
美式英语
混乱的计量单位
旧式的美国家具
美国特色
枪支文化
言论自由
宗教的重要
损献文化
义工精神
堕胎斗争
同性婚姻
个人价值
家庭第一
过度的夸耀与自信
保守的美国人
国旗飘飘
美式肥胖
当心，我投诉你
多如牛毛的法律和律师
反对死刑
……
美国饮食文化
休闲娱乐
美国与中国
必游的美国经典景点

动车行至东莞时，前方的天空已经是黑压压的一片。虽然天色暗了很多，可是从车窗中看出去，周围的景物反倒显得比天气晴朗时还要清晰，突然想起了《无间道I》整部片子里的背景，昏暗，有些压抑，但是对人的视觉有极大的吸引力，连注意力出奇的集中。

到了信息枢纽大厦时，物业已经开始大喇叭广播，要求关好门窗预防台风了。虽然广州的天气也经常受到台风影响，可是还从来没有近距离感受一下台风，好奇啊！可是进了大厦的门以后，没有人带着就没法进出了，围着整层楼转了一圈也看不到一个窗户，又不好意思跟客户说“麻烦您带我去看看台风吧”。于是，只好在屋里呆着，听着外面狂风大作，想像一下是什么样子了。。。

小公务员之死

契诃夫

一个美好的晚上，一位心情美好的庶务官伊凡·德米特里·切尔维亚科夫，坐在剧院第二排座椅上，正拿着望远镜观看轻歌剧《科尔涅维利的钟声》①。他看着演出，感到无比幸福。但突然间……小说里经常出现这个“但突然间”。作家们是对的：生活中确实充满了种种意外事件。但突然间，他的脸皱起来，眼睛往上翻，呼吸停住了……他放下望远镜，低下头，便……阿嚏一声！！！他打了个喷嚏，你们瞧。无论何时何地，谁打喷嚏都是不能禁止的。庄稼汉打喷嚏，警长打喷嚏，有时连达官贵人也在所难免。人人都打喷嚏。切尔维亚科夫毫不慌张，掏出小手绢擦擦脸，而且像一位讲礼貌的人那样，举目看看四周：他的喷嚏是否溅着什么人了？但这时他不由得慌张起来。他看到，坐在他前面第一排座椅上的一个小老头，正用手套使劲擦他的秃头和脖子，嘴里还嘟哝着什么。切尔维亚科夫认出这人是三品文官布里扎洛夫将军，他在交通部门任职。

“我的喷嚏溅着他了！”切尔维亚科夫心想，“他虽说不是我的上司，是别的部门的，不过这总不妥当。应当向他赔个不是才对。”

切尔维亚科夫咳嗽一声，身子探向前去，凑着将军的耳朵小声说：

“务请大人原谅，我的唾沫星子溅着您了……我出于无心……”

“没什么，没什么……”

“看在上帝份上，请您原谅。要知道我……我不是有意的……”

“哎，请坐下吧！让人听嘛！”

切尔维亚科夫心慌意乱了，他傻笑一下，开始望着舞台。他看着演出，但已不再感到幸福。他开始惶惶不安起来。幕间休息时，他走到布里扎洛夫跟前，在他身边走来走去，终于克制住胆怯心情，嗫嚅道：

“我溅着您了，大人……务请宽恕……要知道我……我不是有意的……”

“哎，够了！……我已经忘了，您怎么老提它呢！”将军说完，不耐烦地撇了撇下嘴唇。

①法国作曲家普朗盖特（一八四七－一九０三）作的轻歌剧。

“他说忘了，可是他那眼神多凶！”切尔维亚科夫暗想，不时怀疑地瞧他一眼。“连话都不想说了。应当向他解释清楚，我完全是无意的……这是自然规律……否则他会认为我故意啐他。他现在不这么想，过后肯定会这么想的！……”

回家后，切尔维亚科夫把自己的失态告诉了妻子。他觉得妻子对发生的事过于轻率。她先是吓着了，但后来听说布里扎洛夫是“别的部门的”，也就放心了。

“不过你还是去一趟赔礼道歉的好，”她说，“他会认为你在公共场合举止不当！”

“说得对呀！刚才我道歉过了，可是他有点古怪……一句中听的话也没说。再者也没有时间细谈。”

第二天，切尔维亚科夫穿上新制服，刮了脸，去找布里扎洛夫解释……走进将军的接待室，他看到里面有许多请求接见的人。将军也在其中，他已经开始接见了。询问过几人后，将军抬眼望着切尔维亚科夫。

“昨天在‘阿尔卡吉亚’①剧场，倘若大人还记得的话，”庶务官开始报告，“我打了一个喷嚏，无意中溅了……务请您原……”

“什么废话！……天知道怎么回事！”将军扭过脸，对下一名来访者说：“您有什么事？”

“他不想说！”切尔维亚科夫脸色煞白，心里想道，“看来他生气了……不行，这事不能这样放下……我要跟他解释清楚……”

当将军接见完最后一名来访首，正要返回内室时，切尔维亚科夫一步跟上去，又开始嗫嚅道：

“大人！倘若在下胆敢打搅大人的话，那么可以说，只是出于一种悔过的心情……我不是有意的，务请您谅解，大人！”

将军做出一副哭丧脸，挥一下手。

“您简直开玩笑，先生！”将军说完，进门不见了。

“这怎么是开玩笑？”切尔维亚科夫想，“根本不是开玩笑！身为将军，却不明事理！既然这样，我再也不向这个好摆架子的人赔不是了！去他的！我给他写封信，再也不来了！真的，再也不来了！”

切尔维亚科夫这么思量着回到家里。可是给将军的信却没有写成。想来想去，怎么也想不出这信该怎么写。只好次日又去向将军本人解释。

①古希腊一个洲，居民以牧羊力业。喻：安乐之邦。

“我昨天来打搅了大人，”当将军向他抬起疑问的目光，他开始嗫嚅道，“我不是如您讲的来开玩笑的。我来是向您赔礼道歉，因为我打喷嚏时溅着您了，大人……说到开玩笑，我可从来没有想过。在下胆敢开玩笑吗？倘若我们真开玩笑，那样的话，就丝毫谈不上对大人的敬重了……谈不上……”

“滚出去！！”忽然间，脸色发青、浑身打颤的将军大喝一声。

“什么，大人？”切尔维亚科夫小声问道，他吓呆了。

“滚出去！！”将军顿着脚，又喊了一声。

切尔维亚科夫感到肚子里什么东西碎了。什么也看不见，什么也听不着，他一步一步退到门口。他来到街上，步履艰难地走着……他懵懵懂懂地回到家里，没脱制服，就倒在长沙发上，后来就……死了。

一八八三年七月二日

守卫卢沟桥的战士在掩体后面准备战斗

    1937年7月7日，日军进攻卢沟桥。
    卢沟桥横跨永定何，属河北省宛平县管辖，距北平仅30里，为捍卫北平的屏障。驻守在平津一带的中国军队是第二十九军，总兵力约有10万人。
    7月7日夜10时，驻丰台日军河边旅团第一联队第三大队第八中队，由中队长清水节郎率领，在卢沟桥以北地区举行以攻取卢沟桥为假想目标的军事演习，11时许，日军诡称演习时一士兵离队失踪，要求进城搜查。在遭到中国驻军第二十九军第三十七师二一九团团长吉星文的严词拒绝后，日军迅即包围宛平县城。翌晨2时，第二十九军副军长兼北平市长秦德纯为防止事态扩大，经与日方商定，双方派员前往调查。
    但日军趁交涉之际，于8日晨4时50分，向宛平县城猛烈攻击。并强占宛平东北沙岗，打响了攻城第一枪，中国守军忍无可忍，奋起还击，日军在同一天内，连续进攻宛平城三次，均遭中国守军的英勇抵抗。
    7月8日，北平当局令驻军坚守卢沟桥。宋哲元致电蒋介石，报告卢沟桥事变真相。
    同日，国民政府外交部为卢沟桥事变向日本大使提出口头抗议。
    同日，日本内阁会议提出所谓“事件不扩大，就地解决”的方针，欺骗世界舆论，麻痹国民党当局，争取时间调集部队。
    9日，北平当局与日军达成协议：(1)双方立即停止射击；(2)日军撤退至永定河左岸，中国军队撤至右岸；(3)卢沟桥守备由河北保安队石友三部担任。翌日，中国军队撤退，日军不仅不履行诺言，反而大批调兵向中国军队进攻。
    11日，平津当局与日军达成现地协定：(1)第二十九军代表声明向日军表示道歉，并惩办此次事变责任者；(2)取缔GCD、蓝衣社及其他抗日团体的抗日活动；(3)永定河以东不驻中国军队。
    10日，各方纷纷报告，日军已由天津、古北口、榆关等处陆续开到，且有大炮、坦克等向卢沟桥前进，已将大井村五里店等处占领；平卢云路也不通行，战事即将再发。
    11日起，日军时以大炮轰击宛平城及其附近一带，城内居民伤亡颇多，团长吉星文亦负伤，就将城内居民向城外比较安全地带疏散。战事由此扩大到八宝山、长辛店、廊坊、杨村等处。第二十九军各部分散于各处应敌。日军出动飞机在各处侦察扫射，战事时断时续。
    卢沟桥事变揭开了全国抗日战争的序幕。

20世纪30年代的卢沟桥 

驻守宛平县城的中国军队出城抗击日军 

日军炮轰宛平县城 

守卫卢沟桥的国民党第29军士兵

不说了，上图。

“坦白地说，微软所面临的挑战之一是它的很多员工还没有遭遇过多少失败。很多人从未遇到过失败的项目。结果是，人们把成功视为理所当然的事，这是很危险的。。。人们遭遇失败时，将被迫发挥出创造性，不分昼夜地深入探索并冥思苦想。每个公司都需要有过这种经历的人。”

——比尔.盖茨

“犯错的重要性”，《美国航空杂志》，1995年7月

深有体会。特别是在软件项目越来越庞大和复杂的今天，项目中任何一个环节的失误都将对整个项目产生无法预计的影响。因此，也就特别需要富有经验的——特别是有过失败项目经验、并从中反思总结过的人参与到项目中来。

Thinking in Risk.