转眼已经被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
Tree, 到Dave & Buster.最后一次的party是在我们的大老板家里开的.

2001年11月, i2开始了第一轮裁员. 以后基本上就是一个季度一次. 开始几批的裁员事实
上挺不错的.一些能力太差或捣乱的人给赶走了.但到后来,干得再好的人也开始被裁掉了.
除了在美国裁员以外,i2又搞了一个M2I Program.意思就是Move To India.在i2工作的人
可以选择到i2的印度公司工作.当然,这就意味着大幅度地降低工资.i2补发一些期权作为
补偿.对许多印度同事来说,这就意味着要么take M2I,要么被解雇.很多人不得不卖掉他们
的Acura, RAV4, Accord, 选择了M2I.对中国人来说,只有别无选择地被解雇,再找工作.我
也毫不例外地于2002年光荣下岗.吃了几个月的联邦救济.

巨长的SQL -- 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.两三天后,我终於
建立好了开发环境.这让我的印度同事非常吃惊.他没想到我用这么断的时间就完成了这项
工作.我后来发现有的人用一个星期,甚至一个月的时间才建立好开发环境.

"I first open a Saki" -- i2佚事 (三)
在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后不久，就开始参预面试工作。在那几个月里，着实地面试了不少人。大部分是
印度人和中国人。后来同别人聊面试的经验，发现大家得出的结论都是一致的。印度人普
遍能说会道。中国人普遍英语能力较差。

在我面试的人当中，印度人的表现要比中国人好一些。给人的总的感觉是比较profession
al。而中国人则较差一些。这一方面是因为语言的问题，另一方面则是因为不同文化背景
的问题。因为文化背景不同，在中国人看来是正常的表现，在美国人看来则是信心不足。
举例来说，在面试的时候，不能想得时间太长。时间一长，美国人就认为你slow。尽管你
在脑子里想得非常复杂。但他并不知道。一次，一个从国内名牌大学毕业的人来面试。一
个印度人随便地问了一句：“你每天都干什么？”这个人被问愣了。心想：“我每天早晨
起来吃饭，上学，再吃饭，再上学。每天如此。有什么好说的呢？”结果愣了一会儿没回
答。结果这个印度人给他写的评语是英语能力太差，连基本的生活用语都表达困难。其实
，美国(印度)人希望听到的是你的思维过程。所以你这时应该think out load。先把他的
问题重复一遍，给你自己点儿思考的时间，然后再一边思考，一边回答他的问题。一般地
来说，只要你自己知道你在说什么，你一般都会给人以sharp的印象。

在这方面，印度人就强多了。你若问他的工作经验，他能给你讲得栩栩如生的，仿佛那个
产品就是他一个人设计的。但你再进一步问他自己作了什么，你才发现他有可能才做了一
小部分。你若再问他具体的技术问题，他有可能就开始支支吾吾了。但不管怎样，印度人
的表达能力还是停不错的。

在所有的面试当中，最有意思的是同一个台湾来的小伙子的面试。通过他的简历，能看出
他是挺努力的。学Java的时间不长，但已经考了两个Java Certificate。在面试时，小伙
子穿得整整齐齐的。一看就是一个非常认真的人。在交谈的过程中，问什么，答什么，显
得非常拘禁。英语能力差了一些，每回答一个问题都要想一会儿。对我来说，这个面试也
挺吃力的。但我随意问的一个问题却让这个面试成为最有意思的面试之一。

我问他怎么从Java的界面连接Java的server。答案很简单，就是用一个socket就完了。但
我万万没想到，他一本正经地回答道：“I first open a Saki." 我立时想大笑起来。但
又不能当着他的面笑出来，所以我使劲忍着。可他却偏偏认真地左一个Saki,右一个Saki
地说。我不得不用牙使劲咬着嘴唇，以免笑出来。我心想：“看来你在台湾喝Saki喝得太
多了。”

追认 -- i2佚事 (四)
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的运行速度.RC
P在与竞争对手竞争时,RCP的运行速度永远是远远领先于竞争对手.与此同时,我们还积极
地进行有关的工作,包括在i2内部进行知识交流,宣传我们的PSR的经验.我们还积极地筹备
同一个作server的主要vendor共同进行RCP的benchmarking测试,以此来作市场宣传.

好景不长,就在我们积极地进行这些工作时,i2的状况每况愈下.i2一方面积极进行M2I,另
一方面又在美国不断裁员.2003年8月,RCP开发部门被彻底解散了.一小部分人留下收拾残
局,产品转移到印度.其它人另谋出路.具有讽刺意味的是,就在我被裁以后,i2给各个部门
颁发所谓的顾客满意奖(Customer Satisfaction Award).我所领导的PSR小组被授予这个
奖.我的名字列在第一位.我一看这个奖,哭笑不得.心想:"这他妈的不跟追认烈士一样吗?"

Sun Certified Java Architect -- i2佚事(五)
刚来美国时,听到这么一个听人讲英语的笑话. "一个人讲英语, 如果你能听懂百分之百,
那么这个人肯定是中国人.如果你能听懂百分之五十,那么这个人肯定是美国人.如果你一
句也听不懂,那么这个人肯定是印度人."

在没来美国之前,对印度所知甚少.只知道它是全世界人口第二大国.剩下的了解也就限於
印度电影里的那些东西.谁想到来美国之后,除美国人之外,打交道最多的就是印度人.我到
i2以后,那更是整天都在同印度人打交道.时间长了,同他们交流倒是一点儿问题都没有.有
的中国人甚至讲英语都开始带点儿印度味儿了.

我对i2印度同事的印象挺好的.他们中的许多人的工作精神很强,为人友好,也很能干.在这
些方面,他们同中国人差不多.但在其它方面,他们同中国人还是不一样.比如在开的车方面
,他们尽管也买Camery和Accord.但有很多人开RAV4,Accura甚至Mustang一类的车.他们在
穿衣服方面也更讲究一些.在工作方面,i2的印度人似乎不太善於按部就班地进行计划管理
,更多地象是fire fighter的工作风格.当时我的老板,一个七七级的毕业生(其故事见以后
章节),对此最不满意,认为这种方式根本不是公司应该有的管理方式.但不管怎样,i2里的
印度人还是挺有意思的.

i2里需要提到的第一个印度人当然是i2的创始人Sanjiv Sidhu.Sanjiv最初是在TI作人工
智能的研究.他后来发现他的研究可以应用在公司的生产计划上,以此可以提高生产效率.
他在这方面的提议并没有得到TI的重视.结果他辞职以后自己继续这方面的研究.他的一家
人住在一个apartment里.一干就是三年.软件作出来以后又到处推销.最终把i2发展成供应
链软件的第一家.Sanjiv对人十分友好.从没听说他对谁发过火.在RCP的初始时期,RCP的产
品质量不过关,很多客户向他抱怨.我想他当时肯定非常恼火.但他在给RCP的开发人员讲话
时,却没流露出一点儿这样的情绪.只是鼓励大家更好地工作.Sanjiv的演讲能力也相当强.
他能站在那儿一口气儿不停地讲一个多小时.也不用讲稿.而且讲得非常有条理,非常令人
信服.时至今日,我依然对Sanjiv十分敬佩.

在RCP开发部门,能干的印度人很多.RCP的发起者就是一个年轻的印度人.刚开始时,i2对这
个产品并不感兴趣.是他说服了Sanjiv,让他同另外几个人一起作出了这个产品.结果RCP一
炮打红.成为i2创始以来最成功的产品之一.他因此也受益不少.他当时有多少option不知
道.但他开的那辆 Jaguar肯定是不便宜的.他后来还被提升为i2仅有的两个Research
Fellow之一.RCP被解散后,他也辞职不干了.又同别人开发新的产品去了. RCP里还有另外
一个印度同事也非常出色.他不仅技术好,工作精神强,而且为人也相当好.我在RCP部门提
议并推行的许多改进措施都受到了他的积极支持. 在我们积极努力下,RCP部门的软件开发
过程改进了许多.

当然了,正象毛主席教导我们的那样,凡是有群众的地方,就有上中下三等.在i2的印度人也
是如此.有的是pain in the ass.有的就是能力太差.有一个人整天穿着一件印着 Duke字
样的T-shirt.但他的能力让人怀疑他是不是Duke毕业的.还有的人干活儿极慢.给他分配四
天完成的工作,别人干快点儿,两天就能干完.
但他非得等到第四天快结速时,才发个email过来,说是作完了.真是没治.

我在i2期间,同印度人打交道的最戏剧性的一次是同一个开发人员打的交道.当时,i2也积
极地搞所谓的交易平台(Trading Platform).用这个交易平台,供应商和顾客可以进行多对
多形式的交易.i2给它的交易平台起了一个非常时兴的名字叫 TradeMatrix.TradeMatrix
其实就是把几个软件捆绑起来一起卖.其性质同微软的Office很象.RCP是TradeMatrix的主
要板块之一.我负责的那部分是一个各板块共用的通讯部分.问题的就是由此引起的.

这个通讯的部分的source code写得很乱.由於很多人用, 所以每个人都根据自己的需要对
这部分进行稍加修改.时间一长,这个部分变得乱七八糟的.根本无法维护.我根据object-o
riented的原则对它进行了修改.大部分有关的内容我也都作了相应的修改.只有两个文件
没有动,我怀疑这两个文件就从来没有用过.为了保险起见,我给所有的人发了个email, 将
此修改通知了所有人.让他们进行有关的测试,以免出现问题.

在这个TradeMatrix就要release的前几天,我突然收到一个email.发email的印度人说我的
改动把他的那部分给break了.我一查,原来他还在用那两个文件.我心想:"你早干什么去了
?到现在才发现这个问题." 尽管如此,我还是给他回了个email,告诉他我愿意和他一起解
决这个问题.但这家伙给我回个email,说我的改动影响了他的程序,应该我自己来改,跟他
没关系.我一看就火了.心想我早就通知了所有的人.你不作改动是你自己的事.我好心好意
帮你,你还想把所有的责任都推在我身上.我当时就给他回了个 email,明白地告诉他没这
好事儿.这家伙又打电话找我的直接老板告状.我的老板也好不留情地把他给挡回去了.

在第二天的TradeMatrix War Room的管理人员会议上,这个问题成了主要问题之一,
成了show stopper.而且当时打电话还找不到他.我的大老板也不得不参与此事.War Room
会议后,我们为此专门进行了一个conference all(因为他在另外一个办公楼里).我, 我的
老板和大老板在电话上同他进行了商量.结果还是我最初提议的由我们两个人共同解决.

我到他的办公室后,发现他是一个留着大胡子的年轻的印度人.一看就是那种极易冲动,非
常自负的人.我同他一起分析问题的原因,结果没一会儿功夫就把问题解决了.他一下高兴
起来,以前的敌意也没有了.开始向我吹嘘他多能干.声称自己并不写程序,只作设计工作.
同时作几个项目.除了在达拉斯的项目外,还带领加州的一个组.一边说还一边把墙上的项
目时间表指给我看.我一看,立刻明白他为什么想把这事儿推给我了.他的时间安排过於紧,
根本没有一点儿缓冲的余地.稍有差错,他肯定不能应付.

还没等我多想,他又吹道:"我是Sun Certified Java Architect.在i2,包括我在内,只有三
个人有这个证书."我立刻反驳道:"不对,我就是一个Sun Certified Java Architect. 我
还有Developer和Programmer的证书.你有几个?"他登时改变了态度.说话的语气也不一样
了.他承认他只有Architect和 Programmer的证书.看着他马上改变的态度,我觉得好笑死
了.没想到Architect的证书还有这么一个好处.

这件事以后,我们倒是不打不相识了.以后见面还打个招呼.

中国同行 -- (i2佚事之六)
在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)。但一般地都是指下属对上司的忠诚。苏力也有loyal
ty。但他的loyalty是对下属的。他不仅有 loyalty。而且是极其地loyal。假如苏力的下
属同别人有争执，苏力永远是站在自己下属的一方。这些还算是小的。在大的方面，有的
中国同事进i2 时的工资偏低，苏力尽自己所能把他们的工资长上来。在i2后来一批又一
批地裁员时，苏力每次都是尽力保护自己的下属。能保下来的就保。不能保下来的就尽量
转到i2的别的部门。当苏力自己被裁时，他还恳求我们的大老板留下我们部门一个没有身
份的中国同事。在我们被解雇之后，一起找工作时，苏力还想着如何自己找到工作后，把
那些尚未找到工作的下属招过来。

KT的故事 -- (i2佚事之七)
英语里有句俗语，“There is a silver lining to every cloud"。翻译成中文就是祸兮
福之所伏。这句话谁都知道。但一旦真到那个祸的时候，当事人很难看到福的银边儿。大
部分人都会感到沮丧。现在回过头来看看i2当时的裁员，发现当时的每次裁员，包括我被
裁的那次，对我来说都是好事。只不过当时没有清楚地认识到这点。我当时认为最初几次
裁员是非常好的事情，越往后越不好。最不好的一次当然是我被裁掉的那次。在那一次，
被裁的不只是我一个人，而且是我们这个部门的大多数人。自那以后，RCP基本上就是在
维持了。
2001年第三个季度，i2开始赔钱了。公司采取的主要措施当然是美国公司屡试不爽的招数
，裁员。第一批的裁掉的人没有什么出人意料的。那些在各个阶层工作成绩最差的人被裁
掉了。其中有一个小的manager。据说能力特差。上下左右的人对她都不满意。有一次产
品出现一个问题，她愣是打电话把她的下属从度假的地方叫回来解决问题。但后来发现问
题其实并不是这个人的。那个人给气坏了。唯一的一个出人意料的是个manager。据说是
政治斗争的结果。但这倒成全了那个人。他到另外一个大的软件公司作了director。后来
在那个公司也搞了类似i2的M2I 的计划。

在刚开始裁员的时候，我并不太担心。因为RCP当时还是赚钱的产品。一些Fortune 500的
公司还在买我们的产品。我没想到的是，自从第一次裁员以后，i2几乎每个季度都裁员。
尽管我比较有信心，但每次还是挺紧张的。那个时候，我们的大老板从来不召集开会，只
是在每次裁员以后才召集所有的人说一下裁员的情况。所以当时给人的感觉是只要是他召
集开会就没好事。有一天，他的秘书给大家发了个 email,通知第二天开一个全体人员大
会。大家登时开始紧张起来，不知又要发生什么事儿。谁想到第二天到会议室一看，原来
是庆祝印度的一个节日的 party，是几个印度同事同秘书一起串联搞的。还真有点儿黑色
幽默的感觉。但并不是每个人都欣赏这种幽默，反映到大老板那里。大老板为了改变大家
的印象，从此以后隔三差五地搞个ice cream party。

i2每次裁员，各个部门都给定下明确的财政预算。这个预算当然是比现有的小得多。具体
怎么达到这个预算，由各个部门自己决定。谁都知道，预算里最大的开支是工资。要降低
开支，只能裁员。那时，RCP的老板尽了最大的能力来保护现有的人。RCP的许多可能被裁
的人被转到i2的其它部门，或在RCP内部进行了调整。我当时对此并不了解，只是后来才
逐渐知道的。

裁员一般地来说不是什么好事，但把那些不称职的人裁掉，有利于公司的健康发展。这对
那些兢兢业业工作的人也才合理。i2的最初的几次裁员还是挺不错的。但是到后来，那完
全就是要硬把成本降下来。那跟个人的工作表现完全没关系了。这就象当年打右派一样。
名额一定，剩下的就是轮到谁的问题了。所以当时的确是人心惶惶的，从上到下全是如此
。当然了，假如大老板又认为你能力差的话，那你留下的机率就更小了。我的前任KT就是
如此。

KT是个相貌堂堂的大个儿。身上的肌肉跟施瓦辛格一样。我每次见到他，总是纳闷儿他为
什么没在NFL打football，而在一个软件公司作项目管理。 KT在我之后来到RCP。但他一
进来就位置不低。他的职务是Senior Project Manager。而且还是在RCP的全盛时期进来
的。当时RCP估计有一百多人。RCP当时的协调管理完全是由他和他的直接老板，另外一个
Project Manager负责的。当时他的权力非常大。RCP的全盛时期过后，他的直接老板调到
别处，他留在了RCP。向我们的大老板直接汇报。

KT尽管是个大块儿头，但性格却极其好。这与他的外表很不一至。在RCP的管理人员会议
上，从没见他跟谁争吵过。这在当时是不多见的。RCP的 release时间非常短，各个部门
经常在彼此协调方面有矛盾。开会时进行争吵是经常的事儿。KT的性格让他在这种环境中
感到非常不适。但他又处在一个负责协调的位置上。这更让他感到无所适从。他的工作效
率因而也受到影响。有人背后嘲笑他，说他象个秘书似的。

我同KT的交往很有限。只是在RCP的管理人员的会议上。在i2的一次裁员的前不久，我听
到消息，说他躲不过这一回了。不久，我的大老板找我谈话，告诉我 KT不久就要离开i2
。他要我接过KT的工作，并要我跟他谈交接的工作。我一听，还真有点儿紧张。设身处地
地从KT的角度想一想，这个交接并不是什么愉快的事儿。但我万万没想到，事情的发展同
我想象的完全不同。

交接的那天，KT来到了我的办公室。进门后随手把门关上了。然后没说几句，就开始向我
倾诉他的委屈。他说自己是project manager，没有实权。关不了RCP各个部门的manager
，RCP的大老板没有对他进行有力的支持，他的一些建议没得到采纳，自己干的工作没什
么价值等等。他又说我干这个工作会比他干得好，因为我能干，在RCP又有很多人的支持
。他的这一番倾诉让我吃惊不小。我们平常也就是泛泛之交，我更本没想到他会如此推心
置腹地深谈。能听得出这完全是他自己真实的想法，不是一般的客套。他的诚恳使我深受
感动。我问他对我接管这个工作有什么建议。他说：“If I were you, I wouldn't take
it.” 我一听，马上跟他开玩笑道：“Thanks, KT. That helps a lot.”他稍一窘迫，
但马上给我解释他这么说的原因。

交接完工作之后，我问他离开i2后去干什么。他说他已经找到了另外一份工作。不久就要
去报道了。我听了以后，很为他高兴，但愿这个工作环境对他更适合。

现在回头想想，i2 当时的工作环境的竞争性还是很强的。一层压一层地逼着出成绩。每
个人的压力都很大。而且预算又少，每个部门只能容纳有数的人。所以象KT这样的人就很
难留下。与此同时，这种环境又提供了让人显示才能的机会。坦白地讲，要不是i2一次又
一次的裁员，我也不会承担越来越多的管理责任。至於我被裁的那次，当时觉得很沮丧。
但现在回头一看，那次其实对我来说是最好的一次。看来，只有云彩过去以后，才能看见
那个银边儿。

进化的终结 -- i2佚事( 九) (Can't find eight)
作软件开发的人都知道软件开发过程管理的重要性。小型的软件无所谓，两三个人很容易
相互协调。但大型软件的开发就必须有科学的管理过程。没有这种严格的过程，开发人员
的能力再强也没用。Apple公司的System7操作系统的开发就是一个失败的典型。

在RCP的初期，开发部门的开发过程管理可以说是一塌糊涂。我印象最深的是我在刚进RCP
不久作的第一个release。在原程序冻结的那天，一个主要的功能竟然还没开发出来。这
让我着实吃了一惊。我不明白当时的开发计划是怎么制订的。当时最倒酶的是QA。开发部
门不仅拖延开发时间，而且交给QA的产品也是bug一大堆。QA总是给逼得加班加点儿地干
。所以QA的manager坚决不干了。

在开发过程的上游部分，问题也是巨多。在这方面，有两件事让我记忆犹新。当时开发部
门和产品管理部门总是打架。开发部门抱怨产品管理的产品要求写得不清楚，甚至在产品
开发快完成的时候再提新的要求。为了解决这个矛盾，当时的开发部门的大老板说：“假
如产品开发的人在走廊里遇到产品管理的人。产品管理的人提出产品要求，应有产品开发
的人记录下产品要求。”这让我觉得不可思议。另一件事是产品管理部门写的产品要求。
一次，一个同事邀请我参加设计讨论。讨论之前给了我产品要求。产品要求写在一份Exce
l 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是不是真的问题。他因此一直是我们的pai
n in the
butt。我开始作缺陷分析后，数据表明他的QA的成绩最差。他於是成了大家的laugh
butt。他以后在这方面小心多了。

在我们的这个部门所有人的努力下，我们的开发过程逐渐变得非常规范化。每次release
的开发都能在计划的时间内按时完成。产品的质量也不断地提高。遗憾的是，就在我们不
断改进的同时，internet的泡沫开始破裂。i2的生意也越来越差。最后，RCP也坚持不下
去了。不管产品作得多好，市场上没人要。商品的使用价值转换不了商业价值。不仅创造
不了剩余利润，连必要利润都保证不了。那么雇员的结果就可想而知了。

<<三国演义>>里的世外高人司马徽称孔明，“虽得其主，不得其时”。我在i2时的情况倒
与此有些相似。我当然不敢自比孔明，但没赶上好时候这倒是真的。经过我与RCP同事们
的共同努力，我们不仅建立起了一个良好的开发过程，而且也建立起了一个优秀的开发队
伍。假如我们不作RCP这个产品，而作其它的软件，我坚信我们也一定能开发出非常好的
产品。但就在我们能够有所作为的时候，我们被解散了。真成了出师未捷身先死。时至今
天，我依然不甘心。但也没办法了。只能偶尔感叹一番。然后再长叹一声：“他奶奶的！
”

(转自www.FoneFtwo.com)