看着这头公牛，它的眼睛透露出愤怒的情绪，它的鼻孔释放出战斗的气息，它的牛角上流淌着鲜血，它的牛头也被染成血红。这个经典的形象浓缩了芝加哥公牛队的命运：他们注定要成为最强者，但代价是满身的鲜血———不仅要有对手的，还要有自己的。流血不够，则成功不至；流血足够，则登峰造极。

　　[鲜血] 曾经屡遭屠杀

　　芝加哥公牛因迈克尔·乔丹而伟大，几乎所有人一提起公牛队就会想到乔丹，可是，当童年的乔丹还在为无法战胜哥哥而苦恼时，公牛就已经在冲击总冠军了。只可惜当时的结果是残酷的，公牛屡屡被强大的对手屠宰。

　　其实，早在建队第一个赛季，公牛就创下一项纪录，他们成为NBA第一支闯进季后赛的新军。那年常规赛，在杰里·斯隆、盖·罗杰斯、鲍勃·布泽等人的率领下，公牛取胜33场，排名西区第四，实际上就是倒数第二。但因为当时NBA只有10支球队，只要不在本区垫底，就可以参加季后赛，所以公牛也成为季后赛当中的一员。当然，对一支刚刚成立的球队来说，这已经相当不容易，所以公牛主教练约翰尼·科尔还被评为那年的最佳教练。

　　前三次季后赛之旅，公牛都只是陪衬，一共只赢下两场球，没有任何晋级希望。到1970-71赛季，也就是建队第五年，以斯隆、鲍勃·拉夫、切特·沃克为首的公牛在常规赛突破50胜大关，以51胜31负的战绩高居全联盟第三。从那时开始，公牛真正具备了向冠军发起冲击的实力；但也从那时开始，公牛被湖人这个"屠夫"缠上。

　　1971年西部半决赛(实际上就是首轮)，公牛对阵杰里·韦斯特和威尔特·张伯伦领军的湖人。湖人队常规赛战绩比公牛差，但由于公牛与西部头号种子雄鹿同属中西区，而湖人是太平洋区第一，所以湖人成为西部二号种子；更重要的是，根据当时的规则，湖人享有对公牛的主场优势。正是这个主场优势，决定了那轮季后赛的胜负，双方均在主场取胜，而湖人凭借决胜第七战的主场优势将公牛淘汰。

　　1971-72赛季开始不久，公牛从皇家队换来富有激情的组织后卫诺姆·范莱尔，构建出一套完善的主力阵容。范莱尔和斯隆搭档，虽然攻击力一般，但防守堪称联盟顶尖，队友鲍勃·拉夫说："他们俩是最优秀的后场防守组合。如果说球像一片奶酪，那他们就是两只老鼠，只要球落地，你就得当心了。"而拉夫本人则和切特·沃克组成一对其他球队难以匹敌的前锋组，两人都能跑能跳，场均得分常年高居球队前两位，其中有三个赛季同时超过20。至于中锋汤姆·博尔文克尔和克利福德·雷，虽不那么起眼，却也是篮板和内线防守的保障。

　　从1972年到1975年，公牛队都是西部豪强，可是连续四个赛季，他们都与总决赛无缘，每当碰上湖人和雄鹿，公牛总成为失败的一方。对此，范莱尔的话一针见血："卡里姆·阿布杜尔-贾巴尔(雄鹿)和威尔特·张伯伦(湖人)是关键所在，他们总挡在我们面前。"

　　1975年西部决赛，公牛以3比4惜败给里克·巴里领军的勇士，失去了争冠的最后机会。1975-76赛季，切特·沃克退役，斯隆受伤，公牛战绩一落千丈，跌出季后赛。20世纪70年代后期，虽然公牛得到一个全明星级的中锋阿蒂斯·吉尔摩尔，但仍然频频被关在季后赛大门外。

　　[鲜血] 曾经难逃天敌

　　20世纪80年代，公牛被联盟划归中区，成为东部球队。1984年选秀是公牛历史上的重要转折点，因为他们在首轮第三位挑中了来自北卡罗莱纳大学的得分后卫乔丹，新一轮球队建设由此开始。

　　当然，乔丹并非一进NBA就成为联盟里的头号球星。中国人都明白："天将降大任于是人也，必先苦其心志，劳其筋骨，饿其体肤，空乏其身，行拂乱其所为，所以动心忍性，曾益其所不能。"在乔丹和公牛队的成长之路上，情况正是如此。整个80年代，虽然乔丹的个人表现一年比一年强，公牛的实力也越来越强大，但他们每年季后赛最终收获的都是失败。

　　职业生涯前三个赛季，乔丹只能把球队带进季后赛，不能取得靠前的排位，所以公牛总是在首轮碰上凯尔特人这样的顶级劲旅，即便乔丹大发神威，也往往难逃被横扫的结局。1986年4月20日，季后赛首轮第二场，乔丹率领公牛与凯尔特人大战两个加时，乔丹个人独得63分，创下NBA季后赛历史上单场得分最高纪录，伯德就是在那场比赛之后说出那句名言："我想那是上帝乔装成了迈克尔·乔丹。"然而，那场比赛，公牛还是输了；那一年，公牛还是被凯尔特人横扫出局。

　　1987年夏天，公牛队完成了两件大事，一是在选秀大会上选入斯科蒂·皮蓬和霍勒斯·格兰特，二是任命菲尔·杰克逊为助理教练。1987-88赛季，乔丹连续第二年坐上NBA得分王的宝座，但真正难能可贵的是，他已由一个超级得分手变成一个攻守全能的伟大球员---那年，乔丹包揽NBA年度最佳防守球员和年度MVP两大奖项，公牛也以50胜32负的战绩排到东部第三。

　　1988年季后赛，公牛在首轮以3比2战胜骑士，从此，他们有了第一个可以欺负的敌人。不过，也正是从1988年季后赛开始，公牛遇到了真正的天敌---底特律的"坏小子军团"。东部半决赛，活塞队祭出"乔丹规则"，加强对乔丹的防守，结果以4比1将公牛轻松淘汰。

　　其后两年，从东部半决赛到东部决赛，活塞总是挡在公牛面前的一道障碍。要命的是，这道障碍，公牛迟迟跨不过去。从1988年到1989年再到1990年，从4比1到4比2再到4比3，获胜的总是活塞，杀进总决赛的总是活塞，赢得两连冠的还是活塞。乔丹和公牛队并非没有进步，他们变得越来越强大，心智也越来越成熟，但活塞总是比他们更胜一筹。

　　1989年夏天，菲尔·杰克逊被"扶正"，取代道格·科林斯成为公牛队主教练。1989-90夏季，公牛已是NBA顶级劲旅，他们惟一没有做到的就是在东部决赛第七场掀翻活塞，但乔丹认为，到那时为止，公牛已经在精神上翻过了活塞这座大山，他们表现出了足够的心气。

　　六年，乔丹和公牛队被挡在总决赛之外已整整六年；三次，乔丹和公牛队被活塞淘汰已连续三次。没人能真正理解他们的痛苦，因为没人和他们一起每年流那么多血。

　　[鲜血] 终于成就霸业

　　血流够了，痛尝过了，公牛舔净身上的血渍，开始让每一个对手血债血偿，开始成为真正的强者。

　　其实转变从1989年5月7日就已开始。那是东部季后赛首轮第五场，公牛和骑士一战决生死。最后3秒，公牛还以一分落后，乔丹在对方克雷格·伊洛面前投中了著名的"TheShot"，完成了史上最伟大的绝杀之一。那球之后，乔丹彻底成为NBA最可怕的季后赛杀手，公牛的那种好斗的本性也在乔丹身上展现无遗。

　　到1990-91赛季，公牛已将全部焦点放在活塞身上，他们把对活塞的每一场比赛都当作一场战争，他们对底特律充满仇恨。常规赛，公牛取得61场胜利，高居东部第一，乔丹也赢得第二个年度MVP奖。东部决赛，公牛如愿与活塞重逢，"坏小子军团"的"乔丹规则"不再管用，公牛以4比0横扫活塞。1991年5月27日，东部决赛第四场最后4秒钟，公牛胜局已定，活塞队的王牌球员艾塞亚·托马斯和比尔·兰比尔等人一同起身，没有和公牛球员握手，径直走回更衣室，那是他们最后的挑衅。

　　公牛跨越活塞之后，再也没有谁能挡住乔丹前进的脚步。1991年总决赛，公牛在先输一场的情况下连赢四场，把"魔术师"约翰逊和80年代的王者湖人队送上断头台。经过七年的浴血奋战，乔丹和公牛队终于尝到了冠军的滋味。这一次，公牛不再流血，但乔丹流下了眼泪。

　　后来发生的事情，就是中国球迷耳熟能详的了。1992年和1993年，公牛队先后在总决赛击败开拓者和太阳，赢得总冠军，完成三连冠，"公牛第一王朝"建立。1993年10月，乔丹宣布退役，改行去打棒球，而公牛队在皮蓬的率领下保持了一流球队的实力，可惜在1994年东部半决赛被尼克斯淘汰。1995年乔丹复出，又率领球队在1996至1998年三夺总冠军，建立"公牛第二王朝"。1995-96赛季，公牛在常规赛取得72胜10负，创下NBA历史纪录，被誉为"史上第一强队"。1998年夺冠后，公牛的王朝霸业让无数人顶礼膜拜。

　　值得一提的是，虽然20世纪90年代是属于公牛的时代，但并不表示他们是轻轻松松完成霸业的。从1991年到1998年，NBA巨星辈出、强队林立，而公牛在季后赛(尤其是总决赛)遇到的对手，很多都是难啃的"硬骨头"。90年代的战斗，依然是鲜血淋漓的战斗，只不过公牛在大部分时间里---尤其是关键时刻---都取得了胜利。

　　鲜血，才是公牛王朝的基石。

　　序：大项目在本文的定义为企业信息建设中客户大名气高而且项目金额大，在我国，能签下大项目的单有一部分是靠草根阶层更专业化的服务和质量以及行业客户赢得的，但一般而言签下的这样的大项目对软件开发商而言都不可能是天平两端同样的法码，所以销售人员为了能签下这样的大单一般都不得不答应或是承诺一些超越公司目前实力和技术水平的需求，因为不这样根本就没有竞争的机会。这样的苦果程序员即使抱怨非常多，还是不得不照样加班加点去拼命实现。(想想国外的厂商做中国的市场真是爽，国内的客户无不乖乖地听他们的话)

　　目前国内的软件公司靠产品批发赚大钱的非常少，象金蝶和用友上也都有靠签大项目来发展，所以大项目的成败及效率就直接影响着公司运营成本和利润以及大家的薪金收入。因为一开始签定的就是不平等条约，所以项目经理的人选更是直接决定了项目的成败和收益。这样的项目经理有两种，一是为自己镀金的，那是非常光荣和开心的事，因为费用及人手配置都非常充足，第二种是很有责任心而且想做成功的项目经理，会做得非常辛苦，累得半死。如何让项目早些验收让领导放心，让下属开心和放松是项目经理时时刻刻都关注的事。

　　正文：结合自己的经验谈谈项目经理在主持项目实际运作时的二个要点三种避免和四个注意。希望对大家的实际工作会有所帮助！

　　两个要点

　　一、如何尽快地将项目验收回款，为公司和团队创造更多的利润，为下属带来更多的利益。
　　二、板回双方不平等中的劣势。

　　这是项目中非常关键的一个心理预期，因为早期签的合同让开发商处于劣势，客户从你进场开始自然而然地在气势上压着你，如果你长期处于心理上的劣势，项目失败的风险就非常高，因为大公司中的人员都有一种出了事情后他们会将你原本认为是他们的责任的推得干干净净，如果你纠缠下去和他们的关系就搞僵了，项目的后期工作会非常难进行，公司高层考虑的就是更换项目经理，因为这时的客户真的是上帝，老板都不敢得罪的人你得罪的后果大家都知道会怎样。笔者当初和他们打交道时就花了一个月多的时间让整个团队在专业上体现出来是行家和经验娴熟，因为客户是大公司的，技术资源很丰富，他们懂的面很广，也有知道得深的，所以要抓住机会和他们多交流特别是非工作时间，首先你要认可他，然后让他感觉他专业，再然后你在合适的机会某些方面要自然而且不露痕迹地表现出你知道得更深更专业，当然当初没少花我银子。劣势板回后，后期他们才会注重你说话的份量，才可以指出哪些需求是不合理的，哪些是微软都没有办法做到的。
　　　
　　三个避免

　　一、避免事情太多杂乱无章

　　大项目也意味着需求多，参与的人员也多，如何保证项目的进度，避免事情太多，需求点太多而导致最后项目失控，就是项目组加班加点做了大量的工作，最后却发现什么都没有做好，客户不认可，领导很焦虑，下属很失望，你很郁闷的局面。在项目进行过程中不可避免地会遇到很多提出的需求和修改意见，如何快速把握这些需求提出正确可行的解决方案是项目经理首先要考虑的事情。别忘了项目合同上都是有时间限制的，如何在时间段之内完成项目而且完成得好就是关键。一味地否认抵制客户的需求当然不行，全盘照收只会让项目越变越大，项目组的人每日每夜地加班。笔者的作法一般是记录成文字性的文档，然后根据实际情况提出哪些现在做，哪些暂时不做，哪些到二期或三期工作时再考虑，并请他们确认。这套方法笔者常用不衰，希望对各位项目经理在项目运营过程有实际的帮助。

　　二、避免太多个性化的需求

　　这是最头痛的事情，因为客户是大公司，会议没完没了，每个会议都要求得非常正规，而且客户看起来确实是很正规，相关的制度文档相关的人员以及部门级的经理都甚至高层的领导也会请到会议室来和你谈需求，每个经理都会有自己的部门的特点和需求，如何尊重他们的意见并保持自己的思路是非常重要的。笔者早期参加这样的会议时也一样很听客户的话，程序实现的过程中则是非常痛苦，经历过多次后，笔者建议各位项目经理要保证突出你们的专业知识和经验，不要被客户的职位所迷惑了，因为他们的经验很丰富，但在专业特别是软件方面你是专家，而且他们提出的是现实中各个部门的特点，并没有要求软件一定要实现。所以现场一定要记住，不要答应得太快，笔者后面就养成了一句口头禅，我们回去研究讨论后再确定。

　　三、避免人浮于事的现象

　　大公司都会有的现象，如何让你的项目组成员在项目进行过程中最大限度地减少这样的消耗是项目经理要关注的事。大公司踢皮球的现象大家都有所耳闻，所以做为项目经理的你能做就是如何做好事前的工作，避免出了问题后指责，到时你会发现没有人和这有关，都是你的错。所以少些抱怨，事前尽可能多做准备。笔者最常用的方法就是在需求说明书(实际工作中提出，非早期完整的需求说明书)中注明这是某某人提出的，以及我们的意见是什么，你别指望他会签字，一个需求点如果要等他确认签字你就等个两个星期吧。

　　四个注意

　　一、注意内部团结一致，互帮互助和高度的热情保证得项目快速往前推进。

    项目小姐的团结一致，这是基石，不论是在需求讨论分析，还是开发过程和项目内部测试，大家都团结一结，不断提出自己的看法一起交流，在最短时间内将问题细化和明确下来，大大缩短了开发周期。保持项目小组成员高度的热情使得项目讯速得到突破，达到了预期的要求，这是项目经理真正最重要的工作。在项目运作过程中，别忘记项目小组不是孤军奋战，背后还有整个公司的资源别忘了使用。

　　二、注意项目进度的严格控制

　　这是老生长谈的问题，核心还是《人月神话》，在现有的人手配置和资源上如何控制项目的进度，这是所有项目经理也是公司领导最关注的事情。因为大项目的进度要控制出了偏差，后期很多预想不到的事情会让你焦头烂额的。所以必要的会议还是要开，总结和安排工作是每周都必须要进行的工作，笔者当初是将工作总结工作安排和需求讨论严格分开的，即使是参加的人员一样。因为需求讨论需求分析有时是无底洞，有些实现起来是有难度的，这时在会议上一定要注意控制方向鼓励大家踊跃发言的同时要保证主题方向。因为需求的扩散和实现的难度将直接影响到项目的进度，很多项目最后失控追根结底相当一部分原因是需求没有把握住。笔者一同事负责的一个百万级的项目，超过签定合同时间的半年了还没有完成，公司后期调动了所有可调用的技术人员进入项目组，搞得人人疲惫，当初最大的原因就是客户的需求不断扩散导致程序开发无休止地进行。

　　三、注意搞好各方面的关系

　　项目经理首先要搞好的是你和你的领导的关系，特别是老板的关系，你要体会你的老板的心情，他是希望做成功大项目然后开始扩张，他的心里比你更关注项目的进展，要是出问题他心里比你更焦虑，所以记得要让你的老板参与到项目中来，别因为他不懂技术不懂项目管理就把他晾在一边。笔者的做法是每周都会将工作写成简单的总结发给上级领导，然后抄送给BOSS，有什么计划要执行或调整时预先做好书面材料发送给领导们，这时要忌讳的就是越级上报，所以这样的计划我一般是只发送我的直属上级，在MAIL中写到等计划正式拟定后请他转呈老总，大的事情一般是他都会在比你更期望的时间代你向老总汇报了，因为只有和老总搞好关系，他才会信任你，而且还会源源不断地支持你，不然一些公司接到一个大项目要失败了，公司搞不好就负债了，所以你要明白BOSS可能是将公司前途放在你身上。接下来就是要搞好下属的关系，他们是实现完成工作的核心和中流抵柱，平时要舍得花些银子请他们吃吃饭组织一些体育活动，程序员都是典型的亚健康状态，看看程序员那象怀胎三个月的肚子就知道了。再接着就是要搞好客户的关系了，除了言语上尊重他们外，必要的银子还是要花的，而且要花得有特色，因为他们聚餐也不少啊。所以大家明白我为何要将搞好和老总的关系放在第一位了吧，不然这些白花花的银子，老总不签字，项目再失败了，你赔了血本都不够啊，呵！

　　四、注意项目验收的各个环节

　　这是大家都关心特别是老总最关心的问题了，有时你别看他表面上非常平静，一点都没有开心的样子，我的老总那天在去洗手间的路上就哼起了小曲，这是好几年都没有的事情。但是要达成这样的任务并不是象小项目那样双方有意向后谈一天就可以签字，大公司都有自己一套套的验收标准，如果按照他们那样的标准，你卖硬件都难，更不用说软件了，而且谁在这上面签了字以后出了问题谁就要负责，而且软件永远都没有100%没有问题的，你看微软还不是不断升级和发补丁包。如何采用让双方都能接受的方式签定验收合同就要求你平时就要做好准备，笔者一般是每个月都会有一个功能模块实现的清单请他们确认，要他们签字是不可能，笔者的做法是请他们指出哪些没有完成的或有意见的，这样日积月累下来，对方认可了你的工作，后面他个人这一关是可以通过了，后面一定是他的上级以及副总层层把关，记住这时谈的一定要是实现完成了哪些功能，对新需求的千万不能答应就改，可以放到后期，并在验收合同中注明哪些是新需求还没有完成的，层层把关让折磨你的性情考验你的耐性，两周之内要能签下字就算是顺利了。还有一点有过大项目经验的仁兄有没有注意到，项目验收签字的都是客户的最高层和最低层两三个人的名字一起签在上面，中间管理层做了许多幕后工作，所以在验收的过程中不要忘记向客户的每个上级多表扬一下项目中参与的他下属人员的业绩，当他们都是功臣时在最后一关卡住的机会会少很多。因为最后一关没有通过，所有的一切努力都是白搭！希望此篇文章对广大同行能有实际的帮助，祝各位同仁都能在项目验收的庆功宴上多喝两杯。

　　在初始级，企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。

　　第二级：可重复级

　　在这一级，建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于过往的项目的经验来计划与管理新的项目。

　　第三级：定义级

　　在这一级，有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时，这些过程是集成到一个协调的整体。这就称为企业的标准软件过程。

　　第四级：定量管理级

　　在这一级，企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案， 要对所有项目的重要的过程活动进行生产率和质量的度量。软件 产品因此具有可预期的高质量。

　　第五级：（不断）优化级

　　在这个等级，整个企业将会把重点放在对过程进行不断的优化。企业会采取主动去找出过程的弱点与长处，以达到预防缺陷 的目标。同时，分析有关过程的有效性的资料，作出对新技术的 成本与收益的分析，以及提出对过程进行修改的建议。

CMM第一级：初始级

◆ 特征
(1)软件过程的特点是杂乱无章，有时甚至混乱，几乎没有定义过程的规则或步骤。

(2)过分的承诺，常作出良好的承诺：如“按照软件工程方式，有序的工程来工作”；或达到高目标的许诺。但实际上却出现一系列问题。

(3)遇到危机就放弃原计划过程，反复编码和测试。

(4)成功完全依赖个人努力和杰出的专业人才，取决于超常的管理人员和杰出有效的软件开发开发人员。具体的表现和成果都源 于或者说是决定于个人的能力和他们先前的经验、知识以及他们的进取心和积极程度。

(5)能力只是个人的特性，而不是开发组织的特性。依靠着个人的品质或承受着巨大的压力；或找窍门取得成果。但此类人一旦离去，对组织的稳定作用也消失。

(6)软件过程是不可确定的和不可预见的。软件成熟性程度处于第一级软件组织的软件过程在实际的工作过程中被经常的改变（过程是随意的）。这类组织也在开发产品，但其成果是不稳定的，不可预见的，不可重复的。也就是说，软件的计划、预算、功能和产品的质量都是不可确定和不可预见的。

◆ 过程
(1)极少存在或使用稳定的过程

(2)所谓“过程”，往往是“就这么干”而言。

(3)各种条例，规章制度互不协调，甚至互相矛盾。

◆ 人员
(1)依赖个人努力和杰出人物。一旦优秀人物离去，项目就无法继续。
(2)人们的工作方式如同“救火”，就是在开发过程中不断地出现危机，以及不断的“救火”。

◆ 技术
引进新技术是极大风险。

◆ 度量
不收集数据或分析数据。

◆ 改进方向
(1)建立项目管理过程，实施规范化管理，保障项目的承诺。

(2)首要任务是进行需求管理，建立客户与软件项目之间的共同理解，使项目真正反映客户的要求。

(3)建立各种软件项目计划、如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划。

(4)开展软件质量保证活动（SQA）。

CMM第二级：可重复级

◆ 特征
(1)进行较为现实的承诺，可按以前在同类项目上的成功经验建立的必要过程准则来确保再一次的成功。

(2)主要是逐个项目地建立基本过程管理条例来加强过程能力。

(3)建立了基本的项目管理过程来跟踪成本、进度和功能。

(4)管理工作主要跟踪软件经费支出、进度及功能。识别在承诺方面出现的问题。

(5)采用基线（BASELINE）来标志进展、控制完整性。

(6)定义了软件项目的标准，并相信它，遵循它。

(7)通过子合同建立有效的供求关系。

◆ 过程
(1)软件开发和维护的过程是相对稳定的，但过程建立在项目一级。

(2)有规则的软件过程是在一个有效的工程管理系统的控制之下，先前的成功经验可以被重复。

(3)问题出现时，有能力识别及纠正。承诺是可实现的。

◆ 人员
(1)项目的成功依赖于个人的能力以及管理层的支持。

(2)理解管理的必要性及对管理的承诺。

(3)注意人员的培训问题。

◆ 技术
建立技术支持活动，并有稳定的计划。

◆ 度量
每个项目建立资源计划。主要是关心成本、产品和进度。有相应的管理数据。

◆ 改进方向
(1)不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织的标准软件过程。把改进组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任。

(2)确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中。从而可以跨项目改进软件过程效果，也可作为软件过程剪裁的基础。

(3)建立软件工程过程小组（SEPG）长期承担评估与调整软件过程的任务，以适应未来软件项目的要求。

(4)积累数据，建立组织的软件过程库及软件过程相关的文档库。

(5)加强培训。

CMM第三级：确定级

◆ 特征
(1)无论管理方面或工程方面的软件过程都已文件化、标准化，并综合成软件开发组织的标准软件过程。

(2)软件过程标准被应用到所有的工程中，用于编制和维护软件。有的项目也可根据实际情况，对软件开发组织的标准软件过程进行剪裁。

(3)在从事一项工程时，产品的生产过程、花费、计划以及功能都是可以控制的，从而软件质量也可以控制。

(4)软件工程过程组（SEPG）负责软件活动。

(5)在全组织范围内安排培训计划。

◆ 过程
(1)整个组织全面采用综合性的管理及工程过程来管理。软件工程和管理活动是稳定的和可重复的，具有连续性的。

(2)软件过程起了预见及防范问题的作用，能使风险的影响最小化。

◆ 人员
(1)以项目组的方式进行工作。如同综合产品团队。

(2)在整个组织内部的所有人对于所定义的软件过程的活动、任务有深入了解，大大加强了过程能力。

(3)有计划地按人员的角色进行培训。

◆ 技术
在定性基础上建立新的评估技术。

◆ 度量
(1)在全过程中收集使用数据。

(2)在全项目中系统性地共享数据。

◆ 改进方向
(1)开始着手软件过程的定量分析，以达到定量地控制软件项目过程的效果。

(2)通过软件的质量管理达到软件的质量目标。

CMM第四级：管理级

◆ 特征
(1)制定了软件过程和产品质量的详细而具体的度量标准，软件过程和产品质量都可以被理解和控制。

(2)软件组织的能力是可预见的，原因是软件过程是被明确的度量标准所度量和操作。不言而喻，软件产品的质量就可以预见和得以控制。

(3)组织的度量工程保证所有项目对生产率和质量进行度量、并作为重要的软件过程活动。

(4)具有良好定义及一致的度量标准来指导软件过程，并作为评价软件过程及产品的定量基础。

(5)在开发组织内已建立软件过程数据库，保存收集到的数据，可用于各项目的软件过程。

◆ 过程
(1)开始定量地认识软件过程。

(2)软件过程的变化小，一般在可接受的范围内。

(3)可以预见软件过程中和产品质量方面的一些趋势。一旦质量经度量后超出这些标准或是有所违反，可以采用一些方法去改正，以达到良好的目标。

◆ 人员
每个项目中存在强烈的群体工作意识。因为每人都了解个人的作用与组织的关系，因此能够产生这种群体意识。

◆ 技术
不断的在定量基础上评估新技术。

◆ 度量
(1)在全组织内进行数据收集与确定。

(2)度量标准化。

(3)数据用于定量地理解软件过程及稳定软件过程。

◆ 改进方向
(1)缺陷防范，不仅仅在发现了问题时能及时改进，而且应采取特定行动防止将来出现这类缺陷。

(2)主动进行技术变动管理、标识、选择和评价新技术，使有效的新技术能在开发组织中施行。

(3)进行过程变动管理，定义过程改进的目的，经常不断地进行过程改进。

CMM第五级：优化级

◆ 特征
(1)整个组织特别关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生，不断地提高他们的过程处理能力。

(2)加强定量分析，通过来自过程的质量反馈和吸收新观念，新科技，使软件过程能不断地得到改进。

(3)根据软件过程的效果，进行成本/利润分析，从成功的软件过程中吸取经验，加以总结。把最好的创新成绩迅速向全组织转移， 对失败的案例，由软件过程小组进行分析以找出原因。

(4)组织能找出过程的不足并预先改进，把失败的教训告知全体组 织以防止重复以前的错误。

(5)对软件过程的评价和对标准软件过程的改进，都在全组织内推 广。

◆ 过程
(1)不断地系统地改进软件过程。

(2)理解并消除产生问题的公共根源，在任何一个系统中都可找到：由于随机变化造成重复工作、进而导致时间浪费。为了防止浪 费人力可能导致的系统变化。要消除“公共”的无效率根源，防止浪费发生。尽管所有级别都存在这些问题，但这是第五级的焦点。

◆ 人员
(1)整个组织都存在自觉的强烈的团队意识。

(2)每个人都致力过程改进，人们不再以达到里程碑的成就而满足， 而要力求减少错误率。

◆ 技术
基于定量的控制和管理，事先主动考虑新技术、追求新技术。可以实现软件开发中的方法和新技术的革新、以防止出现错误，不断提 高产品的质量和生产率。

◆ 度量
利用数据来评估，选择过程改进。

◆ 改进方向
保持持续不断的软件过程改进。

CMM总结：五层结构图

我们看到，在第五级上，技术和过程的改进像普通商业活动一样有计划、有管理地进行。由于组织不断的致力于改进过程的能力，所以软件开发组织的能力可持续改进。这种改进不仅表现在对存在的软件过程逐步改进，不表现在采用新技术和新方法方面的革新。

画一个图吧：（CMM的五层结构图）
          -----------------
         /   优 化 级     /
        /      (5)       /
        -----------------
               ↑
               | 不断改进的过程
               |
          -----------------
         / 可 管 理 级    /
        /      (4)       /
        -----------------
               ↑
               | 能预见的过程
               |
          -----------------
         /   确 定 级     /
        /      (3)       /
        -----------------
               ↑
               | 标准一致的过程
               |
          -----------------
         /  可 重 复 级   /
        /      (2)       /
        -----------------
               ↑
               | 有纪律的过程
               |
          -----------------
         /  初 始 级      /
        /     (1)        /
        -----------------

　　第一只狐狸跳了几下摘不到，从附近找来一个梯子，爬上去满载而归。

　　第二只狐狸跳了多次仍吃不到，找遍四周，没有任何工具可以利用，笑了笑说：“这里的葡萄一定特别酸！”于是，心安理得地走了。

　　第三只狐狸高喊着“下定决心，不怕万难，吃不到葡萄死不瞑目 ”的口号，一次又一次跳个没完，最后累死在葡萄架下。

　　第四只葡萄因为吃不到葡萄整天闷闷不乐，抑郁成疾，不治而亡。

　　第五只狐狸想：“连个葡萄都吃不到，活着还有什么意义呀！”于是找个树藤上吊了。

　　第六只狐狸吃不到葡萄便破口大骂，被路人一棒子了却性命。

　　第七只狐狸抱着“我得不到的东西也决不让别人得到”的阴暗心理，一把火把葡萄园烧了，遭到其他狐狸的共同围剿。

　　第八只狐狸想从第一只狐狸那里偷、骗、抢些葡萄，也受到了严厉惩罚。

　　第九只狐狸因为吃不到葡萄气极发疯，蓬头垢面，口中念念有词：“吃葡萄不吐葡萄皮……”

　　另有几只狐狸来到一个更高的葡萄架下，经过友好协商，利用叠罗汉的方法，成果共享，皆大欢喜。
　　（最后几只狐狸分葡萄的时候出问题了，每只狐狸都认为自己贡献最大，所以应该分最多的葡萄，结果拼了个你死我活。）

　　当时我看到这个文章。不是针对程序员的。不过我发现 这9个狐狸更能代表每一种程序员。甚至是一个团队。请大家对号入座。

　　同时更加欢迎大家 回复的时候扩充  更多的狐狸。

　　摘要：
　　本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的各种因素，列举了系统构架设计文档应考虑的一些问题。

　　关键字：
　　系统构架、设计、考虑、因素

　　正文：
　　约公元前25年，古罗马建筑师维特鲁威说：“理想的建筑师应该既是文学家又是数字家，他还应通晓历史，热衷于哲学研究，精通音乐，懂得医药知识，具有法学造诣，深谙天文学及天文计算。”（好难哪，软件构架设计师的要求呢？大家好好想想吧。）

　　本文目录
　　一、与构架有关的几个基本概念；
　　二、构架设计应考虑的因素概揽；
　　三、程序的运行时结构方面的考虑；
　　四、源代码的组织结构方面的考虑；
　　五、写系统构架设计文档应考虑的问题
　　六、结语

　　一、与构架有关的几个基本概念：
　　1、模块（module）：一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、内部信息、运行环境（与功能对应但不是一对一关系）。
　　2、组件（component）：系统中相当重要的、几乎是独立的可替换部分，它在明确定义的构架环境中实现确切的功能。
　　3、模式（pattern）：指经过验证，至少适用于一种实用环境（更多时候是好几种环境）的解决方案模板（用于结构和行为。在 UML 中：模式由参数化的协作来表示，但 UML 不直接对模式的其他方面（如使用结果列表、使用示例等，它们可由文本来表示）进行建模。存在各种范围和抽象程度的模式，例如，构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式（通过使用代理来替代实际的对象，使程序能够控制对该对象的访问）；对于交互系统，我们使用MVC（M模型(对象)／V视图(输出管理)／C控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可以针对需求的特点采用相应的模式来设计构架。
　　4、构架模式（architectural pattern）：表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。
　　5、层（layer）：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架的横向划分，分区是对构架的纵向划分）。
　　6、系统分层的几种常用方法：
　　　　1） 常用三层服务：用户层、业务逻辑层、数据层；
　　　　2） 多层结构的技术组成模型：表现层、中间层、数据层；
　　　　3） 网络系统常用三层结构：核心层、汇聚层和接入层；
　　　　4） RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层；
　　　　5） 基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层；
　　　　6） 某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层；
　　7、构架（Architecture，愿意为建筑学设计和建筑物建造的艺术与科学）: 在RUP中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互；《软件构架实践》中的定义：某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性及相互间的联系；IEEE 1471-2000中的定义：the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution，构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构件和接口组成。（“构架”可以作为名词，也可作为动词，作为动词的“构架”相当于“构架设计”）
　　8、构架的描述方式：“4＋1”视图（用例视图、设计视图、实现视图、过程视图、配置视图）是一个被广为使用的构架描述的模型；RUP过程的构架描述模板在“4＋1”视图的基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明）；HP公司的软件描述模板也是基于“4＋1”视图。
　　9、结构：软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架也表现为多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。

　　二、构架设计应考虑的因素概揽：
模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。
　　1、程序的运行时结构方面的考虑：
　　　　1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求；
　　　　2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）；
　　　　3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同；
　　　　4） 与其他系统接口兼容性；
　　　　5） 与网络、硬件接口兼容性及性能；
　　　　6） 系统安全性；
　　　　7） 系统可靠性；
　　　　8） 业务流程的可调整性；
　　　　9） 业务信息的可调整性
　　　　10） 使用方便性
　　　　11） 构架样式的一致性
　　注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。
　　2、源代码的组织结构方面的考虑：
　　　　1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响）、利于配置管理、大小的合理性与适度复杂性；
　　　　2） 可维护性：与运行可管理性不同；
　　　　3） 可扩充性：系统方案的升级、扩容、扩充性能；
　　　　4） 可移植性：不同客户端、应用服务器、数据库管理系统；
　　　　5） 需求的符合性（源代码的组织结构方面的考虑）。

　　三、程序的运行时结构方面的考虑：
　　1、需求的符合性：正确性、完整性；功能性需求、非功能性需求
　　软件项目最主要的目标是满足客户需求。在进行构架设计的时候，大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则，架构设计应以满足客户所有明确需求为最基本目标，尽量满足其隐含的需求。（客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等，在其他小节中细述）
　　一般来说，功能需求决定业务构架、非功能需求决定技术构架，变化案例决定构架的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个构架的范围。（此段From林星）
　　这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子：此系统的需求本身是比较简单的，就是将某城市的某业务的全部历史档案卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张，需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量，并且今后数据不会增加，经过计算20万张卡片总体容量之后，决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时，才发现数据至少有60万，这样使用那种中小型数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，不得不对系统进行重新设计。从这个小小的教训可以看出，需求阶段不仅对客户的功能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为构架设计的依据。
　　对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力）。对于功能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性，可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。
　　“软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。”
　　2、总体性能
　　性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的，这里把它单独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不是单台客户端的性能，而是应该考虑系统总的综合性能；
性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响；
　　几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分，让用户先把主要部分显示出来。
　　3、运行可管理性
　　系统的构架设计应当为了使系统可以预测系统故障，防患于未然。现在的系统正逐步向复杂化、大型化发展，单靠一个人或几个人来管理已显得力不从心，况且对于某些突发事件的响应，人的反应明显不够。因此通过合理的系统构架规划系统运行资源，便于控制系统运行、监视系统状态、进行有效的错误处理；为了实现上述目标，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运行状态、进行有效的错误处理；（运行可管理性与可维护性不同）
　　4、与其他系统接口兼容性（解释略）
　　5、与网络、硬件接口兼容性及性能（解释略）
　　6、系统安全性
　　随着计算机应用的不断深入和扩大，涉及的部门和信息也越来越多，其中有大量保密信息在网络上传输，所以对系统安全性的考虑已经成为系统设计的关键，需要从各个方面和角度加以考虑，来保证数据资料的绝对安全。
　　7、系统可靠性
　　系统的可靠性是现代信息系统应具有的重要特征，由于人们日常的工作对系统依赖程度越来越多，因此系统的必须可靠。系统构架设计可考虑系统的冗余度，尽可能地避免单点故障。系统可靠性是系统在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行，满足功能需求，还要求当系统出现意外故障时能够尽快恢复正常运行，数据不受破坏。
　　8、业务流程的可调整性
　　应当考虑客户业务流程可能出现的变化，所以在系统构架设计时要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块或组件，充分考虑他们与其他各种业务对象模块或组件的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块或组件调用规则即可。
　　9、业务信息的可调整性
　　应当考虑客户业务信息可能出现的变化，所以在系统构架设计时必须尽可能减少因为业务信息的调整对于代码模块的影响范围。
　　10、使用方便性
　　使用方便性是不须提及的必然的需求，而使用方便性与系统构架是密切相关的。WinCE（1.0）的失败和后来改进版本的成功就说明了这个问题。WinCE（1.0）有太多层次的视窗和菜单，而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正，但最好不要等到失败了再来纠正，这样会浪费巨大的财力物力，所以在系统构架阶段最好能将需要考虑的因素都考虑到。当然使用方便性必须与系统安全性协调平衡统一，使用方便性也必须与业务流程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求，便于用户使用，同时又使得操作流程尽可能简单。这就是设计之本。”
　　11、构架样式的一致性
　　软件系统的构架样式有些类似于建筑样式（如中国式、哥特式、希腊复古式）。软件构架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构架样式和虚拟机构架样式，每一种样式还可以分为若干子样式。构架样式的一致性并不是要求一个软件系统只能采用一种样式，就像建筑样式可以是中西结合的，软件系统也可以有异质构架样式（分为局部异质、层次异质、并行异质），即多种样式的综合，但这样的综合应该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机，应当根据系统最强调的质量属性来选择。 

　　四、源代码的组织结构方面的考虑：
　　1、开发可管理性
　　便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响：一个好的构架同时应有助于减少项目组的压力和紧张，提高软件开发效率）、利于配置管理、大小的合理性、适度复杂性；
　　　　1）便于人员分工－模块独立性、层次性
　　　　模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性，模块联结方式应该是纵向而不是横向, 模块之间应该是树状结构而不是网状结构或交叉结构，这样就可以把开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工作的进行。现在有越来越多的的软件开发是在异地进行，一个开发组的成员可能在不同城市甚至在不同国家，因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要的。
　　　　2）便于人员分工－开发工作的负载均衡
　　　　不仅仅是开发出来的软件系统需要负载均衡，在开发过程中开发小组各成员之间工作任务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人员特点进行分配任务，尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设计时应当充分考虑项目组手头的人力资源，在实现客户需求的基础上实现开发工作的负载均衡，以提高整体开发效率。
　　　　3）便于人员分工－进度安排优化；
　　　　进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结构对所有程序编码工作进行分解，得到每一项工作的输入、输出、所需资源、持续时间、前期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间，分析各模块的并行与串行（顺序制约），绘制出网络图，找出影响整体进度的关键模块，算出关键路径，最后对网络图进行调整，以使进度安排最优化。
　　　　有个家喻户晓的智力题叫烤肉片策略：约翰逊家户外有一个可以同时烤两块肉片的烤肉架，烤每块肉片的每一面需要10分钟，现要烤三块肉片给饥肠辘辘急不可耐的一家三口。问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片，再花20分钟烤完第三片。有一种更好的方法可以节省10分钟，大家想想。
　　　　4）便于人员分工－预防员工人员流动对开发的影响
　　　　人员流动在软件行业是司空见惯的事情，已经是一个常见的风险。作为对这一风险的有效的防范对策之一，可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思路还是在模块的独立性上（追求高内聚低耦合），组件化是目前流行的趋势。
　　　　5）利于配置管理（独立性、层次性）
　　　　利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工外，物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分工和配置管理。（尽管现在配置管理工具有较强大的功能，但一个清楚的源码分割和模块分割是非常有好处的）。
　　　　6）大小的合理性与适度复杂性
　　　　大小的合理性与适度复杂性可以使开发工作的负载均衡，便于进度的安排，也可以使系统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的好处。另外，过大的模块常常是系统分解不充分，而过小的模块有可能降低模块的独立性，造成系统接口的复杂。
　　2、可维护性
　　便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置，并能方便地进行局部修改、切割；（可维护性与运行可管理性不同）
　　3、可扩充性：系统方案的升级、扩容、扩充性能
　　系统在建成后会有一段很长的运行周期，在该周期内，应用在不断增加，应用的层次在不断升级，因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利
　　4、可移植性
　　不同客户端、应用服务器、数据库管理系统：如果潜在的客户使用的客户端可能使用不同的操作系统或浏览器，其可移植性必须考虑客户端程序的可移植性，或尽量不使业务逻辑放在客户端；数据处理的业务逻辑放在数据库管理系统中会有较好的性能，但如果客户群中不能确定使用的是同一种数据库管理系统，则业务逻辑就不能数据库管理系统中；
　　达到可移植性一定要注重标准化和开放性：只有广泛采用遵循国际标准，开发出开放性强的产品，才可以保证各种类型的系统的充分互联，从而使产品更具有市场竞争力，也为未来的系统移植和升级扩展提供了基础。
　　5、需求的符合性
　　从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及构架的最小冗余（同时又要使得系统具有一定的可扩展性）。

　　五、写系统构架设计文档应考虑的问题
　　构架工作应该在需求开发完成约80％的时候开始进行，不必等到需求开发全部完成，需要项目经理以具体的　　判断来评估此时是否足以开始构建软件构架。
　　给出一致的轮廓：系统概述。一个系统构架需要现有概括的描述，开发人员才能从上千个细节甚至数十个模块或对象类中建立一致的轮廓。
　　构架的目标应该能够清楚说明系统概念，构架应尽可能简化，最好的构架文件应该简单、简短，清晰而不杂乱，解决方案自然。
　　构架应单先定义上层的主要子系统，应该描述各子系统的任务，并提供每个子系统中各模块或对象类的的初步列表。
　　构架应该描述不同子系统间相互通信的方式，而一个良好的构架应该将子系统间的通信关系降到最低。
　　成功构架的一个重要特色，在于标明最可能变更的领域，应当列出程序中最可能变更的部分，说明构架的其他部分如何应变。
　　复用分析、外购：缩短软件开发周期、降低成本的有效方案未必是自行开发软件，可以对现有软件进行复用或进行外购。应考虑其对构架的影响。
　　除了系统组织的问题，构架应重点考虑对于细节全面影响的设计决策，深入这些决策领域：外部软件接口（兼容性、通信方式、传递数据结构）、用户接口（用户接口和系统层次划分）、数据库组织和内容、非数据库信息、关键算法、内存管理（配置策略）、并行性、安全性、可移植性、网络多人操作、错误处理。
　　要保证需求的可追踪性，即保证每个需求功能都有相应模块去实现。
　　构架不能只依据静态的系统目标来设计，也应当考虑动态的开发过程，如人力资源的情况，进度要求的情况，开发环境的满足情况。构架必须支持阶段性规划，应该能够提供阶段性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、依赖关系找出来，形成一套开发计划。

　　六、结语
　　系统构架设计和千差万别的具体的开发平台密切相关，因此在此无法给出通用的解决方案，主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的，构架设计时需要根据具体情况进行平衡。

　　有一个自以为很博学的人向一位大禅师请教佛法，禅师不说话，只是不停的为他倒茶，茶水溢出来了也不停下。那个人很诧异：“师父，茶杯已经满了，装不下了！”禅师微笑，停下手，意味深长的对他说：“是的，你的脑子就如同这个茶杯，已经满了，我对你说法，又怎么能装得下呢？”
　　佛家说“所知障”，就是说学了很多的东西，这些东西反而妨碍了自己的修行。项目管理人员也一样，如果过多的执著在技术上，反而会妨碍自己管理技能的提升。
　　那么项目经理这个职业具有什么特点呢？让我们从思想和执行两个方面来说。

　　先说思想方面：
　　技术人员有两个特点，一是注重细节，做事情追求完美；二是动手能力强，做事情往往喜欢喜欢亲历亲为。而对于项目管理者，这两个特点都是要不得的。
　　任何人、任何公司，只要做事情就会犯错，作为管理者，如果一心想把每个细节都做到完美，那么可能到最后就是一事无成。对于细节的改进，我比较喜欢的做法是抓住最重要的事情(一般来说是与QCD直接相关的节点)，这些关键点一定要达到要求，其余的事情就不需要太抠了。另外，如果发现组员在细节上下了功夫做得好的地方，一定要及时表扬。诚于嘉许、宽于称道，是对细节最好的态度。
　　作为管理者，团队的绩效就是你的绩效，但是团队的能力却不等于你个人的能力。也许你的技术很强，但也不可能什么事情都自己做了，就像踢足球一样，一个人的球队是不可能取得好成绩的。因此，要敢于把事情放给别人做，也许他做得不那么好，那么告诉他如何改进，如果同样的事情总是做不好，那么也许这位组员需要换一个更合适的工作。
　　总而言之，作为项目管理者，你不再是做自己的工作，更多的是做别人的工作。重视和领导、商务、技术等各个层面的沟通，关注项目QCD的状态，着眼全局，对事不对人，这就是项目经理们的思维方式。

　　再谈执行方面：
　　一个朋友聊天时提到，他们公司的一位部门经理这样教导见习经理：“想做好部门经理吗？那你要先学会怎么发奖金！”题外话，所有事情里面，我最喜欢的就是拿奖金的感觉……
作为一位项目经理，如何汇报，如何明确自身的责任和权力，是很关键的。发奖金只是一个方面，真正执行起来还有更多。
　　汇报工作，先要学会发邮件。在汇报工作时，邮件发送给你的领导，抄送给相关人员；在安排工作时，邮件发送给目标接受者，抄送给相关的领导。不要小看邮件，它是工作内容的重要载体，也是明确各人责任的证明。电话、面谈、会议等沟通方式，最终都要以书面的形式确认，而邮件，就是最好的书面确认方式。善用邮件，能让你的工作更加有序。
　　权力是和责任紧密关联的。从接受项目经理任命的那一刻起，你就要对这个项目的QCD负责，但是这个责任是泛化的，大多数公司也不会直接赋予项目经理人员、费用等资源的支配权，这些资源可能把握在老板的手上。项目经理需要及时地汇报项目的进展状况，并提出下一步工作的计划，以及所需资源的预算，然后由上级领导批人员、批费用。好的项目经理能够和企业高层保持良好的沟通和信任，从而获取推进项目所必需资源。
　　作为项目管理者，一方面要把握好项目的关键节点，另一方面准确、及时、合理的汇报工作，以充分得到领导层的信任，才能获得推进项目必要的资源，赋予自己相应的权力，这就是项目经理们的工作方式。

　　从细节到全局，从自身到团队，管理者和技术人员从思维方式到工作方法，都是有着本质不同的，这也正是管理者其实并不需要是技术牛人的原因。
　　回到本文开始的问题，我认为，项目经理是不是懂技术并不重要，关键是不能让技术“拖累”了自己，只有超越技术，在项目整体的层面思考问题，才能真正把项目管理工作落到实处；从另一个角度看，在把握好整体工作的前提下，项目经理适当做一些技术工作，也能很好的带动团队士气呢！

　　注：QCD即质量、成本和进度，是项目管理的三个重点，对QCD的把握能力标志了一个组织项目管理的成熟度。

　　有些自己创业的人可以自己选择喜欢的编程语言和框架，当然那毕竟是少数。如果我能够选择的话，我肯定不用 Java 来做网站应用。因为它完成一个简单的工作太麻烦了，很难快速适应需求的变化。当然我也不会去用 PHP ，因为我已经习惯了面向对象的编程方式了。 我发现一个奇怪的现象：大多数转向学习 Ruby on rails 框架的人都是来自 Java 阵营的程序员，而转向Python 框架Zope，django 的程序员大多有 ASP,PHP 背景。因为 Ruby 是一个真正的面向对象的语言， 它同时具备了脚本语言的特点，而 Python 首先是一个脚本语言，它具备了一些 OO 的特征。Java 程序员 很难忍受走回头路，所以他们选择了一个比Java更面向对象的语言 Ruby ，而PHP,ASP程序员没有那么重的思想负担，他们选择 Python 可能是因为它的代码更 Beauty ，远比他们以前写的"意大利面条"式的PHP,ASP 代码要干净的多。 无论是 python, 还是 Ruby 这些非主流程序语言开发的框架，使用起来都异常的简便，他们可谓是真正从程序员角度考虑的框架。为什么 Ruby 一出，搅的 Java 的世界一片混乱，我想原因还是出在 Java 这里，当 Java 程序员想当然地认为程序开发应该如此麻烦的时候，Rails 的出现让他们立刻觉得被这些所谓的 Java 流行框架和 Sun 给欺骗了，这种欺骗是如此之深，以至于他们中间有的人"头也不回"的离开了 Java, 转而攻击 Java 的种种不是。这其中比较有名的人就是 Bruce Tate ，这位老兄写了两本轰动 Java 世界的书，Spring: A Developer's Notebook 和 Better, Faster, Lighter Java （该书可是获得 Jolt 大奖的，恰好我还都读过），随着 Rails 的流行，这位仁兄立刻叛逃出 Java 阵营，写了 Beyond Java 一书，着重介绍了一些非Java 框架，比如 Smalltalk 的Seaside, 和 Rails。

　　Java 为什么这么复杂，我想了很久，得出这么个结论：这是因为 Sun 希望它那么复杂。为什么这么说呢？Sun 不是一个好的软件公司，它最擅长做的是制定规范，这很类似Java 编程中的 Interface, 经常编写 Java 程序的人，会发现 Interface 可能是出现最多的一个词汇了，任何框架中都充满了Interface —接口，大多数编程书都推荐面向接口编程（当然这不是Java的错，是设计模式要求的，不过 Java 将此发挥的最好）。首先定义接口，然后针对接口编写不同的实现，至少提供默认的实现。Sun 也是如此，看看 J2ee 的规范包含了多少 J 打头的技术， JDBC,JNI,JCA,JDO,JPA .... ，现在的 JCP 组织更加如此，每隔一段时间，就有大量的规范问世，Draft 的，还是 Final 的，充斥着Java 世界，这是 Sun 希望的， 每定义一个规范，就会有很多厂商来实现它，Java 的软件市场就做大了，这样 Sun 就可以靠授权，认证拿更多的钱，你看 Sun 的股票那么低迷，而却拥有那么雄厚的流动资金，原因再明白不过了，只要 Sun 还拥有 Java ，它就拥有了一切。Sun 希望 Java 变得复杂，就如同程序员希望 Perl 代码难看一样，这样做是可以带来好处的。Java 的复杂性也带来了产业链上其他行业的繁荣，比如咨询，在 Php ，Perl 流行 Internet 的年代，网站开发似乎还不需要咨询师，包括 C/S 盛行的时候，企业开发也不需要咨询师，然而随着 J2EE 逐步主宰企业级开发，咨询行业也开始兴旺起来。企业大把大把的把钱投入到开发咨询中，究竟效果如何，不得而知。我想对大多数程序员，尤其是那些有自己想法的程序员来说，请求咨询公司，还不如自己去了解来的清楚。软件开发咨询师在我看来，有点象是"律师"—"代表贪婪的公司，让这个世界变得更糟糕一些"（中 Alex 的对白）。如果说国外的咨询师是希望通过主观的努力来解决客观存在的开发复杂性的话，那么国内的咨询行业可能把原本复杂的软件开发变得更加复杂了。我不相信他们，我宁可选择某个软件的培训，而不希望有人来从头到尾指点你如何开发，因为国内咨询师的水平比你从书本上了解的高不到哪里去，公司又何必花费这笔冤枉钱呢。

　　那么如果你是个"主动程序员"，你会跟着 Sun 的指挥棒走吗？ 我想离开 Java 世界，你选择的机会应该很多，但是前提是：你愿不愿意离开 Java 。因为大多数人觉得改变现状其实并不是个好事情，学习一个新语言和框架意为着你过去所有的经验就消失了，这其中有风险。对大多数程序员 来说，编程其实就是份工作，跟卖盒饭，装机器没什么区别，只要搞好本职工作就可以。试图改变现状的人很痛苦，了解差异的人也是如此，就如同 Neo 在接受红药丸和蓝药丸。 我在当年学习 Perl 的时候曾经买过一本《Learning perl》，书的作者曾经这么说，学习 Perl 是为了让自己把更多的时间用在去滑雪， PHP 的创始人 Rasmus Lerdorf 也曾经这样表示过，他希望自己能够减少盯着电脑的时间，可是这么多年过去了，他发现自己还是要继续盯着该死的电脑。其实我对选择框架语言也并没什么兴趣，我只是希望能够以简单的方式完成工作，而把时间省下来去听听音乐，看看电影。实际上我跟不希望改变现状的人没什么不同，他们不希望学习新的东西，因为现有的东西很熟悉了，学习新框架，还不如把时间放到玩上去，我的目的一样，我学习只是希望自己的工作更轻松一点，这样可以用更多的时间来玩。所以每当我看到各种技术论坛上充斥着Java, .net , ROR ，Python 之类的争吵，我都觉得很好笑。其实为了维护一个语言而争吵最没有意义。编程语言就和英语，计算机一样，就是个工具，选择它们只是为了尽可能简单地完成工作，提高生活质量。为了语言而语言，为了框架而框架都是没必要的。"主动程序员"可以选择自己的方式来工作，这是大多数人做不到的。如果有可能，我也希望做一个"主动程序员"。

　　他们的专业是空调。跑业务的朋友毕业后被河南一家公司录了，干了一年，后想到结婚，便丢了工作，又回到了湖南老家，找到高中情人，干起了结婚生孩子的勾当。据说他当年读书不怎么样，但4年过去，如今不但孩子会跑会叫他爸爸，而且他的业务也做起来了，越做越红火，赚了一大笔，在家乡的城市与长沙各买了一套房子，日子过得有声有色；念硕士朋友毕业后也去了海尔总部，做起了普通的管理，据说每月也有几千块的收入。2年后，他想着求大发展，想去学校镀金，于是硬着头皮翻开了课本。3个月的复习，没想到硝烟弥漫的考研战场，他居然过五关斩六将，顺利上了中南大学的录取线。

　　我还清晰记得他来办理读硕报到手续那天的情景。开学典礼上，院长在台上慷慨一番陈词，套话太多，我已记不大全，印象中他强调得最多的一句是，中南大学的硕士生教育是作为国家精英教育的模式来培养人才的，大家从此要树立精英意识，云云。

　　读硕士的朋友那天与我在典礼后聊了很多。毕竟他已在社会上闯荡了2年，有些见识；再回到学校，与那些一直就进行读书考试的直升生，之间有一种无形的膜。当时他那样子，有点落寞，有点孤独。但他始终笑嘻嘻的，至少看上去还是蛮开怀的。

　　我真的佩服他考硕士的勇气。从海尔集团重返校园，除了心理的承担，必然还需要承担经济压力，以及与女朋友分手的现实。而且，那时社会上已满是硕士生在外面找不到工作的传闻了。据说中国一流的企业家经常折磨自己的方式就是让自己去抉择。企业家的抉择就是在两难中作选择。累，且呛。他说，报考之前，自己好的坏的都想过了，所以很坦然。我看他比一流企业家的内心在抉择时不见得轻松。

　　这次他们见面，恍然间已有4年多了；老同学再次碰面，地点在我家。

　　跑业务的朋友才喝了2杯酒，话就多了。张口说来，就是这里几万，那里几十万的业务，钱虽不多，但随便拉个小业务，光提成就够得上念硕士的朋友一年的学费与吃喝拉撒！念硕士的朋友从海尔出来后光身一人，口袋空空，也是个能屈能伸的男子汉，现在境况远不如人，便时而打起哈哈自嘲，要么就笑咪咪地看着跑业务的同学，言不由衷地恭维上几句，算是圆场。

　　问题就出在跑业务的同学不知是故意装，还是就这么个脾性，他放肆吹嘘起目前的优越感来。老婆有了，孩子有了，房子有了，下一步车子也马上就有了，每个月运气不好就只能接个把单，赚个万把块钱，手气来了，几个业务同时送货上门，赚个十万八万也就是看几场电影的工夫。看他那油亮而年轻的脸，我怎么老压也压不住就联想到1990年代老被人提起的暴发户。

　　想想吧，一个二十五六岁的青年，拿着大本文凭，每个月压根就不用为生计发愁，也不作什么理想与去外面大世界拼搏的打算，那种来自骨子里的优越感让人10公里外都能感觉到。他放肆一款一款地去证明，老同学读硕的行为是一个纯粹浪费青春的举动。接着他举出一大堆事实来论证在空调行业，硕士研究生文凭只是一张废纸。他说：干我们这一行，最多就像我，读个本科封顶了。再读下去只是空洞的理论，没一点实际用场。

　　我好奇起来，问：你现在的工作到底是怎么赚钱的嘛！

　　他说，简单得很！一个造价在10万左右的室内空调安装计划，他只需要花上2个小时做个报价方案，然后丢给一帮民工去干，自己就可从中提成一两万块钱。他说得极其轻松，仿佛这世上最容易干的工作就是赚钱。我有点疑惑，便问念硕士的朋友，是这样的吗？

　　他点了点头。确实有这么简单。

　　我问：那你可以做方案，难道你同学就不会做吗？跑业务的的朋友马上摇头：他也可以做，但他没有实践经验，不敢接单。等他读研出来了，就看不上我这个行业，就算他再来做我这一行，那么他这三年里学的，全部浪费了。

　　我终于弄明白，跑业务的的朋友这一行目前是只适合本科生干的行当，有点技术含量，所以不读个大学怎么也鼓捣不出来。但因为技术要求非常之低，所以硕士生一般都不屑于这一行，所以行业的竞争对手非常有限，再加上人缘关系对业务的影响也是至关重要，所以他干的这一行成了名副其实的“垄断性”暴利行业。

　　我听得终于有点替念硕士的朋友愤愤不平起来。社会分工也好，财富分配也罢，毕竟要遵循一个游戏规则，就是工作的回报与工作的智慧或技术含量要挂勾，而且职位的重要性与不可替代性也是直接影响到工资回报。但这跑业务的朋友却根本不需要遵循这一游戏规则，享受着收入与付出严重倒挂的待遇。而现在衡量成功的标尺，就一杆：钱。

　　若问题到此为止，也还简单。但后面还没完。

　　跑业务的朋友嘲笑念硕士的朋友说：你硕士毕业后做什么呢？最好是进设计院。可就算进了国家一流的设计院，他所能领到的薪金仍不能同自己相提并论。而且现在20刚出头的硕士生与博士生随手一抓一大把，人家好设计院哪里看得上你？

　　知识的尊严至此终于彻底垮了，念硕士的朋友终于悲观起来，那境况颇有点鲁迅笔下梦醒后铁屋子里挣扎的无奈。他又扯散话题，问起了念本科时老同学毕业后的去向，跑业务的朋友马上得意地告诉他：有个老同学现在仕途看好，据说做了副县长，——至少也是镇长了。以后老同学团结起来，有官有商，相互拉扯，什么大事做不成？

　　跑业务的朋友懂了许多的官场，在我面前说起市里某某新领导上任，最喜欢抓工程，他说，这有个诀窍，形象工程一搞，一有政绩，二则自己趁机可捞一把，要不当官的喝西北风去？现在新领导都这么做，所以他开始注意拉近与市领导的距离，寻找着接近领导的机会。

　　老实说，我突然差点同情起念硕士的朋友来。换了我，内心会严重失衡。在这样一种心态下熬完学业，拿到硕士文凭，将来一旦有发迹的机会，会再去考虑择手段么？总不可能硕士毕业后看着同学没来由地发达而自己古井无波，老老实实地呆在像跑业务的同学此类人的手下，乖乖地讨生活看颜色吧？

　　我脑子里又浮现他办理读硕报到手续时的情境来。这硕士教育到底是什么样的精英教育呢？我不知道了。但作为社会精英的大学生们、研究生们的口号已越来越不可信了，这是事实，也是经验。在校期间疯狂地喊着打倒某某，抵制某某，支持某某的学生，毕业后往往第一个成为自己当年要打倒要抵制的对象。精英教育是可敬的，但精英有时也是让普通老百姓非常害怕的。知识不能代表真理，而知识分子的尊严报复有时也让人恐惧。

　　求学是赚钱途径的一种，但书本并不全然是教育你如何去一心一意地去赚钱。被知识分子经营出来的社会，经常不按人生的常理出牌，这社会如何能够让人心不设防？

　　大学时我听来一个典故。说三个同学参加同一堂考试，A复习一个月后从容通过；B靠2.0的视力和远近皆交的手腕，抄袭轻松过关。C一不做，二不休，白卷交上，然后提一对五粮液去任课教师家里改分数。毕业后，A做了教授，B做了省委书记，C做了上福布斯排行榜的首富。初听这故事时我一直疑惑是小说，后来方明白是报告文学。这才是课本外最真实的社会人生。

　　这年头最让读书人斯文扫地的就是钱。小学毕业可以做首富，中学毕业就只能做巨富了。至于大学毕业，不出意外多做了老板的贴心秘书，而硕士与博士，则多做了年薪100万的高级保姆。

　　我同学中也颇有几个去进修硕士，后来顺风念到了博士，现在都怀揣两证，陆续在积极地张罗工作，前途光明，道路曲折。今天在校园里，像我这样而立的人是老字号了，因为导师带的，清一色是20才出头一点的年轻人。

　　如今40岁以上的人，不分男女老幼，学问高低，除了每个行业内冒尖的几个象征性地作了点缀，其余差不多都已经被历史淘汰了。这个世界，马上就要被20多岁的一代人主宰了，他们中的精英，即将充斥在各行业，成为中坚。我的富业务、穷硕士朋友不过是他们中的两个分子。他们的故事现在才开端，后面远远没完。

　　聊天累了，天色已晚，做业务的富朋友叫上穷硕士朋友，招手拦了一辆的士，握手道别，一齐消失在长沙茫茫的夜色中。我懵懂地看着车拖一条长长的白雾，依稀又记起最近不知道从哪里听来一句顺口溜：读完博士读壮士，读完壮士读烈士，读完烈士就成了圣斗士。

在五点二十九的我是白领圈子里看到很多人发牢骚，说薪水少，可在我看来，你们这样的人拿得到高薪才怪！ 

我先问一句：这里有多少人是本科的？有多少人是正规本科的（不算自考，成考和专升本）？有多少人是有学位的？有多少有学位的是拿着网大排名前５０所大学的学位的？恐怕是少之又少吧！在中国，薪水和学位的关系对于应届生来说是绝对的，即使对于以后的发展，学位也很重要，要不那些低学历的人评职称为什么吃亏呢？你可以告诉我这不合理，不错，这确实不合理，但却是现实。如果你不能改变现实，那还是适应它吧！你也可以告诉我低学历一样可以拿高薪，我承认，不过你要准备比别人多付出１０倍以上的努力。 

接下来是语言，这里恐怕是有不少人没有过四级没学位的吧？有多少过六级的？有多少过专四专八的？有多少有其他英语证书的？你不要和我说你的水平好，可不喜欢中国的考试制度，所以没证书。在中国，毕业一开始的几年就是靠证书，你有本事跳过１楼２楼造３楼吗？如果你英语不行，你有其他二外吗？要知道，老外对于it的重视可是比国内那些买的电脑做装饰品的土老帽要强得多。 

其实这些都不是最重要的，最重要的做人的风格，现在很多it人除了技术什么都不懂，整天得罪人。哪怕你是四个ccie全考出的，我不用你难道地球就不转了？中国多的是人，技术有什么了不起的？更何况很多技术是根本用不到的。 

现在总看到一些所谓的“技术牛人”在误导新人，你们知不知道你们是在误人子弟啊！自己混不出头，还要去害别人，今天要和你们好好算算帐。 

先自我介绍一下，我是９８年从上海交大毕业的，在ms工作了６年，现在在一家系统集成公司工作。

第一个意见：读书最重要，就是为文凭。我承认大学里确实学不到什么东西，但为了文凭请一定要认真读。这个社会要文凭，没办法。还有大学成绩要读好一些，像ms,cisco,oracle这些大公司是会看的。读大学还有一个好处是大学很空，你可以自己去学想学的东西，不过学校的功课永远是最重要的。那些大专的不要以为本科生学不好技术，确切得说并没有几个优秀的学生是书呆子。没有什么规定说大专生学技术有优势。

第二个意见：好好读英语，要想在it立足，英语是必须的。至少要过六级，如果能有专八或者中高口证书或者bec什么的就更好，最好还要有二外，可以考虑德语或者日语。作it一定要去外企，国企绝对没前途。

第三个意见：要认真选择入的行业。it是非常广泛的概念，网络只是其中一个非常小的（而且也是非常没有前途的）领域。it最有前途的领域是什么？是开发，开发中最有前途的是什么？是硬件开发，也就是电子工程，那些家伙的月薪差不多是我的年薪（我现在月薪是税后１０K）；其次是软件开发，不过很苦，而且需要不错的数学基础，不过在中国不要去搞通用件开发，一盗版全完，最好是搞ERP类的专用系统开发，连开发带维护都有了。如果你没有数学基础，却有不错的美学功底，那就去搞设计，photoshop也好，autocad也好，3dsmax也好,flash也好，视屏后期处理也好，但不要搞网页设计（无论是前台还是后台），因为一个人作的模扳一万个人用，不会有好的收入的。再不行就来搞网络和系统，这个方面最好搞数据库，不过这样又要涉及到开发，如果搞网络也要搞部署（系统集成），或者去大公司作技术支持，最差的就是作维护了。 

为什么说维护是最次的？因为无论是什么公司，维护都不是主营业务，或者说，不会为公司带来收入。在公司，能直接影响利润的部门收入才高，所以说任何企业，最重要的是销售和市场，其次是研发和生产，至于我们维护部门，不过是和扫垃圾的和扫厕所的一个级别而已。 

维护虽然是最差的，但不代表不能拿高薪。首先，要去大的外企，他们对于it部门的重视程度高。第二，要学会为人处世，我们本来就是服务部门，所以对其他部门的人要热情一些，主动一些，不要老摆个“高手”的臭架子。要知道，技术如果不能换钱，那不过是垃圾而已。第三，不要老是问老板要钱换设备，我们已经不能产生利益了，就要让老板感觉我们能节约管理成本，我们的任务是最大限度利用现有的设备，而不是整天采购新的设备。

即使如此，我所谓的高薪不过是在维护这个领域里的高薪而已，和其他主要部门是不能比的。所以最好还是跳出这个行业的好，去作系统部署。而作系统部署不要去做部署人员（即使暂时作，将来也一定要做项目经理），这是民工都可以做的。或者就是做方案销售，这样你就是企业的主营业务了。

顺便说一下我对认证的看法，相对与学历和英语，它是最不重要的。当年我去ms，靠的不是什么mcse，而是我的专八和名校学历。ms的面试并不关心你的技术，而是关心你是否聪明，是否能溶入企业文化。还有，国内好象很多人对ms不满，因为软件太贵了，这些钱都进了我们这些技术支持的口袋了，不错，ms的员工薪水很高，可这是我们努力工作换来的，我们每天都要工作１２小时左右，xp刚发行那段日子xp组的工程师都要工作到凌晨２－３点，白天还是9点上班，难道我们不该拿高薪吗？至于mcse我是进ms后再考的，没有看过书，全是靠*****过的，也就是你们所说的paper，不过我想说一句，对于应届生，你不用在意自己是不是paper，因为企业已经默认你是paper了，所以无所谓的。 

总结一下，it界不是没有高薪，而且it的高薪在所有理工类行业中是高的。关键是看你自己的能力。对于还没毕业的同学，我希望你们能先认真读书，至少拿个学士出来（最好是名校的），然后看看能不能考上好的大学的硕士，同时学好英语，多参加社会活动，即使你作it，技术也不过只有20%的比重而已，重要的是沟通和为人处世的技巧。对于刚出来的大学生，我的意见是先苦几年，多考一些外语和it的证书，准备向外企跳。

最后一句，我所说的也许确实不好听，但事实如此，你可以举很多反例来反驳我（中专生拿高薪之类的），但这些例子是不能反映总体情况的，不信我们可以抽样调查。还有，中国有很多现状是不合理的，但你不能改变它，那要么你适应它，要么你毁灭。在沙漠里谁能活下来？是万物之长的人还是骆驼？还是慢慢成长的五点二十九？

1.  对项目的成功没有全心全意投入。Never committing to project success.
2.  在充分理解项目之前就定死进度和预算。Freezing the schedule and budget before a project is sufficiently understood.
3.  过分扩大某个解决方案的适用范围。Overscoping a solution.
4.  没有雇用专业的应用开发公司。Circumventing the application development organization altogether.
5.  对问题的复杂性估计不足。Underestimating the complexity of a problem.
6.  缺乏领域专家，而专家的参与也不够。Being stingy with subject-matter experts, in which their participation is not sufficient.
7.  项目的领导班子选择不当。Choosing the wrong project leadership.
8.  用人又疑。对已经委以任务的管理人员不信任。Distrusting managers who have had tasks delegated to them.
9.  未经足够研究，就进入开发阶段。Jumping into development without enough research.
10.  报喜不报忧，沟通不足。Suppressing bad news, in which dialogue is insufficient.

　　坐落于此的逐鹿茶楼，正是个清净所在。待走进门去，只见砖墙、朱漆、木刻，各处摆设有战鼓、军帐，又刻意营造出一股兵戈气势。此种静中取闹，虽然算不上别具情趣，但对于来此畅谈梦想与未来的人们，倒是不乏励志之隐喻。

　　这半年来，每月的第二个星期四，总有一群人相约至此。他们先是极轻松的相互玩笑、回忆往事，用过饭后，便一个个严肃起来，把自己当下最困扰的问题和盘托出——如何顺利融资？如何管理好一、二十人的团队？应该开发什么新产品？—并进行数小时的研讨。一切显得颇为正式，他们甚至轮流担当主持人，控制话题进程。

　　这是一家创业公司定期召开的高层会议？错了，这里至少有四家公司的创业者，还有几人正在筹备创业。让他们坐在一起、并保持高度坦诚的理由是：他们曾在百度共同工作数年，由此获得了网络创新的经验、个人的第一笔财富，以及一个巨大的创业梦想。

　　众人中，岁数最小的段晖只有27岁，2003年他离开百度时，已经是公司技术委员会五人组之一。今年初，他和曾经同一小组工作、皮肤黝黑的林应明创立了一见互动，试图打造一个Youtube+ MySpace的社区。

　　同样于3年前离开百度的雷鸣，曾编写了百度第一代程序的大量代码，并被李彦宏称为“中国最好的工程师之一”。去年于斯坦福大学MBA毕业后，他与同学怀奇开始打造一款将歌曲、歌词、歌星新闻相结合的音乐识别软件“酷我”，并依此寻找解决音乐版权问题的方法。

　　一副书生气的谌振宇曾任大搜索部门高级技术经理，直到今天，百度内外仍有很多人将其姓氏念作“申”，他也颇为大度地从不纠正。今年4月，他和“百度的女婿”徐易容(其妻为百度的工程师)搭建了博客订阅平台“抓虾”，因为灵活运用AJAX技术而实现了良好用户体验，一经推出即在国内确立了不俗口碑。

　　原企业软件事业部门高级工程师、长着一张娃娃脸的吴世春是唯一坚持在搜索市场摸索者，他与段晖的北大同班同学陈华联合创建了生活信息搜索引擎“酷讯”，并在2006年一年内完成了两轮共1200万美元的融资。

　　这是一个罕见的创业群落。这些百度的早期员工在因不同原因离开百度之后，一直保持着长期的友谊，并由于接连创业而达成了更为紧密的联合。正因此，在今年初段晖的婚礼上，谌振宇提议各自创业的朋友们有必要定期聚会一次，迅速得到了所有人的认同。而这个“逐鹿会”的确尽其所能：参与者不仅共享商业判断(如酷讯开通二手车版块就得益于聚会上的讨论)、经验(新近离职的前首席架构师周利民于11月首次参加聚会，就应邀向众人提供很多建议)，还疏通人脉(投资酷讯后，联创策源投资基金继而找到了抓虾)，寻求合作可能(如抓虾上可以订阅酷讯的资讯和一见的视频)。

　　过去十年间，在中国取得成功的网络公司并不缺乏高层外出创业故事，如搜狐就输出过张黎刚、陈剑锋、古永锵等创业者。但百度的创业者阵容可能是最庞大的：《环球企业家》先后采访8名活跃在业内的前百度员工，包括被称为正在“享受生活”的百度联合创始人徐勇，及身在深圳而无法参加“逐鹿会”的迅雷创始人程浩。近期，又有首席架构师周利民和首席技术官刘建国两名重要高层相继离开，他们的创业也被视为顺理成章之事。

　　然而，这并非另一个港湾之于华为的故事。“对于一个公司来说，有两种情况是不健康的：其一，只有好的人才离开而不好的人留下；其二，好的人才一出来就成为原公司的竞争对手。但是百度并非如此。”在百度工作4年后离开，还在寻找创业方向的曹炜斌认为百度的人才出走是一个健康的循环。

　　更为重要的是，如果说六年前李彦宏和徐勇尝试在百度内部复制硅谷基因—徐勇将硅谷文化总结为三方面：容忍创新失败、容忍不同观点、认可人的价值。如今，百度系的创业公司也在努力传承这些基因：技术主导，创新而散漫的工程师文化，培养学生为主，用户体验至上。

　　“很多早期员工在某种程度上被Robin(指李彦宏)和我‘洗脑’了”，百度联合创始人徐勇玩笑说，随后他认真的表示：“这些人去任何一家跨国技术公司，都能获得不错的薪水，创业可能是风险最大的一种选择。但无论成功与否，只要这种创业文化传承下去，国内一定会有世界级的技术公司出来。”

　　2004年12月，徐勇离开百度，留给所有员工一个承诺：创业时需要帮忙，随时来找我。目前，他是一见互动和酷我的天使投资人，担任酷讯和迅雷的顾问，并在自己擅长的生物制药产业寻找创业机会。目标：做中国的Genentech。

　　【百度血脉】

　　除了两名创始人，至今抓虾只有两名正式的技术员工，其余近十人都是从清华、北大等周围高校招来的实习生。

　　它也像学校一样运转。每天中午所有人凑在一张桌子上吃饭，无所不谈。谁工作累了就在小吧台喝点饮料。晚上加班到两、三点，去到专设的卧室倒头便睡，早上洗漱完毕就又开始工作。“在一个小公司人手缺乏，更能够锻炼你各方面的能力。”一位在抓虾实习的研究生颇有参与感。

　　这种情形颇似当年的百度。

　　1999年底，各自在硅谷生活了3年的李彦宏和徐勇辞掉美国的工作，带着120万美元的风险投资和对搜索引擎的信仰从硅谷回到北京，进驻北大资源宾馆。

　　以其时百度之小，几乎无法招聘来大型技术公司的一流人才，但它并未降格以求，而是转而寻找网络上的、尚未流入微软与IBM的技术尖子。如北大天网是当时国内最好的搜索引擎，百度先后将其主力开发人员刘建国、雷鸣、周利民、段晖等纳入麾下。当时雷鸣还在读研究生，段晖本科尚未毕业。

　　而在他们融入百度体系之后，李、徐又让他们每人建议或发掘身边的人才资源。这种网络扩张式的人才引进方式保证了百度血液的纯度：除了人的质量，还有其价值观的符合。而李、徐摒弃创始人的身份，要求员工称呼他们为Robin、Eric，共同就餐、业余时间组织娱乐活动，形成了百度关系紧密的早期团队。

　　目前，“百度第二代公司”们几乎都在采用这种方式从高校研究生中招揽人才，而且成绩不错。雷鸣的公司今年给予10余名员工以正式加盟的机会，只有2个人转而选择其他大型公司。

　　对于这些加盟的优秀人才来说，雷鸣们所能提供的，和早年百度提供给他们的，相去不远：一个神奇的未来。

　　回国之前，李彦宏曾撰写过《硅谷商战》，而徐勇则拍摄过纪录片《走进硅谷》，像传教士般，两人用发书、放纪录片和反复宣讲的方式让百度最初的员工形成了这样一种价值观：在小公司，你可以发挥自己的自主性，做出这个世界上最酷的技术；在大公司虽然眼前挣钱多一些，但不如一个创业公司上市，期权给你带来的财富那么多。

　　同时，李和徐努力营造一种近似硅谷的文化：崇尚技术创新、推崇平等、强调个性和娱乐精神、不规定硬性的工作时间、一切以成果说话。

　　“每周一次例会，先讲工作，会上我没有发现一个人有意讨好上司，都是怎么想就怎么发言。”一见的创始人兼总裁林应明说。几乎所有百度的初创期员工都有这样一种认识：没有公司政治，任何时候都可以就事论事。

　　徐勇认为这种文化等同于一种机制：决定一家公司命运的关键之处，在于它能否做出比对手更多的正确决策。而百度从其成立之初就形成了一种开放、平等、务实的文化，让所有人都能敢于说出想法，这就让百度做出正确决策的可能性倍增。甚至，当时百度从不避讳在公司内部赞许竞争对手：他们经常讨论Google和3721的长处。这种并不好高骛远，反而非常踏实地直面问题的风格，让百度的员工处事单纯但不失竞争意识。

　　在2002年找到美国Overture公司发明的广告竞价排名的商业模式之前，百度曾经先后变换过三套思路：最初是将其搜索引擎售予新浪、搜狐、网易们，但收入极少，后来转向CDN(内容分发网络)网络加速器，然后又调整进入企业级搜索市场。虽然前几次转型都成果不彰，但这种坚持和最后的成功，赋予百度员工创业中的坚韧理念。

　　徐勇记得当时他跟员工常说的一句话是：“我不能保证百度一定能成功，但是我知道，如果我们一周只干5天，每天干8小时，百度就没资格上市。”

　　这种氛围让拿到美国7所大学奖学金的雷鸣暂时搁置了出国计划，也让吴世春在听说过相关故事后，从华为降薪去到百度。而在那时，雷鸣们已经开始酝酿个人的创业梦想。

　　【抱憾ES】

　　在百度内部，有这样一种说法：百度出来创业的人，大部分是ES部门的人。

　　ES全称企业搜索，后改称企业软件事业部，百度曾投入巨大精力于其中，但终因市场限制未取得太大成就，导致其多数骨干出走，其中便包括程浩、林应明、吴世春和段晖。

　　因此，当2006年7月ES被百度正式裁撤之时，即使是此部门的老员工，也认为这一断臂之举并非错误。

　　事实上，ES的存在，本身只是百度寻找方向中的一步。2001年，尚不明确商业模式的百度按市场将团队划分为PS(大搜索部，即后来推出的百度独立主页)和ES两个部门。

　　两相比较，PS的商业模式在当时看似更不明确，但浏览量日益飙升。而ES看似路径明确，却并未取得大发展。几乎不经意间，两者在公司战略中孰轻孰重就显现出来。以至于一次公司季度会议上，时任ES部门高级技术经理的程浩当着所有员工的面质问李彦宏：“百度两个业务，PS开会你和Eric(指徐勇)都去，而ES开会你们谁都不去，这明显就是你们不重视!”这个尖锐的问题顿时赢来了ES部门员工的一片掌声。李彦宏当时显得非常尴尬，勉强解释说：“我们不是不想参加，而是都不懂这块业务，参加了对你们也是没有什么帮助。”

　　但在当时，百度仍不敢放弃企业市场的探索，因此并不鼓励ES的员工转换到PS去，这也的确让不少人郁结苦闷。除了大家经常共同出游、聊天，也逐渐达成了一个共识：互联网创业，必须做针对普通网民的产品，而不是针对企业的产品。

　　于是，2002年底，程浩选择和美国归来的邹胜龙前往深圳创业，林应民不久后与其会合，成为迅雷的头一号员工。吴世春和段晖也在2003年相继离开。

　　导致这一批人才流失的症结何在？事后回顾，徐勇认为当时将人才分布于两个部门，并不为过——对于任何一家方向不明的公司，在寻找方向时都可能付出类似代价。一个假设是：如果百度能像Google一样设立创业奖励基金，在内部实现对于非核心业务相关创新的激励，结局可能更好。

　　但这仅为假设。李彦宏以其“专注”著称，离开百度的员工虽与其交谊不俗，他却无瑕做出任何天使投资。由此也不难推导，在Google行之有效的内部VC体系，在更强调专注的百度或许并不能有效运转。本刊曾试图就此话题与李进行探讨，他也颇有兴趣，但因其身在国外，未能与本刊进行面访沟通。

　　【新标准】

　　在众多新兴起的“百度系”公司中，最早开始创业的程浩似乎已经看到了成功的曙光。他和邹胜龙所创立的迅雷，在过去一年里取得了长足的发展：今年初实现收支平衡，2006年收入比去年涨了十多倍。更有说法称，他们开发的高速下载软件迅雷已经被安装到上亿台电脑中，成为中国继腾讯的QQ之后，用户最多的客户端软件。

　　2002年下半年，程浩和邹胜龙意图创业时，看准的方向是：利用P2P技术，在分布式邮件存储上寻找商机。

　　刚一开始，他们就发现这条道路并非坦途。两人原本打算先分别在北京和硅谷拜访VC，融资后再做产品开发。却没想到时值互联网寒冬，一个月下来，双方一无所获，只有到邹胜龙的家乡深圳先开发产品。不得已之下，程浩从朋友处借了5万元，方才凑足企业注册资金。整整一年，两名创始人没有领一分工资，全公司居然只用20万元人民币就支撑下了2003年全年。

　　然而，在边开发边和邮件服务提供商接触的过程中，他们却发现这是一个毫无市场需求的产品。两人不得不重新坐下来思考新的方向，逐一分析互联网上的各种杀手级运用：搜索已经有百度和Google；腾迅和MSN霸占即时通讯领域；新闻和邮件为三大门户所擅长。只有下载这个领域，虽然有Flashget等产品，但没有形成垄断之势，且Flashget很长时间内没有进行质量上的明显提升。如果迅雷能做到足够快，就还有机会。

　　此时，林应明已经来到深圳。他们又陆续招来几个人，在一个很小的办公室里专注于这个下载工具的开发。

　　2003年7月，迅雷的第一个版本出来，由于架构上的问题，速度比Flashget还慢，“我们甚至不好意思告诉朋友产品已经做出来了”，程浩说。

　　“10月的那段时间，有一些山穷水尽的感觉。”林应明回忆道。邹胜龙多次去北京和上海找很多风险投资商洽谈，都空手而归。而大家在解决方式上存在分歧，产品的架构问题迟迟没有得到有效解决，

　　多次争吵之后，他们终于做出一个艰难的决定：重新架构整个系统。

　　这一次，他们总结了失败的经验，设计时每一步都讨论得很详细，每个人也做了很详细的单元测试，整个项目甚至提前一周顺利完成。

　　这个版本的迅雷，虽然客户端软件达到14兆之巨，但实现了最重要的特点：快。

　　这终于引来了风险投资商的目光。IDG的合伙人杨飞看过产品演示后，用几个小时就做出了投资决定。

　　随后，迅雷的团队一方面拜访各游戏厂商寻求合作，利用网络游戏大肆发展的契机赢得了其首批用户。这一年来，他们更是运用与正版CD制作商和游戏厂商联合运营、组建社区等方式，让迅雷进入高速发展轨道。

　　虽然现在表示乐观为时过早，但迅雷内外不乏有人相信，它有望于2008年内上市。

　　如果这一预期成真，它对于其他百度系创业者的激励，将不亚于百度现在在资本市场上的成就。

　　而且，其成功可能为中国互联网进一步清晰一种商业模式：以QQ为代表的客户端产品展现出了巨大的粘性和扩张潜力，但行业多数公司仍未认识到除了常见的工具条、插件与即时通讯软件，客户端软件还有何种可能。迅雷证明了客户端产品线的开阔性，也有可能继续证明一款客户端产品将辐射出新的盈利模式。

　　和迅雷思路相近，酷我也是客户端软件。虽然其商业模式暂不清楚，但需求明显：在播放歌曲时，如果能够搭配歌词，对于普通用户就是一个有效的增值服务。在此功能之上，酷我还能将明星新闻、音乐录像等信息与歌曲相结合。推出不足一年，酷我已经有数十万用户。

　　也不难在百度系公司中找到共同点：虽然都是技术主导型公司，但是他们都建立了对产品的群策群力机制。吴世春认为这来自百度的经验：这些年来，百度犯错误极少的最主要原因，便是建立了一个很强大的产品部门。

　　即便规模尚小，酷讯、抓虾、一见等公司都成立了产品委员会：由产品部门调查和整理用户需求，提交产品委员会审议。以酷讯为例，它现在的产品部门有8个人，由产品部、研发、项目管理部、测试、设计等各个部门的人参加，目的是让每个细分产品都能明确指向用户需求。迅雷甚至建立起了更完整的信息反馈机制，在内部，员工提出意见、纠错能够得到奖励，对外，鼓励用户提出意见，甚至对相关人士每周进行抽奖。

　　这里帮你找出几种最适合计算机族喝的茶饮，或是点心，不但可以帮您对抗辐射的侵害，还可保护您的眼睛，抗烦躁呢！

　　★绿豆薏仁汤　　 　　

　　绿豆可以清热解毒、利尿消肿，薏仁则可以健脾止泻，轻身益气，对于经常需要熬夜工作者或是心烦气躁、口干舌燥、便秘、长青春痘时，除了多吃蔬菜水果与补充水份外，把绿豆薏仁汤当点心食用，对于消暑除烦非常有帮助。

　　★绿茶

　　绿茶是近几年来最为人所津津乐道的养生饮品，因为其中含强效的抗氧化剂儿茶酚以及维他命C，不但可以清除体内的自由基，还能使副肾皮质分泌出对抗紧张压力的荷尔蒙，当然绿茶中所含的少量咖啡因也可以刺激中枢神经，提振精神。最好在白天饮用以免影响睡眠。

　　★枸杞茶

　　枸杞子含有丰富的β胡萝卜素，维生素B１、维生素C、钙、铁，具有补肝、益肾、明目的作用，因为本身就具有甜味，不管是泡茶或是像葡萄干一样当零嘴来吃对计算机族的眼睛酸涩、疲劳、视力加深的问题都有很大的帮助。

　　★菊花茶

　　有明目清肝的作用，有些人就干脆菊花加上枸杞一起泡来喝，或是用蜂蜜菊花茶都于疏肝解郁都很有帮助。

　　★决名子茶

　　决名子有清热、明目、补脑髓、镇肝气、益筋骨的作用，若有便秘的人还可以在晚餐饭后饮用，对于治疗便秘很有效果。

　　★杜仲茶

　　杜仲具有补血与强壮筋骨的作用，对于经常久坐，腰虽背痛很有帮助，男女都可以喝，若是女性朋友还可以在生理期的末期与四物汤一起服用。

随着软件团队人员的增加，软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发面临越来越多的问题，其中包括对当前多种产品的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等，这些问题在实际开发中表现为，项目组成员沟通困难，软件重用率低下，开发人员各自为政，代码冗余度高，文档不健全等；造成的结果是：数据丢失，开发周期漫长，产品可靠性差，质量低劣，软件维护困难，用户抱怨使用不便，项目风险增加等。解决这些问题的唯一途径是加强软件开发的管理，而软件开发管理的核心是软件配置管理。

什么是软件配置管理？软件配置管理是一套规范、高效的软件开发基础结构。作为管理软件开发过程有效的方法，SCM 早已被发达国家软件产业的发展和实践所证明。SCM 可以系统地管理软件系统中的多重版本；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。SCM 对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。SCM 是通往ISO9000 和SEI CMM 标准的一块基石。

二、软件配置管理的主要活动

任何一个活动的执行首先是明确谁做，再明确怎么做，配置管理活动也一样，一般来说配置管理中的角色主要包括：

1、项目经理：项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助，制定项目的组织结构和配置管理策略。这些工作包括： 定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，以及进行系统集成；

2、配置管理员：配置管理员的职责是根据项目经理制定的开发组织结构和策略，实施、维护配置管理的环境。其主要职责如下：创建配置管理库，对存储库进行日常备份和恢复，维护配置管理环境，及管理配置管理相关的用户；

3、软件开发人员：软件开发人员依据项目的开发和配置管理策略，创建、修改和测试开发工件；

4、集成人员：对软件进行归并，形成相应的基线或发布版本；

5、QA 人员：需要对软件配置管理有较深的认识，其主要工作是跟踪当前项目的状态，测试，报告错误，并验证其修复结果。

软件配置管理人员应该完成以下几个主要任务：

1、任务一配置标识

要配置标识，首先必须明确项目生命周期内所要产生的工作产品，然后确定工作产品的名称和标识规则。总体原则是，保证配置管理工具检索便利，让项目组成员容易记住标识规则，同时要确保组织一级的标识规则的一致性。

2、任务二版本管理

版本管理一般是使用工具来完成的，如Rational ClearCase、Merant PVCS Version Manager、Microsoft Visual SourceSafe等。使用这些工具时，容易被忽视的一点是制定所使用工具的版本规则。如果直接采用工具的内部版本号，会给产品发布带来一些困难。通常采用“X.Y.Z”方式进行版本标识，明确X、Y和Z各位数字递增的规则，然后结合工具标签（Label）功能，便可实现高效的版本管理。

3、任务三变更管理

变更管理是项目管理的一个重点和难点，涉及的范围很广。实施高效的变更管理至少应该包括两个部分：“定义合理的变更管理流程”、“采用自动化工具作为支持”。在具体的实践中，应该对变更进行分类和分层，建立起处理不同变更的“变更控制委员会”（CCB），既保证项目组成员有一定的自主权，又不会耽误高层经理对关键问题的把握。

4、任务四配置审核

配置审核包括两方面的内容：“配置管理活动审核”、“基线审核”。“配置管理活动审核”用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，如检入（Check in）/检出（Check Out）的频度、工作产品成熟度提升原则等。实施“基线审核”，要保证基线化软件工作产品的完整性和一致性，并且满足其功能要求。基线的完整性可从以下几个方面考虑：基线库是否包括所有计划纳入的配置项？基线库中配置项自身的内容是否完整？（如，文档中所提到的参考或引用是否存在？）此外，对于代码，要根据代码清单检查是否所有源文件都已存在于基线库。同时，还要编译所有的源文件，检查是否可产生最终产品。一致性主要考察需求与设计以及设计与代码的一致关系，尤其在有变更发生时，要检查所有受影响的部分是否都做了相应的变更。审核发现的不符合项要进行记录，并跟踪直到解决。

5、任务五报告配置状态

报告配置状态的目的，是向项目所有成员提供基线内容和状态、基线变更信息（如表2所示），这也是实现资源共享的前提。此外，在项目生命周期中进行对配置项的变更数据统计分析，有利于评估项目风险，有效控制项目的执行。在变更请求被批准、基线版本发生变化及项目组提出任何需要时，可以采用Email等方式进行报告。

6、任务六发布管理

实施了规范的配置管理，发布就显得很从容了。但是必须要注意的是：发布的产品应该是从软件基线库中提取出来的；在软件发布给最终用户之前，要准备发布记录，为软件产品分配发布版本号，同时要对它进行发布评审并确认其得到批准。一般来说，高层经理、项目经理、软件质量保证人员和测试组都应该参加发布评审。

三、研发部实施配置管理的经验分享

要制定切实可行的配置管理规程

实施配置管理，非常重要的是先定义好配置管理规程，可以参看CMM、 RUP等规范来制定，但必须要注重与部门实际项目开发情况相结合，制定的流程不一定要复杂，过于求全，主要是让大家看了规程能够理解，并且可操作，能够遵守执行的，而且确实能解决实际问题的。规程的制定能让组织的人员有统一的标准可以依据，指导配置管理工作的有序执行。配置管理规程要根据实际过程情况定期进行更新；

项目初期要做好配置管理计划

在执行任何软件过程之前一定要有明确的总体计划，特别是各开发阶段的配置管理计划，而且要严格按照计划执行，保证执行的结果与计划的要求一致，而不是做到哪里是哪里，导致整个过程杂乱无章。

保证充分的资源

软件配置管理活动在整个开发活动中是一项支持性、保障性的工作，它本身并不直接为企业产出可以直接赢利的工作成果；而配置管理每一项活动都需要消耗企业的人力资源，有些还需要购置专门的工具来支持活动的进行，这些都会导致企业生产成本的增加。这就需要组织高层和实施人员的大力支持，研发部从实施配置管理至今正是有了公司及部门领导在人力资源和工具资源上的大力支持才使得我们非常有效的实施这一过程。

实施培训

一般来讲，实施配置管理系统，相关人员需要接受一下培训：

a.管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容；
b.开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作；
c.管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合；

工具的支持

选择什么样的配置管理工具，一直是大家关注的热点问题。确实，与其他的一些软件工程活动不一样，配置管理工作更强调工具的支持；缺乏良好的配置管理工具的话，要做好配置管理的实施会非常困难。当然，对于工作的选择应根据部门实际的需要而论，不一定要选最好的，只要是最合适的就可以。

过程不断改进

实施软件配置管理不可能一次计划、执行就可以建立起完整的配置管理系统，要经过不断的经验总结和实际项目管理的需要，不断改进现有的配置管理规程，才可以达到较为成熟的软件配置管理过程，这是一个循序渐进的改进过程。

四、总结

以上只是简单地介绍了配置管理系统实施的相关内容，软件配置管理作为软件开发过程的必要环节和软件开发管理的基础，支持和控制着整个软件生命周期。若要有效的实施软件配置管理，首先要通过一系列的培训，培养软件开发者的管理参与意识，同时更重要的是借助已有的经验教训，建立起真正适合自己团队的管理流程。

　　通过我们的调研，我们了解到，IT行业中，人才需求量最大，所以IT猎头被认为是猎头的朝阳行业，而且各家猎头公司也都特设有IT猎头部门。本土猎头和合资猎头都将目标描述了这块市场，但从细分领域来看，高端IT管理人才相对于高端技术人才，则更受到猎头的青睐。

　　以一家IT猎头公司为例，从2000年开始做猎头，定位于IT行业，其业务涵盖系统集成、互联网、电信、移动增值、IT服务、软件外包等领域，服务层次主要是年薪20万以上的中高端技术和管理人员。但经过几年发展后，公司的主要业务已经逐渐向IT企业的高级管理人员，技术猎头因为成本高、难度大，其业务比例在逐渐的缩小。

　　这是因为，两者的操作难度相差较大。CXO之类的管理职位，主要评估的是候选人的行业视野和经验，薪资并不是决定因素；而且这类职位，因其职业化程度较高，更容易适应不同的环境。相比之下，技术职位候选人的评估难度比较大，技术水平很难从几次面谈了解到，而更多地需要依靠技术研发圈子里的声誉和影响力来分析，但调查这些背景资料往往比较困难。

　　猎头对技术人才的建议：定期在线更新简历，各大网站的人才库是很多猎头寻觅人才的地方，当然包括CSDN的技术人才库；转行要慎重，不要因为“热”而转，任何一个行业都有波峰和波谷，行业积累更重要；跳槽更要谨慎，履历中，超过两次在一家公司只呆了半年到一年就跳槽的，都不会被猎头选择；技术和管理，两方面的能力都要着重培养；英语是高薪的一个非常重要的筹码。

　　项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：

　　1.这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。

　　2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的；

　　3.基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；

　　4.在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间；

　　5.现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。

　　6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。

　　7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。

　　对于这种需求天天变的客户，你就一定要事先做好规矩：

　　一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；

　　二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：

• *有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
• *便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
• *对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；

　　8.现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：

　　第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。

　　第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。

　　9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：

　　完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做干特图的形式表现出来。你做完这个表以后会惊奇地发现，干特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。

　　当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。

　　好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。

　　和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”王局长：“(*&$@@”。和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖）.

　　所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。

　　在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。

　　另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。

　　接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：

　　1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；

　　2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？

　　3. 项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。

　　系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：

　　一、给客户做培训前，多注意一些表面功夫。很多程序员认为，系统的逻辑核心是否正确是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题，而且培训的时候也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后就麻烦很多。

　　作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。

　　验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，这些在前面已经有所提及，这里就不再多说。

　　我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了XP还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。

　　序：大项目在本文的定义为企业信息建设中客户大名气高而且项目金额大，在我国，能签下大项目的单有一部分是靠草根阶层更专业化的服务和质量以及行业客户赢得的，但一般而言签下的这样的大项目对软件开发商而言都不可能是天平两端同样的法码，所以销售人员为了能签下这样的大单一般都不得不答应或是承诺一些超越公司目前实力和技术水平的需求，因为不这样根本就没有竞争的机会。这样的苦果程序员即使抱怨非常多，还是不得不照样加班加点去拼命实现。(想想国外的厂商做中国的市场真是爽，国内的客户无不乖乖地听他们的话)

　　目前国内的软件公司靠产品批发赚大钱的非常少，象金蝶和用友上也都有靠签大项目来发展，所以大项目的成败及效率就直接影响着公司运营成本和利润以及大家的薪金收入。因为一开始签定的就是不平等条约，所以项目经理的人选更是直接决定了项目的成败和收益。这样的项目经理有两种，一是为自己镀金的，那是非常光荣和开心的事，因为费用及人手配置都非常充足，第二种是很有责任心而且想做成功的项目经理，会做得非常辛苦，累得半死。如何让项目早些验收让领导放心，让下属开心和放松是项目经理时时刻刻都关注的事。

　　正文：结合自己的经验谈谈项目经理在主持项目实际运作时的二个要点三种避免和四个注意。希望对大家的实际工作会有所帮助！

　　两个要点

　　一、如何尽快地将项目验收回款，为公司和团队创造更多的利润，为下属带来更多的利益。
　　二、板回双方不平等中的劣势。

　　这是项目中非常关键的一个心理预期，因为早期签的合同让开发商处于劣势，客户从你进场开始自然而然地在气势上压着你，如果你长期处于心理上的劣势，项目失败的风险就非常高，因为大公司中的人员都有一种出了事情后他们会将你原本认为是他们的责任的推得干干净净，如果你纠缠下去和他们的关系就搞僵了，项目的后期工作会非常难进行，公司高层考虑的就是更换项目经理，因为这时的客户真的是上帝，老板都不敢得罪的人你得罪的后果大家都知道会怎样。笔者当初和他们打交道时就花了一个月多的时间让整个团队在专业上体现出来是行家和经验娴熟，因为客户是大公司的，技术资源很丰富，他们懂的面很广，也有知道得深的，所以要抓住机会和他们多交流特别是非工作时间，首先你要认可他，然后让他感觉他专业，再然后你在合适的机会某些方面要自然而且不露痕迹地表现出你知道得更深更专业，当然当初没少花我银子。劣势板回后，后期他们才会注重你说话的份量，才可以指出哪些需求是不合理的，哪些是微软都没有办法做到的。
　　　
　　三个避免

　　一、避免事情太多杂乱无章

　　大项目也意味着需求多，参与的人员也多，如何保证项目的进度，避免事情太多，需求点太多而导致最后项目失控，就是项目组加班加点做了大量的工作，最后却发现什么都没有做好，客户不认可，领导很焦虑，下属很失望，你很郁闷的局面。在项目进行过程中不可避免地会遇到很多提出的需求和修改意见，如何快速把握这些需求提出正确可行的解决方案是项目经理首先要考虑的事情。别忘了项目合同上都是有时间限制的，如何在时间段之内完成项目而且完成得好就是关键。一味地否认抵制客户的需求当然不行，全盘照收只会让项目越变越大，项目组的人每日每夜地加班。笔者的作法一般是记录成文字性的文档，然后根据实际情况提出哪些现在做，哪些暂时不做，哪些到二期或三期工作时再考虑，并请他们确认。这套方法笔者常用不衰，希望对各位项目经理在项目运营过程有实际的帮助。

　　二、避免太多个性化的需求

　　这是最头痛的事情，因为客户是大公司，会议没完没了，每个会议都要求得非常正规，而且客户看起来确实是很正规，相关的制度文档相关的人员以及部门级的经理都甚至高层的领导也会请到会议室来和你谈需求，每个经理都会有自己的部门的特点和需求，如何尊重他们的意见并保持自己的思路是非常重要的。笔者早期参加这样的会议时也一样很听客户的话，程序实现的过程中则是非常痛苦，经历过多次后，笔者建议各位项目经理要保证突出你们的专业知识和经验，不要被客户的职位所迷惑了，因为他们的经验很丰富，但在专业特别是软件方面你是专家，而且他们提出的是现实中各个部门的特点，并没有要求软件一定要实现。所以现场一定要记住，不要答应得太快，笔者后面就养成了一句口头禅，我们回去研究讨论后再确定。

　　三、避免人浮于事的现象

　　大公司都会有的现象，如何让你的项目组成员在项目进行过程中最大限度地减少这样的消耗是项目经理要关注的事。大公司踢皮球的现象大家都有所耳闻，所以做为项目经理的你能做就是如何做好事前的工作，避免出了问题后指责，到时你会发现没有人和这有关，都是你的错。所以少些抱怨，事前尽可能多做准备。笔者最常用的方法就是在需求说明书(实际工作中提出，非早期完整的需求说明书)中注明这是某某人提出的，以及我们的意见是什么，你别指望他会签字，一个需求点如果要等他确认签字你就等个两个星期吧。

　　四个注意

　　一、注意内部团结一致，互帮互助和高度的热情保证得项目快速往前推进。

    项目小姐的团结一致，这是基石，不论是在需求讨论分析，还是开发过程和项目内部测试，大家都团结一结，不断提出自己的看法一起交流，在最短时间内将问题细化和明确下来，大大缩短了开发周期。保持项目小组成员高度的热情使得项目讯速得到突破，达到了预期的要求，这是项目经理真正最重要的工作。在项目运作过程中，别忘记项目小组不是孤军奋战，背后还有整个公司的资源别忘了使用。

　　二、注意项目进度的严格控制

　　这是老生长谈的问题，核心还是《人月神话》，在现有的人手配置和资源上如何控制项目的进度，这是所有项目经理也是公司领导最关注的事情。因为大项目的进度要控制出了偏差，后期很多预想不到的事情会让你焦头烂额的。所以必要的会议还是要开，总结和安排工作是每周都必须要进行的工作，笔者当初是将工作总结工作安排和需求讨论严格分开的，即使是参加的人员一样。因为需求讨论需求分析有时是无底洞，有些实现起来是有难度的，这时在会议上一定要注意控制方向鼓励大家踊跃发言的同时要保证主题方向。因为需求的扩散和实现的难度将直接影响到项目的进度，很多项目最后失控追根结底相当一部分原因是需求没有把握住。笔者一同事负责的一个百万级的项目，超过签定合同时间的半年了还没有完成，公司后期调动了所有可调用的技术人员进入项目组，搞得人人疲惫，当初最大的原因就是客户的需求不断扩散导致程序开发无休止地进行。

　　三、注意搞好各方面的关系

　　项目经理首先要搞好的是你和你的领导的关系，特别是老板的关系，你要体会你的老板的心情，他是希望做成功大项目然后开始扩张，他的心里比你更关注项目的进展，要是出问题他心里比你更焦虑，所以记得要让你的老板参与到项目中来，别因为他不懂技术不懂项目管理就把他晾在一边。笔者的做法是每周都会将工作写成简单的总结发给上级领导，然后抄送给BOSS，有什么计划要执行或调整时预先做好书面材料发送给领导们，这时要忌讳的就是越级上报，所以这样的计划我一般是只发送我的直属上级，在MAIL中写到等计划正式拟定后请他转呈老总，大的事情一般是他都会在比你更期望的时间代你向老总汇报了，因为只有和老总搞好关系，他才会信任你，而且还会源源不断地支持你，不然一些公司接到一个大项目要失败了，公司搞不好就负债了，所以你要明白BOSS可能是将公司前途放在你身上。接下来就是要搞好下属的关系，他们是实现完成工作的核心和中流抵柱，平时要舍得花些银子请他们吃吃饭组织一些体育活动，程序员都是典型的亚健康状态，看看程序员那象怀胎三个月的肚子就知道了。再接着就是要搞好客户的关系了，除了言语上尊重他们外，必要的银子还是要花的，而且要花得有特色，因为他们聚餐也不少啊。所以大家明白我为何要将搞好和老总的关系放在第一位了吧，不然这些白花花的银子，老总不签字，项目再失败了，你赔了血本都不够啊，呵！

　　四、注意项目验收的各个环节

　　这是大家都关心特别是老总最关心的问题了，有时你别看他表面上非常平静，一点都没有开心的样子，我的老总那天在去洗手间的路上就哼起了小曲，这是好几年都没有的事情。但是要达成这样的任务并不是象小项目那样双方有意向后谈一天就可以签字，大公司都有自己一套套的验收标准，如果按照他们那样的标准，你卖硬件都难，更不用说软件了，而且谁在这上面签了字以后出了问题谁就要负责，而且软件永远都没有100%没有问题的，你看微软还不是不断升级和发补丁包。如何采用让双方都能接受的方式签定验收合同就要求你平时就要做好准备，笔者一般是每个月都会有一个功能模块实现的清单请他们确认，要他们签字是不可能，笔者的做法是请他们指出哪些没有完成的或有意见的，这样日积月累下来，对方认可了你的工作，后面他个人这一关是可以通过了，后面一定是他的上级以及副总层层把关，记住这时谈的一定要是实现完成了哪些功能，对新需求的千万不能答应就改，可以放到后期，并在验收合同中注明哪些是新需求还没有完成的，层层把关让折磨你的性情考验你的耐性，两周之内要能签下字就算是顺利了。还有一点有过大项目经验的仁兄有没有注意到，项目验收签字的都是客户的最高层和最低层两三个人的名字一起签在上面，中间管理层做了许多幕后工作，所以在验收的过程中不要忘记向客户的每个上级多表扬一下项目中参与的他下属人员的业绩，当他们都是功臣时在最后一关卡住的机会会少很多。因为最后一关没有通过，所有的一切努力都是白搭！希望此篇文章对广大同行能有实际的帮助，祝各位同仁都能在项目验收的庆功宴上多喝两杯。

　　至少在目前看来，发行商与游戏制作人的这场博弈中并没有输家。

　　重新刊登以下这篇文字，或许您能从中看到一些从前所不知道的故事。

　　前言

　　2003年6月30日，暴雪娱乐公司（Blizzard Entertainment）副总裁比尔·罗珀与暴雪北方公司（Blizzard North）的三位创始人——恩里克·斯卡伊夫、马科斯·斯卡伊夫和大卫·布雷维克——集体离职，在美国游戏业内引发了一场不大不小的震动。如今围绕这一集体离职事件的各种传言已渐渐消散，这也给了我们一次重新审视的机会。

　　笔者无意再添加更多茶余饭后的谈资，只是想借此文陈述一些故事，一些枯燥而真实的故事。

　　五天内发生了什么故事？

　　在这次人事地震前的一周内，暴雪北方公司显得非常平静，唯一一条新闻是6月24日的网络程序员招聘启事，条件为“优秀的客户端/服务端网络架构能力和编程能力，很强的游戏设计感，善于团队合作”。这则招聘启事并没有为我们带来任何有价值的提示，因为战网（Battle.net）在暴雪北方公司内部也有架设，招聘网络程序员可能只是为了维护战网，或是对《暗黑破坏神2》的联网功能作进一步的优化。

　　而此时，比尔·罗珀也如往常一样在暴雪总部忙碌着。6月25日，罗珀接到HomeLAN记者打来的电话，这位记者希望就暴雪开发中的几款游戏进行一次访谈。作为暴雪的官方发言人，罗珀愉快地接受了这一请求。在接下来的谈话中，双方聊到了暴雪正在开发的三款游戏——电脑游戏《冰封王座》、电视游戏《星际争霸：幽灵》和网络游戏《魔兽世界》，罗珀还对近几个月战网对作弊者的数次大规模封杀发表了自己的看法。

　　当时那位记者一定不会想到，五天后暴雪内部竟会爆发一场人事地震，6月25日的这次访谈竟成了比尔·罗珀代表暴雪的最后一次发言。而更具讽刺意味的是，这篇访谈的开头是这样写的：“当你拿起电话与暴雪公司副总裁比尔·罗珀交谈的时候，你能够清楚地感受到，他非常乐于就这家PC游戏业内最成功的开发商/发行商的所有话题进行交流。”
　　
　　比尔·罗珀离职后的第二天，7月1日，HomeLAN再次采访了他。罗珀确认，6月25日接受HomeLAN采访时，他与暴雪北方的三位创始人根本没有想到自己会在五天后离开暴雪。
　　
　　算上在暴雪北方的前身Condor的日子，斯卡伊夫兄弟和布雷维克在暴雪北方已经呆了整整十年，而罗珀也只差一个月便将在暴雪工作满九年。十年的光阴，竟在五天之内土崩瓦解，而这一切又是来得如此突然，毫无征兆。
　　
　　在6月25日至6月30日的这五天当中，暴雪内部究竟发生了什么故事？这一切是否与微软行将收购维望迪环球游戏公司（VU Games）的传闻有关？是否与暴雪北方秘密开发中的两款新作有关？是否与暴雪未来的倾向网络游戏与主机游戏的发展战略有关？这四人又为何要选在6月30日卸职？一天后，《冰封王座》发售；三天后，《暗黑破坏神2》1.10测试版发布；而三年前的6月29日，又恰恰是《暗黑破坏神2》问世的日子。
　　
　　这些疑问也许只有留到若干年后才会一一解开。
　　
　　维望迪环球游戏的故事
　　
　　作为暴雪的分公司，暴雪北方与暴雪之间一直保持着非常密切的合作关系，双方出现重大矛盾的可能性很小。比尔·罗珀的离职及其随后的发言也进一步证明，这次事件很可能是与暴雪母公司维望迪环球游戏（Vivendi Universal Games，以下简称VU Games）之间的冲突所造成的。让我们先来了解一下VU Games的故事。为便于读者理清关系，笔者绘制了一份简单的演化图。 　　
　　
　　今天的VU Games是建立在多次资本重组的基础上，故事得从Havas互动公司说起。1995年底，Liris互动公司在巴黎成立，该公司作为CEP Communication集团的多媒体分部，在母公司的强大支持下，一年后即发展为当时法国最大的多媒体出版公司之一。1997年，Liris互动公司被法国出版巨头Havas收购，更名为Havas互动公司，成为Havas旗下的多媒体分部。
　　
　　Havas公司的历史可以追溯到19世纪。经过整整一个世纪的发展，先后经历了国有化、私有化等变动，经历了多次并购和重组，至1997年时Havas已是全球最大的通信集团之一。其核心业务包括六大部分：视听、通信咨询、信息与出版、本地媒体、旅游与休闲，以及多媒体。
　　
　　1998年是Havas公司发展史上的一个转折点。一年前收购了Havas公司30%股份的CGE集团（Compagnie Générale des Eaux）为打造一个全球性的媒体帝国，于1998年再次收购了Havas公司余下的股份，Havas自此成为CGE的全资子公司。同年，拥有150年历史的CGE集团更名为Vivendi。
　　
　　1999年，Vivendi通过Havas在法国、西班牙、阿根廷、巴西和美国等全球各地展开大规模的并购行动，暴雪当时的母公司、美国的Cendant软件公司即是并购目标之一。收购Cendant是Vivendi踏上美国领土的第一步，促成这桩7亿美元的并购计划的是Vivendi高级执行副总裁、43岁的女强人安妮丝·图拉尼（现任VU Publishing公司董事会主席兼首席执行官）。
　　
　　2000年6月，Vivendi公司以高达340亿美元的价格并购加拿大Seagram集团公司（环球电影、环球唱片的母公司），在大西洋两岸引起强烈震动。并购完成后的公司被命名为Vivendi Universal，股票分别在巴黎、纽约和多伦多上市。
　　
　　2000年底，重组后的Havas更名为Vivendi Universal Publishing公司（以下简称VU Publishing），成为Vivendi Universal旗下的出版分公司，而Havas互动公司也相应地更名为Vivendi Universal Interactive Publishing公司（以下简称VU Interactive Publishing）。VU Interactive Publishing被划分为两大分支机构：VU Interactive Publishing北美公司和VU Interactive Publishing国际公司。北美公司位于美国加州南部的托兰斯，负责北美地区的业务；而北美以外的业务均划归国际公司负责，包括欧洲、亚太地区和南美洲，其办事处设在法国巴黎总部。在重组Havas的同时，Vivendi Universal还组建了一家新的游戏开发工作室——环球互动（Universal Interactive），并将其与暴雪、雪乐山一起归入VU Interactive Publishing旗下，“蛊惑狼”系列和“侏罗纪公园”系列是该公司的知名品牌。
　　
　　2001年11月4日，VU Publishing将VU Interactive Publishing北美公司与VU Interactive Publishing国际公司整合为Vivendi Universal Games公司，统管全球游戏业务的开展。
　　
　　2002年8月13日，VU Publishing组建Black Label游戏公司，归入VU Games旗下。Black Label公司侧重于开发和发行以小说、电影、音乐为题材的游戏，其第一部作品是根据1982年约翰·卡本特执导的恐怖电影《第三类异物》改编而成的同名游戏，第二部作品是根据托尔金的奇幻小说《指环王：魔戒现身》改编而成的同名游戏。
　　
　　至此，VU Games在北美已拥有五处分公司：暴雪娱乐、雪乐山娱乐、环球互动、Black Label和Partner Publishing Group（以下简称PPG）。其中PPG为新组建之公司，负责与Coktel、Empire互动、福克斯互动、Interplay、Knowledge Adventure、Mythic娱乐和Simon & Schuster互动等合作伙伴共同发行和分销产品。
　　
　　VU Games公司的首席执行官为肯尼斯·克朗，他负责公司全球战略的制定及组织管理，以及重要品牌的研发推进，其中多平台分销、全球拓展和互联网内容经营是其工作的三大重点。原VU Interactive Publishing北美公司首席执行官鲁克·瓦恩哈继续负责北美地区的业务，并对北美的四支开发团队——暴雪、雪乐山、环球互动和Black Label游戏——以及PPG进行统一管理（如果暴雪与VU Games之间发生任何冲突的话，瓦恩哈恐怕是最直接的当事人）。原VU Interactive Publishing国际公司首席执行官克里斯多夫·兰姆伯兹继续负责北美以外地区的所有业务，同时管理跨国分支机构的发行业务和产品的本土化。
　　
　　2002年，疯狂扩张中的Vivendi Universal公司陷入严重的财务危机和信用危机，Vivendi Universal董事会于2002年7月解除了前总裁让·马里·梅西耶的职务，由让·雷纳·福图取而代之。八年前，梅西耶这位曾效力于法国财政部的并购狂人正是通过大胆割舍非核心业务才挽救了濒临破产的CGE公司，八年后的今天，其接班人福图又将使用同样的手法去挽救陷入危机的Vivendi Universal公司。上任数周内，福图即出售了一直处于亏损中的Canal+。为尽快摆脱310亿美元的高额负债，福图还计划陆续出售VU Publishing公司的部分资产，VU Games即是其中之一。

　　今年5月，知名投行贝尔斯登公司（Bear Stearns）公布过一份关于VU Games的简报。据贝尔斯登统计，VU Games目前共有约380款游戏，其中52%为原创产品，30%为授权产品，18%为第三方产品。在VU Games公司2002财年发布的产品中，一半为游戏机游戏，一半为PC游戏，公司收入56%来自PC游戏，44%来自游戏机游戏；从收入的地域分布来看，63%来自北美市场，27%来自欧洲市场，10%来自亚洲市场。
　　
　　贝尔斯登援引材料称，VU Games去年在以下地区的PC游戏市场上排名第二：北美、法国、德国、西班牙、澳大利亚和英国。在全球游戏市场上，威望迪游戏排名第六，占据约5%的市场份额。

　　暴雪与暴雪北方的故事
　　
　　接下来让我们回头看看暴雪公司的发展历程。
　　
　　艾伦·爱德海姆是暴雪公司的创始人之一，早在加州大学读书的时候他就开始编写游戏，他最初的两部作品——《西部牛仔》和《恶魔地狱》——获得了不错的反响。1991年2月8日，爱德海姆组建了一家专业的游戏开发公司——Silicon & Synapse，这就是暴雪的前身。
　　
　　Silicon & Synapse最初以移植为主，曾移植过Amiga版《指环王》和《战棋2》。之后爱德海姆与同伴迈克·摩尔海米一起制作了《摇滚赛车》和《失落的维京人》两款经典超任游戏，由Interplay公司代理发行，这两款游戏博得了业内人士的高度评价，成为他们通往成功之路的基石。
　　
　　1994年初，爱德海姆把Silicone & Synapse改名为“Chaos Studioss”，随后又于4月正式定名为“Blizzard Entertainment”，暴雪娱乐公司正式诞生。同年，暴雪被以开发儿童学习软件“Blaster”系列而闻名的教育软件出版公司Davidson & Associates收购。
　　
　　1994年11月，暴雪发布成立后的第一款游戏——《魔兽争霸》，暴雪的辉煌由此开始。1995年，《魔兽争霸2》发售。1996年2月，暴雪收购Condor工作室，将其更名为暴雪北方。同年12月27日，《暗黑破坏神》发售。
　　
　　1996年，CUC国际公司以11亿美元收购Davidson & Associates公司，成为暴雪的新东家，原为独立开发商/发行商的雪乐山也于当年被CUC国际公司收购。1997年12月，CUC国际公司与HFS合并，成立Cendant公司，暴雪与雪乐山遂成为Cendant公司的资产。Cendant公司在酒店、汽车出租代理、大型消费抵押贷款、住宅房地产经纪和报税服务等领域处于全球领先地位。公司总部设在纽约，业务遍及100多个国家，雇员超过35000名。在美国教育软件市场上，Cendant与The Learning公司一同占据了当时60%的市场份额。
　　
　　1998年4月，Cendant被查出会计违规，投资者信心大跌，股价一路下挫，公司形象也受到极大损害。所幸的是，母公司的风波并未影响暴雪公司的开发计划，1998年4月，《星际争霸》正式发售，资料片《母巢之战》开始制作。
　　
　　1999年，Cendant被Havas收购，暴雪归入Vivendi旗下。2000年6月29日，《暗黑破坏神2》发售。2002年7月，Vivendi Universal因假帐事件和高额负债而遭受重创。同月，《魔兽争霸3》发售，资料片《冰封王座》开始制作，《星际争霸：幽灵》秘密筹备中。
　　
　　1998年的暴雪是幸运的，在Cendant遭遇困境前，《星际争霸》的开发工作已经完成，次年又找到一家财大气粗的买主。2002年的暴雪尽管同样是在Vivendi Universal公司出事前即完成了《魔兽争霸3》的开发，但这一回母公司的财务窘境却将直接影响到它的命运。
　　
　　同暴雪娱乐公司一样，尽管经历了一系列公司变动与所有权转换，暴雪北方公司始终保持着处变不惊的态度。
　　
　　玩家通常所说的“暴雪”实际上包括了暴雪娱乐公司与暴雪北方公司，这两家公司均位于加州，前者位于洛杉矶与圣地亚哥之间的尔湾市，后者位于旧金山以南30分钟驾车路程的圣马特奥，故被命名为暴雪北方公司，而暴雪娱乐公司有时也被人们习惯性地称为“暴雪南方”。
　　
　　整个暴雪公司共有三支开发小组，暴雪北方的小组主要开发《暗黑破坏神》系列，暴雪娱乐拥有两支小组，其中一支负责即时策略游戏，如《魔兽争霸》系列和《星际争霸》系列，的开发，另一支负责网络游戏《魔兽世界》的开发（此小组组建时日不长，约有40名全职工作人员，在名气上无法与其它两小组相提并论）。这三支小组分工严格而氛围开放，不同小组的成员之间也常常相互交换意见，分享彼此的想法。
　　
　　如上所述，暴雪北方的前身是一家名为Condor的独立游戏开发商。Condor创建于1993年9月，最初是一家专门移植游戏的公司。那时的暴雪尚未诞生，仍旧挂着Silicone & Synapse的名字。这两家公司最早的接触是在1994年，当时Condor与Silicone & Synapse均在为Sunsoft公司作一款名为《正义联盟》（Justice League Task Force）的格斗游戏的移植外包工作，Condor开发的是Genesis版本，Silicone & Synapse开发的是超任版本。
　　
　　在1994年芝加哥举办的CES展会（国际消费电子产品展）上，两家公司再度碰面，Condor被Silicone & Synapse在展会上所演示的《魔兽争霸》的精彩画面所吸引。半年后，Condor向其表达了合作意向，而Silicone & Synapse也正需要外力加入，帮助他们壮大PC游戏的开发阵容，双方一拍即合，Condor便带着《暗黑破坏神》的雏形投奔过去。一年后，《暗黑破坏神》开发进程过半，暴雪正式收购Condor，并将其改名为暴雪北方公司。
　　
　　暴雪北方公司在开发方面始终保持着独立的地位，暴雪总部为其处理质检、市场推广、公关、技术与客服支持、战网架设等事宜，并不过多地干涉暴雪北方的开发工作。以《暗黑破坏神2》为例，其设计和制作完全是由暴雪北方公司独立完成的，暴雪总部主要提出修改意见、帮助其进行质量测试，并提供动画方面的支持（暴雪有一支专门负责动画的制作小组，由十数名美术师与音响师组成，暴雪娱乐与暴雪北方两家公司均使用同一支动画小组）。
　　
　　目前暴雪北方公司除继续维护《暗黑破坏神2》外，还在秘密开发两款尚未公布的游戏；而暴雪娱乐公司则将主要精力集中于《星际争霸：幽灵》与《魔兽世界》的开发之上。

　　以人为本的故事
　　
　　话题越扯越远，在这由资本构筑而成的错综复杂的企业关系中间，人的存在意义似乎变得越来越渺小。比尔·罗珀、恩里克·斯卡伊夫、马科斯·斯卡伊夫和大卫·布雷维克四人的突然离开暴雪，也许仅仅是出于一些非常个人化的原因。但我们仍然固执地认为只有把他们放在公司的层面上进行考量，才有可能得出合情合理的结论。在这个被异化的社会中，人所扮演的角色的重要性已经超过了人本身。
　　
　　在公司层面上，令比尔·罗珀等人下决心离开暴雪的深层原因很可能是VU Games未来的发展方向与他们的计划相左。VU Games公司首席执行官肯尼斯·克朗去年年底接受记者采访时曾表述过公司未来的两大发展目标：一是在产品结构方面逐渐缩小PC游戏所占的比例，增加电视游戏与网络游戏的数量。截至2005年，VU Games公司的产品结构将调整为35%的PC游戏、50%的电视游戏和15%的网络游戏，而1999年VU Games公司营业收入的98%均来自PC游戏。
　　
　　二是在游戏与小说、电影、音乐之间进行更多的合作，这一方面与大众市场的崛起有关，另一方面也是因为Vivendi Universal拥有环球电影和环球唱片等丰富的可利用资源。从VU Games近期开发的一系列作品，我们可以看出他们已经在加大这方面的努力，例如将环球电影公司出品的《速度与激情》、《绿巨人》等影片改编为游戏；与福克斯公司合作开发《X档案》游戏；开发以李小龙为主角的游戏；邀请环球唱片公司旗下的Def Jam唱片公司为《霹雳小组：都市正气》谱曲；邀请环球唱片公司旗下的摇滚乐队No Doubt为《恶意》谱曲并配音；邀请环球唱片公司旗下的传奇摇滚乐队Metallica为一款尚未公布的新作谱曲并配音。
　　
　　这两个发展方向对于始终专注于PC游戏、专注于原创游戏的暴雪来说自然不是什么好消息，这意味着公司在业务方面将面临转型，否则其资源及地位会受到影响。

　　在短短五天内下决心离开一家呆了十年的公司，并不是一件容易的事。上述猜测也许能解释四人离职的必然性，但却无法解释究竟是怎样的偶然原因促成了这次集体离职。比尔·罗珀在接受CNN记者采访时曾特别提到人的重要性。他说：“希望这一事件能给这个产业提个醒：游戏的成功并非是由印刷在包装盒上的名字、品牌或其它什么所决定的，而是由制作这个游戏的人决定的。正如你希望阿诺德·斯瓦辛格参与你的影片，希望斯蒂夫·金或J.K.罗琳为你写书，你同样希望最优秀的人来为你做游戏。……人是最重要的。”

　　无论个体收入还是社会分工，开发商与发行商相比均处于弱势。在美国，绝大部分游戏开发人员的年薪在10万以下，只有极少数程序员可达到30万美元。而7月1日美国证券委员会公布的一份电子艺界公司管理层2003年收入表中，高层管理人员的平均年薪加分红均在100万美元左右，此外还持有公司的数十万股票。游戏开发人员的地位显然无法与电影演员或图书作者相提并论，尽管两者的性质非常接近。

　　在美国游戏业现行的版权金预付模式下，绝大部分游戏的版税金最终都无法超过预付款，因此除非作品获得较大的成功，否则独立开发团队很难通过资本积累得到发展。版权金预付源自唱片业与图书业，在这种模式最初被游戏业采纳的时候，开发一款游戏的平均预付款仅为1万美元左右，游戏的零售价约为20多美元，游戏的版税率等于或高于目前的版税率。时至今日，由于项目越来越复杂，开发一款游戏所需的预付款提高了100倍以上，而游戏的零售价只上升了2到3倍，版税率与以往相同甚至更低。对于开发者来说，版税金已经成了一座可望而不可及的海市蜃楼。
　　
　　开发者是否永远只能默默无闻地扮演附庸的角色？比尔·罗珀等人的出走，与其说是对这一问题的解答，不如说是一种逃避。

RUP 的另一大特征是Use Case 驱动。Use Case是RUP方法论中一个非常重要的概念。简单地说，一个Use Case就是系统的一个功能。例如在一个基于电子商务的医疗系统中，病人可以坐在家里通过网上浏览器与医生约定看病的时间（Make appointment），这样，“Make appointment”就是系统的一个Use Case。在系统分析和系统设计中，Use Case被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是Use Case,然后以每个小的单元为对象进行开发。按照RUP, Use Case贯穿整个软件开发的生命周期。在商务需求分析中，客户或用户对Use Case进行描述，在系统分布和系统设计过程中，设计师对Use Case进行分析，在开发实现过程中，开发编程人员对Use Case进行实现，在测试过程中，测试人员对Use Case进行检验。

RUP的第三大特征是它强调软件开发是以构架为中心的。构架设计（Architectural Design）是系统设计的一个重要组成部分。在构架设计过程中，设计师(Architect)必须完成对技术和运行平台的选取，整个项目的基础框架（Framework）的设计，完成对公共组件的设计，如审计（Auditing）系统，日志（Log）系统，错误处理（Exception Handling）系统，安全（Security）系统等。设计师必须对系统的可扩展性（Extensibility），安全性（Security），可维护性（Maintainability），可延拓性（Scalability），可重用性（Reusability）和运行速度（Performance）提出可行的解决方案。

在RUP方法论中，不同的角色可以从不同的侧面来认识同一个项目。RUP定义了“4+1”个场景(View）：Use Case场景(Use Case View)，逻辑场景(Logic View)，进程场景(process View)，实现场景(Implementation View)和发布场景(Deployment View)。在Use Case场景中，客户和商务分析员对Use Case进行描述，在逻辑场景中，设计师对系统进行分析和设计，在进程场景中，设计师对系统可能出现的并发性，运行速度和分布特性进行描述。实现场景则反映了程序开发员开发实现的过程。发布场景是描述系统管理员和组装人员实施系统发布和管理的过程。值得强调的是，系统构架的设计是在逻辑场景中描述的。

RUP还定义了4个模型，即Use Case模型（Use Case Model），分析模型(Analysis Model)，设计模型(Design Model)和实现模型(Implementation Model)。Use Case模型包含Use Case Diagram和Use Case文档。Use Case模型是其他三个模型的基础，分析模型即是概念模型(Conceptual Model)，是系统分析所得到的结果，分析模型包含了类图(Class Diagram)，次序图(Sequence Diagram)以及活动图(Activity Diagram)。设计模型则是构架设计和系统设计的结果。当设计模型完成后，开发编程人员便可以进行编程了。设计模型主要包含了类图，次序图和状态图(State Chart Diagrams)。分析模型和设计模型看起来有许多相似之处，但两者的含义有本质的区别。分析模型强调的是问题的范围，但并不给出解决问题的方案，分析模型并不涉及具体的技术和平台。

例如它并不关心是否应用EJB或一般的JAVA BEANS，系统是安装在WebSphere或是在WebLogic。但是与之相反，设计模型要考虑这些细节，而且要提供解决这些问题的全部方案。当然设计模型是建立在分析模型之上的，分析模型中的一个类可直接映射成为设计模型中的类，但这种映射关系一般并不是一一对应的，最后一个模型是实现模型。实现模型包含构件图（Component Diagram），从这个模型出发，开发编程人员可以产生骨架源程序(Skeleton Source Code)，也可以从源程序出发更新设计模型。

目前应用于系统分析和设计的工具主要有Rational Rose和Together Software Center(TogetherJ)。JAVA和J2EE的开发工具有IBM Websphere Application Developer(WSAD), Borland Jbuilde和WebGain VisualCafe. WSAD和WebSphere Application Server应用在一起，使得服务器端的排错和系统的发布变得非常的容易。Jbuilder和VisualCafe一般与WebLogic Server紧密结合在一起。目前WebSphere Server和WebLogic Server占据了Application Server市场的66%，其中WebSphere Server占据了37%，成为同类产品的No.1。在单位测试和集成测试中，广泛应用的工具和框架有Junit, JunitPerf和Cactus.。

综上所述，软件开发的方法论已经成为现代软件工程过程中不可缺少的一个重要部分。是目前在Java/J2EE和面向对象的大型项目中广泛被采用的一种方法论。他对整个软件开发的生命周期提供了基础框架和指导。RUP, UML/Rational Rose, Java/J2EE, WSAD, Websphere Application Server和Oracle这样的技术、工具和平台的组合是目前许多公司、政府信息技术项目中采用的方案。因此，RUP的知识和经验也是现在求知是场所需求的热门技能。

　　英国诺丁汉大学的物种进化方面的基因学专家约翰•布鲁克菲尔德教授认为，对他而言，这个答案再明确不过了。他说，动物个体在出生之后，其体内的遗传物质是不会发生变化的。现代生物分子学说认为，是先有蛋中遗传物质的基因突变，才有鸡这个物种出现的可能。布鲁克菲尔德进一步解释说，第一只鸡先是包含在蛋中的一个胚胎，而那个胚胎的遗传基因与生出来的这只鸡的遗传基因是一样的；这也就是说，属于鸡这个物种的第一个成员肯定是一只含有鸡的遗传物质的蛋。

　　英国伦敦国王学院的哲学家大卫•帕皮诺从哲学的角度证明了布鲁克菲尔德的观点。他说：“种瓜得瓜，种豆得豆。说是袋鼠生下的蛋，结果蛋里孵出的却是鸵鸟，那么这枚蛋一定是鸵鸟产的，而不是袋鼠产的。”同样的道理，第一只鸡不可能是从其他种类动物所生的蛋中孵出来的。

　　英国一家禽养殖协会的主席查尔斯•博罗什说：“第一只鸡出生前，肯定是先有鸡蛋。当然，那些鸡蛋的样子可能和现在的蛋不一样。”

　　 在中国，技术以及技术人员缺乏社会地位，具有悠久的历史传统，自古就被斥为“奇技淫巧”，工匠（技术人员）在古代的地位非常低下； 而欧洲从几个世纪以前就非常重视科技了，各国都成立了皇家科学院，很多科学家拥有爵位，地位非常高。
　　
　　2、中国是个官本位的社会

　　 这导致了“唯官正确”的怪象，很多事情，当官的并不懂，但是他发表几句狗p不通的指示，人人都点头称是。我们在做项目的过程中这种事情屡见不鲜，领导的话不管对错，都跟圣旨一样，没人敢去怀疑和辩驳，其实也不是大家都傻到不明是非，而是辩驳只会给自己带来麻烦。
　　 但是如果某个技术人员发表一番见解，则会遭来诸多诘难，原因不是你说错了，而是因为你没权力，人家不怕你，每个人都敢辩驳你，不管他的观点多么荒谬。
　　
　　在这样一种氛围下，试问还有多少人有兴趣继续搞技术。
　　
　　3、中国几乎有无限的劳力供应
　　
　　在几大生产力要素中：土地、资本、劳力（在中国还要加上权力），资本最值钱（在中国也许是权力），而劳力最不值钱，原因在于中国几乎拥有无限的劳力供应，供大于求，价格当然下跌（也包括劳力的地位）；而资本是最紧缺的，供不应求，当然价格上涨（也包括资本家的地位）。
　　
　　当然有人会说高端技术人才并不多，甚至极度紧缺，这点我承认，但是我们当中（来此论坛的）有几个是紧缺的高端技术人才呢？99.99%的不都是普通技术人员嘛。
　　
　　4、缺乏支持技术创新的体制，缺乏良好的知识产权保护环境
　　
　　没有上述二者，请问还有多少技术人员有无穷的热忱投身于技术创新和发明创造？
　　
　　5、企业宁可去买技术，也不愿投入资金进行研发
　　
　　君不见上汽南汽抢着收购罗孚汽车，TCL收购阿尔卡特手机研发部门和飞利浦彩电研发部门，我们的政策是市场换技术，而不是加大研发投入自己搞技术。
　　
　　6、企业内的“政治”让技术人员心灰意冷
　　
　　大部分热衷于技术的人员在“政治”上都相当低能，这也不是他们笨，而是“一心不能二用”，满脑袋都琢磨的是技术，怎么可能天天去琢磨人，但是，企业里混得好的都是成天琢磨人的主。
　　
　　这也是为什么很多搞技术的都想自己去创业，没办法，实在受不了这种环境。但是在现在这个时代，没有足够的资金，仅靠几个人的小作坊很难成功。

　　不过我从不抱怨。内存就常常抱怨，抱怨他们主板部门的复杂，抱怨他如何跟新来的杂牌内存不兼容，网卡和电视卡又是如何的冲突。我的朋友不多，内存算一个。他很瘦的而我很胖，他动作很快，而我总是很慢。我们是一起来这台机器的，他总　　是不停地说，而我只是听,我从来不说。内存的头脑很简单，虽然英文名字叫memory，可是他什么memory都不会有，天大的事睡一 觉就能忘个精光。我不说，但我会记得所有的细节。他说我这样忧郁的人不适合作技术活，迟早要精神分裂。我笑笑，因为我相信自己的容量。
　　 
　　有时候我也很喜欢这份工作，简单，既不用象显示器那样一天到晚被老板盯着，也不用象光驱那样对付外面的光碟。只要和文件打交道就行了，无非是读读写写，很单纯安静的生活。
　　 
　　直到有一天......
　　 
　　我至今还记得那渐渐掀起的机箱的盖子，从缺口伸进来的光柱越来越宽，也越来越亮。 空气里弥漫着跳动的颗粒。那个时候，我看到了她。她是那么的纤细瘦弱， 银白的外壳一闪一闪的。浑身上下的做工都很精致光洁，让我不禁惭愧自己的粗笨。等到数据线把我们连在一起，我才缓过神来。开机的那一刹那，我感到了电流和平时的不同。后来内存曾经笑话我，说我们这里只要有新人来，电流都会不同的，
　　
　　
　　上次新内存来也是这样。我觉得他是胡扯。我尽量的保持镇定，显出一副很专业的样子，只是淡淡的向她问好并介绍工作环境。
　　 
　　慢慢的，我知道了，她，ibm-djsa220，是一个笔记本硬盘，在老板的朋友的笔记本里做事。这次来是为了复制一些文件。我们聊得很开心。她告诉我很多旅行的趣闻，告诉我坐飞机是怎么样的，坐汽车的颠簸又是如何的不同，给我看很多漂亮的照片、游记，还有一次她从桌子上掉下来的的历险故事。而我则卖弄各种网上下载来的故事和笑话。她笑得很开心。而我很惊讶自己可以说个不停。
　　 
　　一个早晨，开机后我看到数据线上空荡荡的插口。
　　 
　　她一共呆了7天。后来，我再也没有见过她。
　　 
　　我有点后悔没有交换电子邮件，也没能和她道别。不忙的时候，我会一个人怀念射进机箱的那股阳光。
　　 
　　我不知道记忆这个词是什么意思，我有的只是她留下的许多文件。我把它们排的整 整齐齐，放在我最常经过的地方。每次磁头从它们身上掠过，我都会感到一丝淡淡的惬意。
　　 
　　但我没有想到老板会要我删除这些文件。我想争辩还有足够的空间，但毫无用处。
　　
　　 秘密的地方，再把那里标志成坏扇区。不会有人来过问坏扇区。而那里，就成了我唯一的秘密，我常常去看他们，虽然从不作停留。
　　 
　　日子一天一天的重复，读取写入，读取写入...我以为永远都会这样继续下去，直到一天，老板要装xp却发现没有足够的空间。他发现了问题，想去修复那些坏扇区。我拒绝了。很快，

    我接到了新命令：格式化

　　我犹豫了很久
　　。。。
　　。。。
　　。。。
　　。。。
　　。。。
　　track 0 bad, disk unusable

　　深圳

　　从三级B证书开始

　　在93年毕业后我选择回到家乡——内地一个美丽的小城市里工作。非常幸运，我进入本地的一个政府机关，按照老一辈的说法，捧上了铁饭碗甚至金饭碗。工资每月不足1K大洋，但经常有人请客吃山珍海味，而且还显得威风凛凛。我浑浑噩噩地过了7年，到最后仍是个小职员。我是学经济的，但偏好玩计算机，除了完成打字开票据作报表的一些琐碎工作，大部分时间就是“不务正业”去研究计算机的原理以至最后辞职时除了考了个从来没用过的非专业计算机三级B证书外一无所成。有时想想觉得很无奈，谁叫当年念大学时选错了专业。好歹现在兴趣和专业是一致了。兴趣和毅力才是发展之本。

　　2000年底我满怀憧憬地来到这个让我向往已久的城市，IT的泡沫当时却已经沉到了水底。我终于在华强北找到了一家作安防产品的系统集成公司，同意试用期内最高工资4.5k/月接收。

　　这家系统集成公司的面试很简单，只是问了一些Delphi编程的简单知识，面试的L经理大概觉得我和他合得来，就同意我的要求，让我进来了。进来后我才发现，这个公司的R&D部门只有我和他两个人，主要业务是作工程的，R&D是作后勤配合的。

　　在这公司我的工作很简单，主要是用Delphi为引进的国外系统做点小的基于数据库的定制，这对我来说相当轻松。我的兴趣常在C++和Windows平台技术，大多时候我都把一个Delphi小应用做得很花俏，看得L经理眼花瞭乱。

　　与老板的首次暗战

　　在2001年春节，公司中了一个投标项目，为某某大公司作门禁系统二期，其中的软件部分是关键。老板急得跳，因为不能再定制了，要基于该硬件协议开发一整套软件并且要提供与该公司的Oracle数据库应用程序的接口；L经理暗地里跟我说不要管，因为老板一直不加他的工资，这事情如果我们接了累死累活也是白累，还不如找外面人来做。

　　于是老板找来一个台湾人做统领，还找来两个临时的打工仔做配合。台湾人带来一套好多年前他编的宝贝，扬言小case，会很快搞定新的Requirement，老板听了乐得嘴都合不拢。台湾人的价钱是每月三万，不给源码。L经理和我说，要是老板给3万我们，什么东西都会做出来还白送源码。

　　台湾人一直不肯让我们看到源码，躲得远远的修改他的代码。直到第一次现场集成测试，一大堆问题浮出了水面，有通讯上的, 有数据库上的，事情变得很紧急很糟糕，我立即建议和老板一起开会讨论下一步的解决方案，在会上我从容的谈了我的看法，并提出了一些应急措施，我用VC来写ODBC数据库接口及通信部分的代码，台湾人要把源码公开出来让我们一起解决等等。最后我的意见被采纳，第一次集成测试pass。我第一次看到台湾人的宝贝源码，乱七八糟得可以，到处是补丁硬编码，非常难于维护。

　　这次和台湾人的合作给我在2003年后在新加坡与香港人合作过程中的确有不少帮助。他们都和我一样，有着这或那的缺点，但都非常自信。

　　到二月中旬，我的3个月试用期转眼已过去一个月了, 但工资还是保持不动，老板老是推托事多没空和我讨论。我便和L经理商量转正工资的事，这是非常好的时机，我已经在这个项目里取得了主动权，L经理，台湾人和两个临时打工仔都会听我的，而软件演示定在3月中旬。L经理和我很快站在了一个立场上：立即加工资加配笔记本电脑。老板很恼火，但也不得不当夜从香港带了两台笔记本回来,并且打电话给我，工资调到6k，转正补差明天就办。L经理也加了一千每月，乐不可支。第一次和老板交手，我们赢了。

　　在我拿到的转正工资及一分钱不少的差额(补1 - 2月转正)时，工程部一个河北的小女孩正在伤心的哭泣，她进这个公司近6个月了才转正，可三个月差额不再补给她，相当于变成了6个月的试用期。她干得很辛苦，经常通宵达旦做标书，可连正眼都没一个，无情的老板。

　　第一个失败的项目

　　虽然我得到了我想要的位置，而3月份的项目演示还是失败了。我一直没有意识到这仅仅只是要作一个演示系统，然而我却过份沉溺于技术细节以至于最后根本连最基本的东西没有做完调试好。演示时出了大量的问题，很令人沮丧的结果。L经理和我一样缺乏经验。我有点伤感但很快平衡了——我不比专业人员差。

　　在随后的1年多，老板开始重视软件开发这一块，同意我和L经理的建议，我成为了这家公司的软件经理，L经理是硬件经理，由我招兵买马，一时我们的队伍达到8人之多。

　　随着我对MFC/ATL的逐渐熟悉，我开始在队伍中推动使用VC加基于COM/DCOM/COM+的中间件与分布式技术，在工作分配上，我把接口用IDL写好，按照联系紧密程度进行划分；而L经理不熟悉这些东西，他就象他说的已经没有动力再学新的东西，一直没有技术上的进一步发展，他感到会被逐渐淡化出局的压力，我们之间不时出现争吵，距离越来越大。

　　2001一年下来，我写了不下4万行的C++代码，但却始终离一个真正监控平台—老板的想法—很远。这只是国内一家很小的系统集成商，没有任何软件开发的经验和积累，我感觉到自已能力有限，有负老板重托，我再一次走到了发展的尽头。做软件不仅仅是写代码。我越来越想到一家真正的软件公司去学习新的东西。

　　由深圳到香港

　　我从来没想过会去一个新加坡软件公司工作。当我2002年7月第一次来到这个公司面试时，在做完C++/VB/COM/IQ等一系列试题后，两个穿得整整齐齐的小伙子面试我：你的得分很高，多谢夸奖，你介意加班吗？我说不，相反我喜欢，你有什么缺点？我想了一下，哦，有，晚上加班后第二天会起不来。对不起，能问一下你们公司是哪的吗？新加坡的一家上市企业的下属软件公司。同意我的8K试用期工资吗?没问题。就这样我进来了。

　　新加坡上市公司

　　我初进这家公司的身份是开发人员，感觉很新鲜。首先项目都大得我从来没见过，动则上亿。其次所有的项目都是香港或国外的，所有的文档包括Email都是英文的，后来我才知道，虽然新加坡人会讲国语，但却斗大的中文认不到半罗筐。我的英文不好，但很快也习惯了。多亏中国的英语教育体系，学了十多年，虽然半句英文都难出口，象聋子哑巴，但开着金山词霸写英文俺还是能凑合凑合。另外一个现象，几乎所有的人都象是工作狂，每天到晚上20:00公司还是坐满了人。难道新加坡公司都这么敬业？

　　这儿的阶层划分非常不明显，人和人之间的关系比较平和，所谓的Team Leader都和我一样要参与编码测试，所有人都是直呼其名，对老板或董事长也不例外。老板是个新加坡人，其实也是个打工仔，相当于新加坡外派到深圳的经理。他绝大部分时间和我们在一起，基本上只管项目进度和与新加坡或客户联络，有时也会参与需求分析，他对软件开发的了解显然比原来公司的老板要高出很多个数量级。但是他却很扣门儿，连一起和大家出去吃快餐也是AA制，每人10元不等，而他一个月差不多有3万新币，相当于15万人民币的收入，年底还有分红。不过说实话，我还喜欢这样的工作氛围。觉得象是在做事，求发展吧。

　　闻所未闻的大项目

　　试用期里我还呆在深圳，我最初参与的是两个基于J2EE的解决方案的演示项目，演示地点在香港，一个V项目，一个B项目。招标总金额都在几个亿以上。Demo项目周期刚好是3个月。开发的流程大体相同，每个项目差不多6个人，确定了总体框架后，把要交待的功能点列出来，分配到各个人手里，每隔几天集成一次，即所谓的Iterative development。每个iteration结束都会完成一部分功能。

　　V项目中我只是参与了一个次要功能的定制，是一个基于Windows的中文字体制作和输入法的扩展的解决方案，我通过配合一个COM+服务器，在客户端用代码插入技术把一个Windows上的已有的一个桌面应用变成了一个分布式程序，解决得很漂亮，大部分的功能都不用写了。在做完V项目后项目组中3个人即去了新加坡。剩下三个包括我加上另外三个开发人员转入B项目的开发，由于V项目里我表现出色，B项目里我开始负责主要的应用服务器逻辑。

　　B项目和印度第二大的软件公司合作，我们负责移动通信和调派部分，他们负责SAP的安装和定制。我们还要负责开发和他们的接口。

　　我在这里首先学会的是如何快速开发一个Demo系统。在两个月内想作完一个价值数亿的项目是不可能的，“没关系，把数据库当内存使用，只要你能正确快速地实现功能”，我的Team Leader这样告诉我。在这个指导下，虽然我几乎没有用过Java,也在几个星期内完成了要求的Demo应用服务器逻辑层设计。效率低点，500毫秒吗?够了，远远满足Demo的需要了，千万不要钻到技术的牛角尖里，时时想着自已在为谁作，要作什么，记往我们卖的不是自已的技术而是用户需要的功能。这的确是非常非常重要，如果再要我回到2001年重作当时那个标，我肯定能拿下。

　　我们在十月底到了香港做最后的与SAP的集成测试。印度公司出的是一帮10来个黑不溜秋的印度人，叽哩咕噜不知说的是什么英语，我基本一句听不懂。情况十分糟糕，接口存在大量的差异，我们给他们的XML他们居然不懂如何处理，他们一大帮人居然没一个会Coding!他们要求全部改成标准的文本文件来交换信息，但是又不知道如何控制多进程读写冲突，流程几乎无法进行下去，我简直无法相信这是SAP的水准。我们原来的工作必须要做很大的改变，我们必须去适应他们。这次的教训为我在两年后设计一个雷达系统的接口时积累了宝贵的经验。

　　能压死人的压力

　　刚进公司时，同事和我说，在香港工作压力很大，不是人过的日子，我还很难想象，直到这时才真正体味到。印度人在不断的报怨以显示他们Ready了很久，听着他们的嘟囔经常会有种要跳过去扁他们一顿的冲动。我们的处境非常糟糕，天天有一大帮经理们在耳边催，好了没好了没；催得人脑袋一片空白。幸亏有老板在，他白天组织与SAP的集成测试，开会和印度人讨论最后的接口，晚上参与我们的修改，负责逐一检查每个逻辑的正确性。在最后演示的那一个星期里大家平均每天睡不到3小时。星期五Demo日晚通宵旦，好歹pass过了，在调试完毕后，一早7点钟即到会场安排布置。演示开始时，我已经处于半梦半醒状态，坐着坐着头就会坠下，迷迷糊糊听着老板在谈笑风生向客户介绍我们的Demo系统，超人!

　　B项目结束，我转正了，工资升到了10K。我的Team Leader对我的技术打了个很高的分，但对我参与的Leadership(领导精神)给分很低。我奇怪，我不是Leader为何要给我评Leadership? 老板告诉我，Leadership是说不要只表现你这一块，系统是个整体，任何一部分好不等于全都好；不是每个Leader都是神，每个人都要挑起leader的责任。这话我一直牢记在心。在1年后我带队做项目时，我也会要求每个人不仅只是关心他的部分，也要关心整个项目；项目是每个人的，不是项目经理或Team Leader一个人的；每个人都得负起这个责任来。这就是Leadership!

　　由香港到新加坡

　　2003年初，当我第一次踏入新加坡时，感觉非常好，干净清爽的城市，人都那么彬彬有礼，巴士上一丁点不拥挤。我会在这里生活半年，太好了。

　　但是项目的内容却不象我想象那样是全新的项目可任我发挥，那是一个已经完成并投入使用了的项目M，客户在香港。我过来的任务是熟悉别人做好的系统，在新加坡人的领导下做一次半年一期的维护工作，然后再将维护工作再带回深圳做。

　　印度同事

　　我被安排在一个大约30个平方的房间里，房间名字就是项目名字M。没有窗户，看上去更象个仓库。放了十来台电脑，都是三年前的古董，跑着NT4/Win98这样的操作系统，M项目的全部软件也装在上面。

　　和我搭挡的新同事是一个叫宾杜的印度妇女，大约30出头，黑黑的，总穿着印度人的长外套，有时还会在脖上挂一条长长的围巾，我很少看到她。她在这个项目里已经3年了，主要作coding。她只和我同事了两个月不到便辞职而去，我后来也能体会到为什么她会辞职—这个项目要么搞掂它，要么被耗死在里面，她不能作到第一点，也不甘心最后一点，只好走中间道路。她是这个项目里最后一个Developer(开发人员)，她的情形其实和我类似—都不是新加坡本地人，薪资也和我差不多，连补贴加起来不足3k新币。我从她那里接过了整个M项目，大约几十万行VB代码的维护工作。

　　接交工作基本上等于把代码从一台机拷贝到另一台机上，我在初到新加坡的两个月里除了Setup了一个M系统在我的Notebook上，几乎什么事也没做。即使时不时香港那方发来一些要Fix的Bugs，也大多推到6月的Release包里一起解决。宾杜大多时候也没事儿，经常看她在学习C++与Java或和她的小女儿褒电话粥。

　　新加坡生活

　　新加坡的工作非常轻松，完全不象深圳和香港的风格。按要求是早上8:30上班，8:30到9:00是早餐时间，实际上很多人10点还没见踪影。没有打卡，全靠自觉。中午12:00到下午1点是午餐时间，有钱的新加坡人喜欢一帮人开车出去，在很远的餐馆里吃，吃完后坐着喝冷饮聊天，经常聊到两点才回来。下午4：00到4：30是下午茶时间,有的人趁这个时间换上运动装，出去跑一圈步锻炼身体。6:00准时下班。周末假日雷都打不掉，一定会在家休息。我这才理解去年做香港的演示项目时新加坡人的工作态度。当时都已经到火烧眉毛了，星期五下午5:30,新加坡这边的领导还在叫叫嚷嚷，但一过6:00就找不到人了；第二天我们仍在加班，可新加坡这边一个人也看不到。我终于有个结论，新加坡的工作狂全派深圳和香港去了。

　　这里吃的很杂，马来，印度，香港，福建风味或西餐，但变化很少，好象总共只有几个模子，而几乎每家店铺的菜都是从其中一个里造出来。新加坡管大排档叫巴沙(马来语)。每个巴沙结构都差不多：每种风味各有一个私人铺档，吃饭的地方是公共的，有专门的人，一般是马来人收拾餐桌。巴沙比较便宜，一个人一顿在2-5个新元内就可以吃饱了。而餐馆点菜比较贵，一般一个菜也要10个新元(50元人民币)左右。相比起来，麦当劳、肯得基这样的店在新加坡算贵的了，一顿至少要6元（30人民币左右），而在香港，MacDonald与KFC是最平的快餐，和大陆是一样的价。新加坡人不喜欢在家做饭，大概是怕油烟，都会跑出来吃；去新加坡人的家里，经常看到房子买了好多年，厨房和厨具还是崭新的。所以在这里巴沙是最普遍的。虽然是岛国，新加坡本地大部分食品来自进口，新鲜的海味都非常贵，难怪老板在深圳那么爱吃海鲜。在新加坡呆久了，让我最想念的便是吃一顿四川麻辣火锅。

　　我开始有这样的感觉：什么叫发达国家？就是发达到已经没有什么发展了的国家。就象新加坡很多的建筑都是十几年前都建好，每年新建改建的相当少。楼价在下跌，下跌了好几倍，经济不景气，很多人从公寓搬出来搬到政府组屋里住。一些新加坡人则很想到中国来工作，我问他们中国哪里好？他们告诉我上海。2003年上半年正值SARS其间，节假日商店里都很少人，连往日很热闹的体育馆游泳池都空荡荡的，除了在门口量体温的几个工作人员外，几乎没什么人。

　　会“死”在里面的项目

　　在宾杜辞职之后，只剩下我一个人在这个大房间里，偶尔才会有个新加坡人进来这个房间和我讨论将要做或正在做的事情。他们显然对我不在意—一个Developer而已。无论是和香港客户的会议还是内部的会议，都没有让我参与。我只知道在6月份会去香港客户那里做Release前的调试工作，平常自已安排时间对付那些发过来的bug。到最后我甚至不知道究竟目前M项目组中有多少人。可能只有一点是肯定的，只有我一个Developer。每次香港发过来新的问题，那帮新加坡M项目组的人就会开一次会议，想必除了聊天的主题外，估计就是七嘴八舌猜测症结可能出在什么地方。也许他们太高层了，以至于没人愿意看代码。

　　事实上,那一大堆VB代码上很让人头疼。它是一大批人做过的结果。一个函数能长达上千行，打满了补丁，到处是交叉引用莫明其妙的全局变量，面对这么混乱的代码笨蛋都想得到根本是没什么设计文档可言。M项目组中有人认为我对整个项目的需求非常不清楚，还专门给我上过近一个钟很严厉的课，我还在想他们是不是在暗示我懂需求就会看懂那代码吧?!直到今天我都还没法读懂那些代码，没完全搞懂M项目中每一个详细的需求。我只是见招拆招，针对每个要修补的问题来做事—医治一只手指上的伤，犯得着把整个人体研究个遍?两个月差不多解决了30-40个bug后，6月份我飞到香港呆了两个星期，和香港子公司同事一起作回归测试，按计划，轻松地交出了第一次Release。

　　我还不能回深圳，在香港子公司的测试安装人员把应用程序deploy到客户的几百台移动客户端上之前，我还得在新加坡作最后1个月的技术支持。从香港再次回到新加坡后，我开始直接和香港测试人员联系而不再需要M项目组作传话筒。

　　补丁加补丁还是其他

　　7月的前三个星期一点问题都没有，在最后的一个星期4却突然发过来一个特殊的需求，是一个传真的中文支持问题。非常关键的问题，如果不解决的话，整个的Release就不会得到客户的认可。我花一天时间测试，发现牵涉的地方相当多；要做大手术才能根本解决问题。而香港的执行经理Tim不同意动大手术，坚持用补丁上加补丁的方法解决—那样会比较保险，但会出现拆东墙补西墙的问题。按日程我每天都得不断提交测试版本，要在下星期三前让东墙西墙都得到照顾。

　　我估计了一下时间后，认为补丁上加补丁风险更大，于是在没有通知香港方面的情况下，在周末作了较大范围的修改。星期一，我按要求提交了测试版本，香港那边发现了很多新问题，比原来发过来的要多一倍—这是在我看来是很正常的，动大手术的结果，但仍很有信心。Tim开始叫嚷起来，我只是跟他说“Trust me”。星期二早上我又例行提交了一个版本，返回还是一大堆问题，Tim坐不住了，打电话到了新加坡M项目组的陈老板大骂我不听话。将近中午时间，我发出了来新加坡这半年来最后一个修补版本。吃完午饭回来，收到香港Test Bed那边发回的结果，所有问题都Ok。我随即向陈老板和Tim转发了这份Email。哈，我赢了。星期四，Tim发回信件再次确认我的所有工作都完成。陈老板亲自请我吃临别饭，称赞我Creative。那个周末我终于返回了告别已久的深圳。

　　这最后的一次和Tim的较量让我开始在这家公司得到了真正的重视。8月底老板交给我一个Demo项目，由我为首带了两个新人作。客户是新加坡民防部门。时间非常短，只有不足3个星期时间。发挥的机会来了。我选用了MSMQ为中间件，我作通信和COM接口部分，由两位同事分别作客端和服务器端逻辑部分。开发工具主要用VB，GIS部分复用了我在M项目里作的一个组件。此时我对这种分布系统的快速开发的过程已非常熟悉。曾经被我瞧不起的VB现在看来实在是个快速建原型的好工具，两个星期我们就推出了两个版本。9月中旬，我带着两个同事再次回到新加坡，非常轻松的完成了一次成功的Demo。一个月后，新加坡同事告诉我，这个项目已经接下来了，Demo效果非常好。

　　此时的新加坡对我除了沉闷无聊外已经没有其它感觉，在接下一个游戏引擎项目里呆不到三个月，我就坚决要求返回深圳。12月底，我被安排到香港的一个6个亿的T项目里作System Testing(系统测试)。

　　新加坡到香港

　　香港这个T项目是由深圳公司从2001年就开始开发的。开发人员多达30多人，连设计测试管理人员一起加起来不下100多人。曲曲折折已经开发3年多了，现在进入最后的测试阶段。我被安排常驻香港，任务是对系统的效率，稳定性进行测试并给出解决方案。

　　Team Leader

　　我初进便是Team Leader的身份，带的几个T项目里的老资格的开发人员一起作System Testing。这对我非常不利。因为我对整个系统的需求非常不熟，我也不能再用见招拆招的策略，因为Testing的第一要事便是熟悉需求。现在的需求文档堆起来可以有几米高，我光去读它就要读上半年，还能作什么事呢!?

　　从新加坡回到香港，大都会觉得香港破旧和脏乱。但香港人的敬业精神却远远超过了新加坡人。项目作了三年，很多新加坡人或深圳人都觉得如嚼干蜡，唯有香港这边的员工仍是乐此不疲，每人每天都处于高度运转状态。我虽初进此项目，却没有新鲜感；好几天都没有任何的进展，也不知道从何干起。香港的项目经理每天都会要求Update Status(汇报工作进度)，压力很大。

　　测试工具

　　这里有个北欧人，是Technical Consultant身份，他将要被安排到其它的项目里去。我的一项任务便是要接替他的工作。我几乎花了两个星期研究他现在的System Testing的方案后才把焦点集中到自动测试的工具上。

　　我的目标要在带有500台客户端，200个并发连接的情形中连续测试，以证明我们的软件可以稳定快速的运行X天，达到预期的目标。自动测试工具是必不可少的。WinRunner 和Rational 公司的Robot是常见的大型软件测试工具，但却在这个项目里使不上劲来。首先是两样工具都庞大缓慢，测试里经常发现连测试工具和测试对象一起死掉。其次，这么大的一个项目在设计时居然没有考虑为测试专门留接口，很多情况下要玩技巧来判断应用程序当前的状态和下一步鼠标键盘的动作。第三是这两种软件都比较贵，而公司目前只为WinRunner买了4套License，对近五百台要测试的机器来说无异于杯水车薪。

　　北欧人推荐了一款小共享软件，Automate4.5，一瘸一拐可以走一两个流程自动化。我仔细的分析了一下它的风险，除了是现成的软件外，其它没一点好。一是太邪门儿，自动记录的脚本是一堆看不懂的乱码，没法修改编辑，只能重新记录。(在5.0以后它已改用XML。)二是功能虽广泛但界面处理这块太弱，10%的要求都达不到。三是数据和流程混在一起，没法应用大量不同数据进行测试。更糟的是(1)和(3)结合在一起，哪怕只要我们的应用界面上有一个控件的Tab顺序调换一下，我都得重写整个流程的脚本代码。如果用这个软件作System Testing, 我以后都别想出来了——死定了。

　　我还是要试一试

　　我对Windows平台技术相当熟悉，很有信心在一个月内完成一个比Automate 4.5更好更适合于现在的系统测试要求的自动化工具。于是我把想法发到项目经理那里。他很担心，北欧人是个权威，我说的也有道理。我让他给我一个星期时间来测证我的想法，他同意了。

　　一星期后，我的原型出来了，其实是一套COM组件服务外加一个脚本容器。首先使用的是那个北欧人，在我的配合下，他试了两个钟头，用VBScript重写了原来他用Automate 4.5作的两个流程，是一模一样的效果。他非常满意，数据流程分开了，脚本语言是常用的VBScript, 功能扩展很容易，挂入动态库就可以。于是我从项目经理那得到了一个月的开发时间。

　　经过一个月艰苦的开发工作，好歹自动化工具终于完成。我带了一个熟悉需求的开发人员一起又花了两天，作了第一套System Testing的自动化测试流程的脚本。当天，我们作了一次简单的Demo, 所有人评价都是: So Impressive! 这是他们三年来第一次看整个复杂的流程被自动化运转起来了。

　　2004年5月份职位变动，老板宣布了最新公司最高领导层人员名单，其中一个就是我。

　　对程序员职业的思考

　　很多人认为程序员是一种吃青春饭的职业，其实这只是一种误解，或者说他们根本没有深入程序员的生活和工作，只是肤浅的接触了软件开发领域的表象，渴望迅速成功，却不愿意付出艰辛的努力，这种努力不是熬几个夜就可以的，而是应该是持之以恒的。回想起在新加坡孤独的日子，在香港挑灯奋战的日子，我始终没有放弃，我相信自己能够闯出一片天地，我想给年轻的朋友们一点忠告，也可以说是我个人对实现职业规划的几点看法：

　　1. 工作要主动。你的领导和你其实一样，经常不能确定下一步将要做什么才是对的，你要积极主动地考虑你应当如何开展下一步的工作。

　　2. 把自已放在更高的位置上去考虑工作，如果你是Developer, 就要至少站在Designer的立场上。不但要想到自已的工作，也要想到别人的工作，想到对整个工作组与项目的影响，想到今后的变化如何应付。

　　3. 了解，相信和展示自已。相信自已要落在实处，而不是象阿Q式的精神胜利法。了解自已是前提，想方设法把自已的擅长与能力充分地应用和体现到每个工作中去。

　　4. 认真负责做好每一件事，否则就不要做，切忌用混日子，消极的方式处理。

　　5. 多和你的领导与周围同事沟通，了解他们的情况，尽可能的帮助他们。

　　6. 要不断学习新的技术，开阔自已的眼界，提高自已的内在素质。这是个基础条件。没有内在的提高就没有能压倒的优势和正确的判断力。

　　也许你会说这些都是老生常谈，这些我都知道，但知易行难，贵在持之以恒。

作者: 爵士
时间: 2004-08-03
出处: 天极网

　　程序员处于技术成长历程的最下端。他们需要熟练掌握各种语言技巧，知道技巧适用性，还要对资源作出最恰当安排。

　　第2层：系统分析师

　　系统分析师是抽象模型的建立者，他们需要专业的概念模型知识和基础编程技巧。杰出的系统分析师会利用编程技巧来辅助建立概念模型。

　　第3层：系统设计师

　　系统设计师应当对“系统结构”所使用的软件技术非常了解。如果自身具备良好编程技巧，才会成为优秀的系统设计师。系统设计师的职责是把结构模型对应到实现模型，作用非常重要。在从概念到实现期间规划和组合模型的优劣是决定系统设计师好坏的标准。

　　第6层：架构设计师

　　架构设计师是程序员的最终归属，也是成长链中最“硬”的一环。架构设计师对整个项目的贡献非常大。架构设计师彻底摆脱了语言的束缚，身兼数家之长，熟悉很多语言的精髓；同时知道软件发展趋势，会开发新一代产品或制订新一代产品的方案，了解各种软件产品的特性，会根据这些特性做出非常好的产品。另外，杰出的架构设计师一定要具有杰出的创新能力。

　　第5层：产品经理

　　产品经理必须具有产品管理能力。这是一项非常重要的技能，产品经理需要融合技术和市场趋势，知道未来市场需要什么，使开发的产品实现技术和市场上的引导作用，他们还要快速学习技术，并融合起来做很好的演示。

　　第4层：项目经理

　　项目经理必须具备较强的专业知识，具备沟通技巧，了解团队人员的组成，还需要知道如何对团队分工，学会根据项目特性选择最适合的语言和工具，不能有任何偏执。

来源：sina