爱投创业指导2016-10-2020:38（转自微信订阅号许永硕：xuyongshuo-work）本文第一部分见古原：i2佚事编者：这一系列文章中，有很多细节只有了解i2的文化才能理解。i2内部是重视计划的，也就是APS产品在i2是受到重视的。而供应商协同，原本不受重视，但却成为卖得最好的软件。说明了协同的重要性，对应于现在工业4.0的横向集成。此文作者工作的部门的研发人员，后来主导设计了i2的BPE平台，曾经有一个阶段，这个BPE产品作为i2的开发工具推广，名字定义为 i2 Studio，是不是借鉴了visual studio的名字？后来这个平台更名为ABPP。（五）Sun Certified Java Architect刚来美国时，听到这么一个听人讲英语的笑话. '一个人讲英语， 如果你能听懂百分之百，那么这个人肯定是中国人.如果你能听懂百分之五十，那么这个人肯定是美国人.如果你一句也听不懂，那么这个人肯定是印度人.'在没来美国之前，对印度所知甚少.只知道它是全世界人口第二大国.剩下的了解也就限於印度电影里的那些东西.谁想到来美国之后，除美国人之外，打交道最多的就是印度人.我到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-oriented的原则对它进行了修改.大部分有关的内容我也都作了相应的修改.只有两个文件没有动，我怀疑这两个文件就从来没有用过.为了保险起见，我给所有的人发了个email，将此修改通知了所有人.让他们进行有关的测试，以免出现问题.在这个TradeMatrix就要release的前几天，我突然收到一个email.发email的印度人说我的改动把他的那部分给break了.我一查，原来他还在用那两个文件.我心想:'你早干什么去了?到现在才发现这个问题.' 尽管如此，我还是给他回了个email，告诉他我愿意和他一起解决这个问题.但这家伙给我回个email，说我的改动影响了他的程序，应该我自己来改，跟他没关系.我一看就火了.心想我早就通知了所有的人.你不作改动是你自己的事.我好心好意帮你，你还想把所有的责任都推在我身上.我当时就给他回了个email，明白地告诉他没这好事儿.这家伙又打电话找我的直接老板告状.我的老板也好不留情地把他给挡回去了.在第二天的TradeMatrix War Room的管理人员会议上，这个问题成了主要问题之一， 成了show stopper.而且当时打电话还找不到他.我的大老板也不得不参与此事.War Room会议后，我们为此专门进行了一个conference call(因为他在另外一个办公楼里).我， 我的老板和大老板在电话上同他进行了商量.结果还是我最初提议的由我们两个人共同解决.我到他的办公室后，发现他是一个留着大胡子的年轻的印度人.一看就是那种极易冲动，非常自负的人.我同他一起分析问题的原因，结果没一会儿功夫就把问题解决了.他一下高兴起来，以前的敌意也没有了.开始向我吹嘘他多能干.声称自己并不写程序，只作设计工作.同时作几个项目.除了在达拉斯的项目外，还带领加州的一个组.一边说还一边把墙上的项目时间表指给我看.我一看，立刻明白他为什么想把这事儿推给我了.他的时间安排过於紧，根本没有一点儿缓冲的余地.稍有差错，他肯定不能应付.还没等我多想，他又吹道:'我是Sun Certified Java Architect.在i2，包括我在内，只有三个人有这个证书.'我立刻反驳道:'不对，我就是一个Sun Certified Java Architect. 我还有Developer和Programmer的证书.你有几个?'他登时改变了态度.说话的语气也不一样了.他承认他只有Architect和Programmer的证书.看着他马上改变的态度，我觉得好笑死了.没想到Architect的证书还有这么一个好处.这件事以后，我们倒是不打不相识了.以后见面还打个招呼.（六）中国同行在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的别的部门。当苏力自己被裁时， 他还恳求我们的大老板留下我们部门一个没有身份的中国同事。在我们被解雇之后，一起找工作时，苏力还想着如何自己找到工作后，把那些尚未找到工作的下属招过来。（七）KT的故事英语里有句俗语，“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一次又一次的裁员，我也不会承担越来越多的管理责任。至於我被裁的那次，当时觉得很沮丧。但现在回头一看，那次其实对我来说是最好的一次。看来，只有云彩过去以后，才能看见那个银边儿。(八)One of you is lying毛主席教导我们说：“阶级斗争要年年讲，月月讲。” 在美国公司里也讲斗争，政治斗争。不仅要年年讲，月月讲，而且还要天天讲。我刚开始在i2工作时，作软件开发。那时，工作很紧张。Release一个接着一个。我在一台计算机上同时要保持两个开发环境，一个环境用于下一个release的开发，另外一个用于现在release的 bug fix。尽管很忙，但看着自己的工作成绩，还是感觉很充实。一个人从早干到晚，几乎就不出办公楼。今年夏天不在i2工作了。感觉到达拉斯的七八月份特别 热。跟别人一说，别人居然说今年夏天不算热的。这让我感到特别奇怪。前面四个夏天我都是在达拉斯过的，为什么我以前没感到热呢？直到有一天我突然明白过来，我以前在i2，太专心于工作了，根本没功夫注意到天气的冷热。这让我不禁又感慨一番。我后来开始参加管理工作，发现管理工作同开发太不一样了。开发工作的成绩完全取决于你自己。你干得好，马上就能看到成绩。管理就不一样。你的部门的成绩的好坏不完全取决于你的部门。你需要别的部门的配合才能完成你的工作。但问题往往就出现在这里。RCP的release十分频繁，各个部门需要密切协调才能保证产品在规定的时间内交付。RCP的各个部 门经常因为协调的问题进行争吵。有的部门的工作必须等到另一个部门的工作完成之后才能进行。有时候，眼看着release的时间就要到了，但前面的部门的 工作要拖延，后面的部门的manager就开始着急了。於是在管理人员会议上就开始逼着前面部门的manager赶紧完成他们的工作。争吵就这样开始了。 开发部门同开发部门吵，开发部门同产品管理部门吵，但吵得最多的还是Du带领的QA同各开发部门的争吵。QA是每个release的最后阶段，哪个部门的拖延都会直接影响到QA的工作，所以在RCP的管理人员的会议上，Du经常是争论的一方。我所在的开发部门作的软件的质量比较好。出现的bug少。即使 QA发现bug，我们也很快就修改好。所以我们的两个部门间的矛盾较少。RCP管理会议上的大部分的争吵是有建设性的。大家的目的都是 为了工作，所以即使有时争论激烈，但一点儿也不影响大家的工作关系。但有的manager没有基本的品德。有的十分阴险，有的厚颜无耻，能够当面撒谎。有 一个manager公然说：“在i2工作，就是要有点儿streetsmart.'我们部门曾经同加拿大的一个开发部门合作，共同作一个release。那个部门的工作必须先完成，我们才能开始我们的工作。那个部门管理得不好。开发人员的素质不错，但manager的管理的能力不行， 所以经常拖延。在到他们应该完成的那天，我在RCP管理人员的会议上特别追问那个manager，问他们是否完成了他们的工作。那个manager肯定地 说他们完成了所有的工作。等到会议后，我问我们的开发人员，发现他们的source code根本没在ClearCase里面。在我接触过的所有的i2的manager当中，最厚颜无耻的莫过於BH。BH是在RCP的全盛时期从别的部门转过来的。刚开始时，他同时管几个部门，包括我后来 接管的PSR小组。但后来他管的部门越来越少。在被i2裁掉的时候，他只管一个部门。尽管如此，那个小组的问题还是很多。BH的各方面 的能力都差。他是软件开发的manager，但他的专业知识极差。在一次设计讨论的会议上，他居然问MCV(Model， View， Control)代表什么。这让我大吃一惊。BH的专业能力不行，管理能力不行，为人处世的能力也差。他与同级同事及老板的关系不好。在RCP管理人员的 会议上，经常会干一些愚蠢的事，进一步破坏他与别人的关系。有一次，他居然同我们部门的VP当众争论起来。象他这样的人居然能够躲过i2的前几次的裁员，这也算是个奇迹。导致BH的最后被裁掉的原因恐怕是他的最严重的一次撒谎。那一次，我们马上要给一个Fortune 500的客户一个release。当时Nike的事件已经发生，所以大家都特别小心。产品交付的时间马上就要到了。但QA还是不断地发现bug。RCP的 manager们都非常紧张。我们的VP也开始参加每天的War Room会议。在一天的War Room会议上，突然发现一个bug居然有两天了，还是没被修改。这个bug是BH开发部门负责的。BH说QA根本就没有通知他们。Du说早就告诉了BH 部门的某个开发人员。BH坚决否认。於是两人就争论起来。在场的VP开始发火了。不客气地打断他们，说道：“One of you is lying.' 当场打电话找到发现这个bug的QA，把电话的speaker打开，让那人讲事情的经过。真实的情况当然是证明Du是对的。BH只好讪讪地说：“我回去看 看是怎么一回事儿。”在i2的下一次的裁员的名单上，BH就榜上有名了。( 九)进化的终结作软件开发的人都知道软件开发过程管理的重要性。小型的软件无所谓，两三个人很容易相互协调。但大型软件的开发就必须有科学的管理过程。没有这种严格的过程，开发人员的能力再强也没用。Apple公司的System7操作系统的开发就是一个失败的典型。在 RCP的初期，开发部门的开发过程管理可以说是一塌糊涂。我印象最深的是我在刚进RCP不久作的第一个release。在原程序冻结的那天，一个主要的功能竟然还没开发出来。这让我着实吃了一惊。我不明白当时的开发计划是怎么制订的。当时最倒酶的是QA。开发部门不仅拖延开发时间，而且交给QA的产品也是 bug一大堆。QA总是给逼得加班加点儿地干。所以QA的manager坚决不干了。在开发过程的上游部分，问题也是巨多。在这方面，有两件事让我记忆犹新。当时开发部门和产品管理部门总是打架。开发部门抱怨产品管理的产品要求写得不清楚，甚至在产品开发快完成的时候再提新的要求。为了解决这个矛盾，当时的开发部门的大老板说：“假如产品开发的人在走廊里遇到产品管理的人。产品管理的人提出产品要求，应有产品开发的人记录下产品要求。” 这让我觉得不可思议。另一件事是产品管理部门写的产品要求。一次，一个同事邀请我参加设计讨论。讨论之前给了我产品要求。产品要求写在一份Excel spreadsheet里。十个需要开发的功能用十行就写完了。我不明白这两个部门是怎么交流的。RCP的产品居然就这样开发下来，这也算是个奇迹。有一 次，RCP的一个开发部门的manager在闲聊时问我知不知道什么是CMM。我一听，觉得非常可笑。心想RCP的这样的开发过程还能提什么CMM。由於缺乏良好的开发管理过程，RCP部门也吃了不少苦头。顾客抱怨得很多。i2的高层管理人员对此也非常恼火。但是，尽管如此，真正有效的开发管理过程却始终没有得到推行。有的部门的开发过程稍好一些，但这些好的措施并没有推广到整个RCP部门。RCP部门后来开发过程的改进当然是大家共同努力的结果。但在这方面，Li和我作了很多工作。在RCP的所有的管开发的manager当中，Li无疑是最能干的。否则的话也不会把他提升为director。Li接管过RCP的核心部分以后，争取把开发过程规范化。他首先把每次开发的范围控制起来。在这方面，他与产品管理部门进行过不少争吵。最后产品管理部门也开始逐渐地变得有条理了。开发范围的控制是朝开发过程规范化迈出的一大步。以前RCP的很多问题都是由此引起。Li同时也鼓励开发人员作切合实际的开发估计，不鼓励他们作太乐观的估计。以此保证在计划的时间范围内完成能作的任务。他又不鼓励在工作以外的时间继续工作。他提倡效率，而不鼓励增加工作时间。在我们这个部门承担越来越多的任务后，Li一个人忙不过来。於是我开始帮他管理协调开发方面的工作。当时，尽管开发过程有所改进，但仍有许多不足的地方。产品管理与开发部门的矛盾依然存在。矛盾主要是在产品要求上。产品管理总是不能在开发开始时将产品要求写清楚。他们总是在开发部门作了一段时间以后又提出修改。开发人员因此非常恼火。让他们写产品要求。他们又借故推脱。为了治他们，我提议作设计评审。开发人员根据他们对产品要求的理解写出产品设计。开发人员与产品管理一起开会作设计评审。如果产品管理没意见，那么开发部门就以此进行开发。既然大家都同意这个设计，产品管理以后也不好再提异议。除了设计评审的提议以外，我又提议将设计文件标准化。在此之前的设计文件各式各样。不仅读起来费劲，而且质量差别很大。经过讨论后，我们把格式定了下来。每一份设计文件都包括必须的部分。这大大提高了开发部门的整体设计水平。我推行的另一个改进是进行产品缺陷(bug)的分析。以往每个 release作完之后，也不进行项目总结。所以以前犯的错误以后还犯。在这些问题当中，bug的数量一直是个问题。每次作完一个release之后，也不知道这次是不是比以往作得更好一些。为了解决这个问题，在每个release之后，我都对这次release中的bug进行分析。分析的结果使大家进一 步提高了质量意识。在开始这样的分析之后，bug的数量逐渐开始减少。这个方法的另一个好处是了解QA的工作的质量。谁发现的bug的数量多，质量高，看得一清二楚。当时，产品管理有一个印度人。经常声称发现bug。但大部分都是他自己的错误， 不是产品的问题。但每次开发人员还得化时间研究他发现的bug是不是真的问题。他因此一直是我们的painin the butt。我开始作缺陷分析后，数据表明他的QA的成绩最差。他於是成了大家的laugh butt。他以后在这方面小心多了。在我们的这个部门所有人的努力下，我们的开发过程逐渐变得非常规范化。每次release的开发都能在计划的时间内按时完成。产品的质量也不断地提高。遗憾的 是，就在我们不断改进的同时，internet的泡沫开始破裂。i2的生意也越来越差。最后，RCP也坚持不下去了。不管产品作得多好，市场上没人要。商 品的使用价值转换不了商业价值。不仅创造不了剩余利润，连必要利润都保证不了。那么雇员的结果就可想而知了。三国演 义里的世外高人司马徽称孔明，“虽得其主，不得其时”。我在i2时的情况倒与此有些相似。我当然不敢自比孔明，但没赶上好时候这倒是真的。经过我与RCP同事们的共同努力，我们不仅建立起了一个良好的开发过程，而且也建立起了一个优秀的开发队伍。假如我们不作RCP这个产品，而作其它的 软件，我坚信我们也一定能开发出非常好的产品。但就在我们能够有所作为的时候，我们被解散了。真成了出师未捷身先死。时至今天，我依然不甘心。但也没办法了。只能偶尔感叹一番。然后再长叹一声：“他奶奶的！”（来自：左右逢源创投微信公众号：zjiay8；项目路演、投融资服务请联系schg1999@163.com）关于我们：孙春光 学历：天津大学电子信息工程本科、保送通信与信息系统硕士 。现担任全国工商联民办教育出资者商会EMBA教育联盟秘书长；北京左右逢源创业投资有限公司合伙人；中关村众筹联盟发起单位之一、监事长候选单位；磁云科技合伙人；EMBA联盟创业孵化器合伙人；金刚偶巴创意韩餐合伙人；常州火红基金合伙人；南京亨通伟业基金合伙人；博雅金科基金合伙人；飞常酷无人机合伙人；爱投（ITOU）高管会创始发起人；IT高管会创始发起人；陈香梅公益基金会天使荣耀基金理事。在IT行业工作多年，曾任北京智网能达董事总经理，北京海创园投资管理有限公司副总经理（中国留学人才发展基金会支持），香港上市公司高阳科技（00818）全资子公司技术总监，瑞博强芯（天津）科技有限公司部门经理。EMBA联盟是由北京大学、清华大学、长江商学院、中欧商学院、复旦大学、上海交通大学、中山大学、武汉大学、四川大学、西安交通大学、哈尔滨工业大学、香港大学、香港科技大学、台湾大学、澳门大学、新加坡国立大学、哈佛、斯坦福、宾夕法尼亚大学等海内外商学院EMBA企业家共同发起，目前已拥有2万多位EMBA会员（覆盖了全国10万EMBA同学的五分之一），已建立20多个EMBA教育联盟群及全国31个省市自治区EMBA区域教育联盟群及EMBA联盟微信公共平台。在2万多会员中，北京占30%、上海占20%，广州占15%，其他区域占35%。主要会员来自各商学院EMBA校友企业家。这些会员在各行业内具有领先优势，会员占行业比例在20%左右，销售额占行业在10%左右。联盟成立以来成功举办了两届EMBA联盟春晚、“为爱而拍光亮生命”慈善活动、嗨走中国行、中国首届EMBA企业家仲夏音乐节、EMBA联盟创投汇、2015京津冀青年创业路演与发展论坛等一系列活动。 【左右逢源 - 构筑梦想】北京左右逢源创业投资有限公司，成立于2015年3月，是全国工商联EMBA联盟发起成立的以服务于会员(注册会员2万多名)企业为主的互联网投融资服务平台。EMBA联盟一直致力于发展“众创、众筹、众包、众扶”，为大众创业、万众创新服务。未来，EMBA联盟依托于线下创业孵化器、线上左右逢源创投平台，结合产业资本优势，加大对创业创新的支持力度。