在最近两年的软件外包的狂热中，美国公司将印度选择成主要的外包国家。所有的软件公司几乎无一例外地到印度开设软件基地。而在印度的各个城市中，Bangalore尤其受到青睐，号称是印度的硅谷。据称，Bangalore的自然环境很好，又聚集了大量的软件开发人员。所以美国的软件公司都争先恐后地到这里设立开发基地。这颇有些当年加州淘金的味道。 美国公司在Bangalore办软件开发基地的原因当然是利用当地的廉价的软件开发人员。美国的媒体也争先恐后地竞相报导当地软件工程师多么地有竞争力，而美国的软件工程师的成本则相对过高。所有的人只看成本，其它的因素似乎都不必考虑。仿佛美国的经济衰退都是因为美国工作人员工资过高造成。把工作移到印度成了解决经济问题的灵丹妙药。在这个背景下，几乎听不见不同的观点。既使那些到印度考察过的美国公司的高级管理人员们也只说好的一面，而闭口不谈另外一面。这就如同当年的互联网公司股票高涨时，没人提公司财务状况，而只看公司的未来美好前景。就好像明天就能实现共产主义一样。 软件外包当然是好事。它能使公司更加有竞争力。但是，软件外包不能不加分析地进行。有些工作可以这么作，有些就不能。这个题目是一个可以讨论的大题目，在这里就不在多谈了。 软件外包的热潮引起了人们对印度的好奇， 特别是所谓的印度硅谷 Bangalore。居住在达拉斯的干城海先生现在工作于通讯公司Alcatel。 他今年七月份到Bangalore出差。在出差期间，他将他在Bangalore的所见所闻以一系列的email寄给在美国的朋友。他的记述截然不同与一般媒体对Bangalore的报导。他从个人角度而不是公司的角度来观察Bangalore。他的文章揭示了印度硅谷的另一面。 他的细致的观察和幽默的笔法使他的文章非常吸引人。他的email被转发后，引起了巨大的反响。很多人来信鼓励。也有人表达不同意见。FoneFtwo.com在征得干城海先生的同意之后，将他的原文译成中文以餐读者。我们将在FoneFtwo.com陆续发表他的系列文章。 http://www.foneftwo.com 

在RCP开发部门,印度人占大多数,剩下的是美国人和中国人。我进RCP不久,就发现这里的中国人都是从中国名牌大学出来的。这些大学包括华南理工学院,山东大学,清华,上海交大,科大,人大和南京大学。这给我的印象挺深的。心想i2既然能雇到这些人,这说明i2不是一般的软件公司。后来在i2工作的两年多的时间里,这些中国同事的工作成绩证实了我的最初印象。他们不禁业务出色，而且还是优秀的team players。能与他们共事两年多的时间，我始终认为自己挺幸运的。 RCP尽管是由印度人发起的,但其核心的相当一部分都是由中国人后来写的。RCP的初始时期,软件的运行速度极差。RCP的客户都是Fortune 500的公司。需要处理的数据量极大。RCP的速度远远不能在规定的时间里处理完所有的数据。很多客户都向i2抱怨此事。RCP的管理人员也为此感到很头痛。我刚进RCP的时候,RCP的大老板还跟我谈到这个问题。在这方面作出突破的就是RCP部门的一个中国同事。他采用了一个produce/consumer的设计模式,把过去的直线性的数据输入改成了阶梯性的数据输入。一下把数据的输入速度提高了几倍。自此以后,RCP的速度远远领先于竞争对手的产品。i2在与竞争对手竟标时,RCP的速度永远是i2产品的一个主要selling point。由於这个同事的出色的工作能力,在RCP部门里的绝大部分人被解雇后,他仍然被留下继续在i2工作。但他不满i2对RCP产品和开发人员的处理,自己辞职离开了i2。 在RCP工作时的一个特点就是频繁的release。在2002年的第一个季度里,我们是一个月一个release。而且每个release的客户都是大客户。这样快的开发速度,不可避免地产生许多问题。RCP管理人员最怕的就是在release的前几天发现产品问题。比这更恐怖的是不知道问题的原因在哪里。在这么短的时间内,基本上没有什么回旋的余地。在这个时候,RCP的老板们第一个想到的总是我们组里的一个中国同事。凡是交给他研究的问题,从来就没有他找不出答案的。 而且总是能及时地找出答案,不管问题出在RCP自己的产品里,还是在third party的产品里。在这方面,RCP的管理人员对他有绝对的信心。 在RCP部门，中国人除了作开发以外，在管理人员里也占有一定比例。而且在i2最初几次的裁员中，因为中国人被裁得少，所以比例越来越高。这在开发人员和管理人员里都是如此。中国人之所以被裁得少，原因很简单。就是工作成绩好。在RCP的中国管理人员中，有两个人值得一提。一个是QA 的manager杜珏，另外一个是开发的 director苏力。 杜珏于2000年初被招进RCP作QA的manager。在杜珏来之前，RCP的QA作的一塌糊涂。这当然也不能完全是QA的责任。开发部门总是不能按时完成任务。这直接影响了QA的工作。QA发现了bug之后，开发部门又不能及时解决问题，所以拖到最后，总是QA倒酶。在杜珏来之前，前一任的manager坚决要求调走。杜珏接管QA之后，带着一帮人玩儿命地干。在频繁的release的情况下, 不仅按时完成产品的测试工作，而且还改进了测试过程。RCP的测试过程变得非常有效。由於RCP QA 的出色的工作成绩，杜珏带领的QA小组被i2授予2002年第一季度的顾客满意奖(Customer Satisfaction Award)。 在i2的中国管理人员中，最有特色的恐怕是苏力了。苏力是国内1977年的大学生。很早就来到美国。先在明尼苏达，后来到达拉斯工作。1999年初被雇到i2作负责开发的manager。 苏力刚进RCP时，并没有管理RCP的核心部分。只是管理RCP的一个衍生的产品。在当时RCP的总体产品质量不好的时候，苏力带领的小组开发的产品质量却非常稳定。当时RCP在迅速发展，产品质量急需改进。RCP的管理部门从外面雇了一个美国人manager来管RCP的核心部分的开发。在一个重要的release 之前，RCP的核心部分的bug一大堆。但解决的速度极慢。眼看着就要错过release的期限。RCP的大老板没办法，只好让苏力接手。苏力接管后，马上分派人解决发现的问题。他还密切监视问题的解决速度，及时调整人力。最后在release之前，把所有的bug都解决掉了。自此以后，苏力就一直在管着RCP核心部分的开发。后来因为工作成绩出色，被提升为director。 我一进i2就被分配到苏力的小组工作。自此以后在两年零八个月的时间里，我一直跟着苏力工作，直到我们一起被i2裁掉。我刚开始时作开发，对苏力的管理方面的事了解不多。我参与管理工作后，与苏力在这方面的合作更加密切，这才对苏力有了更多的了解。我逐渐发现苏力是个很好的老板。 在开发管理方面，苏力是个很好的manager。他自己以前就是干技术出身，所以对开发的过程非常了解。RCP初始时，管理混乱。产品管理部门同开发部门职责不分。产品管理部门经常在产品作到快要release的时候提出新的要求，而且还以客户的名义压迫开发部门接受新的要求。这造成了产品开发的延期。产品管理部门和开发部门因此互相指责。苏力接管后，利用开发过程的金三角理论(cost, time, scope)，同产品管理部门讨价还价。每当产品管理部门提出新的要求，苏力就要他们或者增加开发人员，或者延期，或者减少别的开发内容。逼着产品管理部门将每个release的开发内容定得合理。几次交锋后，产品管理部门再也不轻易提要求了。这给开发部门省了很多麻烦。 在美国公司里，讲究忠诚(loyalty)。但一般地都是指下属对上司的忠诚。苏力也有loyalty。但他的loyalty是对下属的。他不仅有loyalty。而且是极其地loyal。假如苏力的下属同别人有争执，苏力永远是站在自己下属的一方。这些还算是小的。在大的方面，有的中国同事进i2时的工资偏低，苏力尽自己所能把他们的工资长上来。在i2后来一批又一批地裁员时，苏力每次都是尽力保护自己的下属。能保下来的就保。不能保下来的就尽量转到i2的别的部门。当苏力自己被裁时， 他还恳求我们的大老板留下我们部门一个没有身份的中国同事。在我们被解雇之后，一起找工作时，苏力还想着如何自己找到工作后，把那些尚未找到工作的下属招过来。 http://www.foneftwo.com 

2001年12月,我被提升为Senior Project Manager.在我现有的责任之外,又让我管理PSR小组. PSR的意思是Performance, Scalability, Reliability.这个小组的任务是保证RCP产品在这个方面的质量.在每个release之前,PSR小组都要对这个release进行测试.发现有关的问题并和开发人员解决这方面的问题. 我在接手PSR之前,对这个小组了解并不多.只知道有这么一个小组.但并不了解他们的具体工作和他们的工作效果如何.只是在RCP manager们开会的时候,看见那个小组的manager整天讲他们今天又作了几个testing script.我后来才知道,一个PSR工程师一天能作几十个那种script. 在上任的第二天,我去见小组里的每一个工程师.这才知道这个小组有五个工程师.其中一个人笑着跟我说:”你是PSR小组一年半的时间里的第四个头儿.”我一听这话,顿觉不妙.在进一步了解情况后,才发现这个小组的工作情况很糟.当时RCP的一个主要release已经出去一个月了.但这个小组依然在测试那个release.而且还不知道什么时候才能测试完.更糟糕的是,2002年的第一个季度, RCP马上有三个重要的release.基本上是一个月一个.而且每个release的客户都是大客户.令人吃惊的是,三个PSR项目的scope还不知道.我简直不能相信我听到的话.难怪这儿的头儿换得跟走马灯似的. 我马上召集有关人员开会.把产品管理和开发部门的大头儿都找来.首先把三个要作的PSR项目的scope和预计的时间表定下来.在scope定下来之后,我发现这些项目还是不能在预计的时间内完成.我於是和小组里的工程师们谈,了解有什么可以改进的地方.经过了解,发现有三个方面有很大的改进. (1), RCP的两个主要的板块之一的开发进展缓慢.有关的部门在解决PSR问题时非常拖沓.经常耽误整个的PSR的工作. (2) PSR的测试范围不合理.PSR测试作得象是funtional测试.不必要的地方也被反复测试.我们的测试的script多得连我们用的LoadRunner都难应付. (3) 需要测试的平台太多. 针对以上问题,我们提出了解决方案.在RCP的管理人员会上,我提出把RCP的两个板块的PSR测试分开进行.由於开发部门的拖沓而造成的PSR工作的延迟应由有关的贻d发部门负责.第二,我们同产品管理重新讨论了测试范围.删掉不必要的部分.使测试范围更加合理.这大大地缩短了测试周期.第三,我们把需要测试的平台作了prioritization.侧重于客户需要的平台.在这一两个平台上发现问题. 2002年的第一个季度是非常紧张的一个季度.我们除了专注于这些release的测试之外,还要应付其它各种各样的问题.小组里的一个印度穆斯林参加了i2的M2I(Move to India)计划.回到印度后继续为i2工作.但在第一个季度,他到麦加朝圣了一个月.我们的另外一个主要工程师在此期间还休假了一个星期. 尽管如此,我们还是克服了种种困难,在每个release之前,完成了PSR工作.在第二个季度,我们又进一步改进测试过程.我们还与有关部门进行合作,极大地提高了RCP的运行速度.RCP在与竞争对手竞争时,RCP的运行速度永远是远远领先于竞争对手.与此同时,我们还积极地进行有关的工作,包括在i2内部进行知识交流,宣传我们的PSR的经验.我们还积极地筹备同一个作server的主要vendor共同进行RCP的benchmarking测试,以此来作市场宣传. 好景不长,就在我们积极地进行这些工作时,i2的状况每况愈下.i2一方面积极进行M2I,另一方面又在美国不断裁员.2003年8月,RCP开发部门被彻底解散了.一小部分人留下收拾残局,产品转移到印度.其它人另谋出路.具有讽刺意味的是,就在我被裁以后,i2给各个部门颁发所谓的顾客满意奖(Customer Satisfaction Award).我所领导的PSR小组被授予这个奖.我的名字列在第一位.我一看这个奖,哭笑不得.心想:”这他妈的不跟追认烈士一样吗?” http://www.foneftwo.com 

在RCP最红火的时候，开发人员的一项主要任务就是招人。当时市场上对RCP的需求非常高，客户需要开发许多新的功能，而现有的RCP开发人员的数量不够。尽管每个人都在紧张地工作，但还是不能及时地满足客户的需要。所以，招收合格的开发人员就成为RCP部门的一项主要任务。i2当时有得是钱，不怕花钱，就怕招不到合格的人。为了鼓励大家积极参与这项工作，i2定的内部的推荐费是2000美元。重赏之下，必有勇夫。当时给推荐到i2的人还真是不少。但真正通过面试的还是不多。这一方面是因为有的来面试的人根本就不合格，另一方面也是因为RCP的人要求挺高。RCP里的许多印度人是从ITT毕业的。中国人则都是从国内名牌大学毕业的。他们对自己的要求标准高，自然也对来面试的人的要求高。每个来面试的人要通过i2的五个人。五个人里若是有一个坚决反对，那么这个面试的人基本上就会被kill掉。 在RCP所有参预面试的人当中，有一个哥们儿是出了名的严格。他最喜欢的面试方法就是在专业问题之外用智力题。这样一来，没有几个人能在他手下过上几招的。他是开发部门的技术骨干，RCP里许多核心的部分都是他写的。在招人的过程中，他的意见很有影响力。但因为他的严格，许多来面试的人都被他给淘汰掉了。这让人事部门的人非常头痛。他们一方面需要他参预面试，另一方面又恨他砍掉的人太多。这让他们很难完成招人的任务。一次，一个人事部门的人无可奈何地对我说：”He takes out our people one after another. He is not making our job easy.” 我进RCP后不久，就开始参预面试工作。在那几个月里，着实地面试了不少人。大部分是印度人和中国人。后来同别人聊面试的经验，发现大家得出的结论都是一致的。印度人普遍能说会道。中国人普遍英语能力较差。 在我面试的人当中，印度人的表现要比中国人好一些。给人的总的感觉是比较professional。而中国人则较差一些。这一方面是因为语言的问题，另一方面则是因为不同文化背景的问题。因为文化背景不同，在中国人看来是正常的表现，在美国人看来则是信心不足。举例来说，在面试的时候，不能想得时间太长。时间一长，美国人就认为你slow。尽管你在脑子里想得非常复杂。但他并不知道。一次，一个从国内名牌大学毕业的人来面试。一个印度人随便地问了一句：“你每天都干什么？”这个人被问愣了。心想：“我每天早晨起来吃饭，上学，再吃饭，再上学。每天如此。有什么好说的呢？”结果愣了一会儿没回答。结果这个印度人给他写的评语是英语能力太差，连基本的生活用语都表达困难。其实，美国(印度)人希望听到的是你的思维过程。所以你这时应该think out load。先把他的问题重复一遍，给你自己点儿思考的时间，然后再一边思考，一边回答他的问题。一般地来说，只要你自己知道你在说什么，你一般都会给人以sharp的印象。 在这方面，印度人就强多了。你若问他的工作经验，他能给你讲得栩栩如生的，仿佛那个产品就是他一个人设计的。但你再进一步问他自己作了什么，你才发现他有可能才做了一小部分。你若再问他具体的技术问题，他有可能就开始支支吾吾了。但不管怎样，印度人的表达能力还是停不错的。 在所有的面试当中，最有意思的是同一个台湾来的小伙子的面试。通过他的简历，能看出他是挺努力的。学Java的时间不长，但已经考了两个Java Certificate。在面试时，小伙子穿得整整齐齐的。一看就是一个非常认真的人。在交谈的过程中，问什么，答什么，显得非常拘禁。英语能力差了一些，每回答一个问题都要想一会儿。对我来说，这个面试也挺吃力的。但我随意问的一个问题却让这个面试成为最有意思的面试之一。 我问他怎么从Java的界面连接Java的server。答案很简单，就是用一个socket就完了。但我万万没想到，他一本正经地回答道：“I first open a Saki.” 我立时想大笑起来。但又不能当着他的面笑出来，所以我使劲忍着。可他却偏偏认真地左一个Saki,右一个Saki地说。我不得不用牙使劲咬着嘴唇，以免笑出来。我心想：“看来你在台湾喝Saki喝得太多了。” i2佚事系列 

初接触RCP时, 立刻发现它的复杂程度比我以前接触的任何Java软件都复杂. RCP是个多层的企业软件, 在UI上用JSP和Java Bean, 在web tier用的是一个商业用的servlet engine. 中间的application server完全是自己写的, 一点儿商业application server 都没用. 数据库用的是Oracle. 当时,RCP刚出来不久,很多方面都不完善.从软件到开发过程都是如此.我刚开始看RCP软件的source code时,经常感到非常吃惊 .Souce code经常会有非常基本的错误.其中的一个最基本的错误是我在建立开发环境时发现的. 我到i2后, 需要做的第一件事是建立起开发环境. 当时, 开发环境的软件和参数都需要自己逐个建立调节. 尽管也有指导建立开发环境的文件, 但文件的很多地方都已过时, 所以指导文件的很多地方都不准确. 指导文件只能起参考的作用. 建立起一个新的开发环境, 对当时在RCP已工作一年的开发人员来说都是个不容易的是, 更别提我这个新入门的人了. RCP当时compile用的工具是Make, 因为RCP用的Java文件太多了. 当时市场上一般的开发工具比如JBuilder和Visual Cafe都不适用. 在所有的文件重新Compile一次的时间非常长. 所以采用了Make. 我当时对Make并不熟悉, 但又急于建立起开发环境, 就想用JBuilder来先compile所有的文件. 在compile的过程中,compile的速度非常慢,这就自不待言了.在修补compile过程中的各种错误时,我发现一个Java文件里的一句SQL出错了.我到出错的地方一看,发现一句巨长的SQL从左到右写在一行上.这让我感到又可气又可笑.没想到在专门作软件的公司看见这么不专业的程序.再仔细一看,发现这句SQL没有写完.这让我感到惊讶.我到ClearCase里一查,发现这句SQL是完整的.但JBuilder里的SQL明明是不完整的.在经过几个小时的研究之后,我发现当时的JBuilder允许的一行的最宽长度是1024bytes.如果一行语句超过这个长度,JBuilder自动把超过的部分砍掉.这句长SQL就是这样被JBuilder自动从中间截断了.RCP的人不用JBuilder来compile,所以这个错误一直没有被发现. 在改完这个语句后,我继续compile.但我发现在别的文件还存在着同样的问题.显然这种写法出自同一个人之手.我一气之下,不用JBuilder了,改用make来compile.两三天后,我终於建立好了开发环境.这让我的印度同事非常吃惊.他没想到我用这么断的时间就完成了这项工作.我后来发现有的人用一个星期,甚至一个月的时间才建立好开发环境. i2佚事系列 

转眼已经被i2解雇一周年了。在这一周年时，我在i2挣的股票期权全部作废了。想想自己在i2辛辛苦苦地工作，结果是挣的期权一钱不值，心里不觉感到很遗憾。但转念一想，或许这些钱根本就不该是我的。只不过在我的账户上临时居留一下。一到时间，它从哪儿来的就回哪儿去了。这么阿Q地一想，心里倒也踏实一些。 回想一下自己在i2的经历，尽管在金钱上有些损失，但总的来说，在i2的两年零七个月的时间还是非常愉快的。同i2的大部分同事一样，我在i2也工作得十分努力。这份努力也得到了相应的报答。刚进i2时作contractor。就在i2开始第一次裁人时，我被i2雇进来作正式雇员。最初干开发，然后又作project manager。在被i2裁掉的时候，我已经作到Senior Project Manager。若不是赶上经济不好，i2的生意每况愈下的话，我在i2的仕途或许会挺不错的。但不管怎样，在i2的经历还是值得怀念的。下面回忆几件i2时期的佚事与大家分享。 短暂的好日子 1999年底，我当时所在的公司把我派到i2作contractor。我进了当时的产品开发部门RCP(Rhythm Collaboration Planning)。RCP是供应商和客户共同进行各种原材料计划和供应的企业软件。RCP是这个领域的开拓者。事实上，它在这方面开拓了一个全新的领域。产品一出来，就在市场上受到客户的欢迎。在1999年和2000年，正是RCP卖得最火的时候。它是i2自创建以来开发的最成功的产品之一。 2000年时的i2同当时的许多.com一样,过着美好的日子.Internet的热潮疯狂到了极点. 我刚一进i2, 就发现几乎每个人的计算机上都联接着股票市场上的股票价格.i2的股票一涨再涨, 每个人都兴奋地关注着自己所拥有的股票价格的变化.每个人都对未来充满了信心. 有一次, 一个印度同事丢了一件价值300美元的皮夹克, 尽管比较沮丧, 但随后又安慰自己道:”不就是两股股票吗!” 有一次,我在上班的路上,看见我前面有一辆崭新的Corvette,车牌上写着”THNXI2″.不用说,这辆车是用i2的股票买的. 那时, 公司厨房里充满了各种零食, 从巧克力到TV dinner应有尽有, 大家随便吃.当然,当时的人干得非常玩命, 每天多干和周末加班是经常的事儿.除了零食外,公司每周还提供免费的pizza. 我们当时对pizza已经吃烦了, 所以每当星期四, 我们几个中国同事就到外面去吃中国饭. 那时, 我们每完成一个较大的release, 除了发option外, 开发人员还要到外面的高级餐馆去美餐一顿. 我赶上的一次是去Del Frisco’s Steak House. 你如果去过那个餐馆你就知道那不是工薪阶层去消费的地方. 2000年, 我所在的开发部门搬到了Luna Road的新的办公楼.i2给每个开发人员都分了一间办公室. 一人一间办公室, 不知道美国有几家公司有这样的条件. 办公楼里还配有Shower Room,乒乓球室和其它的娱乐场所. 能看得出来, 公司的确非常照顾开发人员. 这颇有点Microsoft的劲儿。但是, 随着网络泡沫的破裂,i2的好日子也开始逐渐成为历史. 厨房里的零食先停止供应. 每周一次的免费pizza在坚持了几个月后也被取消了. 当然在此之前, 我们也知道吃pizza的日子也不会太长了,所以也改吃pizza了. 这时的pizza似乎比以前好吃了一些. Release dinner的质量也逐渐降低.从Del Frisco降到Double […]

作软件开发的人都知道软件开发过程管理的重要性。小型的软件无所谓，两三个人很容易相互协调。但大型软件的开发就必须有科学的管理过程。没有这种严格的过程，开发人员的能力再强也没用。Apple公司的System7操作系统的开发就是一个失败的典型。 在RCP的初期，开发部门的开发过程管理可以说是一塌糊涂。我印象最深的是我在刚进RCP不久作的第一个release。在原程序冻结的那天，一个主要的功能竟然还没开发出来。这让我着实吃了一惊。我不明白当时的开发计划是怎么制订的。当时最倒酶的是QA。开发部门不仅拖延开发时间，而且交给QA的产品也是bug一大堆。QA总是给逼得加班加点儿地干。所以QA的manager坚决不干了。 在开发过程的上游部分，问题也是巨多。在这方面，有两件事让我记忆犹新。当时开发部门和产品管理部门总是打架。开发部门抱怨产品管理的产品要求写得不清楚，甚至在产品开发快完成的时候再提新的要求。为了解决这个矛盾，当时的开发部门的大老板说：“假如产品开发的人在走廊里遇到产品管理的人。产品管理的人提出产品要求，应有产品开发的人记录下产品要求。”这让我觉得不可思议。另一件事是产品管理部门写的产品要求。一次，一个同事邀请我参加设计讨论。讨论之前给了我产品要求。产品要求写在一份Excel spreadsheet里。十个需要开发的功能用十行就写完了。我不明白这两个部门是怎么交流的。RCP的产品居然就这样开发下来，这也算是个奇迹。有一次，RCP的一个开发部门的manager在闲聊时问我知不知道什么是CMM。我一听，觉得非常可笑。心想RCP的这样的开发过程还能提什么CMM。 由於缺乏良好的开发管理过程，RCP部门也吃了不少苦头。顾客抱怨得很多。i2的高层管理人员对此也非常恼火。但是，尽管如此，真正有效的开发管理过程却始终没有得到推行。有的部门的开发过程稍好一些，但这些好的措施并没有推广到整个RCP部门。RCP部门后来开发过程的改进当然是大家共同努力的结果。但在这方面，苏力和我作了很多工作。 在RCP的所有的管开发的manager当中，苏力无疑是最能干的。否则的话也不会把他提升为director。苏力接管过RCP的核心部分以后，争取把开发过程规范化。他首先把每次开发的范围控制起来。在这方面，他与产品管理部门进行过不少争吵。最后产品管理部门也开始逐渐地变得有条理了。开发范围的控制是朝开发过程规范化迈出的一大步。以前RCP的很多问题都是由此引起。苏力同时也鼓励开发人员作切合实际的开发估计，不鼓励他们作太乐观的估计。 以此保证在计划的时间范围内完成能作的任务。他又不鼓励在工作以外的时间继续工作。他提倡效率，而不鼓励增加工作时间。 在我们这个部门承担越来越多的任务后，苏力一个人忙不过来。於是我开始帮他管理协调开发方面的工作。 当时，尽管开发过程有所改进，但仍有许多不足的地方。产品管理与开发部门的矛盾依然存在。矛盾主要是在产品要求上。产品管理总是不能在开发开始时将产品要求写清楚。他们总是在开发部门作了一段时间以后又提出修改。开发人员因此非常恼火。让他们写产品要求。他们又借故推脱。为了治他们，我提议作设计评审。开发人员根据他们对产品要求的理解写出产品设计。开发人员与产品管理一起开会作设计评审。如果产品管理没意见，那么开发部门就以此进行开发。既然大家都同意这个设计，产品管理以后也不好再提异议。 除了设计评审的提议以外，我又提议将设计文件标准化。在此之前的设计文件各式各样。不仅读起来费劲，而且质量差别很大。经过讨论后，我们把格式定了下来。每一份设计文件都包括必须的部分。这大大提高了开发部门的整体设计水平。 我推行的另一个改进是进行产品缺陷(bug)的分析。以往每个release作完之后，也不进行项目总结。所以以前犯的错误以后还犯。在这些问题当中，bug的数量一直是个问题。每次作完一个release之后，也不知道这次是不是比以往作得更好一些。为了解决这个问题，在每个release之后，我都对这次release中的bug进行分析。分析的结果使大家进一步提高了质量意识。在开始这样的分析之后，bug的数量逐渐开始减少。这个方法的另一个好处是了解QA的工作的质量。谁发现的bug的数量多，质量高，看得一清二楚。当时，产品管理有一个印度人。经常声称发现bug。但大部分都是他自己的错误， 不是产品的问题。但每次开发人员还得化时间研究他发现的bug是不是真的问题。他因此一直是我们的pain in the butt。我开始作缺陷分析后，数据表明他的QA的成绩最差。他於是成了大家的laugh butt。他以后在这方面小心多了。 在我们的这个部门所有人的努力下，我们的开发过程逐渐变得非常规范化。每次release的开发都能在计划的时间内按时完成。产品的质量也不断地提高。遗憾的是，就在我们不断改进的同时，internet的泡沫开始破裂。i2的生意也越来越差。最后，RCP也坚持不下去了。不管产品作得多好，市场上没人要。商品的使用价值转换不了商业价值。不仅创造不了剩余利润，连必要利润都保证不了。那么雇员的结果就可想而知了。 里的世外高人司马徽称孔明，“虽得其主，不得其时”。我在i2时的情况倒与此有些相似。我当然不敢自比孔明，但没赶上好时候这倒是真的。经过我与RCP同事们的共同努力，我们不仅建立起了一个良好的开发过程，而且也建立起了一个优秀的开发队伍。假如我们不作RCP这个产品，而作其它的软件，我坚信我们也一定能开发出非常好的产品。但就在我们能够有所作为的时候，我们被解散了。真成了出师未捷身先死。时至今天，我依然不甘心。但也没办法了。只能偶尔感叹一番。然后再长叹一声：“他奶奶的！” i2佚事系列