不率意斋

这算啥? 我想了一切办法, 也没能从问号里还原文字. 只好去客服页面填单子. 说实在的, MS的客服还真是不错, 第二天就回信了. 说我的BLOG涉及儿童色情! 这这这, 这又从何谈起!!!???!!!

仔细一看, 说我的相册里有一些图片不宜, 有裸体儿童! 我$%(@#^#$)@#$!, 那是我儿子大雄, 有两张光屁屁照片, 三个月大时照的. :~(

MS说得很客气: 请注意，为了保护未成年人，避免他们被某些不道德的个人所利用，无论色情与否，我们都不允许用户发布关于婴儿以及儿童全裸或者部分裸露的图片。

哦, 原来是为我们大雄好, 嗯, 还真是让我越想越后怕哦! 万一大雄的光屁屁不雅照片被坏人利用, 比如拿来PS啥的, 那可怎么办呀, 我我我, 我这就删除.

于是, 再向MS申诉, 说那是我儿子, 我知道我错了, 我这就去删除, 我们国家里小孩子光屁屁不要紧, 不知道美国的法律严格. 还有, 你们发给我的信, 没有字嘛! 我啥也看不到, 也不全赖我.

MS的服务还真得是没话说, 一会儿功夫, 空间恢复了!

赶紧删除大雄的漏点照, 连光膀子太大的也都删了, 这才有功夫擦擦汗....

所以, 朋友们呀! 千万不要发自己孩子的露点照片, 为了下一代,  千万要拒绝儿童色情!

公司搞讨论, 让思考我们的工资是谁发的？老板的意思是让大家说 "工资是业务员发的", 也不是不对, 只不过凡事需要有个限度, 真理和荒唐也只差一小步. 

    首先，毫无疑问，我们的工资是各个条钱的业务同仁发的。他们用深情的目光注视着客户，用美妙地话语使他不自觉地松开口袋，最后再温柔地把客户的手捧起，在令人信任的微笑里，把客户手心里的钞票温柔地接过。有时这样的事情一次成功不了，还要来两遍三遍，太伤自尊了！
    没有他们，这钱还在客户的钱包里呢。
   
    第二，我们的工资是契约核保部发的。他们生来就毫无幽默感，天天朝九晚五地（有时候还加班到12点多，真是搞不懂），只为一个目的，那就是相方设法鸡蛋里挑骨头——客户如实告知了自己的健康情况了没有? 保险协议是不是有让公司损失的陷井？最后搞得身心疲惫，从经理到员工一个个心理阴暗，下意识里认定每个客户都是骗子。
    不过没有他们，业务同仁们好不容易找来的钱铁定会全部赔光，回到客户钱包里去，而留我们都喝西北风。
   
    第三，我们的工资是客户服务的同仁发的。他们有两大职责：在电话里被客户骂，以及当面被客户骂。据说他们在招聘时，会试着打新人几个耳光，如果他左脸挨完了，又把右脸递过来，那就通过了测试，读读历史，这种测试只有客户部的同事们和基督本人能通过。
    他们挨完了骂，就可以有空做做服务；有空做服务，客户就会满意一些，然后就不退保，还按期把钱继续交来。不然我们就没钱发了。
   
    第四，我们的工资是计财部发的。如果你偷偷站到计财部经理的背后听一会儿，就会听到他在喃喃自语：又花多了，又花多了……  他们就是一帮守财奴，把公家的钱当自己的钱似的扣门儿。每天只有两件事：数钱，和不花钱。
    不过说实话，如果不是他们天天算得那么精，这点家底等不到变成工资时就糟蹋没啦！
   
    第五，我们的工资是理赔发的。说来叫人惊讶——整个公司里，只有这么一点点人是在真正实现公司产品的价值。如果没有理赔，我们的产品就没有意义，客户就不会来买我们的产品。没有理赔，我们就只能分行李回高老庄了。
   
    第六，我们的工资是信息技术部发的。这是全公司最古板无聊的部门，不管和他们说什么，他们的只会给出两种固定的回答：是，不是，就象是1和0。不光如此，他们还总是要求别人用同样的方式交流，不管怎么说，没法商量的人真是让人无法忍受。
    但是话又说回来，有人说公司的金库其实在IT机房的硬盘上，IT部就是守金库的人，多亏了他们，业务才能跑起来，大家晚上才能睡得着觉。
   
    第七，我们的工资是总经理室发的。总经理的主要用途也是两个：开会时臭骂大家，和有大事时踏皮球给他。但是如果没有总经理臭骂着给大家指出前进方向，那我们就全乱套了。当然，最最重要的一点，发不发钱最后关头还要看他。他要决定不给发，公司挣再多的钱，大家也只能干看流口水。
   
    我们工资还是合规部发的。要不是他们天天吓唬我们，这群天不怕地不怕的人还不早炸了营胡干一场？要是有朝一日政府生气了，肯定落得个镜花水月一场空。我们的工资还是人力资源部发的，虽然几年也不给涨一下，但毕竟待遇还是他们定！我们的工资还是办公室发的，没有他们我们就只能站着办公，还要被狗仔报骂得狗血喷头，股票狂跌……
   
    最后，我们的工资是大家一起挣的，一个锣丝一个钉，少了谁，只怕都不行。
   

    给公司的业务部门的人扫盲写的。
   
    --------------------------------------------------------------------------------
    
     
    你必须了解的信息技术之二
    计算机与软件工程
     
    怎样把世界压平？――序
     
    如今有一本书炒作得非常火热，就是《世界是平的》这本书，从第一册《凌志车与橄榄树》到第二册《二十一世纪简史》都卖得十分叫座叫好，只是有一点需要提醒读者，此书的作者是经济全球化的内行，书中对IT技术对社会文化、经济形态的催化剂作用进行了广泛的论述，却忽略了对IT技术本身在发挥 “催化作用”的过程中的一些问题。
     
    因此，对于大多数没有非计算机行业的人们来说，这本书所描述的世界的扁平化过程似乎显得太容易了一些，好像一夜之间，一切经济、文化和政治问题都随着信息技术的触手伸及而得到了解决。人们没有意识到，把世界“压平”的过程，也是需要大量投入过程，而这个投入的规模，无论是财富的投入还是智力的，都远远比大多数人所能想象的要大得多。
     
    另一方面，我们在面对需求时，常常发现双方对于同一件工作的难易程度认同戏剧性地相反——一些对计算机说来易如反牚的任务，需求方常常会认为困难得不好意思向我们张口，而另一些真得无法用计算处理的事情，大家反而会认为这个需求理所当然地容易实现。这都是人们对IT工作的一些内在规律的不了解造成了认知鸿沟。
     
    作为《你必须了解的信息技术》系列文章的第二篇，我将面向非IT专业的人士，对IT项目开发中的一些内在规律进行轻松简介。
     
    霍尔*定理－－计算机的原理
     
    霍尔定理第一条：计算机什么也做不了。
     
    岂今为止，你从好莱坞电影上学到的计算机知识都是错误的。
     
    我真得希望现实中的计算机都如同电影中的那样强大。在影视作品中，对计算机的表现大概有两类：第一，完全的人工智能。第二，超强完美的应用系统和集成能力。我们先来讨论第一类。
    计算机的人工智能设想最早可能来自于A·C·克拉克的《2001年太空史诗》这部作品。这部写于1968年的小说中设想了一个具有超级计算能力、绝不出错的计算机“HAL9000”,这台计算机与后来发展起来的计算机的基本原理完全不同，它的运行基于高层次的逻辑演绎和完全的人工智能。HAL 9000能够与人进行无障碍的交流，并可以自主决定如何执行任务。它有着人们对计算机所期望的一切优秀品质：正直，诚实，聪明，客观，逻辑和永不厌烦，绝不出错，能正确回答你的任何问题。
    我多么希望拥有这样的一台电脑，那怕是做为宠物也好。但是现实与克拉克的期望相距太远。直到现在，也就是书中描写的场景发生之后的六年后，现实中的计算机还只是在硬件的运行速度上有了——呃……很大的——提高，而在计算机的灵魂——软件方面，则没有什么质的飞跃。
     
    我们目前所使用的计算机（没错，就是你眼前的这台，美国国防部的秘密实验室里正在研制的那些不在本文的讨论范围之内），都基于同一个祖先——图灵的通用机模型。当年大数学家图灵为了他的一篇数学论文的需要，而顺便提出了一种通用计算机的模型：一个无限长、且分为很多格子的纸带，用来记录指令和数据，加上一个每次移动一格，并能擦或写一个数字的铅笔头，就组成了一个通用的计算机。通过指令和数据来指挥铅笔头前后移动和在纸上读写信息，这样，通过最基本的指令的无穷组合，就达到了任意多的计算目的。
     
    到现在为止，这种方式还是没有大的变化，另一位数学家“冯·诺伊曼”在图灵机的基础上设计现代计算机的通用体系：“冯·诺伊曼”，把计算机系统分为软件与硬件，软件包括基本的指令与所需的数据，硬件电路根据指令一步步地进行运行。
     
    我们以一个例子说明。我需要计算机帮助我解决下列的数学难题：我有一个苹果，小明又送给我了两个苹果，我一共有几个苹果？
     
    用比较贴近机器底层的汇编的程序来完成任务，你需要告诉计算机如下进行：
    1.       将被加数“1”放到某个寄存器（或变量）。
    2.       将加数“2”放到另一个辅助寄存器（或变量）。
    3.       将两个数据执行“加”操作。结果放入原来的加法寄存器（或结果变量）。
    4.       拼接出 “你会有？个苹果”的答案字符串。问号要用加法寄存器里的数字代替。
    5.       在屏幕上或是其他输出设备上输出这个答案。
     
    只是一个简单的运算，计算机却需要你去告诉它每一个最详细的步子，否则它就会愣在那里，像一堆废铁（其实连铁也不是，计算机的核心部件是硅，和沙子和石头的成份类似）。
       
    把上述运行方法用计算机代码组织起来，就是编程了。用1969年发明的C语言，这个任务要下面的程序完成。
    ……
    Int A;
    A = 1 + 2;
    Printf(“你有 %ld 个苹果“，A);
    ……
    在1974年生产的英特尔的8080计算机上来执行这个运算，如果删除最后的输出（因为慢吞吞的输出设备会影响CPU的效率），这段程序每秒种大约可以执行几万遍。
     
    而用最新的C#开发语言来编写这个任务，所需要的程序为：
    ……
    Int A;
    A = 1 + 2;
    System.Console.Writeline(“你有{0}个苹果”, A)
    ……
     
    在我用来写这篇文章的PC上，上面的程序每秒种能执行307,694,276遍，速度已经提高了几万倍，但程序员为了完成这个操作而编写的程序却一直变化不大，仍然是对基本算法的详细描述。我们还是没有办法直接对计算机说：“霍尔，请告诉我，我有一个苹果，小明送给我了两个苹果，我会有几个苹果？”而计算机更不会从容地回答：“SIR，我已经验算了10亿次，所有结果都表明你将会有3个苹果。”
     
    一口伦敦腔，倍有面子。
     
    不知道你注意到了没有，我提出的问题是关于苹果的，而上述程序中计算的是纯数字，只是机械地在最后拼接上一个“苹果”字样而已。没错，计算机不知道苹果是什么东西，它所理解的只是数字，而后最拼接上的“苹果”字样对它来说，也并非是那种香甜可口，大大的、圆圆的、红红的有很多水份的一种蔷薇科植物的果实，只是两个毫无意义的UNICODE字符。
     
    从关于苹果的应用问题，到转化为计算机能够解决的纯数学运算过程，是用计算机解决现实问题的过程中所不可缺少的步骤，我们称之为“需求分析”。这个步骤目前为止只有人类能够胜任，对于如同计算苹果这样简单的问题，可能你我在不知不觉已经做完了需求分析，将之泛化为1＋2的纯数学问题，但是对于复杂得多的商业领域的需求，如流程规则、业务模式、数据分析等，要完整严格地用逻辑语言和数学表达式来描述，则需要很多受过专门训练的人，花费大量的时间才能够完成。
     
    通过对计算机内在运行方式的简单介绍，我想大家都会开始理解计算机是什么样的东西。是的，它本质还是一台机器，毫无智能可言。它从不理解它正在做的事情，只能按照事先设计好的方式运行，它只支持最简单的基本功能，比如把一个数据加上另一个数据，比较一个数是不是负数，以及根据比较的结果跳到另一条指令上等。所有的工作都要用这些基本功能来组合。你看到的每一个功能，都是程序员们一点点在键盘上敲出来的。
    在运行中，每一个细节都需要程序员考虑到，只要出现一点程序员意料之外的情况，它就立即歇菜，甚至连歇菜的方式也是由程序员决定的——或是停在那里等人过来，或是以每秒几亿次的速度把这个错误重复到关机为止。
     
    因此，霍尔第二定理就很容易理解了：“计算机是万能的，因为它什么也不能自己做。”
     
    计算机的优势在于速度和精确，它可以毫无怨言地进行重复性的工作到世界未日，或是从海量的数据库中迅速找到某合条件的信息，但是它不会主动思考，在可预见的将来中都无法真的理解人类。
     
    当然，也很容易地引推出其推论：“计算机从不犯错，所有的错误都是人犯的。”
     
    因为计算机的上述工作原理，所以IT的才成了“挨踢的”。
    我们是如何“挨踢的”――摸索中的软件工程
    这不是在搬砖头――两难的开发管理
    上世纪80到90年代时，IT业出现了“软件危机”，其成因往白了说就是为计算机编写程序太难导致。计算机程序要事无巨细都要人落实到一行行白纸黑字上去，但是人们对计算机的期望又越来越高，需要越来越复杂的应用系统。巨量的开发任务从“编程工作”变成了“项目工程”。
     
    人们自从有了计算机以来，还没有遇见过这样的事情，没有多少人有软件工程的管理经验。一开始大家试着用一般的项目管理方法来处理软件项目的工作，但是立即就发现成了一团乱七八糟——工程拖延，预期超支，需求不符，质量粗劣，项目失败。说来你可能不相信，直到现在，软件项目的失败率还在80%以上（当然，有些项目明明失败了，还非得说是成功了）！
     
    这和请一帮人来帮忙搬砖头可大不一样。请人搬砖头，只需要计算一下每个人的搬运速度，总量除以速度就是完工时间，如果最后发现来不及搬完，大可以多找一些人来搬，效率就可以提高。但是在软件项目中，如果一个项目如果即将延期时，增加程序员人手只会让项目更加延期，
     
    原因是什么呢？一个大型的软件系统，其中包括的程序代码往往有百万甚至上千万行，每一行都需要专业的程序员用脑子想出来，用手敲进去！而且更要命的是，这些代码基本上每段都不一样，每行都不是简单重复性劳动，都是智力劳动的结果。特别还要注意到，这些开发人员的工作内容之间都是联系的。搬砖头时工人之间的合作关系可能只限于在路上不要互相撞在一起，但是程序员之间却需要密切讨论设计方案，定义数据模型和接口规格，共享代码和数据，互相依赖对方的工作进度，其合作关系广泛而深入。同时，由于计算机程序的细粒度特征，程序员也需要花费大量的时间来学习其他程序员的工作成果。因此，在后期增加新的人手，只会导致沟通成本增加，进而让项目陷入更大的混乱之中。
     
    我以前常常对计划项目开发的工作进度计算过于乐观，但是有那么多的细节需要处理，时间往往不够用，直到最后，我终于认识到，项目规模与工期成本并非是线性增长的关系，而实际上，是指数关系，换句话说，当项目规模增长时，成本就按指数比例上升。
     
    其实这很容易理解：软件开发项目中的成本就是时间成本，而时间包括两个部分：编码、测试等“硬活”需要的时间，和为了搞清楚这一切，团队之间——甚至是自己和自己之间，如花功夫弄明白自己在早一段时间写的代码的意思等——的沟通成本。当项目规模越来越大时，沟通的成本就开始占了越来越大的比重。想象你去参加一个宴会，与会的每个人都要和另一个人握手，握手的次数和人数之间的关系就是指数关系，如果人数太多，你就根本没有功夫吃饭了。
     
    总而言之，软件工程是对开发人员智力、知识与创造力的组织和管理，与以往的重复性劳动为主的项目管理全然不同。虽然近年来“组件化”思想的发展使软件系统的复杂度有所降低，但是不可能完全解决问题。
     
    你明白了吗? ――需求定义中的无奈
    另一个软件项目中的巨大难点就是需求分析。IT业的最终使命是为其他行业服务，为其他专业领域提供应用支持。但是俗话说得好：隔行如隔山。于是在软件项目的需求分析阶段，常常是鸡同鸭讲，客户说得是东，分析人员听得是西，销售代表吹出来的是狗，技术部门做出来的是鸡，项目结果常常是似是而非，到最后客户对结果不满意，而与开发商之间互相指责，各执一辞争执不下之事毫不少见。
     
    最理想的解决方案，是能有一座桥梁能跨于专业领域和IT领域之间。但是一个专业领域可能需要一个人一生的精力去学习实践才能精通，而精通专业而同时又深刻领悟IT的人真是少之又少，这样的“行业解决方案专家”大都身价极高，工作报酬以小时计算、以美金支付得也不少见，寻常公司极难有这种资源，即使是大公司，住住也只是供养几个充充门脸而已。
     
    既然专家难求，外包开发公司一般都会采用一些标准工作方法来采集需求，需求分析人员也往往来不及完全理解需求的业务含义，只是用数据建模的方法把客户提供的信息分门别类，比如说，下面的场景在需求分析的工作讨论中常常发生：
     
    需求方：“我们希望可以分析客户的潜在价值。你明白了吗？我说是潜在价值… …”
    分析人员：“嗯，没问题，那么如何定义‘潜在价值’?”
    需求方（一惊）：“这个，我想，那应该是一个整数表示的值。”
    分析人员（耸耸肩，详细记录在案）。
     
    你可能在心中想象的是根据以往销售记录而对客户进行评分，以及华丽的图表什么的，但是，做为非IT专业的人士的你，往往不知道如何（也不习惯于）精确地表达你的想法，而分析人员并不洞析你的内心独白，他已经将之纯粹化为一个需要记录于数据库中的整数字段，而关于这个整数表示什么，他才来不及搞搞明白呢。
     
    当然，软件开发外包商确实在真诚地希望达到客户要求，但是，你看，实在太难了！大家都不容易。
     
    你怎么不早说！ ——变更的代价
    在上世纪的软件危机中，提出过一个影响很广的“瀑布式”开发过程的标准，这个标准是现在大部分传统过程控制论的原型，其特点是将软件开发的过程定义为以下几个阶段：
    l         需求分析
    l         设计
    l         实施
    l         测试（确认）
    l         集成和维护
    这五个阶段每一个都要完成之后，才能进行到下一个阶段。例如只有需求分析全部完成后，项目才能进入设计阶段。
    但是，经过多年的实践，人们发现这是一种太过于理想化的标准，客户简直不可能在需求分析阶段完成之后再不进行需求变更。甚至大多数客户连自己想要什么都说不清楚。对于客户来说，一般都缺少如同程序员那样细致入微地考虑每一个细节的习惯和能力（并非是在这里责怪谁，要知道程序员拥有这种能力其实是被逼出来的），很多需求的细节甚至是随着应用程序的开发过程中而一步步随“灵感的火花”蹦出来的。
     
    因为这些原因，后来的开发过程已经不再绝对反对需求的变更，但是客户仍然需要认识到的是，对已经完成的阶段成果进行变更是需要代价的，而且此代价随着变更需要回溯的阶段越多，而以指数式暴涨。
     
    因此，需求的变更是各种变更中成本最高，最难以项目承受的。因需求变更发生时所处于项目阶段不同，变更代价小到导致设计和代码的修改，大到调整系统的基础模型，甚至导致返工重做，项目延期以致于失败。更深层次的，在项目后期进行需求变更对项目团队所带来的挫折感和信心打击，是难以用金钱度量的。
     
    因此，当一个不负责任的客户在项目的后期提出一项需求变更时，项目经理的反应常常是大吼一声：“你怎么不早说！”
     
    出于项目组的共同利益考虑，客户应该对需求质量负责，尽可能地在分析阶段里完善需求定义，提醒做为客户的你，在需求阶段应该注意以下几条：
    l         全职参与项目的业务专家。由于IT项目中信息沟通的重要性，非全职的项目人员会极大地增加风险，特别是在需求定义这样重要的工作上。
    l         与需求分析人员面对面地沟通，确信他已经真正了解了你的意思。有时会很费力气，但是请再坚持一下，做IT的人智商数应该都会在80分以上。
    l         对可能存在的潜在需求也一起提出，主要是对系统未来在扩展、集成方面的可能需要，这些潜在需求虽然不做为正式定义，但可做为需求定义的备忘录供设计人员参考。大部分程序员都是完美主义者，他们会以能够满足你的未来需求而骄傲的。
     
    大失所望——系统的生命周期

    不管你信不信，新开发的系统总是不如旧的好用。
     
    前一段时间有人问我，“XX系统什么时间上线？现在的这个系统都烦死了。”他是位操作员。
    还有人这么说：“听说新的系统能够解决咱们所有的问题，是吗？”他是个业务人员。
    我听了之后大为惊讶，说实话，他们并不知道，那个正在开发中的新系统，根本没有考虑过他们的需求。如果真得上线了，他们连手头都没法干了，只能先干瞪眼等系统慢慢完善起来。
    一个新的信息系统，在刚刚上线时都是磕磕绊绊的，这个也没考虑到，那个也没顾及到，如果需求分析有问题，那这时根本就没法用，项目失败。如果需求分析没有问题，实现得也没问题，这时就会有很多的细节问题还没有处理，界面好不好用啦、必要的报表有没有做啦、使用中不时出现错误啦等等等等。
     
    程序员们开发系统的时候，面对的情况是很少的，他们常常会用一些理想化的案例和数据进行调试，然后一切正常。但是在客户的真实生产环境中使用时，各种各样意想不到的情况一下子会让系统难以应付，出现无法预料的错误，或是没有料到的性能压力等。这些问题是因为测试环境难以穷尽所有可能情况而造成的，因此，软件运行时的维护阶段是非常重要的，只有通过生产运行，隐藏在系统中的程序错误才能逐个被发现，并修正程序，增加错误预防、纠正等处理机制，系统的健壮性在运行中一点点得到增强。
    因此，新开发的系统上线时，客户的反应基本上都会是大失所望。客观地说，这种情况是正常的，客户应该正确评价新系统的质量，并有信心随着系统的运行维护而渐渐好起来。
     
    顺便提及，客户对新系统的下意识恐惧也很常见。曾见过一个项目，在需求分析时把未来程序界面设计出来请客户看，客户立即认为不如自己原来的做法方便——实际上他们原来是纯用手工处理的！
     
    所以说，好的软件系统是需要时间来打磨出来的，这与硬件设备的折旧正好相反：只需要几年的时间，高档的设备就会变成没法升级、维护和修理的古董。而软件系统的持续维护、不断完善则需要长期且昂贵的投入，而这种投入，是有积累性的，越是历久，就越是宝贵。
     
    但并不是说信息系统永不过时，一般来说，信息系统的生命周期是一个“浴盆曲线”：一开始技术问题多多，经过一段时间的运行维护，大部分问题得到解决，问题出现的概率降低，开始进入欢乐的稳定期，但等市场变化、新的业务模式变化、数据量压力等新需求出现时，而这些新的需求都是在系统原来的需求范围之外的，这就造成系统较大的变更和二次开发。修改一张已经画好的画，远不如在白纸上创作来得容易，因此新的补丁会让旧的系统破绽百出，问题又开始回升。如果控制得好，或是系统一开始时即已经充分考虑了可扩展性，那么就会渐渐回到下一个稳定期，否则就会恶性循环，左支右拙，最后整个系统陷入混乱，直到死亡。
     
     
    注：霍尔：即后文中的HAL9000.  不过 “霍尔定理” 是我杜撰的。