IT外企那点儿事（1~12）

注：本内容转自cnblogs"觉先"

IT外企那点儿事(1)：外企也就那么回事

外企，一个听起来似乎充满光环的名字，每年众多大学毕业生向往的地方。

 

说起外企，总能让人联想到很多令人心动的名词：高薪，人性化，浮动工作制，年假，完善的流程，各种福利如：旅游，室内乒乓球台，健身房，按摩椅，小食品，酸奶……

然而真正进入了外企，时间长了，也就发现，其实外企也就那么回事。

 

高薪

所谓高薪，严格意义上来讲是高起薪，也即刚毕业的时候每个企业公开的秘密，同学们总能够从师哥师姐那里打听到这个数字，有的企业甚至爆出较去年惊人的数字来做宣传。一个个光鲜的数字吸引着尚未毕业的大学生们，宣讲会的人数是基本和这个数字成正比的。

然而由于大多数的外企，由于规模比较大，机构也相对的稳定，高起薪的背后是稳定的加薪，每年7%~10%是常道，20%则是皇恩浩荡了，除非你能够取得整个Team都认可的成就，然而如果不幸参与的项目是一个多年的产品，至多是修改一些Bug或者增加一些边边角角的功能，又有多少这样的机会呢？大约在下看到的是这样的，也许并不符合所有外企的情形。

于是当毕业生中的佼佼者很幸运的加入大的外企的时候，不如你的同学只有默默的加入了不算太大的民企。

这一直是你引以为豪的资本，并总在同学聚会的时候大说特说你们公司的薪水，福利，在你的同学抱怨民企的加班声中附和着，心中却莫名的产生了一种优越感。

这种优越感使得你进一步沉浸在美好的外企生活中，却发现越来越没有那么优越了。三年，五年，你一次次的听说你的同学升职了，又升职了，而你还是一个普通的engineer，因为外企的升职基本是由严格的年限的，有时候多少有些按资排辈的味道。你一次一次听说你的同学加薪了，又加薪了，薪水直逼你当前的薪水，甚至在五年的关头超过你。

你越来越发现你的同学逐渐的掌握了一个系统前前后后的模块，能够完整的负责起一个项目的时候，你却还是螺丝钉，每天接受外国人的指示，在yes, ok, no problem,i am 100% agree的声音中继续做你的螺丝钉般的小功能。

我不知道十年后会如何，在参加了多次的开发者大会后，我发现几乎所有的外企的演讲者都是外国人，中国的演讲者则多来自本土的创业企业，当听着他们如数家珍的谈着自己的创业企业如何一步步做大，系统如何一步步改进，直到今天的架构，他们外企的同学能有这种机会吗？

 

人性化

所谓人性化，用外企的语言就是我们是很Open的。

Open体现在很多方面，诸如高管的办公室的门始终是开着的，你可以在任何时刻走到任何的高官的办公室里发表自己的看法，只是你必须保证，当你满怀激情的走进高官的办公室，关上门，半个小时后同样满怀激情走出办公室，你的顶头上司对你没有看法，即便你确实没有说什么，仅仅谈论了一下午餐而已。

所以除非高层主动安排和你谈话，尽量不要没事跑到高层那里，在你的顶头上司控制范围之外和他的上司进行私密的谈话，要知道有一种关系叫表面上支持，心中的隔阂。即便是高层主动要和你谈话，最好事先和你的顶头上司事先沟通，当然不用太正式，比如在闲聊的时间抱怨一下："今天下午又要被老大找去One on One，项目这么忙，不知道有啥事情可谈的"，呵呵，一些术而已，姑妄言之姑听之吧。

对你最重要的永远是你的顶头上司，当高层听完你的建议，OK, I will take itinto consideration之后，便和你没有啥关系了，绝不会存在当你的顶头上司决定给你涨薪7%的时候，高层会出来说一句，我觉得他表现还不错，涨10%吧。

当然，按照公司的规定，你的顶头上司也会过一段时间和你来一次One on One，问问当前的情况，问问有啥意见等等，这可不是推心置腹的时候，需要把握火候，对当前的情况说的太满意，感觉不真诚，太不满意自然领导不爱听，说没意见显得对Team不够关心，说太多意见会让人感觉你不安全。

所以总的原则是：

·        要多提改善性意见("code review预留的时间应该更长一些")，少提颠覆性意见("现在的项目流程有很大问题")，

·        多提有证据的具体意见("我们有几十个Bug，可能一个星期确实做不完")，少提抽象型意见("Team之间的沟通有问题")，

·        多说与项目相关的意见，少说与自己相关的意见(尤其不要太真实的说自己的人生规划)，

·        多说在领导意料范围之内的意见(这样会给领导以对Team的控制感，比如说天天加班到10点，领导也看在眼中，可以提一下)，少说在领导意料之外的意见(即便有，请事先沟通，让领导在One on One之前就心里有数)。

Open还体现来另外的方面，比如领导会和员工一起参加各种工作之外的活动，比如打球，比如年会表演，比如一起健身等等，而且在此过程中，往往是充满的欢声笑语的，但一定不要忘记领导就是领导，哪怕不在项目中，千万不要因为你曾经是学校的篮球高手，或是文艺主干，就能在此类的活动中充当领袖角色，在你的项目领导面前指手画脚，虽然在活动中他会夸你，没想到你还有这方面的才能，但是在领导面前充老大，这笔账是迟早要还的，比如在项目的后期不能够完成美国派来的任务的时候，你会被冠以虽然前一阵成功组织了活动，但是耽误了一些项目进度的罪名，从而影响你的绩效。

如果你在健身房遇到领导，和你一起健身，你们可以边健身边聊的很开心，但是领导的心中的第一个想法一定是，这小子项目干完了吗，还有空工作时间健身？，并且会在以后的工作中反映出来，比如时常关心你的工作进度，加大你的工作量等。

 

浮动工作制

所谓浮动工作制，很好听的名字，就是你早上可以推迟来，晚上可以早些走，只要能够完成任务，每天工作6个小时都可以。

初入外企的时候，看到很多前辈可以早上十点，甚至十一点才到公司，认为浮动工作制太好了，于是拼命的工作，企图在6小时干完10个小时的活，然后有时间或学习或休息。然而最后发现，活是永远干不完的，资本家花钱请了你，会让你轻松应对？

浮动工作制，其实就是加班不给加班费的另一种说法，也即合同中也许会写着"所有的加班费已经被计入了薪水中"。只要能够完成任务，每天工作12个小时也是应该的。晚上留下来很晚，或是早上很早被拉起来和老美开会，也是浮动的时间之中，你无话可说。为了改美国客户的一个Bug，深夜加班，你无话可说。在中国是休息日，但美国不是休息日的时候派去美国，并不补偿你的休息日，也不给三倍工资，你无话可说。

 

年假

外企的年假是相对较多的，也是外企在校园宣讲中经常引以为豪的一点。然而年假又有多少真正能够落到实处呢？其时大部分是休不到的，项目不允许，领导不允许，外国人也不允许。

不允许当然不是显式的，而是潜规则的。项目永远是紧的，即便不那么紧，也会被人们喊得使大家觉得很紧，如果一个Team有很多人休很多假，对领导来说，好像对上面不太好交代。

如果Team中你单独休假，你会被提醒，现在大家都在赶进度，不要因为你这个模块把项目block了。

如果Team中大家想一起休假，领导会说，大家都在这个时候休，连backup都没有，出了事情找不到人啊。

如果你平时想休息一天，领导会说，有什么事情吗？没什么事情可以等项目闲了些集中休息一下，明天早上可以晚来些，可能这一阵确实太累了。

如果你想连着长假一起休，领导会说，本来就有一个星期了，还另外请，不如平时累的时候休息一天，效果好。

如果美国人放假(如圣诞)，中国不放假，美国人会在放假前有很多任务布置过来，要在这个期间赶上美国的进度。

如果美国不放假，中国放假(如过年)，总不能让美国老板找不到人吧。

当然以上借口只是在你提出请假的时候，以商量的口气被提及，如果你真想请假，领导还是会毫不犹豫的批准的，因为我们是Open的嘛。然而以上借口却会使得多数员工不太敢于请假，因为大家都明白，有一种关系叫表面上支持，心中的隔阂。

当然即便假期被批准，还是有条件的，比如"没问题，好好休息，走之前把文档(报告，邮件，代码)发出来(提交到svn)就行了"。一般这个附加条件都会耗费一些时间的，一般是第二天休，前一天晚上至少九十点走，早上请，中午才能走，中午请，下午三点多才能走。

 

完善的流程

外企的流程是非常完善的，甚至是极度的完善，过分的完善。

所以外企一般都会有会议室预定系统，会议室永远是被占着的，一天一天的总是开会，讨论。

例会就有模块组的，开发组的(包含多个模块)，项目组的(开发和测试)，Group的(同一个大老板的多个项目)，all-hands的(整个公司)。

写一篇文档要模块组review，开发组review，测试组review，和美国开会review，重新改了第二轮review。以及code review，bug review。

每个项目组作了一个阶段后给整个项目组的demo，甚至给整个group及老外demo，说是增加visualbility。

一般要到下午晚些时候才能够清净些写代码，晚餐后才是代码的高峰期。

这也是为什么小公司半年作出来的东西，大公司要做几年。当然大公司这样做自然有它的道理，大公司稳定，不愁客户资源，不差钱，今年做出来或是明年做出来，客户别无选择，员工也养得起。这些小公司都做不到，必须尽快的满足客户的需要，必须在钱花完之前拉到下一个项目。

然而这对程序员的职业生涯来说好么，我不敢评价。只是在和很多朋友讨论的时候，他们发现，自己一直在忙啊忙，当跳槽试图总结自己做了啥的时候，却发现就不多的东西，不多的技术，当他们去面创业公司的时候，经常会被问，你们这么长时间，怎么就做了这么个东西？

大公司完善的流程还有一个特点，就是这个流程是完全为此公司定制的，当然公司大，自然可以有钱从头到尾弄自己的东西，既不用常用的，也不用开源的，无论是开发工具，测试工具，代码管理工具。这也导致了员工的粘性特别强，当走出这家公司，就像换了一片天地，原来会的别人用不到，别人常用的，却不怎么会，最后只好在公司养老，好在薪水也不错，福利也不错。

 

设施

最后提及的是各种美好的设施，这是很有吸引力的。然而为了您的前途，虽不能说敬而远之，也要注意享用的时间，如中午，晚上。

尽量不要在工作时间娱乐，甚至喧哗，人民的眼睛是雪亮的，领导的眼睛也是雪亮的，尤其是对于软件这种成果极难量化的产品，有时候表现和态度反而成了一种指标，不像销售一样，给公司带来的是真金白银，我无论怎么玩，能拿回单子就行，然而对于软件，你有绝对的证据证明成果超越别人吗？

所以外企有个很有意思的现象，一个团队的座位，离食品的距离越近越好，离娱乐设备的距离越远越好。离食品近，取用方便，领导看到你拿吃的也不会说什么，然而离娱乐设备近，领导办公室的门都开着，有谁胆敢长时间玩耍啊。所以娱乐设备上面玩耍的人一般都是座位离得比较远的。

 

此篇就写到这里的，在外企多年，其实发生了很多有趣的事情和现象，当走过几个外企的时候，发现有很多相似的潜规则。

 

进入中国的外企，其实是有中国特色的外企。中华文化的强大，使得所有的东西一到中国就会中国化，甚至改变了味道。很多民族如满族，回族的很多人都失去了原来民族的特色。也只有在中国，才可能存在儒释道三教合一的说法，不知道释迦摩尼有何感想。上学的时候，一个我很佩服的大物老师，年纪很大，他是坚定的马克思主义者，但是他曾经说，上个星期我病的厉害，差点就去见马克思了。我笑道，马克思是唯物的，是不相信死后有鬼的，死后去见阎王是迷信，去见马克思就不是了？

 

等有空的时候，再接着给大家讲外企的故事。

 

 

 

IT外企那点儿事(2)：多种多样的外企

不是所有的外企都是一样的，外企也分多种，基本按照地域和文化的划分可以分为日韩外企，欧企，美企。

 

日韩企业

日韩企业是十分强调等级观念的，这可能和这两个民族的文化有关。

上级在下级面前总是一副严肃或者装深沉的样子，虽然其在外面有可能花天酒地，什么都做。

上层和下层很少有哪怕表面上的互动，比如开玩笑，打球，年会一起表演等，所以工作环境相对的压抑，安静。

甚至在伴有生产性的企业中，中午的食堂都是按照等级来的，先是管理层，然后是办公室人员如IT，行政，HR等等，最后才是蓝领的工人阶级同志，不能不说到最后像样的饭菜都比较少了，虽然自己是较先吃饭的一部分，但是看到这种情形仍然不是滋味，毕竟我们的父辈也是普普通通的工人。

员工的绩效是完全由上司指定的，甚至没有解释为什么，不知道别人是多少，也很少存在如欧美企业一样哪怕形式主义的反馈，其时只有默默接受，或者走人。

员工的入职薪水在外企来讲相对是很低的，每年的加薪也少可怜，其解释也是振振有词：当你的水平和贡献没有提高，凭什么公司付给你更多的薪水？所以要想薪水有较大的改善，唯一的途径就是升职，用他们的话来讲就是能做更多的贡献。

日韩企业中，级别与级别之间的薪水差距是比较大的，所以一旦能够做上去，拿到的薪水可能不比欧美企业差。这也就造成了一种现象，就是日韩企业中最底层是非常不稳定的，每年大批的毕业生几乎像换水一样，一批一批几乎都走了，留下的基本就是当年就升了职的，而中层是相对稳定的，所以公司的管理也不会出什么问题。

无论在哪里，一旦有了很深的等级观念，伴随而来的是管理者相对比较累，所有的决定权都在上司的手里，所以其会忙的不可开交(所有的猴子都在他的身上，请参照《哈佛经典：谁背上了“猴子”？》)，甚至管理的蛮大的Team的时候，还可能亲自写一些代码，并对每一个细节都心中有数，不像欧美的项目经理一样只管流程就可以了，甚至做的时间长一些，技术都忘了很多了。

这也难怪，当下属每年流水一样几乎全走了的时候，Teamlead总要保证项目能够继续下去。这多少让我想起清朝的皇帝，由于对大臣们极度的不信任，最后不得不一个个殚精竭虑，连县一级的官员都亲自任命，而明朝的皇帝很多将政务抛给宰相后，就可以逍遥自在，过自己的无厘头的生活了。

说到外企，一个不可回避的问题就是天花板问题，也即多高的职位还会属于本土的中国人。

日韩企业的天花板是相对较低的，不太大的官就已经是日韩人士了，因为对中国人，这两个民族似乎总是不放心的，其民族文化中多少存在一些非我族类，其心必异的倾向，所以中国人在这些企业中做不到太高的位置。

所以有一种说法是，和欧美企业不同，日韩企业不能算作真正意义的跨国公司，而是分派在不同国家很多分部的日韩公司，这些分支不能够很好的本地化，不能够融入本地文化，不能包容多元文化，不能实现真正的国际化，而仅仅是接受日韩总部的指令的分支机构而已。

在这里还要提及的是台湾的企业，台湾是中国领土不可分割的一部分，但是很奇怪的是，在大陆登记的时候，台企是被登记为外资企业的，而且可能是台湾被日本统治了一段时间的原因，在台企中多少有一些日本企业的影子，如等级化，天花板等，同是炎黄子孙，台湾企业似乎也对大陆的人才不能够完全的信任，看了多少心中有些不舒服。

 

欧企

欧企是三者之中最人性化的一类企业，尤其是北欧企业，大概和这些地区的高福利，共产主义化有关。

当然天花板肯定是有的，只是相对较高，中国区的总经理一般会是是外国人，好一点的还可能是美籍华人，香港人，甚至可以使中国国籍但在美国留过学的人，然而总监一级就可能是本土的中国人了。这样的组织架构既能够和外国人很好的交流，又能够很好的本地化，适应中国文化，和本地政府交流，何乐而不为呢？

欧企的等级观念也是三者之中最不明显的，管理多个Team的line manager还会在旅游之中和我们最底层的员工打牌，娱乐。公司内部的相互称呼也是叫名字，hi jack，hi peter这样的叫，无论其是多么高的高层，不会称其为王总监，刘经理此类的。

欧企的加班也是比较少的，他们强调worklife balance。

工资相对日韩企业比较高，但相对美企来讲要低，但是福利比较好，公司会经常有吃蛋糕，开Party，旅游等活动，如果赶上公司的经营状况很好，公司给的旅游的budget是比较多的，经常可以近郊旅游，每年还能有一次出国旅游。

由于较好的福利，公司是非常稳定的，每年跳槽的人很少，有的人甚至放弃美企的高薪，因为那儿比较累，舍不得这里的福利，环境，以及较好的培训机制。

一个欧洲人在培训中讲，美国人是喜欢跳槽的，并不是公司不好，而是他们喜欢挑战，如果五年待在一个地方，别人会问：what iswrong with you?，而在他们国家，人们是不怎么跳槽的，他在这家公司待了20多年，他的父亲就是在这家公司退休的。这多少让我想起了我们原来的国有企业的制度，父辈退休，孩子在这个岗位接着干。难道欧洲已经到了劳动已然成为一种需求的阶段？

想必这种日子说的大家心驰神往，这的确是个养老的好地方，然而对于年轻人打拼来讲，却不一定好。在此类地方，系统已经是很大很稳定的，技术进步是不太快的，可能很长时间才能修改很小一部分代码，而由于人员稳定，向上升职也是比较慢的，这样你的竞争力其实是在一步一步的下降。

当公司经营状况好的情况下，大家一好百好，彼此都很开心，但是一旦遇到金融危机，公司经营状况变差的情况下，福利会急剧下滑，资本家终究是资本家，哪怕披着绅士外衣，在欧洲，由于有健全的法律，高额的赔偿，强大的工会，公司一般是不怎么敢大幅度裁员的，而中国地区就成了他们开刀的地方。

当大幅度裁员后，获得了比较可观，但其实比裁一个欧洲人少得多的赔偿金后，你会发现找工作比较难了，日韩和国企你已经不适应了，那里天天的打拼如同地狱，美企好一点的则需要比较强的技术，而可能你发现你的技术能力不如刚毕业的时候了，你还记得多少的算法，操作系统，计算机网络呢？

 

美企

美企是三者之中薪水最高的企业，然而压力也相对比较大。

在这里你会发现，美国人有时候会很拼的，很认真的，甚至很较真的。美国人总是会规定一个任务完成的时间点，然而却常常是非常紧的。而且由于流程又长又复杂，时常弄得你焦头烂额。

美国人会一遍一遍拉着你和你reveiw文档，很认真的揪出其中任何不合理的地方，甚至拼写错误。

在美企，加班是经常的事情，虽然第二天早上你可以来的比较晚。

所以美企也会有和欧企一样的福利制度，然而真正享用的时间比例要小的多。

美企的天花板和欧企差不多，相对于欧企，美国企业多少还是有些等级在里面的，只不过不是如日韩企业显而易见的在外面，等级之间平时说笑，娱乐的时候是几乎看不出来的。

然而美企心中的等级是存在的，主要体现在两个方面：邮件和开会。如果一件事情所发出的第一批邮件就包括你，则说明你属于处理这件事情的主要人员，如果你被别人转发，则在这件事情中你属于辅助地位，哪怕你和他是同一个level的，因为先知情的他可以做很多的准备，更全面的信息。如果一件事情需要开会，你在第一次的邀请中，则你也属于处理这件事情的主要人员，如果这件事情分成了多个小部分，然后让你再拉上另外一些人另外开会讨论如何处理这个小部分，在这件事情上，你就是那些人的核心，哪怕他们和你都是同一个level。

这两点所有的人都心知肚明。美企有时候是强调管理扁平化的，也即事情的参与者大家没有level的差别，在这件事情上可能你是lead，在另外一件事情上他是lead，然而如果你能够很好的处理和上司及同事的关系，较多的出现在第一批发出的邮件或者第一次召开的会议中，则恭喜你，你很快就能够升职了，很快就能够脱离现在的层次，融入到另一个层次的人员的邮件和开会的博弈中去了。

先知情权如此的重要以至于可以当做政治斗争的手段，在美企，用level压人到哪里都是说不过去的，然而如果事先没有足够全面的信息用邮件发给你，在开会的时候即便临时叫上你，在没有任何思考，准备和证据的情况下，哪怕你level再高，又如何能够说服别人使用你的方案呢？你总不能说：我是高级工程师，你们都是普通工程师，你们要听我的吧。

都说中国人是讲面子的，其实美国人也是讲面子的，在大庭广众之下，他们总是对你的项目一口一个good，一口一个great, impressive。

然而在项目中，美国人可是不讲面子的，经常challenge你，作为被领导的中国一方，经常要做的一件事情就是寻找"证据"，确确实实的证据来保证自己不会被challenge。

有很多人质疑，为什么外企总是那么喜欢写文档，一遍又一遍，写到十分的细节，为什么总是喜欢写邮件，哪怕两个人就挨着坐，开会要写meetingminutes，每天要写daily report，每周要写weekly report，测试完要cc all发送测试报告，功能实现完要cc all发送邮件报告，这些都是证据啊。

当问题出现的时候，每个部门不是第一时间想着如何解决这个问题，而是首先寻找证据证明自己的清白，有时候来来回回很长很长的邮件，回复了n多人，才能解决问题。

美国大老说了，销售那面反应，这个功能不好用，则开发部门首先应该回：我们的designdocument早就发出去了，而且都review过了，当时的会议记录就是决定这样做的啊。性能测试部门说：昨天测下来，性能突然变差了，某个部门昨天提交了代码，应该是他们的问题，那个部门马上回：我们后端在代码提交之前已经做过性能测试了，报告昨天就发出去了，性能没有变差，可能是前段的问题吧。后端发现前段发来的消息不能够解析，前端应该解释：昨天我们商量的通信协议，在邮件中都能够找到啊。

当有成绩了，哪怕一点小的成绩就cc all来增加影响力，当有问题的时候cc all来证明自己的清白，实在是一道美丽的风景线。每天在开会，邮件，文档，扯皮中度过，也难怪开发效率相对民企要低的多了，好在大公司有钱，不怕时间长，不怕客户恼。而对于程序员来说，技术提高不了多少，情商却是大幅度提高了，也难怪《杜拉拉升职记》能够如此的畅销。

 

下一篇来讲外企的面试。

 

 

IT外企那点儿事(3)：奇怪的面试

 

外企的面试都面写啥？不同的企业也是不一样的，总的来说可以归结为以下几句话：

三类企业面实战，二类企业面基础，一类企业面算法。

在此声明，此处所谓的一二三类，绝没有轻视其他企业的意思，这里的一二三类基本上是按照本科毕业的时候起薪来划分的，一类企业指的是年薪15万以上的企业，二类企业指的是年薪10万左右的企业，三类企业指的是年薪5万左右的企业。当然按照上两次的描述大家可以知道，并不是起薪高的企业的程序员一定最好发展的最好，而进入创业企业的人最后可能后来居上，成为IT达人。当然此规律也不仅仅适用于外企。

 

三类企业

三类企业起薪不高，招聘的目的也相对的明确，是要找那种来了就能真枪实弹的把东西作出来的人。

他们多不太关心员工的培训和成长，不太关心员工是否对技术有浓厚的兴趣和深入的钻研，他们就是一个想法，他们要做一个东西，做这个东西需要某方面的技术，所以要找这会方面的人。

他们不知道，大多数的程序员其实喜欢做一些在自己能力以上20%的东西，也即研究研究可以做出来，但不是太熟练，而不喜欢做一些自己已经非常熟，毫无挑战的东西。

但是他们需要这样的人，所以在面试中，面试的问题比较具体，甚至具体到一个个的配置项，也有当场给你环境，让你搭一个框架，做一个东西的。

他们希望，最好你以前做过的项目和他们现在的项目十分相似，来了就能够上手。

其实很多程序员跳槽，就是因为原来的工作已经没有了挑战，想找一个更有挑战的，有更多大牛的地方，如果原来的项目我干的不亦乐乎，还来你这里干什么？

但是现在工作难找啊，所以他们总是能够找到需要的人，毕竟出来混，大家都是混口饭吃，不容易啊。

要想进入此类企业，一个最好的办法就是上手做，在学校里就可以找个实习的公司，哪怕不给钱也去(强烈谴责这种企业，剥夺劳动者的基本权利，也就在中国他们能干的出来，放到欧美罚不死他们)，先混些实践经验，做些边角料的活，然后跟着lead一步一步进入核心模块，相信只要认认真真的做过，面过这类企业应该不成问题。

此类企业的流动性相对较大，往往被用作程序员的跳板，跳到二类甚至一类的企业中去。所以不幸进入此类企业的兄弟们，在实战的过程中，别忘了多看看源码，多想想背后的原理，多补充一下计算机科学的基本知识，早日脱离苦海。

 

二类企业

二类企业其实薪水已经非常不错了，毕业就能进入此类企业的程序员也多是学校中的优秀分子。

此类企业注重程序员的基础，认为只要基础好，他们愿意培训并培养程序员，给你机会进行学习。

此类企业招聘的时候，职位有可能是不太确定的，可能是Java，可能是C++，可能是windows，可能是Linux，他们认为只要你基础好，语言不是问题，平台不是问题，培训一下上手会很快。

记得面试一家与通信有关的欧企，面试官开始问了很多C/C++的基础知识，后来问了很多操作系统和计算机网络的基础知识，最后说，他们是需要有通信背景的，然后连问我三个有关通信方面的问题，我都说不知道，最后只有坦然承认，通信我确实一点都不懂。后来我认为我是彻底没希望了，没想到后来竟收到了他们的offer，并在入职后进行了长达两个月的通信方面的培训，后来我问我的面试官怎么回事，他说，你的C/C++，操作系统，计算机网络的面试题几乎都对了，我觉得你的基础不错。

所以要进入此类的企业，有关基础方面的书还是要认认真真，仔仔细细的看，下面推荐一部分：

·        C： 《The c programminglangage》

·        C++：《Thinking in C++》，《The c++ programming language》，《effective c++》，《more effective c++》，《exceptional c++》，《more exceptional c++》，《inside the c++ object model》

·        Java：《Thinking in java》，《Core Java》，《effective java》，《Java Puzzlers》，《Java Network Programming》，《java concurrency in practice》，《深入Java虚拟机》

·        windows：《Windows核心编程》，《Windows Internals》

·        linux：《Advanced Programmingin the UNIX.Environment》，《Understanding LinuxNetwork Internals》，《UNIX NetworkProgramming》

·        network：《TCPIP IllustratedVolume I》，《The Linux NetworkingArchitecture》

我没有在装B，也不是看过以上所有的书，不过上述书籍的确是程序员必藏书，我也只不过是在用到的时候翻开相关章节看看。

然而给大家的建议是，在做项目的时候，千万不能够做什么就只知道什么，与此相关基础知识也应该多看一些。面试的时候也经常遇到这种情况，就是面试者号称做过socket，问到tcp/ip拥塞控制却一无所知，会简单使用socket client端和server端几个简单函数人太多了，如何保证你能够脱颖而出呢？

其实很多事情我们觉得不可能，但是这个世界上就是有牛人确实做到了，比如英语六级能够考99分(满分100)，就是把答案全给我，就让我写作文，我也做不到啊，再如高考满分750分，山东的状元730+分，也就意味着数理化全对，语文140+，英语140+，我的天，也是把答案给我，就让我写语文和英语的作文，我也做不到啊。

然而读以上书籍却没有上面两个例子难的不可想象，我所知道的身边的人就有C, C++, linux,network这几个分支全读过的，而且不止一个。

能进入二类的企业，混个中层，也能过上满不错的生活了。

 

一类企业

一类企业薪水非常高，毕业就能进入的可以说是学校中的佼佼者了，一般会名校背景，名企实习，甚至有过获奖的才能够进入。

此类企业除了注重程序员的基础之外，更加重视程序员的思想，算法及聪明程度。

所以很多奇奇怪怪的面试题在网上都流传出来了，这些题目真可谓费尽心机。面试过程长达n轮，每轮都可能因为疏漏和状态不佳被刷掉，最后剩下的几近完美。

在面试中，程序是要当场在黑板上写出来的，很短的时间，要求很强的健壮性，面试官还会在旁边施加心理压力，你确定吗？要注意XXX。

虽然问题是经常外流的，然而新的问题却是不断的会出，可能是因为工作中有些需要解决的问题，自己想了一天多才想出的解决方案，却抽象出来考别人，让别人在很短的时间作出来，这种心理开始很爽，后来觉得很罪恶，多少有些原来自己穷，受富人欺负，后来富了又欺负穷人的味道。

有些人会质疑，这些精巧的算法在工作中真的能够用到很多吗？答案当然不是。

这其实是一个供需的问题。马克思告诉我们，商品的价格是由价值量决定的，商品应该以价值量为基础，实行等价交换。西方经济学告诉我们商品的价格会随着供需关系的变化而变化。当供需矛盾相当大的时候，商品的价格就会远离价值量。

《经济学的思维方式》一书中写到，所有的稀缺品都需要以某种方式分配，必须建立某种规则和制度，对那些要求得到稀缺品的人加以甄别，决定谁该得到多少。价格只是最常用的一种方式。

想想我们的高考吧，那些千辛万苦考上清华的学子毕业后又有多少高中的知识留在脑子里呢？学到的东西又有多少是能够在实际中用到的呢？其实很少，高考分数不过是进入清华的一个价格而已，已经由于清华只有一所，考生却有千百万这样的供需差别远远的偏离了使用价值，毕竟能够轻松看懂教科书的人太多了，他们只能够不但要全会，还要全对。

进入一类企业也是同样的，能把我上述书籍都看完的人是大有人在的，仅仅基础知识已经不能够甄别想进入一类企业的人们，所以需要奇奇怪怪的算法题。

要进入一类企业，《算法导论》这本书必不可少，要前前后后仔细的看，而且应该不止一遍。《编程珠玑》也是一本不错的书，其中的例子可以常常的回味。《编程之美》也不错，更贴近面试，更实用一些。其实更重要的是Top coder，就是多看多练。

其实考入名校基本就是一种方法，多做题，以便在考场中看到题目就能够有思路，考场的时间仅仅用于保证正确率就可以了。

进入一类企业也是一样，要想很短的时间，在很大的压力下写出健壮的程序，其实只有一种方法，就是类似的题目遇到过，思路是马上就有的，在会议室的时间仅仅用于保证健壮性就可以了。

曾经一段时间，对精巧的算法十分的崇尚，甚至引以为豪，然而后来慢慢发现，天天沉浸在算法之中，沉浸在计算机的小天地里面，又对社会做了什么贡献呢？难道自己的才能，抱负就仅仅放在这些数字的技巧当中吗？

我们不应该像孔乙己一样研究茴香豆有几种写法，而是应该如阿朱《走出软件作坊》中描述的一样，虽然方案不是完美和精巧，然而逢山开路，遇水搭桥，真正的解决一个个的问题，作出一些可以影响人们生活的软件。

 

先写到这里，下一章要开始写入职了。

 

IT外企那点儿事(4)：激动人心的入职演讲

当你千辛万苦熬过了重重难关，进入了外企的大家庭之后，第一步便是入职培训了。

入职培训非常重要，尤其是对于公司来讲。当然并不是说入职培训有多大的信息量，能够学到多少技术和流程。准确的来讲，这是从心理上拿下你的一步。

我们知道，心理学上有晕轮效应，所谓晕轮效应是指人们对他人的认知判断首先是根据个人的好恶得出的，然后再从这个判断推论出认知对象的其他品质的现象。如果认知对象被标明是"好"的，他就会被"好"的光圈笼罩着，并被赋予一切好的品质；如果认知对象被标明是"坏"的，他就会被"坏"的光圈笼罩着，他所有的品质都会被认为是坏的。

所以面试中，好的第一印象十分的重要。自然企业也想在与员工的第一次亲密接触的时候，在员工心目中留下美丽的光环。

和生产性企业不同，软件开发企业的工作量和工作成果比较难以衡量，即便有了软件工程的各种理论。所以说要想使得工程师们全心全意的工作，自然是攻心为上的。工程师们大多是很清纯的，有时候多少有些高傲，有些古代的士的气质。士可杀，不可辱，所以通过严苛的纪律逼工程师工作是行不通的，他们完全可以坐在电脑前面装作认认真真的写出bug不断的代码。然而士为知己者死，如果能够让工程师感觉到公司是他事业的摇篮，是他可以托付未来的地方，是可以"明朝携剑随君去，羽扇纶巾赴征尘"的刘备式主公(《卧龙吟》)，则工程师们自然会视公司为己任，加班加点也毫无怨言，为伊消得人憔悴。

入职演讲所要起到的，就是这个效果。这也是很多民企和外企相比，有很大差距的地方。外国的资本主义已经十分成熟了，他们已经从马克思所批判的资本主义初级阶段中走出来，摆脱了通过延长劳动时间和提高劳动强度来榨取剩余价值的方式，而使用更加人性化的手段(如股份制，各种激励机制等，有大批大批的管理学大师在研究这个)，让员工自愿自觉的劳动。而中国大多数的民企，还处在马克思所批判的那个时代，从我评it的差评榜的各种评价就可见一斑了。

为了完成上述任务，入职培训一般包括以下几个方面：老大的自我介绍，重要的位置，光明的前途，优秀的员工，企业的文化，良好的福利，学长的自白，快乐的互动。

老大的自我介绍

在入职培训的时候，老大一般是会出来露一面的，即便不是一把手，也至少是二把手，三把手。

一般老大总是很和蔼的，脸上总是露出笑容的，以显示自己的平易近人。

其实有一个规律，不仅是在职场中，即越是和你层次差别大的人，对你反而是越和蔼的，而对你凝眉瞪眼，怒目狰狞的人，也多是比你也强不了哪儿去的人。一方面可能是老大确有老大的气度，一方面层次差别大，你对他构不成什么威胁，谅你也翻不过天来。这可能是为什么我们敬爱的伟大领袖毛主席可能可以容忍一个兵叛逃再回来，却不能容忍彭老总给他拍桌子的原因吧。

老大的名字应该是在业界早就如雷贯耳的，即便不是，当其简历摆在我们面前的时候，也足够我们五体投地。

一旦使得你对他形成崇拜，这第一步的目的就达到了。

其实这是任何成功学讲座的开篇的必然套路，即一拉一打，或两者兼有，或只取其一。所谓拉，就是列举出自己的一长串的title，以及自己的一系列丰功伟业；所谓打，就是提出一系列你原来没有思考过的，或者认为是显而易见却被说成错的问题。这两者的共同目的就是对其形成崇拜。崇拜可以使人们的判断力大降低，从而会减少你对他之后说的话的辨别能力。想象进入演唱会的歌迷的情绪吧，他们是如此的呐喊，以至于听不到歌手的声音，没关系，此时的歌唱质量已经无关紧要，关键是这个歌是明星唱的就可以了。其实那些造星的公司们早就摸透了这些心态，正如《长尾理论》中说的那样，“他们已经发现了制造大热门的秘密：把魅力四射的年轻男人卖给年轻的女人。成功的要点无非就是帅气的外表和打造的个性，音乐本身被外包给一小组专家，几乎成了无关紧要的事。”

在一片清纯而又崇拜的目光下，老大可以进行对公司的介绍了。

重要的位置

入职培训的另一个重要目的就是要培养你对当前获得的职位的自豪感。也即使你觉得你在做一件将影响整个软件业的意义重大的事情，自然事后你会觉得十分可笑，但当时，扪心自问，你是认真的。

培养自豪感的逻辑过程是这样的：

·        首先强调公司在整个IT业中的位置。如果公司能够排在整个IT业的前十位，此点不必做任何修饰。如果公司不能够排整个IT业的前十位，则会划分细分市场，直到能够排到前十名为止。如果在细分市场中能够排到第一，或者并称为几大XXX，则不必再进行修饰。如果不能，则往往冠以"仅次于XXX的XX企业"，或者当已有并称为N大XXX的时候，称为"排名第N+1的XX企业"。通过此步，多能够建立员工对企业的自豪感，能够在外面理直气壮的说出企业的名称。

·        然后强调研发在公司中的位置。IT企业中研发自然重要，然而当你和公司的市场人员接触过以后，他们却不全这么认为。因为市场人员是挣钱的，研发人员是花钱的，自然应该是经济基础决定上层建筑。然而研发人员是几乎接触不到市场人员的，所以此步需要明确的是在程序员心目中要树立只有他们做出了优秀的软件，公司才能够生存的信念。说到这里程序员们不要不服气，除了创业家作为程序员出身做公司的老大之外，还有那些企业的一把手是研发人员呢？一个统计的结果是，企业的一把手多出自两个部门：销售和财务。

·        然后应该强调中国研发中心在整个世界所有的研发中心中的位置。由于中国有廉价的劳动力和广阔的市场，很多国际大公司还是喜欢把研发中心设到中国来的，当然是以被中国很多的优秀人才吸引的名义，而总部也是比较重视中国研发中心的。然而要说中国研发中心成为整个公司研发的核心，怕你很难相信吧。中国的研发中心自然不敢凌驾于美国的研发中心之上，所以一般的措辞是，整个世界的研发中心共有N个，而美国和中国，外加另外罗列的一个或者三个研发中心成为最重要的三大或者五大研发中心。这时候，老大也许会给你看一些公司的高层在各个场合赞誉中国研发中心的语句，所有的描述如同皇帝的谥号一样，只有正面的评价，虽然他们可能对印度研发中心也说过同样的话。但没有问题，这足以使出入职场的程序员们相信这是真的，直到在项目中，他们发现只能接受美国的指令，或者没有权限参与重要的设计的时候。

·        最后要强调的是此一批入职者在中国研发中心中的位置。此处多会强调，此次招聘是高层早就计划好的一个长远的人才计划的一部分，你们进来参与的是具有战略意义的项目，这些项目将对公司的发展起到至关重要的作用，并处于同行业的最前沿，你们做出的产品将影响整个软件业。

就这样，通过步步推理，层层递进，员工似乎瞬间觉得从一个乳臭未干的学生，俨然将变成在软件业举足轻重的团队中的一员。此时的员工，眼中充满激情，心中充满渴望，如果不在此时此处付出自己的青春和热血，开启自己的事业，更待何时！

光明的前途

描述光辉的现在重要，描绘光明的未来更为重要，因为年轻人大多是为希望而活着的。

况且当前的社会是相对浮躁的，人们总是希望有某个机遇，通过某种捷径比别人更快的成功。记得鲁豫有约采访郭德纲的时候，他是这样描述他的北漂生活的：最初来北京，就是想找个名师拜在门下，说不定一次什么样的演出，就能够红了。不得不承认，本人当初也有这种心态，认为加入了一个无比有前途的公司，自己的事业能够得到指数级的增长。奇迹没有发生在郭德纲身上，世界上没有救世主，也不存在神仙皇帝，当自己没能够真正站立起来的时候，是不会有人怜悯你，给你捷径的。于是郭德纲开始了他长达十年的闯荡和积累，直到他成为了顶天立地的相声大腕。我自认为没有郭德纲的天赋，也是到后来才发现，一个人绝不会因为加入了某个组织从而鸡犬升天，绝不会埋头做好公司给你的每一件事情(并不一定都是有技术含量的事)从而随着公司的成功而成功，虽然加入一个好的公司是人生的催化剂，然而自己的路还是要自己来规划，自己的技术还是要靠自己一点一滴的积累，公司不会为你的前途负责，哪怕各个公司都有职业规划的系统，唯一对你前途负责的应该是你自己，所以当你前进的路上遇到阻碍，也一定是你过去的所为造成的，片面的抱怨公司和社会，是对自己的不负责任。记得看一期《中国经营者》节目采访京东CEO刘强东，当问到：如果你的企业将来面临失败，您觉得可能是什么原因？他回答：可能是因为我。不能不说，我们需要学习这种精神。

不过对于公司来讲，在员工心目中画一个大大的饼，还是很重要的。所以此处大多会提及技术路线和管理路线，并强调两者同样的重要(真的吗？我们以后讨论)。也会提及公司有成熟的职业规划系统，你和你的lead会定时一同规划你的职业发展，只要你认认真真做了公司给你的每一件事，自然前途大大的。也会提及公司会全面或者局部的扩张，总会有新的团队，新的项目出现，你会有很大的成长空间。

总之会使得我们相信，只要老子拼了，就能够很快升职，迅速到达成功的彼岸。

优秀的员工

任何人都愿意和优秀的人一起工作，所以必须让大家认识到，你们是最优秀的。

此处多会提及你们是从多少份简历中，选出多少进入笔试，又选出多少进入面试，最后拿到offer的，这个数字之间的比例和差额会让你大吃一惊，似乎没有想到自己原来这么优秀，悠然而生了一种自豪感。

用余世维讲座中的话来讲，当准入制度越严格，越能够激发员工的尊严。

用《影响力》一书的第三章承诺和一致原理来解释就是：履行一个承诺所要付出的努力越多，这个承诺对许诺者的影响越大。与不费吹灰之力就能够得到的那些东西相比，人们更加珍惜那些来之不易的东西。书中举了原始部落严酷的成人仪式和兄弟会入会的"地狱周"都会使人们对于部落和兄弟会更加的忠诚，也明确的指出跨国企业强化进入公司过程的难度，从而使新员工一旦进入公司，会有更高的忠诚度和自豪感。

企业的文化

每个企业都有自己的文化，其实差别还是蛮大的，然而令人奇怪的是，正如高中学校的校训多包涵团结，勤奋，诚实等词一样，每个企业声称自己的文化也基本包括以下的词汇：激情，挑战，平等，开放/公开，卓越，责任，结果，创新，诚实，尊重，团队，客户。

虽然不同的企业可以用同样的词汇，然而他们的文化却可以大相径庭。

其实每次的入职演讲中提及企业文化，仅仅是此文化传播的第一步，却远远不够。企业文化不是知识，不是告诉你就完成了交接的，正如不是你学会了东北话，就成了东北人一样。文化需要载体，既包括死的制度，更重要的是活的人，会在员工的不断入职和离职中发生微妙的变化。文化需要传承，需要在人与人的相互作用中发扬，如果一个企业最初只有100个人，作为文化A的载体，每过1年来10个人，作为文化B的载体，这10个人足够在一年内被熏陶成文化A，再过20年，当企业变成300人的时候，仍然差不多秉承文化A，然而如果第二年一次来了200个人，作为文化B的载体，则20年后，企业可能就更接近于文化B。文化是可以推动的，如上面的例子，如果企业想一直贯彻文化A，则需要小心的干预，同过正向激励和反向激励来推动文化A。文化不是一元的，文化下面多少会有亚文化，这就是为什么同样的公司有的Team很活泼，有的Team很沉闷。

良好的福利

公司的福利是会提及的，或以大幅的图片展示，或以精彩的视频放映，甚至会带你到现场去看，无论哪种方式，都会使你激动不已。

其实不过吃喝玩乐四大项，所谓吃，或是小吃，或是自助；所谓喝，无非饮料，咖啡，茶，酸奶；所谓玩，即各种各样的室内设施和五花八门的社团活动；所谓乐，则要提到每年的旅游，年会。总之slides上的每个人都是充满的快乐的笑容，预示着你将来美好的生活。

这些活动永远应该是你在公司活动的一小部分(否则你就大错特错了，买椟还珠，捡了芝麻，丢了西瓜)，而这些福利真的对你的职业生涯一点都不重要。

学长的自白

当然仅老大一人的独白不足以有说服力，员工们多比较相信和他们年岁，经历差不多的人的话。

所以有时候，会请你的学长现身说法，描绘他在公司里的美好生活和光明前程。

人在屋檐下，不得不低头，屁股决定脑袋，人站的位置决定了他说的话，当老大还站在旁边以期待的眼神看着学长在新员工面前侃侃而谈的时候，学长说的话除了在老大的描述上锦上添花，也别无选择了。所以你尽可将学长的话打五折去听，如果想进一步了解，请留联系方式，你们可以私下交流，这样就可以打八折听了。人生其实就像一场杀人游戏，唯一大概可以相信的就是被杀后的跳警，如果想了解最真实的情况，私下去问离了职的学长，再和在职的学长的描述融合一下，就基本可以描述客观的情况了。

快乐的互动

入职培训还常有的一项就是新员工之间的互动，让你早日得融入集体，感受主人翁的精神。

在被设计好的游戏中好好和大家交流，交交朋友吧，一般同一批进来的人比较容易建立更深的感情，而且当后来你们被分到不同的组里后，就很难有这种机会相互交流了，这毕竟是你在此企业中积累人脉，增加影响力的第一步，朋友将是职业生涯中最宝贵的财富。想想谁能够在一家企业待很久呢？可曾听说过跳槽的时候：一等人才找朋友，二等人才找猎头，三等人才网上搜。

先写到这里吧，下一篇写啥还没想好。

 

 

 

 

IT外企那点儿事(5)：像系统一样升级

 

 

进行完入职培训，便开启了你在外企中的程序人生了，需要说明的是，此文章不仅限外企。

如果待足够长的时间，你将从程序员，高级程序员，team lead，一直到manager，甚至director。

我们姑且宏观审视一下此过程，然后再品味一个个细节。

然而审视的过程猛然发现，所谓程序员就是把自己作为程序的人。

《道德经》第四十二章：道生一，一生二，二生三，三生万物。

此句大概说明的是宇宙万物发展变化的过程，而道则为宇宙万物运行的规律。

万事万物都有自身的规律，万有引力是规律，相对论是规律，而天天陪伴在我们程序员身边的算法，操作系统，计算机组成等，也可以看成大自然众多规律中的一小部分，也只有掌握好这些规律，我们才能掌控好计算机的运行。

系统的开发，程序员的升级又何尝不是经历了这样一个过程呢？

一、认识规律：道

做一个系统，首先要掌握此项目所需要的技术，如果相关技术没有使用过，则此项技术就是一门尚未认知的规律。在项目开始之前，必须要系统性的认知相关的技术，否则面临较大的风险。

做一个程序员，首先要掌握计算机方面的知识，对知识的掌握，同样需要系统性，否则职业生涯也会面临很大的困难。

系统性在此阶段至关重要。

如果在项目中，对相关的技术没有系统性的认识，则会造成以下后果：

·        设计出的系统不具有扩展性

·        应用了笨拙的方式设计程序

·        出现Bug时无所适从

不知道大家是否参加过这样的项目开发过程，由于时间紧任务重，项目组在没有一个人系统了解某项技术的时候就进行了开发，大家只好从网上下载一些Sample code来通过复制粘贴来拼凑程序，甚至连每一项配置或每一行代码都没搞清楚，就照猫画虎的拿过来用了，这样不但到了后期，系统几乎没有任何扩展性，并且任何不同于Sample code的灵活的改动都是一件十分痛苦的事情，项目组就像眉头苍蝇一样四处乱改乱闯，但并不清楚每一次改动的真正后果，这样要进行大量的尝试和返工，最后整的整个项目组很累，还没有效果，这个过程我称之为“盲试”，也即在不明白原理的情况下靠反复的体力劳动，逐一遍历所有自己认为可能的修改。

“盲试”是初入职场的程序员经常犯的错误，初入职场，信心百倍，情绪高涨，急于出成果是多数时候的心态，当一个任务下达到手中的时候，并不是系统的阅读文档，进行方案评估以及框架设计(这些其实都是磨刀不误砍柴工的事情)，而是急着上手来做，可能在项目的早期，能够很快的出效果，但是随着项目的进行，维护成本越来越大，经常加班，而效果甚微。而对有经验的程序员来讲，前期进行了良好的设计，后期添加模块，需求的灵活变动是相对轻松的事情。

其实也可以理解这种状况的出现，毕竟老板都是心狠手辣的，才不会给你那么多事件做调研，程序员总是有一种被皮鞭赶着走的感觉，从而根本无法系统性的掌握技术和框架设计。这也是面试了很多程序员，每每都号称做过A,B,C项目，分别应用了a,b,c的技术，然而往深入问的时候发现，他们对技术a,b,c的了解也就仅限于A,B,C项目中，对其他一无所知了。

没有系统性的认识技术，则可能写出很多笨拙的程序，丑陋的实现。因为你只知其一，不知其二，只知其然，不知其所以然，本来人家框架中有高效的现成的技术实现这一方面的功能，你不知道，于是根据自己了解的片面技术勉强拼凑成功能，自然也实现了效果，然而当自己开始看这方面的经典书籍的时候，不禁感慨：“咳，原来能够很简单搞定的，当时竟然笨笨的写N多的代码。”

没有系统性的认识技术，出现Bug的时候比添加新模块更痛苦，因为不明白原理，所以只能从表面现象去猜，然后又是进行“盲试”的过程。

因而对技术的系统性认识，实在是不但对项目负责，更是对自己负责的一件事情。如果老板是技术型的，在估计项目时间的时候，应该劝说其将这方面考虑进去，如果老板是非技术型的，则程序员也应该自己留下缓冲时间。不然你辛辛苦苦白天八小时给老板了，晚上再加班几个小时又给老板了，你自己如何进步呢？

如果对于程序员，对计算机方面的技术没有系统性的认识，同样存在上述的问题。

你的职业生涯同样没有扩展性。如果不能够系统的掌握算法，数据结构，操作系统，计算机网络，计算机组成等基础知识，在程序员的初期可能不明显，随便培训培训也能写出不错的程序，然而当转换方向或者平台的时候，会面临很大的痛苦。而我们能够看到的身边的优秀程序员们，无论让他们做C,C++还是Java，无论是linux还是windows，他们都能够很快的上手，是因为基础好的缘故。

项目和程序员认识规律的方式，其实也无非读书，文档，及原型开发(对于程序员来说，实习阶段相当于Prototyping)。

总结：项目或程序员的第一阶段：悟道，关键词：“系统性”

二、道生一

当掌握了项目相关的道，也即技术的时候，就要真正的进入项目开发了。

当前的项目，仍然由一个进程组成的系统比较少了，由于数据量的增大，基本都会开发多节点的分布式系统，然而再复杂的系统，也基本是从单节点系统开始做的，也即所谓道生一的过程。

当掌握了计算机相关技术的时候，你就可以成为一个真正的程序员了。当然不可能让你一开始就管理一个项目组，此时唯一要管理好的，是你自己。

开放性和扎实性是此阶段的重中之重。

对于项目来讲，一个好的单节点系统，所谓开放，就是即便设计单节点的系统，也要站在设计多节点的系统的角度来考虑，使做出来的系统更加容易被扩展成多节点的系统。所谓扎实，就是单节点系统要麻雀虽小，五脏俱全，扎扎实实的实现大部分功能，并有相当量的测试用例来保证功能的正确。

否则会造成以下后果：

·        当做多节点系统时候，发现单节点系统需要大量修改，甚至等于白做，重新开始。

·        单节点不稳定，以至于多节点时Bug丛生，但不知道是因为错误出在多节点实现部分，还是单节点部分，较难定位。

·        没有足够的测试用例，当为了多节点进行修改的时候，不能保证的功能实现仍然行为正确。

假设做一个100个节点的项目，要100天时间的话，并非每个节点要1天的时间，而是第一个节点就需要30天的时间，当第一个节点做好之后，扩展后面是很自然的事情，然而如果第一个节点做不好，每天都做一个节点，每天都把昨天做的设计推翻然后重做，怕是100天也完不成100个节点。这个例子比较极端，然而在我们周围没有发生过吗？

对于程序员来讲，做一个好的螺丝钉，同样需要开放和扎实。

所谓开放，就是我们虽然仅仅是最最低级的员工，可能整个系统的架构根本轮不到我们，但是这并不表明我们只盯着自己的一亩三分地，完成功能了事，而是要经常站在整个项目的角度考虑问题。不想当将军的士兵不是好士兵，建议做一下几件事情：

·        在项目的各种会议上，经常站在项目经理和架构师的角度考虑问题，要是自己会如何设计，前辈们为何这样设计，然后多问前辈问题。虽然最初的想法比较幼稚，但可以不说出来，但是长时间这样思考，会发现自己的设计水平会突飞猛进的，慢慢的，你会发现你能够在会议中给出一些建议，然后你会发现能够发现前辈设计中的一些缺陷，然后你会发现你能够对当前的设计提供恰当的改进方案，终于有一天你发现你不再是一个单节点的普通程序员了。

·        除了完成自己的功能外，多看一看前辈们实现过的代码，用自己的方式手绘一些他们的架构图，记下不太明白的部分及觉得很优秀可以借鉴的部分。

·        尝试在自己的模块中(可能最初是很小很小的模块)尝试使用学到架构。

·        可以重读或新读一些经典书籍，争取能够用业界内公认的理论来解释自己接触到的设计及架构，使得从感性认识上升到理性认识。比如原来前辈们写这些类，用的是这种设计模式，它还有以下的优点和缺点，适合设计怎么样的系统。这样不但有利于我们在以后的项目中恰当的使用已掌握的设计，而且也有利于向他人准确的描述项目。试想在面试中，一个专业术语要比杂七杂八的列一大筐类更显水平吧。

·        可以在餐桌上，向自己的同学，朋友描述一下学到的架构，让你的朋友往细节里问，不确定的回去再下功夫，争取做到虽然你只是项目中的一个螺丝钉，但是好像你从头到尾设计了这个系统一样。

这里要提醒一下大家，并不是所有的上司都喜欢要当将军的士兵和老问问题的员工，适当把握火候吧。

所谓扎实，就是指对接触到的知识，都应该根据实践，结合理论，由点到面的掌握。在这个阶段，信息量是很大，要学的东西很多，往往对各种技术都接触一下，又对各种技术都浅尝辄止，最后形成样样通，样样松的局面，阻碍了自己的发展。面试的时候也经常发现一些应试者，掌握的东西仅仅局限于他做过的那个点上，相关知识的掌握非常弱，这自然会影响他从一个单节点程序员向多节点发展。因而每当在项目中接触到一方面的东西，除了上班完成项目外，下班后多看一些有关此方面的书，博客等，使得从知识点变成知识面，知其然，还要知其所以然，并了解存在的问题。当白天在MFC中拖完控件后，总应该读一些《深入浅出MFC》来了解其机制，读一下《windows核心编程》了解一下windows API及一些原理，最好读一下《windows internals》了解一下原理背后的故事，不然面试的时候如何向别人开口做过windows下的程序设计呢？总不能够创建过socket对象就声称会socket编程吧，至少看一下《UNIX Network Programming》。用过NFS怎么不把linux的filesystem的机制了解一下呢？

当然这样是很累很费时间的，然而刚毕业的我们，没有经验，没有人脉，没有资金，有的不就是时间吗？

珍惜刚毕业的这几年多多打实一下基础，等年纪大了，精力没这么旺盛了，很多事情要照顾了，还要靠这时候的老本啊。

总结：项目或程序员的第二阶段：道生一，关键词：“开放性”“扎实性”

三、一生二

对于项目来讲，当单节点系统足够稳定的时候，是应该向client/server或者master/slave结果扩展的时候了，也即一生二的过程。

对于程序员来讲，当你已经足够胜任个人工作的时候，是可以带一个实习生或者初级程序员了。

此步的关键即"communication"，沟通。

对于系统来讲，主要考虑的应该是节点之间如何通信，如何协作，采取何种协议。

·        通信可以是面向连接的，也可以是不面向连接的。可以是同步的，也可以是异步的。

·        通信是分层次的，不同的情况应用不同层次的协议，heartbeat用何种协议，内部数据块传输用何种协议，发布成service向外提供服务用何种协议，都是应该考虑的。

·        数据的内部结构就想接口一样是要通过沟通商定的，便于解析又易于扩展，rpc? serializedobject? xml? json? protocol buffer? 还是自己定义的格式？

·        对于要经常访问的客户端，连接池是必须的，每次建立连接是很耗时的

·        服务器端应该有对连接总数的限制，以及请求的分发，拥塞控制(并不一定是网络拥塞，而是某个阶段的处理相对较慢)

·        通信模块在项目中不应该是任何两个需要通信的模块都要开发的，而是应该作为基础性模块，经过大量的测试后达到稳定，使得需要应用通信模块的人员能够集中精力在本身的逻辑上，当模块间协作出现故障的时候，不用担心是通信模块传错了的问题。

对于程序员来讲，同样要考虑和实习生或初级程序员之间的通信协议问题。

有的代码自己觉得写的很清楚，但是让新手上手的时候，如何能够准确的描述你的思路，想法，设计，遇到的困难呢？如何根据对方的反馈确认对方真实了解了你所表达的信息呢？有很多有经验的程序员，由于天天面对着电脑而疏于和人的沟通，可能会一肚子能耐却说不出来，非常可惜；而对于新人，他的回馈是懂了可并不一定代表他真的懂了，也可能是不懂又不敢说。

·        重要的问题的沟通应该是同步的，也即面对面沟通，这样除了语言上的反馈，还能通过表情得到一定的反馈。任何问题都要事先划分为若干阶段，最好脑子中有张拓扑图，后一阶段的理解会依赖于前一阶段的理解，一股脑把所有的信息放在对方面前，任何人都会晕。每经历一个阶段，都要收集一次反馈，作为信息的发送方，可以通过事先准备一些关键点的问题来检测对方是否真正了解，作为接收方，可以通过"你的意思是说。。。"等以自己的方式重复对方的表达来进行反馈。

·        注意拥塞控制，每一次的讨论争取一个小时内完成，再长效果会下降，接受者感觉信息被塞了满满一脑子，没有头绪，难有清晰的思路了。

·        每次沟通都应该至少有会议记录和部分结论，不然讨论等于白讨论，否则会发生团队经常开会，但是总在讨论同样一些问题，感觉上好像每次都在头脑风暴，其实效率很差。

·        对于重要的结论应该是面向连接的，也即书面(邮件，文档，wiki)告知，并有书面回复(ok, I am following the bug XXX)。

·        可以建立一些连接池，也即沟通的特定上下文。经过一定时间的团队磨合，可以下意识的创造或达成共识的一些词汇来代替一定的上下文，可以提高沟通效率。比如"明天甲系统出report"，则程序员明白要有单元测试覆盖率报告，QA明白要有当前bug的报告，性能测试组应该有甲系统性能测试报告。

·        沟通也是分层次的，最容易犯的错误的无论针对谁，写的文档，发的邮件都是一样的。其实针对不同层次的人，应该提供的信息不同，对于本团队人员，原理，架构，设计，测试，每步怎么做，结果如何，具体数据都应该说明，而对于其他团队的人员，具体的数据和每步怎么做就不需要了，对于项目经理，仅仅说明原理，架构，结论就可以了，对于高层来视察工作，原理加结果就行了。这也是为什么一篇文档有abstract,  summary, overview, concepts, detail, appendix等等部分，其实是对不同的人员看的。

总结：项目或程序员的第三阶段：一生二，关键词：“沟通”

四、二生三

对于项目来讲，当Client/Server或者Master/Slave已经运行稳定，是应该开发一个Master多个Slave的时候了，即二生三的过程。

对于程序员来讲，当你能够很好的带一个实习生或者初级程序员的时候，是可以成为一个小的Team lead了。

此步的关键是load balance，平衡。

对于系统来讲，负载均衡最重要的是两个目的：

·        高可靠性：当一个服务器crash的时候，不至于影响对外提供服务。

·        高性能：多台服务器可以并行的做事情，提供服务，加快相应时间。

其实说到底，负载均衡采用的是Data partitioning(数据分块)或Data replication(数据复制)的方法。数据分块即按照某种策略，将某类请求全部指向某个服务器，比如说按照时间分块，例如邮件备份系统，可以将某个时间段的邮件全部放在一个服务器内，对这个时间段的查询全部指向此服务器；再比如按照地区分块，例如地图信息管理系统，将某个地区的数据全部放在一个服务器内。数据复制即将同样一部分数据复制多份，放在不同的服务器上，既保证高可靠性，又能将请求平均的分配给多个服务器，例如Google File system中将数据复制三份，大型网站的服务器也一般会将同一内容放在不同的服务器上。

对于程序员来讲，沟通同样重要，但是不再是局限于一对一的沟通了，不再是能把问题表达清楚就可以了，而是要在团队内部保持平衡。无论是工作压力，项目有趣程度，培训机会，成长机会都应该平衡。

也无非是两个目的：

·        高可靠性：项目不会因为一个人的生病，休假，离职而影响项目的进度。

·        高性能：整个团队的力量发挥出来，不至于一个人成为了瓶颈。

所采用的不过也是数据分块和数据复制的方式。

所谓数据分块，即不同的人负责不同的模块，比如一个负责前端，一个负责后端，或者一个负责开发，一个负责测试等，这能够带来高性能，因为每个人的专业化和经验会使得效率提高，但是同时带来的问题是高可靠性，如果转负责这个模块的人离开，换一个人将大大降低效率。工作压力也不能很好的平衡，往往一个系统的初期阶段，后端的开发十分忙，而前端相对较闲，而到了后期，前端开发非常忙，而后端已经稳定，因而较闲。况且，人不是机器，是有边际效应的，当负责一个模块时间一长，兴趣会大大降低，觉得没有成就感，成长也少了。因而数据复制的方式也是必要的，也即通过伙伴开发，Knowledge sharing，code review等方式，让不同模块的人之间相互了解对方的模块，从而带来高可靠性，也即一个人不在，其他的人可以较快的跟上，也可以在一个模块压力大的时候，其他人帮忙做一些辅助的东西，比如各种tool，测试用例，性能测试，甚至改一些优先级较低的bug，不仅平衡了工作压力，而且接触新的模块会使得员工有较大成长，也是工作更加有趣。

总结：项目或程序员的第四阶段：二生三，关键词：“平衡”

五、三生万物

如果道生一，一生二，二生三是质变的过程，则三生万物是量变的过程。

对于计算机系统来讲，如果一个master能够很好的平衡两三个slave，则可以很好的扩展到十个甚至百个，千个。但是原理是理想的，现实却是，当master管理的slave的数量达到一定的数目的时候，master就是一个瓶颈，master的高性能和高可靠性又成了问题，这时候可以用多个master进行数据复制从而负载平衡，也可以使得多个master每个管理一个group的slave，这时候就应该有master的master了，也即系统出现了分层。Hadoop的Multirack cluster就是这样的一棵树。

对于团队的管理也是同样的，每个人的直接管理精力在10个人左右，多于这些人，往往会有很多疏漏的地方，或者疲惫不堪，因而，当一个团队成长的一定的程度的时候，也是需要分层的。当团队增长的15至20人的时候，应该考虑从现有的人员中选出master，也即team lead或者至少是coordinator，使得组织也成为了一棵树装。

总结：项目或程序人生的第五阶段：三生万物，关键词：“分层”

 

 

 

IT外企那点儿事(6)：管理路线和技术路线

 

技术路线和管理路线始终是每个程序员纠结的问题，也是各大论坛经常被辩论的问题。

然而一个有趣的现象是，在现实生活中，人们多愿意承认自己不精通某项技术，却很少有人愿意承认自己不能做管理。技术方面有问题多能够校正自我，而管理方面有了问题却总认为是对方的错，总之领导怨员工，员工怨领导，闹得不可开交。

在中国传统的官本位的思想中，不能不说管理路线占了绝对性的优势，尤其是在稳定的外企，管好管坏极难衡量的情况下。

做技术苦啊，相比于管理路线，有如下的弱势：

 

首先，IT业的技术变化太快，弄的技术人员疲于奔命。年轻人可以每天晚上几个小时的看新技术的书籍，而年纪偏大的你上有老下有小，做饭，洗衣，陪老婆，照顾老人小孩，逛超市，每天能有一个小时的学习时间十分不易了。如果是你已经很熟悉的领域，你自然可以用较少的时间就能达到年轻人较长时间看完的东西(理想状态下)，然而公司的项目所用的技术方向可不是随你心愿的。如果你是一个Java高手，碰巧公司买的一个第三方的库是用C++写的，需要对其进行封装，如此艰巨的任务，工程师中你的薪水最高，你不入地狱谁入地狱啊。你总不能说：我只负责Java的部分，C++的别来找我吧。

 

也许你经常听领导说：“编程主要靠思想，语言和平台无所谓”。然而如果你跳槽的时候，却经常听到面试官这样说：“好像你没有太多这方面的经验嘛”，你却不能以我很有编程的思想来回答。此矛盾之处着实使人困惑许久。技术路线还是分很多的方向的，正如武林有很多的门派。语言，操作系统等属于内功，然而只有内功却不足以行走江湖，必须还要有一定的套路，如Debugtool，profile tool，出现问题后的分析办法，编程时候的各种习惯，一些非常管用的技巧等，都是因语言和平台不同而不同。虽然对于初级的工程师来说，这些不是很重要，然而工作三年五年之后，是否能够熟练运用这些套路来准确的定位问题和解决问题，却是区别你是初级工程师，还是高级工程师的一个标志。当然当你在上升到项目经理的时候，又可以只谈编程思想的时候了。一句实话，一个要饭的不要因为听富人说吃青菜养生就见肉也不吃。周易中，同样在乾卦，同样元亨利贞，初九则应潜龙勿用，九五则可飞龙在天了，不同的位，同样的话，意义不同。

 

其次，没有优先知情权。当任务到来的时候，美国那面的老大一般是先发邮件给项目经理的。项目经理会进行一系列统筹考虑后再选择发给那些人。作为同项目经理同一级别的技术人员，是否提前或同时，甚至晚于与其他技术人员收到邮件，取决于你技术外的能力(你的reputation, 你和项目经理的关系等)。上面的文章也说过了，在外企，邮件是一门很大的学问，也决定了从属关系。把本来你擅长的任务先发邮件给他人，从而变成了他人的任务，也不是不可能的事情。当然当美国老板过来的时候，陪同和展示成果的，也多是管理人员的事情，虽然里面全是你的心血。

 

其三，没有资源支配权。项目经理一般可以支配多种资源的，如买硬件，Teambuilding的经费，培训的机会等。但是相同级别的技术人员却没有。

 

其四，没有绩效评定权。任何员工的绩效都是基本由其report得顶头上司起决定作用的。相同级别的技术人员可能会有一些评价做参考，但是你不会知道和你平级甚至下级的薪水和绩效。

 

最后，没有人事任免权。一个员工是否能够进某个项目组，也基本是项目经理起决定作用的。一般的外企都会有推荐的制度，而通常会发现一般状况下(被推荐人不是明显的差)，管理路线的人推荐到其他组的人比较容易录取(同组推荐没有推荐费啊)。大家总要多少照顾个面子嘛，万一哪天要向对方的组推荐自己的人呢？

 

基于上述几点，经济基础决定上层建筑，你也就怪不得基层员工对你仅仅是因为技术而产生的尊敬，而对manager则是因为既威且信而产生的敬畏了。也许其实是你的建议是正确的，大家却都同意按照manager的来做；也许你一把年纪还要和年轻人因一个小小的设计争得面红耳赤，而他在manager面前总是yes, ok, i am 100% agree；也许你因一项新技术不很精通而被新人鄙视；也许就没有也许。

 

当前的中国是浮躁的，以上的原因造成大批大批的人涌入管理路线的独木桥，也造成了一些不合格的管理者走上了管理岗位。也许有这样的现象，明明在国外仅够做高级工程师的在中国做了Teamlead，却在和普通工程师争功劳；在国外仅够做Team lead的，在中国做了manager，却不能很好的领导多层化的组织结构。

这种情况是悲剧的，却不仅仅在软件业，包括高校(系主任更容易拿项目)，包括医院(院长更容易申请经费)，包括研究所。

 

这也是为什么总有转管理，转售前，转销售，甚至转其他行业的论调的原因了。

其实技术路线也有它的好处，你可以埋头认认真真研究自己感兴趣的技术，两耳不闻窗外事。而由于一直没有放下技术，跳槽也相对容易的多，毕竟在中国，号称会管理一个团队的一抓一大把，而真的很有经验的技术人员却不是很多。

作为软件工程师，我们应该找到一条属于我们自己的路。

让我们来看上述三条曲线，是随着时间的推移，收入的变化。

 

很不幸，技术人员的收入曲线基本成C曲线状，也即刚开始收人较高，也能较快增加，后面随着时间的推移，收人增长略显平缓。

 

这主要是技术更新迅速的结果，设想从工作开始，就接触某项技术和某项框架，逐渐的掌握直到精通，到了十年的时候，正是规模效应开始体现的时候，可惜，此框架已经不流行了，已经淘汰了，行业中已经使用另一种语言或者框架了。也许你会说，以我十年的经验，对于新的框架也会更好的掌握。是的，我承认，然而由于框架的更新，你所谓的更好的程度，相对于刚接触新框架两三年的人来讲，公司不足以付给你另外7年经验所应给的薪水，毕竟，你也不是很熟。所以C曲线的形态显示出来了，由于技术的更新，你所得到的薪水增长远远低于你的经验所应该带来的薪水增长。

 

原因就在于：不易积累。

 

积累，尤其是对我们普通人来讲，是非常重要的，是最后成功的重要途径。当我们看《大家》栏目的时候，其实我们可以看出，这些成功人士基本上分两种，一种是天才，很年轻就能够取得很伟大的成就，当然我们不可能是这种人。另一种是泰斗，即靠多年的积累而取得的最后的成就，比如2008年获中国国家最高科学技术奖的吴征镒院士，被称为中国植物的“活词典”。虽然我们不期望能够成为大家，但是他们的精神和经验却能给我们启迪。像植物，或者是医生，是相对比较容易积累的行业，吴老可以在90高龄，如数家珍的说着自己年轻的时候积累下来的各种植物的知识。而工作十年的软件工程师，却难以启齿十年前的语言和框架，那已经out了。

 

这也是为什么很多销售的同学最后薪水会越做增长越快的原因。比如他们培养一个客户能得来收入1000元，随着客户的不断积累，手中有20个客户就有20000元。而软件工程师，看了10本fortran的书，得到一份1000元的工作，后来又读了10本Java的书，再加上经验，可能得到1500元的工作。

 

所以，我们也要学会积累，争取从C曲线变成B曲线，使得我们积累的经验能够带来相应的薪水。所以本人窃以为(仅供参考，自己的路还是要自己走)，有至于从事技术的软件工程师，尽量选择一些可以积累，相对稳定的方向，如Linxu内核，windows driver等，相信一个做了10年的Linux kernel工程师，绝不是一个可以读几本书就能够赶上的人。而很多流行的上层框架，如SSH等，如果你熟悉了它们的每一行代码，当Web开发开始使用其他框架的时候，岂不悲剧。(没别的以上，也希望SSH青春常在)

 

然而如果在事业的后期，想成就A曲线，就不是容易的事了。

 

当你想以较少的经验积累获得较高的收入，则必须要有放大器的作用，这种放大器我们经常能够接触的到，即营销。

很多研发人员十分鄙视管理和销售，营销。然而我认为，我们可以不从事管理和销售工作，然而我们最好了解一些人与人之间的交流规则，而非天天埋头于人与机器的交流规则。

 

可以举几个例子，比如我们卖烤鸭，当我们做的不好吃的时候(技术不好)，一只烤鸭卖5块钱，慢慢的我们有经验了，能烤出好吃的烤鸭了，也就能够卖10块钱，再加上好吃的调料，良好的环境，最多也就一只20元，到头了。而全聚德的烤鸭198元一只。

再比如，普通包子铺的包子5毛一个，你如果能够做的好吃1块一个，也就差不多了，而天津狗不理包子一个10多块，20多块。

这就是营销的作用，这就是品牌的力量。

也就可以理解为什么李开复要给大学生写信了，从而创新工厂即便比原来薪水少，即便每周工作60小时，也有大批程序员欣然而往。也就可以理解各个公司的老总总是不定时的出现在电视上，不断重复着自己成功的故事。

 

程序员不应该老待在自己的圈子里面，埋头做着自己的事情，而是要想办法扩大自己的影响力，多交朋友，多参加技术会议，多参加各种聚会。

有很多人抱怨，刚毕业就要工作经验，诸葛亮没有工作经验，不也成功就业了吗？《三国演义》中是这样描述诸葛亮的"或驾小舟游于江湖之中，或访僧道于山岭之上，或寻朋友于村落之间，或乐琴棋于洞府之内，往来莫测，不知去所"。这那是隐居啊，不出茅庐而名声在外，工作也是至交徐庶鼎力推荐的，卧龙先生可不仅仅是束发读史书啊。

 

总而言之，窃以为，做一个程序员，一要钻下去，积累技术，二要跳出来，影响世界(虽然只是一点点)。

 

 

IT外企那点儿事(7)：做一个优秀的基层

 

千里之行，始于足下，无论你有多么的豪情万丈，总要从最基础的东西做起。

然而要做一个好的基层工作人员，并不是低头认认真真写好代码就可以的，其中可大有学问。

按照余世维所论，一个好的下属应该：

·        主动向上司汇报你的工作进度——让上司知道！

·        对上司的询问，有问必答，而且清楚——让上司放心！

·        充实自己，努力学习，才能了解上司的言语——让上司轻松！

·        接受批评，不犯两次过错——让上司省事！

·        不忙的时候，主动帮助他人——让上司有效!

·        毫无怨言的接受任务——让上司圆满!

·        对自己的业务，主动提出改善计划——让上司进步！

我也总结了如下几点，欢迎大家补充。

(1) 做得快还是做得好？

当前的项目管理中，多是强调结果的，号称结果导向或者结果驱动。

作为一个基层，做人重要，做事更重要，除了良好的沟通能力，能拿得出真金白银的成果，更是每个项目经理愿意看到的事情。

然而怎么叫好的结果呢？

一九五八年党的八大二次会议上，提出多快好省的建设社会主义。多快好省四个字即体现了前辈革命家的理想壮志，也成为后来中国管理者心中的梦。所以我们时常听到如下的话："这些功能下个月一定要出来"，"代码质量要高，要有详细的注释，测试用例，code review"，"最好提前一周至少三天，可以准备demo"，"项目现在经费相对比较紧张，希望大家克服一下"。

然而现代的项目管理给我们画出了如下的三角形：

范围，预算，时间三者相互制约，牵一发而动全身。欲范围大(多)，就应该增加项目预算(不省)，如增加人手，增加资源，买第三方成品，或者应该延长时间(不快)，如推迟release的时间等。欲按期完成(快)，则可以增加预算(不省)，或者减少功能(不多)。

然而现实中，老板可不这样想，预算是早就做好了的，时间也是确定了的，功能缺一不可，作为基层的程序员我们唯一可以影响的就是用加班换来更多的时间，当然还有中间的一个圆圈——项目的质量。

到底是尽快的做出一个实现基本功能但设计稍有缺陷，测试不太完备，有少量的Bug的版本出来然后慢慢改进呢，还是经过慢慢的精心设计，做出有完备的测试用例，经过严格测试少有Bug的版本呢？

这个问题如果你问程序员，大部分人会选择后者。尤其对于初涉职场，充满激情的程序员们，往往满脑设计模式，满口软件工程，几乎见不得注释中的错别字和没有覆盖到的测试边界，似乎一个不完美的方案就有辱于软件工程师的名号了，我们称之"技术洁癖"。

如果你问项目经理，也会告诉你后者，而且最好以后者的形式用前者的时间(多少有些多快好省的味道)。然而很少有项目经理会直接看你的代码，更不关心你用的何种设计模式，也不会一个个看你的测试用例来思考是否覆盖所有的边界，更不会看你写的注释了。

所以很不幸，除了少数精通技术，熟悉细节，了解程序员苦衷的项目经理外(这可是大多数程序员都翘首以待的领导啊)，大部分喜欢前者。

因为精心的设计，良好的文档是需要大量的时间，完备的测试用例的代码量几倍于实现本身，功能测试，性能测试以及Bug的修改更是难以估计时间的，所以总的时间将几倍于前者的时间，在此过程中，你献给项目经理的，除了等待，还是等待。

人是不喜欢等待的，尤其是很少反馈的等待，当我们用windows的时候，往往会出现估计时间相当不准确的进度条，然而我们还是喜欢看着进度条一直走到底，同样项目经理也是。

总是能够很快的做出项目经理能够看到的版本，便容易给人一种能力很强的感觉，至少大部分人会这样认为。

也许你会说：我做的版本Bug很少，后期维护成本低，QA一测不就能够看出孰优孰劣来了吗？

仍然很不幸，在大多数人看来，你一个月做了一个稳定的版本被认为是做了一件事情，而别人两个星期做了一个不稳定的版本，后两个星期改了三个Bug是做了四件事情，而且其每次的会议总有进度可以说，成绩斐然。

而且一个人身上所挂着的Bug的个数，实在不是一件值得羞愧的事情，反而是一件令人感到荣耀的事情，这说明了你重担在身，举足轻重。

如果你做了一个模块，用了一个月，后来半年都不曾出过Bug，而另一个人做一个模块两个星期，出过多个Bug，并且后来兼任其他模块的时候还在改Bug，还是很不幸，你会被认为所做的模块相对简单，不容易出Bug，并随着项目的进行而被淡忘，会被这样提及："他在半年前做过一个项目"，而另一个人却会被认为所做的很复杂，有很多疑难杂症，而且后来会被认为身兼数职，会这样被提及："随着能力的提升，同时维护并负责多个模块，有并行工作的能力，有很强的解决问题的能力"。

也许你觉得我说的太极端，那就举一个历史上的例子吧，有兴趣大家可以看李亚平的《前清秘史——入主中原之路》，其中是这样描写当时并称“南戚北李”的两位将军的：

李成梁屡立大功，受封为伯爵，跻身于帝国贵族行列。在当时，他的地位、名望等，很有可能已在戚继光之上。有一种看法，包括《明史》的作者们认为，恰恰因为戚继光威名太盛，坐镇蓟门十六年，使敌人从来不敢来犯(没有Bug啊)，于是转道入侵辽东，才给了李成梁屡立战功的机会。张居正死后，新政被废，受到张居正支持重用的戚继光被迅速边缘化，在郁郁寡欢中死去(可能明朝认为蓟门这个模块不需要再维护了)。而李成梁，他同样受到过张居正的支持和倚重，然而，可能由于下面的三个原因：其一，远离京师，与张居正没有过多的私人交往；其二，赫赫战功给万历皇帝留下了深刻印象(每次总有进度可说)；其三，动荡不安的辽东局势离不开这位骁将(辽东模块还需要维护啊)。从而，李成梁避免了池鱼之灾。

当前社会中，不是如此吗？是修了坚固的河堤的市长感动中国，还是和民众一起抗洪抢险的市长感动中国呢？是治理的地方路不拾遗的公安局长应该升职，还是让黑社会猖狂十年然后一举击溃的公安局长会升职呢？

如果你觉得你的项目经理英明过于历史甚至当朝首辅，那么恭喜你。

(2) 有问题要尽早喊

当一个模块或者一个任务交给你的时候，可能存在各种各样的困难，会出现各种各样的问题，需要各种各样的资源，这一切都应该慎重考虑后尽早提出。

问题的尽早提出，其实是风险控制的一种手段。

调配资源，排除干扰，风险控制是一个项目经理的重要责任之一，然而不要认为项目经理会英明神武到知道一切细节，也不要认为这是项目经理的事情，与你无关。其实一个模块，真正了解细节的是你。

所以对团队来讲，事先问题没有提出，到时候出现是你的甚至你的团队的责任，问题及早提出了，项目经理向相关人员请求资源，到时候没有解决就不是你的责任，甚至也不是你们团队的责任了。这个样子既帮助你的项目经理控制风险，又能够在外国人面前撇清责任，是每一个项目经理都欢迎的事情。

对你个人来讲，问题及早提出了，以后或有Bug，或有delay，都不会给人一种突然的感觉，也给项目经理一种对你，也对整个项目可控的感觉。

从心理学上来讲，人们多惯于先听坏消息，再听好消息，而不愿意先听好消息，再听坏消息，这就是我们常说的冷热水效应：一杯温水，保持温度不变，另有一杯冷水，一杯热水。当先将手放在冷水中，再放到温水中，会感到温水热；当先将手放在热水中，再放到温水中，会感到温水凉。

一个经常举得例子是：某汽车销售公司的老李，每月都能卖出30辆以上汽车，深得公司经理的赏识。由于种种原因，老李预计到这个月只能卖出10辆车。深懂人性奥妙的老李对经理说：“由于银根紧缩，市场萧条，我估计这个月顶多卖出5辆车。”经理点了点头，对他的看法表示赞成。没想到一个月过后，老李竟然卖了12辆汽车，公司经理对他大大夸奖一番。假若老李说本月可以卖15辆或者事先对此不说，结果只卖了12辆，公司经理会怎么认为呢？他会强烈地感受到老李失败了，不但不会夸奖，反而可能指责。在这个事例中，老李把最糟糕情况――顶多卖5辆车，报告给经理，使得经理心中的“秤砣”变小，因此当月绩出来以后，对老李的评价不但不会降低，反而提高了。

(3) 用Bug来说不

不知从何时开始《致加西亚的信》以及《没有任何借口》此类的书开始畅销，从而以执行力的名义把责任全部推到被领导的一方，用军队的方式来要求自己的员工，不讲条件，没有借口，从不说不，来完成领导所给的任务。真不知道资本家有什么资格这样要求自己的员工，作为军人为祖国献身后至少能够成为烈士，家人受到抚慰，而资本家在员工连跳九人的情况下却在论证这个数字其实低于全国平均自杀率的。

然而大多数的领导的的确确喜欢没有借口的下属，也不喜欢听到说不。所以当一个任务下达的时候，或者一种方案被指定的时候，不要直接说不。

领导毕竟是领导，能做到现在的位置，毕竟有强于你的地方；领导毕竟也是人，提出的方案也可能是拍脑袋拍出来的，也许会有不合理性。

然而需要记住的一点是：上情下达可以拍脑袋，下情上达则要用证据。

当你认为领导给的任务或者方案有问题的时候，除了上面提到的喊难在前之外，一定要加一句，"我试试看"。

当你经过实验测试，有数据或者日志足以证明你的结论的时候，可以尝试说，"我觉得可能有些问题"。

然而有时候简单的测试并不能够证明的时候，或者领导再次坚持的时候，那就上手做吧，只是别忘了做的有扩展性一些，能在多种方案之间较容易的切换，并将领导坚持的方案暴露出来。当测试人员发现问题的时候，将比你说不有效果的多。这时候领导关心的便是如何Bug进行修复，不在纠结到底应该采用你的方案还是他的方案了，当然此时你千万不要得意洋洋的指出领导原来方案的不合理性，你不指出，领导其实是从心里认可了你的方案的，并且为你记了一功，如果你指出来，就适得其反了，大部分领导绝不会表面承认自己的错误的，可能会再次坚持自己的方案的合理性，并把因此带来的项目失败或者delay记在你的头上。也许大家清晰的记得曹操不承认"鸡肋"的退兵禁令而杀杨修的故事吧。如果你觉得你的领导气度大于曹操，那么再次恭喜你。

也许你会说：这不是浪费了一个过程吗？其实不然，你先做了领导的方案，然后改Bug的时候应用了自己的方案，在领导眼中，你是一个好的下属，好的执行者，你是做了两件事情的。

如果你坚持做了自己的方案而没有优先用领导的方案，则会有以下风险：

·        你永远失去了证明你的方案优于领导的方案的机会

·        你会被认为固执，难于沟通，执行力差

·        一旦你的方案出现问题，你将单独的承担责任，甚至整个项目delay的责任。如果你优先采用了领导的方案出现问题的时候，一般合格的领导会勇于承担起责任，替你说好话："我们采取的方案是相对较优的，也是经过测试的，Bug是难免的"，相反，如果你固执己见，则没有人会替你说话，反而会说："要是用原来的方案就不会出现这个问题" 。

·        领导的方案一般是由一定原理上合理性的，你的方案可能是比较符合你的实际需要，然而当时过境迁，context不在的时候，你百口难辨。

所以，毫无怨言的接受任务——让上司圆满，如果有问题，让Bug来说。

(4) 该干什么的时候干什么

在外企，一个常说的词叫"professional"，何为职业化，一个通俗的说法就是，该干什么的时候就干什么，当然无论干什么，永远不要忘记，你是一个程序员，一个基层的程序员。

前面说过，除了写程序，外企的生活是丰富多彩的，健身，按摩，小食品，饮料，旅游，年会，各种协会等等不一而足，而且外企的氛围是相对宽松的，你可以在任何时间尽情享用，没有人会有意见，当然是在你完成了工作的基础之上的。

然而永远需要记住的是，写程序才是你的天职，而多彩的生活是公司对员工的福利，是一种施舍，说的不好听一点，公司花钱请你来是写软件的，不是让你来娱乐的，公司让你娱乐是给你脸，你总不能给脸不要脸吧。话说的难听一点，但细想想，话糙理不糙，试想如果项目经理每次来巡查的时候都看到你或大声的说笑，或尽情的饮食，或玩桌上足球的时候，其内心不会有上面的想法？只不过是一种优雅的方式表达出来罢了。比如走到你的面前，微笑着问："你的feature做的如何了？"，"Bug XXX有没有结果？"，顺便强调一下你所做的模块的难度和重要性："你做的这部分比较有难度，是对你能力的挑战"，并在最后来一句："慢慢做，不着急"。你可知晓此彬彬有礼下面的深意？经理两次到你这里来说"不着急"的间隔越短，其实是说明这件事情越着急的。

所以说在办公室的大部分时间，你都应该低头写程序，谈话也要讨论技术问题，娱乐要适度，除非你想被人觉得工作量太少，不努力，或者你有足够的信心自己负责的模块不会出问题。

另外在开会的时候，你由于任务太多，总是盯着自己的笔记本默默写自己的代码吗？不要这样，这样会让组织会议的人感到不被尊重，会让领导觉得你对项目组不够关心，不够投入，甚至不够忠诚。开会的时候，就要像开会的样子。你可以提前阅读材料来准备几个问题；你可以支持，补充或建议组织者的方案；你可以在外国人面前举出证据来维护中国团队的利益；实在没招，你至少可以记会议记录，会后发meeting minutes。这样你给人的印象永远是你是有想法的，你是有贡献的，你是关心项目的，你是热爱团队的。

一个Team出去吃饭，或者出去旅游的时候，你是得意忘形的放开手脚去玩吗？甚至脱离团队和要好的朋友去逛吗？不要这个样子。余世维在《经理人常犯的11个错误》的演讲中曾经说过，出去Team building，对于员工来说是休息，而对于经理来说是工作。的确，你要清楚资本家为什么会出钱让员工去做这些和工作看起来无关的事情？为什么要大家一起出去而不是每人发钱自己去玩？当然是要增加团队的凝聚力和归属感，为共同合作奠定基础。既然对于经理来讲是工作，难道你不应该有责任辅助你的经理做好工作吗？在大家一起吃饭的时候，如果冷场，积极的起一个话题吧；在经理提出玩一个团队游戏的时候，率先支持，主动去做吧；在外出旅游的时候，帮助你的经理订餐馆，清点人数，摄影照相吧；当爬到山峰，或者年会表演节目的时候，喊出增加团队凝聚力和影响力的口号吧；在活动结束后，整理资料，相片，发出email来进一步增加活动的效果吧。这样你就是有组织能力的，辅助经理成功的，有良好影响力的，也是热爱团队的。

这里提到了团队聚餐中的话题问题，这里顺便提一下，当然根据不同的Team的氛围以及当时的情况而定，话题的优先级依次如下：

·        项目话题：如进度，难点，后面还会提到，学会喊累，喊忙，这是一个比较好的机会。当然此话题比较适合加班或者中午时的团队聚餐，不太适合旅游时候的团队聚餐。此话题可表明你对项目的关心。

·        技术话题：比如语言排名，那家公司被收购了，平台之间的差异等等。此话题可说明你对技术无限热爱。

·        员工生活话题：比如周末干什么了，介绍女朋友，结婚，孩子教育等，当然以当事人意愿为准，不要太当真。此话题可说明你关心同事。

·        娱乐话题：比如看什么电影，娱乐圈出来什么事情等，这是万能话题，也是最保险的话题。

·        员工敏感话题：比如非议其他Team，或者美国团队等，此类话题最好不要涉及，背后议人不太好。

·        公司敏感话题：如有的Team裁员，减薪，福利下降等，此话题千万不要提及，这是领导层想尽力遮盖的问题，甚至不在项目经理的权利范围之内。涉及此类话题将给人以你是一个不可托付大任的人。

最后，如果你在学校中是演艺明星或者体育明星，那么年会的表演以及团队之间的比赛也不是你表现英雄主义的地方，而是体现团队意识的地方，也是交流沟通的好机会。所以不妨在节目中介绍一下自己团队的产品；不妨在角色设定的时候劝说core team的人加入扮演一个牛人角色(欢乐可以一定程度上冲淡马屁味道)；不妨申请印有团队logo的运动衣；不妨在运功过后和高层一同边走边聊(比平时冲到高层办公室里面好的多的机会)；不妨去敬HR一杯酒，被她们多灌几杯(HR的办公室是个敏感区，平时很难交流感情啊)；不妨去维护机房的团队那里敬酒以感谢他们的工作，去前台那里敬酒以夸赞她们的服装，发型等(他们对你来说真的很重要，想想几百人的团队，前台和运维都只有两三个人，还是那就话，当供需相差很大的时候，价格都会越来越高)。这将使你成为一个受欢迎的人。

(5) 适当的增加影响力

做一个好的基层程序员，除了完成自己的本职工作以外，也需不断增加自己的影响力，这既是你的品牌，也是日后加薪升职不可缺少的因素。

增加影响力主要有以下几种方式：

·        在工作中，如果完成了一定的功能，或者测试有了详细的报告，可发邮件给领导并cc整个Team，让领导知道你的付出，和同事分享你的喜悦，让众人知道你的亮点。邮件或者报告要在开头做精炼的总结，使得大部分人能够尽快的了解结果，具体细节可放在后面，供同模块的员工详细查阅。千万不要默认你的上司和其他人都显而易见的知道你完成了什么，这也可能是很多人觉得怀才不遇，难遇明主的原因吧。台湾作家黄明坚有一个形象的比喻：“做完蛋糕要记得裱花。有很多做好的蛋糕，因为看起来不够漂亮，所以卖不出去。但是在上面涂满奶油，裱上美丽的花朵，人们自然就会喜欢来买。”

·        在各类的会议中，如上面所说，事先准备问题，合理提出建议，适时提供证据，都是在同事，领导，以及外国人面前展现自己的机会。

·        有时候美国有或管理或技术的老大来中国，都会召开all hands，这是一个不可多得的在整个公司面前展现自己的机会。而在外企，程序员的竞争力大约包括对产品的把握，对技术的把握和对英语的把握等能力。all handls也是展现这三种能力的好地方。也许你会发现这样的事实，在all hands上英语流利的提问者们，提出问题的目的也许并不是为了想弄明白什么，而是为了展现什么。他们大多是这样问的："As what youside A, but actually what we did in our project is B, so how/what/when C"，你会发现，A和B会说的很具体，而C很抽象，显然A是为了展现产品把握能力(你讲的我都听懂了)，B是为了展现技术把握的能力(我们采取了什么样的技术)，整篇都用英语表达自然展现了英语的能力，最后问一个很Open的问题C，总不能问老大个很难的问题吧。

·        tech talk：当有了一定的技术积累，tech talk是一个很好的展现技术实力的平台，毕竟程序员是吃技术这碗饭的，所以良好的技术口碑对最初的升职至关重要。tech talk所讲的对象一般不是同项目的员工，因而难度要适当的把握，太简单则不足以体现你的技术实力，太难则大家会听的云里雾里，不能真正了解你的价值。在做tech talk的时候，最好一开始有一个整体的流程或者框架的介绍，以使得听众不会在途中迷路。一般有一个规律，就是在最前面几个slides的问题是最多的，大家总能够提出各种各样的问题，所以开始的几页，一定要是你最最熟悉的，最最有价值的，然而随着信息量的增大，后面就几乎提不出什么问题来了，到演讲最后，一般也就只能提出一些open question了，一般可以通过三个阶段轻松回答，其一，that is a goodquestion，其二，it really depends，其三，I'd like to give an example。

·        demo：在很多施行迭代开发的项目管理的公司里，一个阶段是会有一个demo的。很多程序员重代码，而轻demo，明明实现的非常优雅的功能，却懒得花时间生动的demo出来，中国有句古话：六十四拜都拜了，就差最后一哆嗦，多对不起你前面没黑没夜的工作啊。demo是应该好好准备的，应该有一个详细的demo流程，先录入什么数据，然后如何操作，最后应该看到什么等等。然而demo是容易失败的，似乎成为一个难以规避的定律，即无论原来demo如何准备，临阵总会有意想不到的结果，大概因为看demo的人可能会提出奇怪的尝试需求，而可能正是程序员没有考虑过的边界。所以demo中，应该事先将良好的过程录制下来，以防止真实demo过程中有差错，造成功亏一篑，至少可以证明原来是好的。在demo中一定要用近似真实的数据，如输入人名，就用真实身边的员工姓名，输入日期就用当天的真实日期，千万不要用aaa, bbb, 123456此类的数据，既不美观，也容易出问题。而且在demo的过程中，应该严格按照已经准备好的流程走，当完全走完流程后，方才可以处理现场提出的各种尝试，可保证能够完成demo任务。

·        帮助他人：在不耽误自己工作的情况下帮助他人解决技术难题，是比tech talk和demo更能够体现技术实力的地方，并会积累下人脉，当众望所归的时候，你的升职也就仅仅是时间和名额问题了。举个相似的例子，tech talk好比是保健医生，只不过是给你宣扬养生之道，而解决技术难题就如同主治医师，可以使你药到病除。很显然，如果一个人如果能够很好的按照保健医生的养生之道去做，就很少会去找主治医师去看病了。然而主治医师却比保健医生更受欢迎，一方面因为相对重要的事情，人们多会更重视紧急的事情，一方面可能因为只有在逆境，出现问题的时候，人们才会虚心接受他人的意见。试想听tech talk的人们，就如同6000点的股市中的股民，多抱有"你懂，我可能比你还懂"的想法，而出现了问题的人们，便如跌至2000点股市的股民，才会虚心向专家请教，并对给出的方案五体投地了。而且此点满足，不忙的时候，主动帮助他人——让上司有效!

·        培训新人：有时候公司会招来一些学校来的实习生，一年一度也会招很多应届毕业生。当然一般公司都会有各种的培训，然而一旦进入团队的时候，如何更快的上手项目，仍然需要一个过程，如果能有老员工指导一二，将会轻松很多。在项目比较紧的情况下，很多老员工不愿意培训新人，万事开头难，起步总是相对缓慢的，害怕因此而耽误进度。当然，以耽误自己的工作换来对新人的培训我也是不赞成的，这也是后面所说的要给自己留buffer的原因所在。但我需要指出的是，给一个饥饿的人一个烧饼要比其成为千万富翁后给一百万更加让人感恩。人的眼光应该长远一些，无论如何都不要轻视一个年轻人，因为你不知道其将来会是什么样子。有的人，年纪大，level高，但是基本可以看出其一辈子的轨迹了，有的人年纪轻，level低，却可能前途无量，你永远不能把握将来谁会是你的贵人。

在增加的影响力的前面，我加了一个形容词——适当。要有和你的level相匹配的影响力，小心功高盖主啊。外国人有时候会强调leadership withoutauthority，然而如果你果真这样做了，多半会招来同事的敌意(你凭什么指手画脚的啊)，也可能会招来你的lead心中的隔阂(没有authority你都能够lead啦，给你authoriy还不反了天了，你lead，那我干嘛)，所以还是不在其位，不谋其政的好。

(6) 给别人光环

当同事完成一项功能或修改完一个Bug的时候，你是否给过真诚的赞誉，帮其增加上述的影响力？

当同事帮助你解决了问题或者提出了优秀的方案，你是否公开表示感谢，让群众和领导都知晓？

当领导问及你做的模块的时候，你是否有意隐瞒了他人的功劳而突出自己的贡献？

当会议的时候，你是否会处心积虑的故意反对竞争对手的方案，虽然你觉得其实这真的是个好方案？

当发现其他人的Bug，Code reivew的时候发现他人的设计缺陷，你是否幸灾乐祸的大声疾呼，唯恐他人和领导不知？

你是否在同事，领导，HR的面前非议他人，嘲笑他人的设计，褒贬他人的缺陷，鄙视他人的技术，虽然的确你是此方面的大拿？

当你有幸获得一份荣誉的时候，你是否先谢国家(公司)，再谢政府(团队)，再谢领导，再谢同事？

给别人光环吧，别人也会给你光环。

一个只顾自己头上光环的人，以及一个别人给了光环而不知回报的人，最终都会孤立无援，难以开展工作，是涸泽而渔的做法。

我们必须承认的一点是，每个人都有自己的长处，也有自己的短处，每个模块都有优美的地方，也有不尽人意的地方，你有你擅长的技术，别人也有别人擅长的方向。如果大家互相向别人的头上套光环，则外人和领导看到的会多数是光环，从而大家精诚合作，团队蒸蒸日上。如果大家全部互相揭疮疤，则外人和领导则看到的会多数是负面的，从而大家互相猜忌，整个团队都没有希望。

历朝历代都有权臣，权臣之间必有党争，派别之间多知道对方的优势，也掌握了对方的把柄，如果派系之间相互合作，则大家都会壮大，皇帝则不会知道下面的暗流涌动，然而英明的皇帝多挑拨派系之间的关系，使他们互相揭露对方的把柄，从而下情上达，从中制衡。

我们也会经常看到，当一家公司的高管离开他的老东家而投奔新东家的时候，公开场合下，此高管多会十分赞誉在老东家中工作过的时光，赞誉工作过的团队，赞誉老东家的产品和项目，赞誉自己在老东家取得的进步，而老东家也多会给与此高管十分积极的评价，肯定其作出的贡献，其为公司带来的价值，其培养出的团队。其实如果两者之间如此的默契，如此的互相满意，就不会发生跳槽的事件了，既然选择分道扬镳，则其中必有隔阂，只不过互相心知肚明，各不言明罢了。这样无论对公司的发展，还是对此高管的职业生涯都有好处。试想，此高管必然是清清楚楚公司的优势劣势，公司也明明白白高管的功过是非，就像一对生活了很久的夫妻，既知道你能言善辩，也知道你鼾声震天，既知道你玉树临风，也知道你不爱洗澡，如果在公开场合互相指责，甚至谩骂，岂不家丑外扬？

(7) Daily report和weekly report很重要

很多程序员宁愿多写程序，也不愿意写report，觉得十分麻烦，而又无聊。

但是Daily report，weekly report真的非常的重要。

首先report可以帮助你管理自己的时间。在时间管理中，我们知道，人总是有重要而紧急的事情，重要而不紧急的事情，不重要而紧急的事情，不重要而不紧急的事情之分。你是否总结和思考过自己真的总是做了重要而紧急的事情么？人们总是忙啊忙，从早忙到晚，天天加班，其实每天都在处理各种各样的突发紧急的事件，使得计划一拖再拖，而忽略了对自己很重要的事情。试想想吧，你原来计划过要读的书有多少是真正去读了的？你在朋友面前畅谈的宏图大志有多少是真正实践过的？你还记得儿时的梦想吗？你是一直向着自己想要的方向在不断的进步吗？时间管理的原则告诉我们，每个人应该有一张思考的床，不要穷忙、瞎忙、无心的忙。写daily report和weekly report不完全是应付上司的，也是自己思考总结的过程啊。我还记得最初每周定计划的情况，当一周过去进行回顾的时候，我当时吓了自己一跳，我原以为自己一直过的非常的充实，却发现计划做得事情真的只做了大概三分之一，照此下去，如何进步啊。有兴趣大家可是试着制定一下计划，越详细越好，工作方面的可以写给上司看，学习，社交等方面的可以自己写给自己，有时候多少有些身在江湖，身不由己的感觉。

其二report可以帮助你总结自己的进步。当天做的事情一般人还是记得的，一个星期做的事情，大概就模糊了，半年前做的事情，则很多细节都忘记了。很多的时候，当我们每年对自己进行年终总结以期待明年加薪的时候，当我们想要跳槽来总结自己忙碌了几年的成果的时候，往往会发现，report到用时方恨少啊。面试的时候，对于有经验的人，往往会将项目经验问的很细很细，当时你为什么选择这种方案呢？系统的速度如何一步步改进提高的？你发现你可能说不清楚了。平时尽量多详细的记录一下自己每天的进步吧，这可是影响到你薪水的闪光点啊，对方的公司正等着一个牛人来提高他们的性能呢，你明明取得很不错的结果，只是忘记了自己做了哪些改进，岂不可惜啊。

其三report可以帮助你增加自己的影响力。如上面所述，report不但可以让自己知道自己做了什么，也可以让上司知道你完成了什么，如果写到wiki上，还能让更多的人知道你的成绩。

其四report可以作为维护权利的证据。这一点前面也说过，作为初入职场的基层，作为相对美国来说弱势的中方，证据是非常重要的。当项目delay的时候，你如何证明你是提前schedule完成的？当性能遇到瓶颈，你如何证明你曾经高效且没有做过改动？在写程序的时候，我们知道，当context不在的时候，唯一能够定位问题的，就是log了，report就是你工作的log。

其五report可以使你的上司对你放心。很多初入职场的基层，埋怨上司过多的干预自己的工作，总是有事没事的过来问，做的如何了？有什么困难？这段时间在做什么？有时候这种询问会打断你的思路，着实让人困扰。其实情有可原，你刚来，不放心是可以理解的。如何做到你办事，他放心是你的责任。当有阶段性成果的时候实时报告自己的状态，每天写daily report报告自己的进度都是让上司放心的办法。一个有意思的现象是，当你一天一封daily report向他汇报的时候，他却不怎么过来干预你的工作了，甚至到最后daily report他也不怎么看了。

做到此一点，方能主动向上司汇报你的工作进度——让上司知道，对上司的询问，有问必答，而且清楚——让上司放心！

(8) 给自己留buffer，学会喊累，学会喊忙

初入职场，激情高涨，多喜欢将自己满负荷运作，无论是需求来自领导还是来自同事，都不好意思拒绝，最后弄得自己疲于奔命，焦头烂额。

其实工作中，是应该给自己留有一定的buffer的，一方面，可以在项目有了突发事件的时候，不至于临阵慌乱，尚有调整和处理的时间，不至于第二天demo，当天晚上代码才完成。另一方面，要做好以上所述的事情，还都是需要buffer的，绝不能够低头干个不停。

另外，公司是要对项目负责的，而自己的职业前途，却只有自己负责。除了每天忙于项目之外，总要有一定的时间进行自我进步，从而提升自己的价值。前面也说过，有的人面试的时候，仅仅知道项目中用到的知识点，而相关的却很少知道，从而使自己的职业生涯既不广，也不深。所以日常工作中，留有一定的buffer来将知识点变成知识面是很重要的。

所以如果你真的很忙，真的很累，要勇于喊出来，而不要默默的承受着，当然这不是让你装忙装累，而是向周围散发出一种信息，就是你已经负荷较满了。这样你的领导在安排任务的时候，会综合考虑，你的同事在向你提出需求的时候，也拒绝的合情合理。当然你不能总是喊忙，总是不出成果，如第一点中所说，result永远是最重要的。而总是喊忙，总是能出成果，确是一种工作努力的表现。有的人认为，只有相互说话才叫沟通，其实不然，殊不知自言自语，凝重的表情，同样是沟通的手段。

也只有在有buffer的情况下，你才能做到充实自己，努力学习，才能了解上司的言语——让上司轻松，你才能够做到对自己的业务，主动提出改善计划——让上司进步。

 

 

 

IT外企那点儿事(8)：又是一年加薪时

 

每年过年后的一段时间内，便是一年一度论功行赏的时候了。

年终奖一般设置在年前，而加薪设置在年后，却是一种蛮不错的设计，从而年前大家皆大欢喜，一片祥和，年后又带来新的一年的希望，并激起竞争的欲望。

很多人在讨论加薪的时候，如何同上司或者老板谈方能获得更高的涨幅成为了一个热门的话题。

其实加薪的过程从时间上来讲，近则可以追溯到去年年终的绩效评级，远可追溯到过去一年甚至多年每个checkpoint的评价，从范围上来讲，是一个员工和老板之间，员工与员工之间，甚至Team与Team之间的一个博弈的过程。

当你走进上司的办公室谈话的时候，其实已经没有什么可以博弈的了，尤其是在流程相对规范的外企。因为高层已经根据每个Team的贡献分配可以加薪的份额，而在你的Team中，你所占的位置上司已经基本心中有数，况且去年的绩效评级已经基本决定了你的加薪范围，所以其实没什么好谈的，无非是优秀者褒奖，普通者激励，不足者抚慰罢了。

当然还有一种情况可以进行谈，加薪一般分三种，原职位加薪，升职加薪以及跳槽加薪，如你在公司外有一个相对高薪的位置的时候，便有了可以博弈的另外的筹码，可以一谈，有的上司也许会多加一些薪水给你的，自然大多达不到公司外的薪水的高度，也是我十分不提倡的加薪方式，且留到后面跳槽一章详细说明。

加薪的博弈其实从很早就开始了的。多早？让我们从入职说起。

一、入职培训中了解绩效体系。

入职培训中，除了描绘出的美好未来和一些令人激动的技术讲座之外，一个不容忽视的方面即HR讲述公司的绩效体系。

而这又恰恰是新人容易忽略的方面，一方面大多认为合同已签，薪水已定，什么绩效，什么加薪是遥远的事情，一方面填表格，走流程实在是令技术人员头痛的事情，很多人宁愿花十分力气埋头苦干，也不愿出一分力气将其表述出来，多少有些到时候别人怎么填我就怎么填的从众心理。

有的程序员清高的认为，自己的所做作为，绩效如何，上司和HR有责任清楚的知道，直到绩效反馈One on One的时刻，获得不合期望的评级的时候，才猛然发现，好钢竟然没有用在刀刃上。凡事预则立，不预则废，加薪要从娃娃抓起。

绩效评价的方法多种多样，很少有外企单独的使用其中一种，往往是综合起来使用，而不同的评价方法有不同的注意事项：

·        目标管理法：也即先制定目标，一定时期后review目标看完成情况的方式。如果采取这种方式，目标的制定和完成反馈就相对重要，下面我们会详细讲这个事情。

·        关键绩效指标法：提取出岗位所需要的结果的，行为的，优势的，劣势的等等方面关键因素进行评定。则因素之间的权重就显得比较重要，这个权重不仅仅在HR的ppt上，也在你的绩效评定者的心中(也即HR觉得某行为重要不算重要，你的绩效评定者觉得重要才算重要)。崇尚按时来按时走还是加班加点？技术分享更重要还是问题解决更重要(多数情况下，给别人解决一个问题比介绍其一项技术更加让人感恩)？注重技术还是注重流程(有的技术大牛能力杠杠的，就是不愿写注释，写文档)？

·        360度考核法：有的公司进行的是全方位的考核，如上司，下属，QA，同事等，有的则仅仅是上司及上司的上司。了解你的评级相关方，如何与他们良好的沟通，是非常关键的。

·        强制排名或强制分布法：有的公司会对员工进行排名，或者按照很优秀，优秀，一般，差，很差几个等级进行强制分布。这是一种十分残酷的评级方式，也使得你能不能跑得过老虎不重要，能不能跑得过同伴更重要。如果很优秀的会有一个人，优秀的会有三个人，则第四名和第五名虽然从贡献和结果上来讲差别不大，然而对后来的薪资涨幅，升职，甚至股票等都有很大的差别，这就需要你时常通过沟通，了解自己在Team中的位置了。

二、了解评级相关方

了解了绩效体系之后，你就明白了给自己最终的评级将有那些人了。

平时我们常常说顾客就是上帝，观众是衣食父母，而研发人员天天躲在象牙塔里，是几乎不会跟客户见面的。所以很多人认为客户导向这句话是销售人员的事情，与研发无关。然而从某种程度上来说，你做做的模块的调用者，测试你的模块的QA，你的下属，你的上司等等都可以算作你的客户，只有每个模块的客户都达到满意，则最终的产品才能让真正花钱的客户满意。所以日常工作中，如何同你的客户进行交流，让他们了解你的目标，进度，困难，成绩，优势，劣势，期望等，是十分重要的。

然而人各有不同，对于不同的人的沟通方式也不尽相同。

·        过程型还是结果型：

结果导向和过程导向是两种不同的管理风格，是一直被争论不休的。

中国的传统文化中原本是过程导向的，所谓的德、能、勤、技，中国人其实是更加注重过程中表现出的德、勤两个方面的，从较早的举孝廉到后来的以四书五经为纲的科举制度，都表明了过程中表现出的操守要胜于最终建立的功业。从民间崇拜的对象，我们也可以看出，相比于百战百胜的卫青霍去病，人们却更加崇拜投降曹操又过五关斩六将的关羽，相比于辅佐刘邦建立大汉王朝的萧何，人们却更加崇拜六出祁山但未能成功的诸葛亮，相对于帮助秦国强大的商鞅，人们却更加崇拜周游列国知其不可为而为之的孔夫子。

近代外国现代管理思想的引入，使得以过程为导向的方式迅速向以结果为导向的方式转变，老板们多喜欢说这样一句很酷的话："不要给我说过程，我要的是结果"。后来，随着企业发展，人们又越来越发现如果只关注结果，则会造成企业的短视和部门间合作的问题，对于整个公司来讲，如果只为公司的股票和市值负责，在有线电话有巨大利润的AT&T自然不用关心无线通信的发展，所以成就了摩托罗拉，在大型机及硬件方面有巨大利润的IBM自然不用关心一份软件的license能赚多少钱，所以成就了微软。对于部门来讲，如果仅仅关注本部门的结果，又有谁关心部门之间的空白地带呢？

所以后来，人们发现如果不能很好的控制过程，则多半不会达到预期的结果，不但要注重结果，也同样要注重员工的激励和思想行为的培养，从而发明了平衡记分卡等方式，从单纯的绩效考核上升到绩效管理的高度。

其实不仅是管理，结果型和过程型也是人的做事风格之一。当你描述一件自己做过的事情的时候，结果型的人往往会先问事情的结果，对于最终成功的，则过程中的一切便被解释成为正确的，可以理解的，至少是不得已的，而过程型的人则会仔细倾听事情的来龙去脉，并点评和探究其中的点点滴滴。

结果型的人多喜欢财富，权力，成功学等方面的知识，并力争成为这方面的专家，而多不屑例如考古挖掘，红楼梦探轶，农民兄弟自己发明飞机等类似的事件，过程型的人自然也喜欢钱，但同样对不能带来利益的神秘过程感兴趣。

结果型的人多喜欢竞技类的游戏和运动，且往往是高手，在乎每一次的输赢，如羽毛球，乒乓球，篮球，足球，网球，象棋等，过程型的人也会在上述游戏中乐在其中，但更喜欢游泳，唱歌，旅游等非竞技类的活动。

所以在工作中，项目规划的时候，对于结果型的相关方，则应该定下明确的目标，如测试用例覆盖度，性能指标等，而对于过程型的，除此之外，方案的评审，也即你将如何达到既定的目标，同样是很重要的。在项目的进度安排中，对于结果型的相关方，主要设定重要的checkpoint点就可以了，至于学习什么，研究什么，帮助他人做的职责外的事情，请自己留buffer，而对于过程型的领导，这些可以写入时间规划。在项目执行过程中，对于结果型相关方，多汇报进度，如遇到困难，则应有证据证明存在的问题，并估计其对进度的影响，对于过程型的相关方，还可以描述问题的原因，探究及可能的解决方法。在项目结束的时候，对于结果型的相关方，一份详尽的报告逐一用数据表明达到目标很重要，对于过程型的，还可以发起一个knowledgesharing，分享项目中的难点和解决。

·        视觉型，听觉型还是感觉型：

不同的人感知外在世界的方式有所差别，大概分为此三种，当然人们都是这三种类型的综合，只不过更多的偏向于某一种而已。

视觉型的同事常打印出一部分书籍或者文档，并边看便在空白处或者本子上写写画画，画出思路图，或者标出过程的一二三。其学习技术的方式倾向于看书而非看教学视频，因为看书能够很快的跳过各种废话，直奔主题，当然如果书籍能够形象直接的提炼出要点，则将十分欣喜。和他人沟通，首选用邮件或者文档的方式，写明要点，并附上详尽的框图，其次是到会议室中，把框图在白板上画给你看，最不爱采用的，就是电话的方式。在开会的时候，其喜欢坐在能和会议的举行者可以目光交流的地方，而不是角落里，其似乎随时准备上台提炼出演讲者的一二三，或者把过程画出流程图。

听觉型的同事也喜欢看书，但是在其觉得重要的句子下面画波浪或者下划线是常用的方式，在其看来，作者的文章字字珠玑，所以划线的地方非常多。其注重细节，相对于视觉型的人，其掌握架构的速度有些慢，然而一旦掌握，将成为此方面的专家，对方方面面都有所了解。其学习技术倾向于看视频，会不厌其烦的一字不落的听着讲座的每一步，相比于看书，讲座者的语气强调更能给他带来深刻的印象。与他人沟通，电话是其最喜欢的方式，简单直接，且能听到对方的语气，开会其次，如果使用邮件或者文档，将写的非常仔细。其开会的时候往往会坐在非中心的位置，相比于视觉型的人，你可能觉得他似乎不太积极，然而后来你会发现，其对会议的很多细节在较长时间后仍能够清晰记忆，"我记得你在一次会上曾经说过"。如果其是会议组织者，其技术讲座，技术方案都会详尽到代码级别，开会超时是经常的事情，如果视觉型的是其领导，将会在其ppt中删除大量的涉及代码的细节，换以图片，这将使其心疼不已。

感觉型的同事相对喜欢看原书，而非打印稿，如果其觉得书不错，比较倾向于买一本属于自己的书，尽管图书馆，公司，同事的书可以供他无限期的借阅，觉得自己看过的书再次查阅的时候比较容易找出需要的知识。其不太喜欢仅仅讲述理论的书，如果有实例，做上一做，方才有感觉。如遇到问题，尽管从理论或者他人的经验即能推出结论，其还是愿意写个程序加以验证，真正输出结果，方才放心。其接触过的问题，大多真正的实际做过，其经验比较可信，然而其却不太相信他人的经验。其往往不是某一方面的专家，然而经过长时间的工作积累，只要是做过的部分，多有十分扎实的经验，能很快的帮助他人解决问题，或者提出十分可靠的技术方案。与他人沟通，来到他人的座位上是经常的。在讨论接口或者方案的时候，多能够体谅他人的感受，也无形中自己默默的多做了很多事情。

所以对待视觉型的人，邮件中列明要点，附件一个ppt文件，是其最喜欢的方式，ppt既条理分明，又能够画图。如果还有其他的参考资料，可另行附上，如有多个，最好表明每个参考资料和要点中的哪一点相关，否则很有可能被忽略。如果对方是听觉型的，可以先发一个带有详细信息的邮件，然而一定要有一个电话或者会议与其进行沟通，通过语气或显式强调邮件中那些是最重要的，那些是次重要的，否则其在浏览中提取出的重要信息可能偏离你的预期。如果对方是感觉型的，则走到其座位上是最好的沟通方式，拍拍肩膀是很好的表达友好的方式，相信他的经验，如果欲使他相信你的经验，则需要准备足够的证据，有时候认同比争论更容易让其同意你的观点，多体谅他的感受，情绪控制十分重要。

·        技术型还是管理型

所谓技术型和管理型，其实很少有领导完全只懂技术，不懂管理，或者只懂管理，不懂技术，所以将技术型和管理型分为以下几类：

第一类：使用相同类型技术做过相同类型产品的管理者。

比如要使用Java技术搭建一个搜索引擎系统，如果项目管理者原是做过此方面的，则此类是程序员最受欢迎的管理者了。

由于其对此项目的整体架构，模块划分，技术难点等十分清楚，因而在项目规划过程中，能够相对精确的把握时间进度，需求变更，在项目设计的时候能够进行较好的人员，模块，接口的分配，在项目执行过程中，能够及早的提醒可能出现的问题，并在出现问题的时候帮助员工解决，在项目测试阶段，能够把握测试指标和要点，项目结束后，对各个子模块，各个人员的绩效的评估相对准确。

只要比较有心，此类的管理者可以说是明察秋毫的，除了遇到困难请求帮助外，程序员多可静下心来默默的做自己的程序，可以少去很多不必要的沟通，因为只要最后成果一展示出来，只要稍加描述，此类管理者便大概能把握使用了那些技术，会经过那些难点，有多大的工作量，程序员多不用担心自己的成果或者辛勤被埋没。

然而此类的管理者多会给员工以较大的压力，因为其能看到项目进行中的每一步，于是往往以自己的标准来要求员工，在一步刚刚走完，员工还没调整过来，就被催促着进入下一步，在员工看来上不可控的风险在其看来完全可控，在员工仅仅看到第一个跨栏的时候，其已经看到了终点，往往过于乐观的估计员工的水平以及项目当前的状态。当然由于很有经验，其有时候会参与到项目的实际工作中来排除困难，促使项目在其规划的范围内完成，也多搞得员工比较疲惫。

对于此类管理者，模棱两可是最不可以接受的，其往往希望对项目的每一个技术细节有所把握，除了和大多数管理者一样需要有扎实的数据外，从技术理论角度要能够讲的通是非常必要的。在项目规划的时候，你至少应该想出大部分此类管理者能够想出的方案，除了用数据表明一种方案优于其他外，到底采用了那些技术方有此数据表现也是很重要的。在项目执行过程中，遇到了困难block甚至delay了项目进度的时候，除了使用log或者其他工具证明确实有此问题存在之外，要对此问题进行技术理论方面的解释，分析可能那些原因造成了此问题。在项目结束，除了展示漂亮的结果和飞快的速度，如何达到此类速度是其非常想知道的。当然同此类管理者沟通技术是相对容易的，你只需一点，其马上可以体会到背后的奥秘，"哦，你一定是用了XXX技术吧，我原来有个项目也是这样做的…"。相对较难的是对项目进度的沟通，当其评估需要3天时间，你觉得需要5天来完成任务的时候，一定要有充足的证据。

第二类：使用不同类型技术做过相同类型产品的管理者。

如果项目管理者原来用C/C++实现过搜索引擎系统 ，则属于此类。

此类管理者多能够很好的把握需求和架构，以及最终结果的技术指标。然而由于不同类型的技术在具体实现方面的设计思路不同，能够使用的资源也不同，面临的难点和问题也不同，也就造成了其对风险的控制，技术难点的解决，时间进度的控制方面，则要多依赖手下的兄弟们，也可能会有些偏差。

在项目执行过程中，有时候会对风险的评估过高或者过低，对时间进度的控制或紧或松，比如有的功能使用C/C++则需要完全自己实现，而Java中已经有成熟的工具可用，再如有的Java框架在数据量比较大的情况下会出现不稳定，没有真正使用过的很难预料到。其有时候会对遇到的技术难点十分理解，有时候却觉得所谓的技术瓶颈不可理喻。

对于此类的管理者，在上述三个方面，程序员要主动承担一些责任，在项目方案评审阶段，要对风险点有全面的调查，并明确的告知，帮助其进行风险控制，在项目规划的阶段，对自己任务的划分应该足够的细致，对每个子任务的所花费的时间，都应该有明确的理由，在项目遇到没有预料到的技术难点的时候，要主动沟通，解释原因，好在此类管理者多是很有经验的技术人员出身，尽管平台不同，只要耐心解释，还是能够获得理解的，当然你还应该对此技术难点所要花费的时间，是否有替代方案等有一个估计，方便其对进度进行控制。

第三类：使用相同类型技术做过不同类型产品的管理者。

如果项目的管理者用Java做过ERP系统，则属于此类。

此类管理者与第二类恰好相反，其能看到树木，对森林的把握可能会略显不足。其可能会过于关注具体的技术细节，甚至到第一线去写程序以及解决问题。而由于没有相关方面的经验，可能只吃过猪肉，没见过猪跑，对需求的理解可能会有偏差，对模块的划分可能不很合理，从而导致项目开发的过程中多有反复，摸着石头过河，造成经常进行代码重构，在结果出现不理想的时候，出现放弃千辛万苦实现好的旧方案，尝试新方案，时间一长，会造成开发团队人心不稳，目标不明，因为谁也不愿意看着自己的辛苦付之东流而在原地踏步。

就风险管理方面来看，一个团队中至少有一个见过猪跑的人会大大降低风险。如果碰巧你是这样的人，则在项目规划阶段贡献出自己的经验是责无旁贷的，可以使得团队少走很多弯路，千万不要抱着出了事再说的态度，因为这样会给你留下知情不报，有所保留的印象。

如果非常不幸，可能由于人员招聘的原因，你碰巧在一个从来没有人见过猪跑的团队来设想如何养出一头最最先进的猪的时候，你可能在辛辛苦苦的重新造一个市场上已经有了的轮子，如果你到了真正的养猪场，你会发现原来你辛辛苦苦探索的方法在这里随便一个养猪工人都知道。所以此种情况下，前期研究的时间要留的长一些，磨刀不误砍柴工，切勿匆匆下手，导致项目反复。如果有类似的开源软件，则应该对其进行详细的调研，如果市场上已经有公司这方面做的比较成功，则安排一定的技术交流是非常必要的，如果有相关方面的会议，能够参加一下也是有帮助的。

在此类团队中，代码的可扩展性和灵活性十分重要，可能最初设计的时候费些事，会使得以后的反复过程中轻松很多。对于此类管理者，不但最后的结果是成果，中间的反复也是成果，证明一个东西好是成果，证明一个东西不好同样是成果，对技术难点的攻克同样是成果，这些中间的尝试，都应该及时的汇报，以免中间的辛苦因为最后的结果没有使用而被埋没。

第四类：使用不同类型技术做过不同类型产品的管理者，及只了解基本的技术原理的纯项目管理者。

有的项目管理者原来是管理的完全不同的产品，或者虽然读书读的是计算机，然而一毕业就直接从事项目管理工作，而非从开发人员一直坐上去的。所以此类的管理者多是结果导向型的，也多是授权型的。

此类管理者由于缺乏对技术细节的敏感度，因而多表现出以下几个特点：

首先，有成果满分，没成果零分。这如同高考中看不懂计算过程的问答题一样，最后结果正确则基本满分，最后结果错误则几乎零分。

其次，工作态度十分重要。当对技术细节不甚了解，则工作态度就成为是否努力的衡量标准。

其三，通过员工之间的对比和互相评价判断员工的评级。如果不能够很好的把握绝对值，对相对值的把握就成为一种手段。然而每个人干的活不同，此种方法很容易出现偏差，有的功能看着很简单，但背后可能要做很多工作，有的功能看着很复杂，其实却只需稍作修改，这只能导致前者哑巴吃黄连，后者没事偷着乐。

其四，对任务等待的time out时间较短，心理学中的等待效应有八条原则，其中一条是没有说明理由的等待比说明了理由的等待时间更长，由于管理者不明白技术原理，则比较容易time out。我们知道，很多的前期调研工作是十分耗费时间的，常称之为过山车式的，即开始进度缓慢，总是不出成绩，只有当积累到一定的知识量，有了总体的把握，则成绩会迅速大量的出现，然而往往在过山车马上达到顶峰，即将释放势能的时候，管理者time out了，于是很多马上要出结果的调研工作终止或者换人，使得研究了很长时间的员工的辛苦付之东流，或者后继的员工站在前人的肩膀上大出结果的时候，反而庆幸自己尽快换了人，进而褒奖后者的能力，而批判前人的努力，造成对员工评价的不公正。

所以对此类管理者，除了工作态度认真之外，要将任务划分成众多小的阶段，每个阶段都要有结果，要在管理者time out之前，将结果展示出来，将Timer reset一下，重新进行下一个小的任务，也算是针对管理者这个客户的敏捷开发吧。当遇到技术难题的时候，仅仅埋头苦干是不行的，要多和同事进行技术讨论，甚至向此方面擅长的技术专家进行请教，要知道，别人替你说一句"这个模块有很多技术难点啊"比你自己喊有多难有分量的多，也是一种沟通的手段。

三、进入Team后，打响第一枪

这就是所谓的首因效应，即人与人第一次交往中给人留下的印象，在对方的头脑中形成并占据着主导地位的效应。

一位心理学家曾做过这样一个实验：他让两个学生都做对30道题中的一半，但是让学生A做对的题目尽量出现在前15题，而让学生B做对的题目尽量出现在后15道题，然后让一些被试对两个学生进行评价：两相比较，谁更聪明一些？结果发现，多数被试都认为学生A更聪明。

首因效应虽然可以通过训练进行避免，然而不能不说，还是起着重要的作用的。

首因效应之所以十分明显，因为其多半后来会伴随着马太效应，即凡有的，还要加给他叫他多余；没有的，连他所有的也要夺过来。

这在生活中太多见了，想想我们从小到大的学习阶段，几乎所有的好处都给了学习好的学生们，什么三好学生，优秀干部，竞赛机会等，甚至连微不足道的演讲比赛，书法比赛都不放过，虽然他们未必是这方面的高手。再想想新闻中宣传处的模范人物，也是几乎所有的光环都给了他们，领导接见，授予奖章，媒体采访，甚至连感动中国也必须有他们的一方席位，虽然他们只是将人民赋予的使命干的很不错，但没有让人落泪而已。

在公司里，也同样是这个样子的，如果你有幸被冠以某方面强人的名号，则bonus，加薪，升职，代表Team去开会，演讲等都会慢慢的到来。

当然牛人也是可以进行市场细分的，比如语言的，平台的，框架的，工具的，英语的，沟通的，流程的等等，当然还有一种是成为最努力的人。

比如在西游团队中，孙悟空是技术型的，沙僧属于努力型的，猪八戒就属于沟通型的。

每个人要根据自己和整个Team的成员情况，看走什么路线比较好。当然其中技术型的路线相对比较受推崇。

对于英语的，沟通的，努力型的，要正确向技术型进行转型，至少寻求在某项技术类型中占据老二的位置，否则你是最可爱的，最受欢迎的，也可能是常被边缘的。

转型则需要你在本职工作外，做一些中间地带的有挑战性的工作，或是在某个牛人休假，生病，离职等情况下顺利接手，这些都可以成为你是这个方向的专家的标志。

对于其中的努力型，需要指出的是，转型要快，因为你永远拼不过刚毕业的小伙子们，而且时间长了会被认为你的成绩皆是努力所得，并非技术强人的印象，影响了你的前途，况且一旦不能坚持，则容易引起阿伦森效应，一个例子就是，小刚大学毕业后分到一个单位工作，刚一进单位，他决心好好地积极表现一番，于是，他每天提前到单位打水扫地，节假日主动要求加班，领导布置的任务有些他明明有很大的困难，也硬着头皮一概承揽下来。但日子一长，小刚没有了那股干劲，水也不打了，地也不拖了，还经常迟到，对领导布置的任务更是挑肥拣瘦。结果，领导和同事们对他的印象由好转坏，甚至比那些刚开始来的时候表现不佳的青年所持的印象还不好。因为大家对他已有了一个“高期待、高标准”，另外，大家认为他刚开始的积极表现是“装假”。

四、绩效目标的商定

和上司商定绩效目标的时候，是需要遵循一定的原则的，一般的说法是SMART原则：

·        Specific：明晰，即要做哪些任务，怎么做，花费多长时间，优先级是什么，可能的技术难点在什么地方，是否有解决或者替代方案，是否需要资源支持如机器，带宽，软件lisence等，是否需要技术支持，Team内，公司内还是公司外，是否需要添加人员支持。

·        Measurable：可衡量，即如何界定任务是否完成，如功能指标，性能指标，测试用例覆盖度，系统测试，集成测试，Demo，文档，技术会议，report等。

·        Attainable：可实现，即评估任务是否有技术的，资源的，人员的，流程的限制，是否依赖其他的任务，比如美国的设计文档等，评估上述衡量指标是否过高或者过低，过低则任务没有挑战，工作没有成就感，过高则容易使员工绝望，破罐子破摔。所以一般来说，最好顶一个所谓的跳起来够得着的高度，也有的说120%的完成度，最能够激发员工的主动性和潜力。当然如果后期发现完成100%，也应该算作此任务完成，超过则要有奖励。

·        Relvent：相关，即任务要同项目相关。有时候对此项的过分严格的要求，会降低Team的融合程度，因为如果仅仅与子团队的目标相关的话，子团队之间的空白地带将无人去做，所以任务制定要考虑的因为对整个Team的贡献留有buffer。此所谓的任务绩效和周边绩效的概念，任务绩效主要包括两种，一种是技术任务绩效，一种是领导任务绩效，一般的程序员只有第一种，而技术经理，架构师等则同时包括第二种，周边绩效也包括两种，一种是工作贡献，如对流程，方案提出建设性建议，主动承担非工作范围的任务等，一种是人际促进，如帮助他人，协调工作，便利沟通等。

·        Time：时间，需要上司和员工一起商议每个任务所需要的时间，并将任务按照优先级排序，从而得到每个任务的checkpoint点。时间一般应该首先由员工给出，由上司审核后确认，时间不宜指定的过于紧迫，否则一定影响代码质量，可扩展性，技术选型及系统架构。

除此之外，还应该注意以下几点：

·        上司一般可没有耐心等到一个阶段过后才看到可衡量的目标，因而除了最终的目标外，可将目标划分为小的目标，定时考核。

·        除了有工作相关的目标，最好还有一些发展相关的目标，每一个上司都希望看到自己的员工积极上进，不断进步的。

五、绩效沟通与反馈

当项目目标制定好了以后，很多员工就一头就扎进自己的任务中，认为只要最后的结果能够出的来，就一定会有回报。而管理者们也多以授权为由，不太关心项目实施过程，而仅仅check结果进行考评，没有在平时留心记录员工的业绩和表现，在最后以总体印象进行评价。

所以每年的绩效考评的时间，都是多少有些尴尬的过程，有的平时十分内向的员工看到自己的评级的时候，失望，惊讶，甚至愤怒，觉得自己的努力没有被认可，个别会出现在同事面前抱怨评级，同上司争吵，甚至越级上告的情况，无论是上司，同事都很惊讶的发现，这还是平时那个默默工作，积极主动，帮助他人的人吗？

当我们做一个多节点系统的时候，经常需要通过Heartbeat来同步节点的拓扑信息，否则不同的节点将看到不同的拓扑图。

当然项目执行过程中也是这个样子，需要不断的沟通来填补上司和员工对当前状态的理解的差异，当然所谓的沟通，也不是通过良好的表达能力就可以的，沟通中往往存在以下的障碍：

·        因不同的经验水平和知识差异而带来的信息不对称。由于知识背景的缺乏，很多上司觉得很简单的事情，对员工来讲可能是比较困难的，由于经验水平的差距，很多上司看来显而易见的风险，对员工来说可能是毫无思路的。正如老罗语录中所提及老股民在新股民前面卖弄专业术语的时候多会忘记自己当时的困惑一样，很多上司也多会忘记自己当年的懵懂，发出每一代人都会发出的一代不如一代的感叹，觉得还不如自己亲自去做来的省事。然而人总是要成长的，你也不可能自己做完所有的事情，培训下属同样是上司的职责之一。有的上司也会培训下属，甚至一步一步的交给下属怎么做，可有时候还是起不到效果，其实有时候背景知识和原理要比具体步骤更加重要，授人以渔胜过授人以鱼，明白了为什么，聪明的程序员们很容易看懂这一步步的步骤，反而如果只知其然不知其所以然，一旦出现变数，则无法应对。对于背景知识的培训，往往开始需要较长的一段时间，但是无论如何都是值得的，上司一定要有耐心，做为下属，也可以让上司推荐相关的书籍文档等，下功夫尽快度过这个时期。对于经验的积累，却丝毫没有捷径，只有真正做过，遇到真实的场景，方才会有体会，所以经验较少的员工的技术方案评审，上司是一定要把关的，可以很好的进行风险控制，另外一点就是机会教育，也即当项目过程中遇到棘手的问题并得到解决的时候，获得经验的不仅仅是当事者本人，而是应该扩大到整个团队。

·        选择性处理对自己的评价。人对信息的接收，理解和记忆都是具有选择性的，一个人总会根据自身的价值观来选择接收那些信息，并对信息进行解释甚至曲解，使其同固有的认识相互协调而不是相互冲突，并将信息中对自己有用，有利，有价值的信息储存在脑子里。试想当某明星出现丑闻的时候，其粉丝总是不能接受这些信息，并试图证明这不是真的，这一定是有合理原因的，尽管这些证据在外人看来是那么的铁证如山。试问如果你是一个对房价看跌的人，你是否看到有关证明房价会跌的新闻迫不及待的点开，而对证明房价会涨的言论不屑一顾？反之亦然。所以，在绩效沟通中也同样存在这样的问题，中国人的沟通总是会照顾面子的，因而很多人会选择说模棱两可的话，"你总体表现还是不错的，只不过XX方面尚欠缺，没关系，多看看这方面的资料就好了"，有的人是乐观主义的，于是可能会忽略不足的部分，选择记忆好的部分，最后惊讶的发现在一直不错的评价下最后获得了仅合格的评级，造成心理落差。有的人是悲观主义的，从而造成了很大的心理压力。

·        对项目目标或任务重要程度理解不同所带来的方向性问题。有时候项目的目标和程序员的目标在理解上会有一定的差距，项目的目标往往是根据内部客户或者外部客户的需求制定的目标，而程序员则多喜欢有技术含量的工作，一般还要几种倾向：一是技术完美性，如项目目标是做一个有完整功能的，但性能较差的Demo产品，然而测试出来的速度程序员会认为从技术角度是不可接受的，所以花费大量的时间来改进性能；二是方案原则性，即做一个东西，应该用什么方法做，就要用什么方法做，哪怕承担做不完的风险，也不使用丑陋的折中解决方案；三是架构完整性，即一个系统应该包括那几个模块，应该是麻雀虽小，五脏俱全的，哪怕用户没有要求有此模块。这几种现象如果不影响项目进度，是锦上添花的事情，如果不幸影响了最终的deliver，则会最终影响绩效的，但在平时沟通中，不但没有得到提醒，甚至得到鼓励，"我看你做了一些性能改进，好像提高了不少嘛"，"没想到你还支持这个功能"。然而最后绩效评价的时候，当上司以项目delay进行减分的时候，员工往往会十分困惑，"我虽然没按时做完这个，但是我的性能是其他同事不能比的啊，当时你不也给予肯定了吗？"。

·        对员工所在状态的认知。按照经典理论，员工会处于以下四个阶段，对于不同的阶段，应该采用不同的管理方式。第一个阶段：低能力，高意愿，刚进公司，下属的工作热情高，但能力较低，容易听从指挥，应使用指挥式管理。 第二个阶段：有一定的能力，低意愿，过一段时间，能力得到提高，但激情逐渐消退，则应该使用教练式管理，通过培养能力来提高意愿。第三个阶段：更高的能力，变动的意愿，当工作一段时间，能力有了大幅度提高，但意愿处在一种不确定的状态，则应该使用支持性方式，相信其能力，通过让其自行解决问题来激发意愿。第四个阶段：高能力，高意愿，能力已经十分成熟，可以独当一面，行为相对成熟，则应该使用授权型，让其自由发挥，达到自我实现的目的。此理论并不新鲜，然而问题是员工到底处于哪种状态是需要很好的沟通的，而非由上司指定的，如果在上司眼中，员工处于第二阶段，而员工自认为在第四个阶段，则员工会感觉上司对自己不信任，反正员工可能会在面对问题的时候手足无措。

所以在平时，可以由上司发起，也可以由员工发起，定时对以下方面进行沟通：

·        数据化任务的完成情况，任何任务都应该有以数据为支撑的指标，上面已经详细叙述。

·        证据化工作中好的表现和需要改进的地方。为了防止上述的对信息的选择性处理，绩效沟通的信息反馈一定要清晰，最好伴有实际的例子，做的好的地方比如什么项目中的什么工作，需要改进的地方比如什么时候的什么表现，如果作用不很明显则可以通过反复沟通加以确认，尤其对于可以改进的部分制定相应的计划，并实时跟进，如"上次推荐你看的书看的怎么样了？"。

·        仔细分析工作中的困难和瓶颈。为了解决信息不对称的问题，上司此处应该做一个好的听众，学会站在员工方面看一下问题，甚至充当辅导员的角色，帮助分析遇到瓶颈的原因，是动机问题(对界面工作不感兴趣，希望做底层)，还是职位角色问题(此职位涉及太多不同模块之间的沟通，希望深入写算法方面的东西)，或是工作方法问题(不应该盲式，可借助工具进行分析)，或是能力问题(原来是学C++的，刚转到Java，对一些框架不是很了解)，或是沟通问题(没能够正确理解美国老板的需求，英语不好，远程会议达不到目的)等等等等。员工也应该站在上司的角度，通过列举事实，说明某些任务耗费很长时间的原因，自己是怎么想的，如何设计的，为什么选择这个方案，为什么没有估计到这个问题等，当然上司也应该区分是团队的共性问题还是员工的个别的问题，如果是个别问题，则可以商讨解决方案及改进措施，如果是共性问题，则应该对团队进行机会教育，并不应该对该员工的绩效有减分印象。

·        如果评级最终不可避免，那么就做在平时。一般仅仅在最终的年终考核的时候，才会对员工进行很好，好，一般，差，很差五级(不同的公司叫法不同，有可能比较委婉，但没有关系，关键你属于哪个级别)的评级，而平时是不会的，况且评级会带来一些尴尬，因而多进行避免。其实既然最终不可避免，与其最后给一个惊讶，不如平时坦诚沟通更能避免情绪的大起大落，从而影响到团队的士气。当然平时的评级不必大张旗鼓的进行，也不必每个月或者每个季度都给员工打上一个戳，给员工带来很大的压力，可以通过One on One的沟通进行。按照杰克威尔奇的分布理论，员工是按照20%优秀，70%普通，10%不足进行分布的。在这其中，前20%是众所周知的明星员工，是不必显式的沟通就可以达成共识的，而大部分普通的员工也是兢兢业业工作，有自知之明，也不太aggressive的。需要显式沟通的是70%中的比较优秀的部分(我们称之潜力股)，以及最后的10%的部分(我们称之ST股)，是会情绪波动比较大的部分。其中潜力股部分，由于本身比较aggressive，也相对比较乐观，容易误认为自己是属于前20%的部分的，当然如果名额宽松，他们是可能进入第二等评级的，但当名额不足，其落入第三等评级的时候，他们会很失望，自信心大受挫折，从极端的乐观主义变成极端的悲观主义，如果不很好的进行沟通，他们往往从第三等级的top一下跌至第四甚至第五等级，甚至出现离职，他们会想，我这么努力的贡献，和大多数平庸的人一样，还不如也平庸下去。对于潜力股，在肯定其潜力的同时，要显式的表明其与前20%的差距，并对其进行辅导和提供培训，通过非评级和财务的奖励(培训机会，演讲机会，独当一面的机会)，让他们觉得付出有回报，树立向前20%进发的激情。对于ST股，在企业整体效益比较不错的情况下，往往也会给第三级评价，所以他们往往也感觉不出自己属于最后的10%，觉得自己的一些失误可能瞒过了上司的眼睛，觉得自己和大多数人也差不多，仅仅在公司效益出现问题的时候(金融危机中)，或者需要裁员的时候，才显现出来，他们往往也十分的惊讶，从而产生敌对的情绪，影响大部分普通员工的情绪，会传递出这样的信息，你看，我每次的工作都合格了，最后也被裁了，这次是我，下次就指不定是谁了。对ST股，也要有显式的沟通，除了肯定其完成了大部分任务外，表明其与大部分同事的差距，通过对他们额外的监管(多问，多指导)表明对其还是关心的，不放弃的，对其失误也是清楚的，还可以通过安排前20%的员工或者普通员工和其pair work，或者对其进行帮助，来让其自身意识到差距的存在。

·        辨别员工所处的阶段。这个阶段既不是完全由上司进行判定，也不是完全由员工进行判定，而是一种通过不断的沟通，对指挥行为和支持行为所占的比重的调整。上司大可不必定义，你属于低能力的阶段，需要更多的指挥，所以你要听我的，这样反而引起下属的反感。在项目有所delay的时候及时的介入指挥行为，随着进度的赶超而慢慢的减缓，在员工士气向下波动的时候及时介入支持行为，随着员工意愿的提高而慢慢减缓。当然在不同的项目，使用不同的技术的时候，员工所处的状态也不尽相同，不可一成不变。

·        调整目标偏移。当员工为了自己心中的理想和信念，而非项目的目标进行工作的时候，不要反对他们这样做，这样会挫伤他们的积极性，然而你知道，如果继续这样做下去会影响进度，所以行为修正是必须的，然而负向强化不等于打击其追求完美的积极性，一种方法就是不做评价，并同时对高优先级的任务一再的跟进，进行反复的正向强化，从而使员工向正确的项目目标转移。

六、近因效应不可避免

所谓近因效应是指在多种刺激一次出现的时候，印象的形成主要取决于后来出现的刺激，即交往过程中，我们对他人最近、最新的认识占了主体地位，掩盖了以往形成的对他人的评价。

近因效应不可避免，但也不要做的太明显，否则会给同事及上司很功利的形象。

由于绩效管理制度的逐渐成熟，近因效应很大程度上可以减弱，其实是一种锦上添花，而非雪中送炭的事情。

所以，对于近因效应：

·        避免其反作用：即一年表现都不错，最后切忌因为取得了不错的成绩而骄傲自满，甚至懒惰，要注意保护自己的劳动果实。在绩效管理的培训中，很多回强调如何规避近因效应的正向作用，对于反向作用却很少被提及，而由于心理落差，作用相对十分明显。所以千万不要干功亏一篑的事情。

·        是70%中的较优秀分子向前20%冲击的最后阶段。如果恰巧名额宽松，能够挤进第二等评级，则在未来一年甚至更长的时间都会有作用，这是一个资格问题，也是一种等级问题。

·        使得近因效应保持一定的惯性，千万不要像读书的时候那样，考前看通宵，考后扔书包，毕竟绩效考核到最终定下薪资涨幅，还是有一段时间的，而且持续一段时间有利于减少功利的形象。

七、年终考评——最后的机会

终于到了一年的年终，是该综合考评的时候了，也是有可能剑拔弩张的时候了。

一般这一切从自我评价开始。

如果说一年就不谦虚一次，我认为应该是这一次

其实自我评价真的起不了什么作用，唯一起的作用是减少近因效应的影响，使得领导能够回望全年的成绩，并不会遗漏。

即便如此，毫不谦虚的将工作成绩列举出来仍然是必要的：

·        提醒上司：当然列举事实是必须的，最好能够让上司回想起那样共同奋斗的日子，如突破一个难题，向高层demo一个结果，共同加班到深夜等，唤起革命友情。

·        总结过去：工作成绩当然不应该散列出来，而应该加以总结，归类，不但可以看到自己的总体进步，对于以后的跳槽时候的简历书写也是很有用的。

·        反省自我：自己的程序人生应该有所规划，也只有自己对自己负责，当前状态同自己欲达成的目标还有那些距离，在未来的一年如何向职业目标迈进。当然这一切不必让上司知晓，然而如果不经常的反思自我，你会发现，自己总是东一榔头西一棒槌的，为了公司的目标做了很多杂七杂八的事情，反而在职业生涯上迷失了方向。

360度评价，只为上司一句话

有的公司在年终考评的时候，会使用全方位的360度评价法，也即通过自我评估，客户评估，同事评估，上级评估，下级评估，部门评估等多个方面对员工的绩效进行考核。相关评级方或填写问卷，或书写评价，甚至可以给出评级。虽然其信息收集相对全面，但也存在很多的缺点，比如评级方的评价会相对主观，而非根据任务完成情况，因而有良好沟通能力，会做人的员工打分会相对比较高，再如不同的评级方给出的评级有时候会出现冲突，如何综合处理是比较困难的，所以很少有公司是完全按照360度考核的结果作为最后的绩效决策，而是作为参考的手段，从而发现员工在那个方向的结果和行为上需要改进。

其实各方面的评价无论多么的好，无论你的上司在你的评语中写了多少的优美词汇，真正最后起作用的，就是在最后的五个评级中选择的那一个，那最后的鼠标一点，胜过千言万语。

公司对于每个评级应该达到的状态是有严格的描述的，比如成绩会超过期望等等，然而促使上司最后鼠标一点的，却不是你是否达到了这些描述，而是他心中的那个排序。

每个人心目中总有一个排名或分布

有的公司要求用强制分布法，有的公司的不会。然而只要是资源有限，是稀缺的，则需求方就会出现博弈，就会出现竞价，排序就不可避免，无论是在制度中，还是在人们的心里。

所以不要纠结你是否达到了公司的业绩描述，而是看你在team中所处的位置，在平时隐式的不断沟通你认为的位置和你上司认为你的位置，尽量平时就达成同步，而非最后现上轿才扎耳朵眼。

在上司提交前最后一次反馈期望

一般，上司在做最后提及之前，会就你的自我评价以及他的评价对你进行沟通，就你的各种成绩进行反馈以及评价，但是却往往不会告知你最后他的鼠标点在什么地方。但这是最后一次可能表达你的期望的时候，如果平时用隐式的方式，这次可通过较为显式的方式表达自己认为自己应该所处的评级，因为一旦点击提交，则很难反悔。当然如果不能达到你的期望，也不必过于偏执一端，分析原因，面向未来吧，况且你没有博弈的筹码了。

 

理解上司的权衡，评级比涨幅更重要

有的时候，碰巧你在排名的时候同另外一个同事打了个平手，然而名额有限，你的上司必须做一个权衡，一个给评级，一个给较高的薪资涨幅和培训。如果有幸你可以选择，你应该坚决的表达这种态度：你想要评级。

评级比涨幅重要的多，这是一个资格问题，关系到你后来的很多福利甚至升职。有的公司会有这样的强制规定，在股票或奖金等方面不同的评级范围不同，可能相差很多钱。有的公司也会有一些隐性的规则，比如连续几次第二评级以上，可以参加管理方面的培训，或者进行升职等，没有评级，可能就失去了机会。如果你因为项目原因进入另外一个组，那个组的成员及lead可看不到你过去的努力，而一个好的评级，是好的印象的开始。有的公司跳槽的时候，referencecheck也会问及在原公司的表现，一个好的评级显然更利于你在面试中的博弈。所以评级远非一点点钱那么简单，如果你有选择，评级很重要。

当然如果你的上司替你做了选择，理解他吧。

八、One on One——一切已经过去

绩效考评完毕，就是进行绩效反馈的时候了，这个时候，你已经知道了自己的评级，还会组织一次One onOne进行沟通，无论你是否满意，一切已经过去了。

其实如果在一年中经过前面的不断沟通，既不应该有惊喜，也不应该有惊讶，每个人都是应该有自知之明的。

如果不幸，你很失望，请记住博弈已经不再可能，应该重点面向未来。

这时候，上司也会和你讨论绩效改进计划，应对自己的不足之处积极的配合制定改进计划，同绩效计划一样的认真执行，千万不要因为情绪原因进一步恶化和上司的关系，陷入恶心循环。

想想经常被提及的下面这个寓言故事吧：做一棵永远成长的苹果树。

一棵苹果树，终于结果了。

第一年，它结了10个苹果，9个被拿走，自己得到1个。对此，苹果树愤愤不平，于是自断经脉，拒绝成长。第二年，它结了5个苹果，4个被拿走，自己得到1个。“哈哈，去年我得到了10％，今年得到20％！翻了一番。”这棵苹果树心理平衡了。

但是，它还可以这样：继续成长。譬如，第二年，它结了100个果子，被拿走90个，自己得到10个。

很可能，它被拿走99个，自己得到1个。但没关系，它还可以继续成长，第三年结1000个果子……

其实，得到多少果子不是最重要的。最重要的是，苹果树在成长！等苹果树长成参天大树的时候，那些曾阻碍它成长的力量都会微弱到可以忽略。真的，不要太在乎果子，成长是最重要的。

你是不是一个已自断经脉的打工族？

刚开始工作的时候，你才华横溢，意气风发，相信“天生我才必有用”。但现实很快敲了你几个闷棍，或许，你为单位做了大贡献没人重视；或许，只得到口头重视但却得不到实惠；或许……总之，你觉得就像那棵苹果树，结出的果子自己只享受到了很小一部分，与你的期望相差甚远。

于是，你愤怒、你懊恼，最终，你决定不再那么努力，让自己的所做去匹配自己的所得。几年过去后，你一反省，发现现在的你，已经没有刚工作时的激情和才华了。

“老了，成熟了。”我们习惯这样自嘲。但实质是，你已停止成长了。

这样的故事，在我们身边比比皆是。

之所以犯这种错误，是因为我们忘记生命是一个历程，是一个整体，我们觉得自己已经成长过了，现在是到该结果子的时候了。我们太过于在乎一时的得失，而忘记了成长才是最重要的。 

当然作为上司，此时也不要太揪住过去不放，对于优秀员工，此时已经信心过于饱满，可以适当谈一些其缺点和可以进一步发展的地方，对于比较差的员工要重塑信心，防止其破罐子破摔，主动倾听他的意愿，从其原意改进的地方入手，哪怕暂且牺牲一下绩效(比如多利用一些工作时间进行学习来提高技术水平，而少做一些任务)，只要其能够不对立，采取合作的态度，再对其行为进行正向激励，就能恢复到正轨上来。

虽然评级基本决定了薪资涨幅，然而同一评级涨幅也不相同，很多上司在同普通员工沟通的时候，无论其涨幅多少，都说是平均涨幅，防止他们产生心理不平衡，其实坦然的沟通更好，永远不要以为薪资保密真的很管用，员工总会知道他们每个人所谓的平均涨幅是不同的，这样反而会使得他们猜来猜去，对上司产生不信任，对绩效好的员工产生怀疑和敌意，从而影响了调薪后一段时间的工作效率，也就是所谓的调薪后遗症，薪水都涨了，效率反而下来了，团队反而不和睦了。

 

 

IT外企那点儿事(9)：升职的多种方式

 

说完了加薪，我们来聊一聊升职。

升职的方式多种多样，为了升职，不同的人可谓八仙过海，各显神通，每个人有每个人的两把刷子，每个人有每个人的道，这不免是我想象到动物世界中各类生物的生存方式，有的靠力量，有的靠速度，有的靠隐藏，有的靠用毒，林林总总，奇妙无比。

我总结了几种常见的升职方式，如有其它，欢迎补充。

当然要想能够使自己在职业生涯当中，不断的得到提升，还是要根据自己的实际情况，选好自己的道。

1、两情相悦式

此为最理想的上下级关系，也是可遇不可求的升职方式了。即两个人的背景，经历，观念，行为方式，以至价值观都相对统一，俗话说就是互相看对眼。

按照著名的《九型人格》理论，如两人都是追求不断进步的完美者，乐于助人的全爱者，追求成果的实干者，追求独特的艺术家，追求知识的观察者，追求忠心的顺从者，追求快乐的享乐者，追求权力的领导者，追求和善的调停者等。

诚然，人们往往更偏爱与自己的行为或人格相近的人，也常因他人的个人特征或工作表现与自己相同或者不同而对其作出高于或低于实际情况的评价，我们称之为同己性与异己性错误。

如果在工作中，碰巧遇到了此类的上司，只要好好把握机会，一定会在他手下得到尽快的提拔。

这不由得我想起《汉武大帝》电视剧中那首歌唱汉武帝和卫青的那首歌：“当时你给我一个笑脸，让我心跳一辈子，使我的目光永远，融进了你的背影”。汉武帝和卫青的确是两情相悦式的正面的典型代表。善于骑兵作战，长途奔袭的卫青，完全符合汉武帝由对匈奴的被动防御转变为主动出击的大政方针，从而可以在元光六年，在仅有很少的战斗经验的情况下，同公孙敖，公孙贺，李广共同出兵四路，迎击匈奴，虽然从最后的结果来看，卫青没有辜负汉武帝的期望，取得了龙城大捷，然而事后想想，却也后怕，从概率来讲，这是一次极具风险的投资，如稍有不利，则会引得无数大汉将士陈尸疆场。自然也更进一步说明了，如果你和上司能够有幸看对眼，则会获得其它人得不到的的尝试机会和风险投资，卫青成功了，在这次项目中，升了职，封了侯，虽然历史不容假设，然而在实际工作中，如果没有成功，扪心自问，你难道不会再给你的卫青另一次机会吗？

另一个反面的例子则可以说是乾隆爷和我们的和中堂了。和珅堪称乾隆爷的知己了，其能办事，会理财，善书画，明心机，甚至在乾隆弥留之际的所想所念，连嘉庆帝都不清楚，和珅也心知肚明，《春冰室野乘》中纪和珅轶事是这样描述的：

高宗纯皇帝之训政也，一日早朝已罢，单传和珅入见。珅至，则上皇南面坐，仁宗西向坐一小杌（每日召见臣工皆如此）。珅跪良久，上皇闭目，若熟寐然，口中喃喃有所语。上极力谛听，终不能解一字。久之，忽启目曰：“其人何姓名？”珅应声对曰：“高天德，苟文明。”上皇复闭目诵不辍。移时，始麾之出，不更问讯一语。上大骇愕。他日，密召珅问曰：“汝前日召对，上皇作何语？汝所对六字，又作何解？”珅对曰：“上皇所诵者，西域秘密咒也。诵此咒则所恶之人虽在数千里外，亦当无疾而死，或有奇祸。奴才闻上皇持此咒，知所欲咒者，必为教匪悍酋，故竟以此二人名对也。”上闻之，益骇。

这也难怪和大人能够飞黄腾达，如日中天了，可不知道为什么，虽然有远见的和大人在嘉庆未当上太子的时候就开始了对其政治投资，可两个人却总也看不对眼，最后的下场也难以仅仅用和珅是否善于逢迎来解释了。

2、共同利益式

一提利益两个字，往往会引起IT工程师的反感，似乎太功利了，似乎这不是在技术圈中应该发生的事情。

的确，在任何行业的职业生涯的初期，技术总是最重要的，比如IT工程师的程序设计，系统架构等知识和经验，比如在四大工作的要考会计资格证书，比如从事律师工作的要考律师资格证书等等，我们姑且称之为生产力。

掌握了好的技术，是前期职业生涯中升职的一个必备条件，只要技术出众，从工程师升为高级工程师应该不成问题。然而慢慢的，越往上发展，会发现生产力方面的因素(technical)越来越不重要，生产关系的因素(nontechnical, soft skill)越来越重要。

想必大家一定看到过这样的情形：一个manager从其他的公司跳过来，往往会带来一些追随他的人，而这些人也会随着此manager的升职而很快的升一级。这不是任人唯亲，因为追随者也是通过层层面试进来的，能力不会相差太远，况且谁不喜欢用知根知底的人呢？却反而有一种苟富贵，勿相忘的兄弟情义，你难道没有期盼甚至和挚友谈论过朋友圈中一人得道，鸡犬升天的事情发生吗？

有人的地方就有江湖，有江湖的地方就有门派，共同门派的人就属于一定程度上的利益共同体，也即我们常说的谁是谁的人。这不是国家公务员的专利，而是人作为组织的一个属性，当你还是初级程序员，高级程序员时不容易感觉出来，因为你根本不掌握任何资源，换谁都一样做，所以没有人在乎你属于哪个门派，所以给人一种IT行业技术至上，没有江湖的感觉，而当你掌握了一定的资源，比如团队，资金，客户的时候，你就必须有一定的立场，为你的团队去博弈。而其他行业之所以江湖气重，就是因为在职业生涯的初期就能够掌握一定的资源，如销售掌握客户，公务员能够掌握一定的权力等。也许你想凭你的技术，像令狐冲一样笑傲江湖，也要看你的技术是不是独孤九剑，其实如果令狐冲是市井无赖，没人在乎他和谁交朋友，可他是华山派的第一执行总裁和未来的总裁，也即掌握了一定的资源，朋友就不能够随便交了。

其实广义的朋友大概分两种，一种是不需要什么条件就会帮上忙的，我们称之为挚友，如同学，室友，战友等，一种是必须双方都有好处才可能帮你的忙的，如普通朋友，泛泛之交，技术大会上交换过名片的朋友等。

同上司是几乎做不得挚友的，所以要想尽快的升职，则最好加入共同利益圈。

在工作中，一方面你要让上司感觉到你是完全可控的，你有的任务来自他的分配，有的则可能不是，其应该掌握你所有的任务状态，一方面你要让上司感觉到你是他的坚定地支持者，在任何公众的讨论会上，坚定地支持并执行其观点，如有异议，则放入团队内部进行讨论，毕竟在外，其是代表整个团队的观点的。

在工作外，你可以参加业余的自发的聚餐，唱歌，旅游，游戏，运动等，在这些非工作的场合中，更容易得到工作中得不到的信息，也更容易在轻松的氛围中融入团队。

那么如何判断是否进入了某个共同利益圈呢？就是圈中的人同你除了谈论显规则，如项目，流程，进度，技术等话题，还会谈一些明着不会谈的潜规则，如抱怨公司制度，传递公司八卦新闻，讨论跳槽和离职，讨论薪水和涨幅等。

最近偶然看到一个关于官场的漫画《屁脸官场》，其中有一幅画是这样画的，链接如下http://mycomic.qq.com/imageview.php?id=115997&msgid=214471&tid=26，颇有深意。

 

 

3、要挟式

升职有时候像做生意，要让别人给你好处，无非是或者你能够让别人得到利益，或者你有能力让别人失去利益。

第一种就是我们说的共同利益式，第二种也即所谓要挟式。

可能失去的利益最明显的就是钱，所以要挟式多用于销售人员掌握大客户的时候。

对于IT项目，在时间点已定的情况下，对上司来讲，可能失去的利益也可以是进度或者质量，如果项目比较紧张，你又是核心员工的情况下可以使用。

但是必须指出的是，如果共同利益式是双赢的话，要挟式对于上司和下属是两败俱伤的。

要挟式就像几乎所有的绑架案一样，成功概率极低，即便成功，也是后患无穷，你将永远的被上司排除在共同利益圈外，对其他领导来看也是一种不忠的表现，很容易在项目度过困难期后被边缘化。

要挟式是一种置死地而后生的方式，往往出现在上司没有公平的分配下属的责任和权益的情况下，也是一种管理不善的表现，对上司的上司看来，是会对上司减分的。

所以要挟式尽量不要使用，当出现责任和权益失衡的情况下(干得多，工资低)，及时的进行沟通，争取通过协商进行解决，如果上司是不见棺材不掉泪型的，也一般和跳槽式同时使用，做好被边缘化的准备，先内部升一级，然后通过跳槽保住这一级甚至再升一级。

4、跳槽式

通过跳槽来实现加薪和升职是最常用的方式。

当然跳槽也是混迹职场不可避免的话题，我们将在另一篇文章中谈跳槽的话题，本文主要讨论跳槽作为升职的手段的问题。

其实通过跳槽进行加薪和进行升职是完全不同的两种路线。

通过跳槽进行加薪，一般应该从弱势公司向强势公司跳，因为强势公司的薪资水平普遍要比弱势公司要高，所以相同的title，从弱势公司跳到强势公司，就可能带来薪水的较大幅度的增长。

通过跳槽进行升职，则一般应该从强势公司向弱势公司跳，因为弱势公司的竞争力较弱，往往通过提高title的方式吸引强势公司的人才，当在弱势公司积累了一定的高title的经验后，可考虑平行甚至升职跳回强势公司(不一定是同一家公司)，从而使得薪水得到两次增长，毕竟强势公司一般是高手如云，等级森严，人数众多的，在原地很难积累更高title的经验。

通过跳槽进行升职在职业生涯的初期较为管用，因为在职业生涯的初期，跳槽基本等于清除大部分的历史记录，如果在原公司因为与上司不合(据统计这是员工跳槽的80%的原因，尽管其离职的时候会说各种各样好听的借口)，对项目不满，和团队不融洽，因犯过失而排在升职榜靠后的位置，才能没有完全发挥出来等等理由而离职，这些信息通常可以不被下家知道(尽管有reference check，人家都是要走的人了，在本公司混不下去，再断了人家在其他公司的生路是很多上司和同事所不忍的)，这样在新的公司可以构建新的上下级关系，新的同事关系，重新建立新的reputation，在新的舞台上展现出原来没有展现出的亮点。

然而随着职位越来越高，在IT圈混的时间越长，通过跳槽来升职就比较困难。首先，你的历史记录是不会被轻易抹去的，因为IT圈子，说白了就这么大，再加上技术方向的选择，跳过来跳过去都是这几家公司，基本上在哪家公司都会遇到原来同事过的人，或者两个人虽然不认识，但是同时认识同一个人，这样你的reputation可能在简历进入下家的时候，你原来的同事就会对你有一定的评定，所以出来混，迟早是要还得。其次，作为一个管理者，无论是和上司的关系，还是在团队中的威望，都是需要一点一滴的积累的，跳槽就意味这你在原来公司和上司长期交流而形成的默契要在新公司重新的进行握手协议，而且你在原来团队中的威望，在新的团队要通过不断的解决问题重新的树立起来，这都是很大的成本。再次，职位越高，很多公司都倾向于内部提拔，这也牵扯到共同利益体的问题，上司怎么知道未来的你会和他穿一条裤子呢，况且空降一开始团队都不服，也会影响工作，所以管理职位对外公开招的比较少，也大大增加了跳槽的难度。

所以对于在IT圈混的时间比较长的老同志，若因为发展瓶颈等问题需要进行跳槽的时候，首先尽量不要通过投简历，而是通过原来在IT圈积累的人脉来打听是否有更高的位置，刚才也提到了同上司建立信任的问题，如果和你关系不错的老上司在另一家公司有一个较高的位置，则你投奔过去，则是一种不错的选择，有老上司的支持，对上没有问题，对下也可以较快的服众了。其次，如果有新的公司分部或者新的部门成立，也是一种不错的方式，这样新团队是你一手带起来的，则威望自然不成问题，唯一要维护的你和新上司的关系。再次，另则一种比较好的方式就是从管理跳到一个更高位置的技术职位，技术职位往往不掌握资源，因而比较容易让上司接纳，对团队也没有空降的感觉，开放向外招聘的职位也相对较多，当你通过你的技术在新的团队中赢得威望，并同上司建立起信任后，只要沟通适当，一般是可以向相同级别的管理职位转的。

5、明星式

所谓明星式，也即孙悟空式，指的是杰克韦尔奇所说的前20%的员工。

你是团队中显然的明星人物，掌握核心的模块，总是能够很漂亮的完成任务，并帮助他人，在同事中享有声誉。

由于你太耀眼，老板不升你说不过去。

大部分公司都有对于明星员工的都有相对明确的升职制度，如在绩效评级时一次或者两次获得第一级别的，则来年可以升职。

明星式是初入职场的程序员理想化的升职方式，认为只要我的技术足够的牛，就一定能够博得上位。

某种程度上说，是这个样子，只要你能够像孙悟空一样，有火眼金睛，能看到别人看不到的地方，有七十二变，做别人所做不出的事情，则一定能成为斗战胜佛。

然而外企是一个强调团队而非个人英雄的地方，没有团队尤其是上司的支持，很难取得成果。况且外企人数众多，高手如云，分工明细，也很难成为超级明星。

就算是能够成为超级明星，也不是在职业生涯的每个阶段都值得庆幸。超级明星的出现，可能说明了你其实应聘进来的时候，应该申请一个更高的位置，也可能说明了你其实应该找一家更好的公司，至少说明了，你在这个位置上完全胜任，几乎没有挑战，在职业发展的初期，不见得是一件好事情。

我们知道，管理学中有个彼得原理，即在一个等级制度中，每个职工趋向于上升到他所不能胜任的地位，这似乎是作为管理者应该避免的事情，然而在高速发展，一切都在通胀中的中国，作为知识型员工的您，理应处在一个不能胜任的位置，只有这样，你才能够不断的接受挑战，取得飞速进步。

所以我经常把职业生涯分成交替进行的两个阶段，第一个阶段是积累期，就像弹簧被压紧的时期，是积累能量的阶段，在这个阶段，你和周围的人的势能落差越大越好，最好和你同事的是比你多十多年工作经验的老前辈，相对于他来说，你的那点本事就一个字，菜，这方能使得你获得巨大的进步；第二个阶段是释放期，就像弹簧弹起的时期，是利用你积累的能量扩大影响力的时期，这个时候，你可以是某方面的明星，从而树立你的威望，而你应该在其他方面积累能量，比如管理等。

总之，是洪七公，就应该去华山和四大高手比武，那才是展现降龙十八掌的地方。

另外，成为超级明星后，也不是万事大吉了，要注意以下几点：

首先，超级明星往往被立为标杆，则你只能往前冲，没有退路，从而面临巨大的压力，一旦做的不好，反而在上司和同事中产生巨大的心理落差，从而使得总体评分不如表现稳定的同事。

其次，超级明星是容易被羡慕嫉妒恨的，要处理好自己的心态，和团队分享荣誉，做好沟通。

再次，超级明星往往会对奖励产生惯性心理，认为一切理所应当，而且还会有边际效应，从而相同的奖励不能带来相同的刺激，被上司认为自负的表现。

最后，超级明星是会尽快升职的，一旦升了职，你就是和更牛的人比较了，也可能很难再成为超级明星了，会有非常大的挫折感，如果处理不当，反而会产生巨大的逆反，最优秀的和最差的其实只有一步之遥。

6、吃苦耐劳式

所谓的吃苦耐劳式，也即沙和尚式，永远是最努力的一个，早上第一个来，晚上最后一个走，什么任务不挑剔，核心边角都干。

不升职，老板都觉得过意不去。

况且此种员工虽不是耀眼的明星，却往往绩效也不错，而且沙和尚之所以随后成为金身罗汉，还有最重要的地点，即坚定地立场。

孙悟空叛逃过，猪八戒数次要分行李，而只有沙和尚，始终坚定地坚持观音菩萨的指点，坚持唐僧的领导，坚持西行的道路，不能不说，吃苦耐劳式是最让上司放心的下属，是上司眼中天然的同盟军，也是上司不在的时候最放心的托付者。

当然，对西行路来说，似乎孙悟空是不可或缺的，然而对于现实生活中的项目，在不缺资金的情况下，哪有非明星员工解决不了的问题呢？即便明星员工不在，靠吃苦耐劳式的苦干，也同样能够完成项目。所以对于很多上司，他们会觉得明星员工难以控制，并且不很稳定，反而更青睐于吃苦耐劳式的忠诚战士。

从历史中也可以看出，越是强势的领导，越有这方面的倾向。从汉武帝，到唐太宗，到康熙皇帝，他们都有一个共同的特点，废了从小培养的，各方面能力不错的，甚至最后众望所归的太子，也没有选用在大臣中有庞大关系网的太子竞争者，而最终选择了似乎在不争的吃苦耐劳的忠诚者。纵观当朝，毛，刘，林，华，毛弃刘而选林并最终选华，邓，赵，胡，江，邓弃赵，胡而选江，似乎也在说明这个问题。

其实吃苦耐劳式的升职方式的选择，也是有多大本事吃多少饭，有多少金刚钻揽多少活的理智选择，孙悟空，猪八戒，沙和尚虽然都是被贬下凡，可是待遇却非常不同，试想孙悟空如不西游，还可以回到自由自在的花果山，猪八戒如不西游，也可以自自在在的做个妖怪，能吃人，说不定还能娶上娇妻，沙和尚却要在流沙河，忍受万剑穿身，十分痛苦，跟随唐僧西天取经，是脱离苦海的唯一出路。

所以作为吃苦耐劳者，要注意：

首先，一定要有一个忠字，否则就变成了老好人，干最多的活，却可能吃力不讨好，因为这些活没有太大的不可替代性。所以最好跟定一个比较有前途的老板，而不要经常换team，甚至换公司，因为你的吃苦耐劳已经在小环境中形成一致认同，换一个地方，这种认同需要重新建立，成本太大。

其次，吃苦耐劳式有一个比较大的缺点就是会浪费很多时间干边角的工作，从而一定程度上降低了核心竞争力，如果你希望从吃苦耐劳式向其他方式进行转换，则最好用业余时间，补充与明星员工之间的差距，争取在上司信任的时候，也可以独挡一面。

7、论资排辈式

此种方式不像吃苦耐劳式的干这么多活，只是本本分分，兢兢业业的做好自己的本职工作，既没有太多的错误，也没有太耀眼的地方。

虽然现代管理更强调能力至上，然而时间和资历有时候却是不容回避的问题，所谓剩者为王，最终整个团队中只有你在业务方面最有经验，从而得到升职。

之所以在稳定的环境下，人们崇尚资历，有其深刻原因：

首先，的确在很多的情况下，经验是有利于问题的解决的。

其次，老员工可能对公司和上司更加忠诚，并已经融入了共同利益圈。

其三，公司的喜新厌旧，无论是出于什么原因，都会带来团队的不稳定。由于这几年的通货膨胀，应届生开出的薪水的增加有时候会超过有一年工作经验的人的年度涨幅，或者在外面招进来的相同层次的员工薪水要高于老老实实在一个地方干上去的员工，有的公司妄图通过薪水保密制度来解决这个问题，但是事实情况是，薪水永远都不会是秘密，尽管每个人都声称会保密，因为中国人有句经常说的话：“我告诉你，你可不要告诉别人”，然而当每个人都说这句话的时候，其实每个人都知道了，但是每个人都不说。这时候老员工就想：“我辛辛苦苦做了这么多的贡献，还不如一个新兵蛋子。””他会跳，难道我就不会跳？”从而造成了老员工的不满甚至离职情绪，当然也不会很好的将已经有的经验很好的传承给新来的同事。所以很多聪明的公司在公司有很好发展，外部薪水有通货膨胀的时候，会选择全面的加薪，从而保证了公司的稳定和忠诚度。

其四，人们往往喜欢维持某一种利益分配的秩序，因为每个人都会老，每个人都会精力不足，不如年轻人有冲劲干劲，然而每个人都想自己老了以后不会因为能力的下降而遭到年轻人的威胁。所以在西方，总统结束任期之后，就成为了普通的公民，而在中国的文化中，一个万人敌的将军当拿不起剑的时候，如果被剥夺将军的品级和待遇，却会让人怜惜。所以中国人常说：没有功劳也有苦劳，没有苦劳也有疲劳。或者说，他能的时候，你还没出来呢。

很多知名的捧哏相声演员最后成为了艺术家，就是靠一天天，一场场的演出，慢慢的再观众中积累人气，从而获得成功的。他们不像逗哏演员那样善于表现，虽说有三分逗，七分捧得说法，然而逗哏甩掉捧哏的却不少见，而有的捧哏演员能够摆正位置，甘做绿叶，最后成为相声前辈。

8、补缺式

你一直工作的很优秀，当你的领导上去了，或者离职了， 你就有机会补缺升职。

这是最推荐的升职方式，因为这种方式不带来上下级之间的冲突，并继续维护长期积累下来的默契协作和共同利益。

要想补缺式上位，一方面要帮助你的上司成功，因为你和上司是共同利益体，只有他以及整个团队有良好的表现，你才能水涨船高，在加薪，升职，跳槽的时候，有更好的背景，人们大多不会相信一个烂筐里会有好苹果。况且即便是你的上司在职场中没有更好的发展，你想改换team的情况下，对其上司以及其他的主管来讲，他们还是更喜欢忠于上司和团队的人，这样他们才更放心的用你，你才有另辟蹊径升上去的可能，试想魏延和黄忠同样为了自己的前途最终投奔明主，却得到不同的评价，尽管韩玄确实不成器，也的确该杀。

另一方面要建立你在部门外的关系网和声誉，甚至和越级领导之间的关系。有时候你的上司离职了，也许他会在最后向其领导推荐一个后继者，然而此时其领导往往并不会直接听从推荐，这时候平时积累的声誉，关系网以及你和其领导之间的关系就越发重要了。如果平时你的声誉没有传播开来，你的上司就成了你的功绩的唯一知情者，而他的上司却无法分辨你是做的真好还是你的上司说的是客套话，你的努力岂不付之东流。相反如果你在同其他团队的合作中，为公司业余做的职务外的事情中，适当的增加自己的影响力，如果有比你高的职位的人替你说句话，将非常有用。当然，你也应该在平时的工作中，增强在越级上司心目中的印象，这当然是一件比较有技术含量的事情，因为比较容易造成你直接上司的抵触，所以如果要做在职能范围外的事情，一定要让你的上司知道，如果和越级上司谈话，要做到非职能，非具体，非正式。所谓非职能，即如果你评价职能的事情，你的直接上司会认为你怀疑他的能力，所以team内部的事情要team内部解决，不要捅到上面去。所谓非具体，就是尽量讲一些抽象的东西，不要与具体的人和事有关，比如公司的前景，流程的改进，公司的文化，某项技术等。所谓非正式，即尽量利用一些非正式的场合，比如午餐，电梯，出游等方式进行沟通，堂而皇之的在工作时间走入越级上司的办公室，不免让人浮想联翩。

三国中，东吴都督从周瑜，鲁肃，吕蒙直到陆逊，都是采用的补缺式的上位方法。他们每个人都是前任左都督时的得力左右，功勋卓著，或是被前任推荐(周瑜推荐鲁肃)，或被大臣推荐(阚泽推荐陆逊)而登上都督之位的。

9、临危受命式

当项目出现紧急情况(如重要客户报来的客服不能解决的高优先级Bug，开发是最后一道防线)，或者是困难问题的时候(如核心员工的突然离开，导致项目可能延期，模块无人维护)，你主动站出来，调节各方，最后解决问题，在此过程中，你有机会表现出超出你本身职位的能力，很可能在不久的将来获得升职。

当然收益和风险是并存的，并不是所有的临危受命都会得到圆满的结果，有的是力挽狂澜，随着项目的转为成功而升职，有的则可能玉石俱焚，随着项目的失败而断送了前程。

所以是否接受临危受命式的升职，一要看项目的难度，是否在自己能力范围之内，要详细分析项目之所以面临当前的危机，是那些因素造成的，这些因素是否自己可以一一得到解决，二要看领导的支持和授权，大部分的危机是需要超出当前职位权力所控制的资源方能够解决的，而且你是临时任命来解决问题，如果没有领导的强力支持和授权，你是很难调动团队和第三方力量的，因为这需要长时间的沟通和威信的建立，而临危就决定着来不及，所以必须有尚方宝剑，三要看团队的支持，如果原来你是在团队中比较有威望，善于沟通的人，则比较容易调动大家一起共度时艰，如果你的威望和资历不足，即便有领导的授权，你做一件事，被拖三天，也是不成的。

临危受命式的成功典范便是周亚夫，而一个失败的典范便是袁崇焕。如果说七国之乱项目成功概率有五成，则五年平辽则似乎是不可能完成的任务。一个有景帝的全权委托，一却要忍受崇祯的生性多疑。虽然两个将军都是中国历史上带兵打仗的能手，最后不同的项目结果，却不得不令人深思。

10、另辟天地式

如果公司或者团队有新的项目，新的流程需要有人去做，去贯彻的时候，可能不一定是好事，但是如果你敢于承担，一旦新的项目或者流程成功，你自然能够得到较快的升职。

正如杰克韦尔奇说过的：要想获得提升，有效的办法是拓展你的工作范围。采取大胆和超出期望的行动，不要只是做那些期望之内的事情。

同临危受命式类似，另辟天地式也需要注意项目，领导，团队三要素，即另外建立的项目或流程需要哪些资源(经费，人员，机器)，是否很容易获得，是否能够得到领导的有力支持，能否很快的建立一支自己的队伍。有的情况下，队伍是自己招聘的，则相对好处理，有的时候，队伍是其他部门的资源，来兼职的配合你的工作的，则领导的支持则至关重要。

比如公司要推广敏捷开发模式，每个团队要选出一个人来，由你带领在每个团队进行推广，这时要清楚，每个团队选出的人作为你的团队成员是临时的，对他们来讲，其真正的绩效和未来是控制在团队领导手中的，如果你不是一个比所有的团队领导都高的职位，除了得到上层的授权，在安排团队成员的工作时，及时的和他们的团队领导进行沟通，数字化的时间点，可衡量的结果，以及合同式邮件都是必须的，别忘了在团队成员有所进展的时候，抄送一封进度及表扬信给他的领导，这也是他的绩效的一部分，如果团队获得进展，则应该抄送上层和其他团队的领导，既是团队绩效的一部分，也是对其他团队的一种压力。当然你不应该摆出颐指气使的架势，有事就拿上面来压，镇不住就请领导也是一种不好的做法，容易被人指为拿着鸡毛当令箭，既不利于以后在团队中的合作，也有可能因为项目的失败成为千夫所指的替罪羊。所谓筚路蓝缕，以启山林，开辟新天地从来就不是容易的事情，既然你没有至高无上的权威，就需要一步一步的去推动，时常过去问问：“上次开会说这个星期一出方案的，应该没问题吧，进展如何？”，“方案不错，太牛了。下午有没有空，我们讨论一下实施吧”(别忘了发封邮件赞扬其方案，并将讨论的实施细节，时间点等也发出来)，“大家做了一段时间了，进展比想象的要快，我们明天上午碰个头吧，林总也挺关系进度的。”

另辟天地的是个典型的例子就是李鸿章：咸丰十年，太平军二破江南大营后，要攻打上海，需要湘军的支援，而另一方面很多湘军主力正准备攻打天京，建立首功，没有人愿意去支援上海。所以这个项目就落在了欲另辟天地的李鸿章身上，李鸿章在老师曾国藩的支持下，招募合肥的团练，并借用了湘军许多的将领和人马，成立了淮军，最终成功完成保卫上海的项目，从此开始了开始了他在晚清政治舞台上纵横捭阖的四十年。

 

IT外企那点儿事(10)：程序员不是程序

 

作为一个合格的程序员，往往是能够很好的管理自己的程序的，无论是源代码维护，文档，持续集成，设计模式，架构等，很多都深入程序员的思想中，甚至成为日常生活中的一种思维方式。尤其是对于长期处于纯研发中心，甚至软件园的程序员朋友们，无论是上班还是下班，甚至课外活动，碰到的都是具有相同思维的人群，进而容易觉得好像大部分人都是相同的思维方式。因而当程序员成为管理者后，往往习惯于将程序员当做程序一样进行管理。

然而程序员不是程序，是有血有肉的人，所以也呈现出很多与程序不同的特性：

首先，程序是有确定的输入和输出的，一般对于特定的输入，一定会得到特定的输出，一般规定了输入输出，也就确定了接口，对其中的具体实现不用关心，对于成熟的公共模块，也不用担心其维护，可放心的使用，达到一劳永逸的效果。

而程序员不是，不是任何对程序员的输入，都会带来特定的输出的。对于同样的输入，如任务分配，奖惩制度，绩效考核等，对于不同的程序员，甚至同一个程序员在不同的职业生涯周期，都会有不同的输出。相对来说，程序员职业生涯的早期，多倾向于诱人的前景，更多的发展计划，更多的实践机会，往往老总们激动人心的讲话，能使得他们兴奋不已，他们愿意早早的来到公司，一直到很晚才回去，公司的晚餐，健身房，小食品等，对他们来说是一种很好的吸引力，他们喜欢天天写程序，承担加班才能完成的任务，如果工作量不足，或者不让他们承担足够的项目，会使他们感到失望，没有发展，没有进步。随着工作时间的流逝，很多人有了家庭，甚至有了孩子，所以更加倾向于work live balance，也许是换了足够多家公司的原因，老总们激动人心的演讲已经很难打动他们，即便是加班费，良好的晚间福利，也无法说服他们很乐意的加班，他们大多已经无法像年轻时一样，每天晚上看大量的书籍来补充最新的知识，因而多倾向于从事一些自己熟悉的领域的架构或者管理工作，对于有多年工作经验的人，已经对整个IT行业有足够多的体验和观察，对自己的职业规划已经有相对清晰的认识，因而对他们的激励，现实的物质激励相对比较管用，对家庭的关心也是增强其归属感的方式(比如有的公司会举办家庭成员一起参加的旅游，拓展，看电影等活动)。

管理程序员不应该像使用接口，你给他输入，他给你结果，就实践来讲，一般情况下，没有对过程的良好控制，是很难得到满意的结果的。

成熟的程序是可以花很少时间维护的，而哪怕是再优秀和成熟的程序员，也都是需要不断的去维护其激情和归属感的，不然会出现让你意想不到的事情，因为一个稳定的程序，几个月不动，该是什么结果，还是什么结果，然而一个优秀的程序员，如果没有进行良好的维护，是会比普通的程序员更快的蜕变到最差的员工的。一个Bug，如果优先级比较低，可以将它放几个月不去动它，当几个月后，运行你的Test Case，它还是那个错误，也许还是无伤大雅，然而一个团队的很小的问题，如果不及时的处理，可能会传播和扩散成大的问题，甚至造成一些人再也无法回头，尽管离职的时候，谁也说不出为什么，矛盾究竟从何产生。

程序是可以需要的时候，便调用一下出结果，不调用的时候，便可以视而不见。而程序员却是一个完整的人，也即组织行为学中所谓的雇主雇佣的是一个完整的人，而非仅仅是一双可以编程的手。作为一个完整的人，程序员有兴趣，有爱好，有情感，有丰富的业余生活，所以过生日的时候一份小礼物，结婚时的一个红包，生孩子的时候的一个祝福，情人节的一封邮件，都可以是的程序员在每天枯燥的编码生活中感受到一份人文情怀。

程序逻辑常常是非此即彼的二元逻辑，然而程序员却是具有复杂的社会人。可能是从小受到的教育问题，我们常常处于二元世界，以至当我年龄蛮大的时候，还会听到同龄人在看电视或者看电影的时候，问：“这人是好人还是坏人”。尤其是对于程序员，从事了和二进制紧密工作后，越来越处于非此即彼的二元逻辑当中了。所以管理程序员就陷入了一个奇妙的关系中：程序员作为一个社会人，本身是有各种复杂的心理活动的，但是对于其管理的对象程序，则使用二元的思维方式，从而一旦程序员成长为管理者，但程序员成为其管理对象的时候，也不自觉地使用二元思维。你会下意识的区分好员工和坏员工么？你会因为几次观点不同的争吵给员工打上标签么？你是否不自觉地就会否定绩效暂且不佳的员工的建议，心想，自己的事都做不好，还这么多话？如果问卷调查反馈不错，管理是否就一定没问题么？试图去了解员工行为背后的心理和动机吧，里面可能有非此非彼的另外的世界。

对程序的管理往往使用svn，cvs等工具，因而很多在项目和程序员的管理中，倾向于对项目管理工具的研究，什么scrum，什么project软件，似乎掌握了这些工具，就能够很好的管理好团队。这也是从技术路线初走到管理路线上的lead的一般问题，似乎技术和工具方面的深入研究比较重要，其实对人心的管理更加重要。我们知道，程序工作属于知识性的工作，其无论是工作量，工作进度和工作成果都是相对比较难以衡量的，而中华文化又是颇具弹性的文化之一。所以相同的制度，关键看怎么说，怎么做，则大不一样。所以我们也许会看到这样的情形，如果团队人心凝聚，则员工会将自己的工作安排的非常紧凑，模棱两可的灰色区域也会争先恐后的被解决，甚至自觉利用自己的业余时间来工作；而如何人心涣散，则员工也会变得不那么尽心尽力，使得一切流程都形同虚设。如果你强制规定上下班时间，则员工会在上班的时间增加浏览网页甚至玩网页游戏的时间；如果你要求预估项目时间，则员工会讲时间估计的极其宽松；如果你要求十分详细的拆分Task，使得预估的时间更加可靠，则员工会增长商讨文档，设计架构，设计Test Case，联调等看起来十分堂而皇之，十分必要的任务，让你说不出什么来，而其中下的真实功夫就难以衡量了；如果你把每一个步骤都定死了时间，则很可能牺牲的就是产品的质量了，东西确实作出来了，Demo出来也是那么回而事，但是架构十分易于扩展，代码是否干净，测试是否完全就不得而知，往往等有人离职了，才发现原来一直功能正常的模块是个烂摊子；如果你进行Code Review甚至结对编程，希望能够规避掉这个问题，不仅仅Code Review本身的时间如何衡量(很多Code Review成了一个人给另一个人介绍模块的过程了，大多数能Review出来的结果也就是很明显的错误，或者Code style之类的，其他的就很难说了，如果Code Review时间安排短了，几乎是什么都Review不出来，安排的长了，就觉得很不值得)，而且很大程度上，员工互相买面子的概率要大于给你面子的概率，毕竟你好我好他也好，今天我Review你的，说不定什么时候你还Reivew我的呢，相煎何太急啊；等等等等。所以凝聚人心是重中之重的，越是低level的管理人员，技术流程方面要多一些，越是高level的管理人员，人心管理要多一些，level高到一定程度，就可以通过作秀来争取人心了。

欲凝聚团队的人心，也是一个复杂的问题：

·        首先是让员工看到目标。作为知识性员工的程序员，和一般的机械工人不同，你很难只告诉他们你去做什么，然后就让他们心甘情愿的工作。尽管很多励志书籍讲《NO excuse》，但是爱好独立思考的程序员，总是爱问清楚为什么，才能塌下心来工作。我写的这个程序将来是干什么的？Demo出来是一个什么功能？在整个架构中处于什么位置，底层还是上层，有没有技术含量？整个大项目在公司产品线中处于什么地位？对这些问题的了解程度，决定了其会花多大的心思来写这一段程序。本文会用两节：你的员工为什么不努力；你总是在画饼么？来讨论这方面的问题。

·        其次是民主型的领导风格。我们知道，领导者风格大致分独裁型的和民主型的。独裁型的领导指令性较强，多进行自上而下的沟通，关注行动，而民主型的领导注重分享，双向沟通，聆听。而麦克格雷戈的组织行为学，也分X理论和Y理论，所谓X理论，认为管理者的作用就是对人的强制与控制，所谓Y理论，认为管理者的作用是为了共同目标，发挥人的潜在能力。正如上面描述的一样，由于程序设计工作是极具弹性的，因而对于程序员来讲，民主型的领导风格及Y理论的管理是相对较受欢迎。本文会在以下两节讨论这个问题：好领导和好员工，鸡生蛋还是蛋生鸡？；好员工和坏员工只有一步之遥。

·        再次是良好的沟通氛围。作为一个中层领导挺不容易的，上有高层，下有员工，内有同事，外有客户，你就是一个信息流通的桥梁，如何保持信息的畅通，自然沟通能力必不可少。你在员工眼中是上级的走狗，还是他们的利益维护者？你在高层的眼中，是自己有个独立的小团体，还是忠诚的执行者？你是否了解员工的苦乐？你是否清楚高层的喜悲？你能否完成上面给定任务？你能否顶住上面给的压力？你是喜欢板起脸来做老大哥？还是和员工亲如兄弟？这些都无不充满着矛盾。本文在以下两节讨论这个问题：上情下达易，下情上达难；左右逢源，还是左右为难？

·        再者，没有规矩不成方圆。虽然我们强调人性化的管理，但是良好的规矩，往往能够降低沟通的成本，从而促进沟通的效率和欲望。相信大家都有租房和配电脑的痛苦经历，我们都要像防贼那样防备中介是否侵吞我们的押金，防备配件商配给我们假的零件，从而使得租房和配电脑的过程精疲力尽，最后大家都乐意选择最知名的房产中介和品牌电脑，这在经济学上称为交易成本，也即在相关方之间安排合同或者契约的成本。同样沟通也有成本，你们团队是否在每天不停的开会，而效率低下？是不是员工一听开会就头大？是不是每次讨论都旷日持久而精疲力竭?是不是很多事情都在重复的讨论？是不是你的员工宁可自己单独做一份，也不愿和其他人沟通来使用别人的接口？本文会在以下两节讨论这个问题：当“we are a team”成为口头禅；又爱又恨是流程。

·        在这里值得提一下的是，在对人心的管理中，对员工的情商的管理十分重要。情商，是一个团队良好运转，互相合作的润滑剂。就像一台机器，如果每个齿轮都没有齿，可能是这个团队不够Qualify，然而如果每个齿轮都锋芒毕露，机器也不能顺利的运转，而且磨损会比较严重。齿轮的齿就是每个员工的工作能力，而情商，就是员工的沟通能力，冲突化解能力，适应变化的能力等。而这正是程序员的一大弱点。萨洛维认为，情商包含五个方面：自我认知，自我控制，自我激励，认知他人，与人交际。在这些方面，程序员多或多或少有自己的问题，本文会在以下两节讨论这个问题：程序员的大侠情结；为什么受伤的总是我。

 

 

IT外企那点儿事(11)：你的员工为什么不努力

 

有很多人抱怨员工不努力工作，常常想为什么有的人年纪轻轻就不努力奋斗，甚至想现在的年轻人的艰苦奋斗的劲头可是越来越差了。
大部分人认为拿一天工资就应该好好的干一天活，哪怕做一天和尚也应该撞一天钟。这的确是最基本的职业行为，然而在现实生活中，我们却发现，当一个员工心不在焉的时候，也就失去了做好每一天工作的动力，似乎公司对其有所亏欠，而支付的工资是对以往的债务和每天流逝的青春的补偿。
似乎仅仅用懒和不努力并不能够完全解释好这一切，而事实往往相反，表面上表现出不努力和不思进取的员工，却在你不知道的方面非常的努力和进取，也许他在钻研自己感兴趣而你的项目中用不到的技术，也许他在准备跳槽，进入一个比现在的工作强得多的公司或者职位，也许他在暗地里创业，并且心理非常鄙视你这种在外企小富即安的生活状态。其实很容易明白，当年这些小伙子小姑娘们意气风发的成功加入这家公司，必定是有一定的激情和能力的，没有一个人愿意懒，愿意不进取，愿意放弃，你不必抱怨当时这些人是怎么被招进来的，招人的人多么不负责任，也许应该反思为什么他们的激情和能力没有被激发出来而日益埋没。举一个比较极端的例子来讲，如果说让一个人每天工作16个小时，工作三个月，则给1000万，相信没有一个人是不努力工作的，哪怕是平时我们认为很懒的人。
在管理学中，有一个期望模型，内容是：激励是一个人欲望的大小及其对实现欲望的概率估计二者的乘积。也即一件事情是否能够激励人们努力去做，一方面取决于这件事情本身的价值(这件事情能够满足人们多大的欲望)，一方面取决于这件事情做成的概率。
对于上面的例子中，显然1000万能够满足人们对于财富的欲望，这1000万对于大多数程序员来说还是很有诱惑的，很有价值的。而对于做成这件事情的概率，相信大部分人还是能够坚持三个月每天16个小时工作的，概率大大的。所以很难有人不全力以赴。
当然对于程序员有价值的事情不仅仅是金钱，还有比如加薪，升职，以及是否使用期望掌握的技术，是否是核心模块，产品对于公司是否重要等等。

了解员工的需求

他是期望做C++还是Java还是Python，是期望从事windows平台开发还是linux平台开发?虽然作为管理者来讲，觉得语言和平台不是问题，无所谓，能够完成功能即可，况且让他多学一门语言和平台，也是对他能力的提升嘛。可是事实有时候不这么简单，有的程序员是具有宗教式的语言和平台崇拜的，如果感兴趣，大家可以搜索一下各大论坛有关哪种语言好，哪种语言快的讨论贴，也基本验证了一句所谓的论坛规律：当回帖超过一定的数目，双方就不再是摆事实讲道理，而是无理的互骂了。还有一个很囧的笑话来描述这种现象：搞C的看不起搞C++的.搞C++的看不起搞java的.搞java的看不起搞.net的.搞.net的看不起搞js的.搞js的看不起搞html的.搞html的看不起美工.最后美工周末去泡mm的时候,一群傻X在那里加班！
他是期望做底层还是上层?程序员还是有各种各样的性格和目的的。有的人期望做出一样东西来很快的能看到成果，从而心中不断充满了成就感，而有的人则期望深入底层代码，甚至公共库，尽量把每一行程序写得完美和高效。有的人急性子，改点东西要马上运行一下，如果有bug，再debug来改，程序运行到这个地方，变量的值大概是i，他才懒得考虑具体是i + 1还是i – 1，运行出来效果不对再调整。而有的人写完代码一遍遍的自己code review，甚至用笔演算，保证准确无误，才运行看看。有的人实现功能，倾向于用最直接简单的方法，先实现出来跑通再说，有的人则倾向于事先做长时间的设计，考虑种种复杂的场景，最后达成一个在其心目中完美的设计。有人期望更多的了解业务，进而以后能够接触客户，转售前，或者出去创业，能够接项目或者做个互联网应用啥的，有的人则期望成为技术专家，在某个方面挖的足够深，成为大公司的技术骨干。
他是期望加薪升职还是期望跳槽或创业?大部分领导都认为，在公司里面工作，加薪和升职是每个员工必然的追求，其实事实并不一定如此。有一部分人可能并不认同公司的文化，而仅仅是想学习这里的一门技术，将公司作为跳向其理想公司的一个跳板的。或是其想创业，但是还需要一个工作来吃饭。这类员工看起来往往认真刻苦，但却不出成绩，不以组织目标为目标，而利用部分上班时间和大部分业余时间进行学习，其不怎么爱参加集体的任何活动，他们喜欢单独执行的任务，不愿意参加需要大量沟通的任务，他们喜欢从事机械性的任务，而不愿意接触核心模块的复杂设计工作，团队开会的时候总沉闷不言，自己看自己的电脑，对什么反应都是好好好，工作外却异常活泼，有很多公司外的社交活动。对于此类员工的管理相对困难，你对他们讲前途，讲加薪，讲升职是没有用处的，所谓人心散了，队伍就不好带了，他们的心已经不在这里了，他们会想等我跳到另一件公司，薪水起码翻一倍，或是你加的这点薪水，对于物价房价飞涨的今天根本没有用处，等我创业成功才是正道，当你苦口婆心讲在公司如何发展的时候，他们在心目中甚至连你也一起鄙视，心想你混得也一般么，众多程序员中芸芸众生中的一个，我一定能闯出一番事业，一定比你强。所以，对他们来说，务实的沟通是最必要的，对于心已经飞出公司的跳槽者，你们可以在会议室里面将这层彼此知道的遮羞布揭开，然后给他一段时间，比如两个月，三个月，仅仅给他零碎的，边角的，独立完成的活来干，让其尽快的集中精力完成这次跳槽，无论是对他(不必浪费时间)，对你(可以空出名额招人)，对团队来讲(不会影响团队人心)都是有好处的，但是要明确告知这样会影响其当期的绩效，如果三个月后并未跳槽成功(该面试的基本都面过了)，则他一般会稍微的收一收心(外面的行情没有想象的那么好，或者自己的水平还需要积累)，这时候你们可以再次坐下来谈一谈，看当前的工作中，是不是可以有他更感兴趣的工作，希望他在接下来的一段时间内(至少半年)可以全力以赴的工作，如果工作出色，可以弥补上面的绩效损失，这个时候，大部分员工都会沉下心来重新投入到工作中，如果其还是不能够完成基本工作，则已经基本仁至义尽了，则可以再次坐下来谈谈，劝说其自愿离职，这样他可以继续集中精力准备跳槽，不必每天在公司痛苦不堪，如果不愿意自愿离职，则在过一段时间，就可以进入观察期，观察期不合格，就可以进入辞退流程了。如果有的公司没有辞退流程，则可以两年绩效评价四级(Not meet)以下，就可以辞退或者不续签合同了。对于在公司混碗饭吃的创业者(本人其实是不太崇尚兼职创业的)，可不安排他们具有挑战性的核心工作以及在公司内部有发展性的工作，只要其能保证完成基本工作，给予他们基本绩效就可以了，如果不能，则也需要坐下来好好的谈谈了。

知其然，知其所以然

其次，在了解了员工的期望后，在分配工作的时候，要尽量顾及员工的期望，让员工知其然，而且知其所以然，也即不但让员工了解要做什么，还要了解为什么这么做，这么做如何符合组织目标也符合其个人目标(其实大多数员工，尤其是有很长时间工作经验的员工更注重个人目标)，而不能像至加西亚的信中写的一样，只关注结果。有一个不值得定律是这个样子说的：不值得做的事情，就不值得做好。这个定律反映出人们的一种心理，一个人如果从事的是一份自认为不值得的事情，往往会持冷嘲热讽、敷衍了事的态度。不仅成功率小，即使成功，也不会觉得有多大的成就感。毕竟你不能要求每一个员工都是罗文，如果每个员工都是罗文了，还要你这个领导干什么？
在分配任务的时候，使员工了解整个项目的全貌也是很重要的。很多程序员都不甘于自扫门前雪，而是很希望看到系统的整个架构，自己做的模块在架构中的哪个位置，如何层层调用，这样不但能够帮助其了解工作的价值，而且会感觉这些信息透明是对他的尊重，并有利于其在朋友同事面前描述其工作的时候更加的高屋建瓴。
如果能在项目设计，计划，模块划分，任务分配阶段，能够较早的让员工有所参与是很必要的。哪怕是仅仅与会而没有发表成熟的建议，或者头脑风暴的idea没有被接受，员工也会认为自己是项目参与者，而不仅仅是执行者，往往会在工作中更加的投入，更加的愿意承担责任。大多数程序员并不乐意看到这样的情形：一帮子领导在会议室里面开会，不知道说些什么，也不让自己参加，没头绪的开完会自己头上多了个任务，这个任务从哪儿来到，要和那些人合作，做成什么样，为什么不是另外一种方案，全部不得而知，还需要一个个的去沟通。他们往往认为：对有关自己任务决策的会议的参与是必要的，哪怕自己的水平不足以做架构，自己的方案比不上资深架构师的方案，经过讨论败下阵来，明白前因后果，来龙去脉，也算心服口服。自古就有文人相轻的说法，程序员身上多少还真有些文人的高傲气质，如果不加讨论的利用职权将方案A强加于他头上，他往往心理一定认为自己的方案B是好的，并在以后的工作中下意识的来努力证明A方案的不足，一碰到困难就会说：看，我早就知道这个方案会有这个问题，用我的就不会。而且会在后续的工作中逃避责任，于是说：方案是他们定的，性能能达到这个就很不错了，很难再进一步的提高。

提高成功概率

再次，在制定任务目标的时候，要把握好任务成功的概率。既不能把目标定的太高，也不能太低，一个通俗的说法是，制定一个跳起来能够够得到的目标。如果定的目标太高，使得员工无法企及，从而产生极大的挫折感，从而自暴自弃。一个笑话是这样说的：如果领导安排的任务上班时间能按时做完，那是谢天谢地，可以准时回家了，如果上班完不成，那就需要加班完成了，如果加班完不成，那就需要通宵搞定了，如果发觉通宵也搞不定，靠，不干了，于是准时回家了。所以在制定目标的时候，一定需要同员工开会商议决定，由员工来预估时间，然后根据进度要求作微小的调整，或者减少功能，你可以仔细询问员工预估时间的理由，并确保没有什么难题对员工的工作造成阻碍，因为可能在上司或者有经验的人员看起来顺利成章，轻而易举的事情，对员工来讲是一个很大的难题。在这个方面，scrum如果执行较好的话，是一种比较好的实践。当然如果目标定的太低的话，会使得工作没有挑战性，从而丧失激情和意义，程序员多是热爱挑战的群体，他们大多抱怨日复一日的ctrl+C/ctrl+V的重复性工作，期望能经常研究一些新的或者更加深入的技术。所以任务分配中的一人管一摊，做什么总做什么的现象也是不好的，一方面缺少backup，当出现人员流动的时候，不是临时交接就能够交接的了的，另一方面大家的工作都缺少挑战性，也不利于员工了解项目的全貌。所以应该一两个精通的来保证质量，带一两个一般的，这样一方面促进沟通能力，一方面对一般的来说是一个挑战。而在此任务中精通的到了其他任务上，可能就变成一般的了，同样也具有了挑战性。如此下去，大家都了解了项目的全貌，其中素质较好的员工就可以预备成为架构师了。
另一个提高任务成功概率的方面，是对任务执行过程关键点的把控。有时候，我们的员工工作没有成效，并不是员工不努力，而是努力的方向不对，不知道那些是正确方案，遇到问题应该找哪些人寻求帮助。所以作为管理人员，是有义务对过程进行监控的，而不仅仅是要结果。比如在写代码之前，对员工的设计和方案进行评审，就是很重要的一个环节，通过这个环节，可以确保员工做的正是你想要的，而不是代码写了一大堆，却发现南辕北辙，大大的挫伤积极性。程序员是最讨厌一个东西改过来改过去的，一行行的代码就是一行行的心血呀，哪能说扔就扔呀。所以网上流传着一首改编的歌：当初是你要修改，改就修改，现在又要拍脑袋让我改回来，设计不是你想改，想改就能改，让我改版让我修改你丫自己来。虽然在新产品的开发过程中，返工是不可避免的，但是作为有一定经验的老人，是可以通过架构方面尽量的减少这方面的冲击的，新人在这方面是需要指点的，对程序员劳动成果的尊重是最大的激励。

兑现回报

最后，应该给予员工的应有的回报来匹配员工的付出。如果曾经有没有兑现的回报，则会大大降低人们心目中的概率。就像上面的例子中，如果一开始说给1000万，后来只给了10块钱，那下次就再也没有人会努力工作了。

 

 

 

IT外企那点儿事(12)：也说跳槽

 

跳槽的学问不在一个跳字，而在于长期的职业生涯规划。跳槽可以帮助职业生涯更上一层楼，而跳槽之所以能够成功，也是因为以往有了较好的职业生涯规划。

 什么决定了程序员的价格

所谓的职业就是企业和员工之间的价值交换。企业付出薪水，福利来雇用员工，以期通过员工的劳动来实现企业的目标。员工付出劳动，技术，以期通过在企业中的劳动来实现自己的目标。当双方都觉得收获大于付出的时候，交换就会产生，于是供需双方达成合作，价格也就产生了。

当然这里的价格不仅仅是薪水，而是多方面组成，参考马斯诺需求，现分类如下：

 

·        生理需求：薪水够不够吃饭，是不是老是加班，长期出差，是不是需要大量应酬喝酒抽烟，是不是腰椎颈椎有问题，是不是压力太大影响心理健康。

·        安全需求：工作是不是稳定，是不是会随时裁员，朝不保夕，公司可能不可能被兼并或者面临倒闭。

·        社交需求：团队氛围是不是很好，是互相信任，还是勾心斗角，工作环境活泼还是压抑。

·        尊重需求：公司或者上司的领导风格是否过于强硬，是否尊重员工的劳动成果，员工的工作是否有技术含量，在业内得到认可，员工所在的公司是否得到社会的尊重。

·        自我实现需求：是否能够学到新的技术，是否能够职位上难以提升，是否工作过于清闲，职位被架空。

 

那么程序员到底价格几何？由什么来决定的呢？

在工作或者面试中，我们常常看到有以下两方面的误区：

·         企业方面：在给企业提出多少薪水的时候，想想你给企业能够带来多少价值。凭什么你一个大学毕业生，刚入职场，就要求给你1万的收入？你想想你一个月能够给企业赚1万元么？我们还要花时间培养你。你先来我们这里，给你一个月2000，等你的能力上去了，相信薪水也会跟着上去的。这是我们经常听到一些老板的理论，每当这个时候，被问到的求职者就会苦笑不得，我也不知道我能不能给企业每个月赚1万，但是我的确得到了另一个公司的1万的offer，你给不了，我就要去他们那里了。老板的这种理论是典型的使用价值决定价格的理论，虽然这些老板对求职者是这个样子的，转过脸来对消费者就不是这个理论了，变成了供需理论，同样一个房子，原来5000一平米，现在30000一平米，房子给我带来的使用价值值得我花这么多钱么？老板会说没办法，需求太旺盛了。其实同样对于程序员也是这个样子的，是供需而非使用价值决定了我们的价格，我们只要保证在市场中像我们这样整体素质的人需求大于供给就可以了，举一个极端的例子，如果公司想聘用一个清华大学毕业，学生会主席，英文流利，ACM程序设计大赛冠军，就是他写出的软件年年赔钱(当然赔钱的原因很少是因为程序员的问题)，你也必须要付出相应的价格才能聘用。

·         员工方面：我们程序员千辛万苦，加班加点做出的软件，老板卖了1000万，可是每个月还是给我们2000一个月，连加薪都不肯。就像上面讲到的，软件赔钱的原因很少是由于程序员，其实软件赚钱的关键点也多不在程序员。为什么这么说你不是关键点呢？其实还是一个供需的概念。假设你的薪资水平是2000一个月，你们100个人一起完成了这个项目，和你同样水平的程序员在市场上有10万人，可以组成和你们一样的团队1000个，如果有机会的话，每个团队都想赚这1000万，但是却只有你们团队接到了这个项目，这里面可能有以下的因素：一是别的团队不知道，你的老板说不定跟了这个客户n年才知道客户需要这个软件，这叫信息；二是知道了，却拿不下来，招标人说不定是你们公司副总的小舅子，这叫资源；三是知道了，也有可能拿下来，但是前期投入需要500万，做完了才能赚1000万，可是你们这个团队所有能凑加起来才100万，挣不到钱公司就得垮，这叫资本；也可能是销售卖的好，也可能是市场广告做的好，客户相信你们的品牌等等等等，正是这些因素而非你的技术，让你们团队从1000个相同类型的团队中脱颖而出，所以你不是关键点。当然，如果你掌握的是很牛的技术，整个市场上一共100个人会，而想使用这个技术的公司就不止100个，所以是因为你的技术使你的公司脱颖而出，你理所当然的成为关键点，那1000万中你得一大部分也不为过。

所以，程序员的价格是由供需关系决定的，有一个概念叫做机会成本，也即公司换掉你再招一个需要多少钱，那么你大概就是这个价格。就像第一个误区中的公司，你如果想招这样的牛人，无论你的公司是否盈利，就必须要给这么多钱，你嫌他要的高，把他赶走，再招一个同样水平的，还是需要这么多钱，除非你降低要求，招个不那么牛的。再如第二个误区中的员工，如果你所从事的技术很多人都会，甚至培训一下就可以速成，那么如果你因为觉得这样不公平就不想好好干，老板可以辞掉你后，同样花2000到3000再招一个，并不影响其项目的进行。

程序员如何涨价

当然市场上价格不是固定不变的，而是不断变化的。

这种变化有客观方面的原因：有的时候因为需求的增加带来程序员价格的上涨。一些新的产品，新的平台，新的理念，会造成新的技术方向，当新的技术方向刚刚兴起的时候，需求远远大于供给，从而造成在一段时间内从事新的技术方向的程序员薪资高企，引得众多程序员趋之若鹜，然而当进入这个新的技术方向的程序员大大增加后，薪资就会慢慢回归。另外就是整个社会的通货膨胀，新发的货币虽然最先流入基建工程，如铁道，公路，或者房地产，金融，使得这些行业赚的彭满钵满，上游产业吃肉，IT业也能喝点汤，流动资金增多，很多创业企业就能够得到较多的天使投资或者风投，成熟企业也能够借机扩张，从而造成大量的程序员岗位缺口，引得很多人跳过去，这些人的跳槽又造成了原来企业的岗位缺口，从而最终出现大家都跳一跳，薪水也都跟着涨一轮。

在主观方面，作为程序员，我们自己更应该做的是，减少相同水平的供给量，也即提高自己的不可替代性。有人可能会说了，不可替代容易啊，人们不能两次踏入同一条河流，世上每个人都是不一样的，每个人由于性格特点，个人兴趣，学习经历，工作经历不同，会形成不同方面的能力，虽然每个方面的能力不是最好的，但是各方面综合起来，就会存在一定的不可替代性。比如一个人英语好，爱炒股，本科学的会计，研究生读的是计算机，也许这个人做不了最好的翻译，不能成为最好的证券分析师，不能做最好的审计员，不能成为最牛的软件工程师，但是如果说要找一个四门全会的人，这个人就有很好的不可替代性。这种说法有一定的合理性，不过还是必须要指出的是，这里的不可替代性，是供需关系下的，不但要强调供给(我具有某些能力)，还要看这些能力有没有需求，以及这些能力有没有需求结合点(同时需要这些能力)。显然如果一个公司不需要某项能力，就不会为这项能力付出额外的薪水。比如这个人找了一家做web开发的国内公司，公司就仅仅会付给一个软件工程师的钱，如果这个人碰巧找了一家做财务证券软件的外企，则公司自然会为外语能力，证券知识，会计知识付出额外的薪水。这不但告诉我们，在找工作的时候，应该尽量去寻找你的各项能力有需求结合点的公司，也同时告诉我们，自己的职业生涯需要好好的规划，使得自己的多项能力更容易找到需求结合点，而不是东一榔头，西一棒子。设想如果你做了三年C++，三年Java，三年C#，结果样样通样样松，哪一方面也要不上好的价格，和做了9年C++的人就不能比了。

那么程序员应该如何规划自己的职业生涯呢？当然谁都不可能一毕业就知道自己想做什么，即便有想法，也可能能力不及，暂时不能实现，即便能够实现，也可能做着做着，发现最初的想法不符合。但是必须指出的是，一个人，无论多么不成熟，无论前途多么迷茫，每个阶段，都应该有一个目标，随着自己的路慢慢的走，经验不断的积累，前面的路能够看的清楚一些，可以根据自己的经验，性格特点，做事风格，已有优势，目标可以进行一定的调整(不必固执于原来的想法，请参考老罗语录Happy Accident)，每次调整，可能都会面临选择，没办法，只有像李开复说的那样follow your heart，追随内心，人都有一个特点，追随内心的选择比较不会后悔(至于对不对，人生没走完，谁也不知道)。比如面临A，B两个选择，内心想选A，可是家人，朋友都觉得B好，如果选择了A，A选择顺利，则会庆幸自己的选择，如果A选择不顺，也会想，就算选B也可能不顺，相反如果违心选了B，如果B顺利，会想如果选A说不定更好，如果B不顺，则抱怨家人朋友让自己掉坑里了。(也提醒大家在亲友人生重大问题上，必须让其自己选择)

前面说的比较抽象，下面具体说说。在这里，我把程序员的能力分为以下几个维度：技术深度，架构广度，业务知识，管理水平。

当一个程序员从学校里面出来，所掌握的基本只有计算机基础知识以及程序设计语言，这个时候，会面临第一个选择，就是语言方向问题，java/C++/C/C#/PHP/Python/Perl等，有的是主动选择的，非这个我不做，大多数还是被动选择的，可能在学校学习的是C++，擅长的是C++，面试的也是C++，但是分到team后，发现项目是Java的。因为刚毕业，程序员像一张白纸，公司不怎么挑面试者的语言，觉得只要基础好，上手都很快。如果你有很强烈的语言倾向，则在前三年务必坚持使用这门语言进行开发，如果这三年使用了其他语言，再去面试的时候，公司就不再会相信你在大学的时候擅长某门语言这个故事了，在想转回去难上加难。如果没有强烈的语言倾向，倒也无所谓，每门语言都有自己的优势，也都能出牛人。

在最初的三年，根据接触的项目不同，你已经开始接触某个技术分支，比如linux应用程序开发，linux内核开发，windows应用程序开发，windows driver开发，Java SE，Java EE等。在这三年，你可以不怎么稳定，换项目甚至不断跳槽，职业生涯初期的频繁跳槽还是比较容易得到理解的，但是不是盲目的跳，你要做的一件事情就是确定好自己未来的技术分支，并开始在这个方向上深入研究，形成自己的第一维度的能力——技术深度。根据不同的人基础不同，确定技术方向的快慢，深入研究的努力程度不同，在职业生涯的第三到第六年，技术深度一般会达到一定的程度，大多数人都会成为高级工程师，在这个阶段的后期，一般会再一次面临选择，这是职业生涯中关键的一次选择，将影响职业生涯的第六年到第十年。有的人会选择更细的技术分支进行进一步更深入研究，继续扩大自己在技术深度这一维度的优势，此类人职业规划简单直接，就是成为某项技术的大牛，不希望找过多的需求结合点，就像郭靖一样，就是降龙十八掌一掌一掌练下去，就靠一技之长行走江湖，跳槽也是容易，只要是需要这方面技术的就可以，其他的我不想做，对于此类程序员，我的建议还是选择一些有技术含量，稳定不易淘汰，不是一时半会儿能学会的方向，比如linux存储系统的开发，数据挖掘，图像处理等。有的人不希望进一步扩大技术深度这一维，而是希望整个系统从前端到后端，从底层到上层都能够有一定程度的了解，也即开始扩展架构广度这一维度，此类人对每一项技术都会了解到一定的深度，在各项技术大牛的帮助下，能够搭建起整个系统，他们的职业规划就是成为架构师，由于各个模块的技术都有可能更新，所以架构师需要不断的学习新的技术，不至于架构过老而遭到淘汰。有的人做的软件是面向某个行业的，比如金融，证券，财务，航运，电力等，他们出来技术深度形成一定的优势外，在三到六年这段时间里，也开始慢慢了解这些行业，于是扩展了另外一维——业务知识，他们能够迅速理解这些行业的业务需求，并转换成为软件的需求，他们的职业规划就是需求分析师，他们需要更系统的学习业务方面的专业知识，以期能准确把握需求。有的人在成为技术主力后，由于有一定的沟通和组织能力，开始带新人，以及领导一些人完成任务，于是扩展了另外一维——管理水平，他们需要学习项目管理，组织行为学，绩效管理等方面的知识，职业规划是成为技术经理，我的建议是有可能的话，做管理开始尽量在大公司，一方面大公司体制完善，培训到位，会更快帮助你成为一个好的管理者，另一方面大公司的管理岗位才有含金量，不像小公司，动不动就冒出个技术总监。

接下来，在工作的第六年到第十年，就是按照上述的选择各自走各自的道路，最终小有成就，成为真正的技术牛人，软件架构师，需求分析师，技术经理。在这个时期的后期，部分人还是会选择多维的结合，技术牛人技术太牛了，大家五体投地，都心服口服的听他的，最终也会发展处管理水平这一维，成为技术型领导者；架构师由于需要协调各方，也会发展出管理一维，成为经理，由于架构师基本能够自己搭建一套系统，有可能会因为一个idea进行创业；需求分析师一般也会参与到架构设计中，发展出架构广度一维，也需要协调团队完成需求，发展出管理一维，从而可以成为乙方的项目经理，甚至会进行接项目方式的创业；技术经理可以进一步拓展管理一维，成为高级经理直至技术总监。在国内，成为大公司的技术总监，中小公司的CTO乃至VP，是大部分的程序员职业生涯的顶端，如果你是国外派回来的海归，或者自主创业成功的英雄，那应该另说，毕竟都是少数。

当程序员按照自己的职业生涯规划提高自己的不可替代性的时候，会造成市场上此水平程序员的价格上涨。

是时候跳槽了

当某程序员的市场价格上涨，而公司付出的价格没有跟上的时候，跳槽也就产生了。跳槽就是使得程序员的价格不随着公司的盈利状况，薪资制度而线性的增长，而是到市场中重新估价的过程。

根据上述程序员价格的组成，跳槽的原因包括以下几点：

生理需求方面：

·         加薪幅度不够，很多老板抱怨IT行业跳槽频繁，其实也是很无奈的事情，公司内部一般都有一定的加薪制度，根据不同的表现获得不同的加薪幅度，这个幅度不是根据市场情况来定的，而是根据员工之间的比较优势，背后的逻辑是这样的，表现好的员工技术进步较大，应获得更多加薪。一方面，从市场行情自有其运作规律，有的时候外界出现较大的通胀，相同水平的程序员价格普遍升高，其实这些情况公司都很了解，也不得不遵守市场规则，否则就会招不到人，常出现的现象就是应届生起薪升高，从外面挖过来的人薪资偏高，当员工发现应届生比自己辛辛苦苦干了一年薪水还多的时候，当员工发现自己忠心耿耿在公司埋头苦干多年还不如一个外来的和尚的时候，当员工发现自己好好表现还不如表现一般的同事随意一跳的时候，跳槽便成了理智的选择；另一方面，从员工的个人能力角度，需要指出的是，尤其是在职业生涯的初期，由于程序员底子薄，只要肯用功，成长速度往往飞快，远远超过公司的加薪幅度，而且在公司的表现可能仅仅是员工的冰山一角，真的并非表现最好的员工技术进步最大，因为表现最好的员工一般是老板的好帮手，老板指东打东，指西打西，因而可能会干很多的杂活，而且由于疲于应付工作，接触到的每项技术都没有办法深入研究，而很多表现一般的员工，却很有心，活虽然干的慢一些，但是遇到的技术会花时间研究下去，经过一段时间的积累，技术可能大大进步，跳一跳可能会有较大的薪资涨幅，所以跳槽也就成了理所应当的事情。

·         加班时间过长，工作和生活长期失衡，虽然薪资可以，但是性价比较低，甚至造成身体的疾病或者心理的疾病，实在得不偿失。不要过于相信很多成功人士的话，说自己年轻的时候怎么怎么拼命干活，才有的今天。虽然不能说这些成功人士的话不正确，的确很多人是付出了超出常人的努力才能出人头地，但是每个人的身体状况不一样，你听说过因为年轻的时候太拼得了干眼症的周鸿祎，也会听过因疲劳过度而患肠癌死去的王均瑶，更听过因身体不支加班后猝死的狼性公司，以及因心理原因接连跳楼的血汗工厂，我想说的是，自己的身体应该自己最清楚，当身体出现不舒适和不良信号的时候，没有什么理由应该让你不顾一切的工作下去，如果你为国家而死，还能封你个烈士，让你的妻子父母得到一定的抚恤，然而为在某公司内部的一个薪酬评价，你值得么？当你觉得身体有时候有点撑不下去的时候，果断去休息，去看病，这个时候，不要管同事的催促，老板的不满，客户的抱怨，当你倒下的时候，唯一伤心的是你的父母，妻女。有人可能会说，别人能坚持，如果我不坚持，那怎么能够成功呢？首先不可能每个人都能成功，其次即使追求成功，也有早有晚，有不同的方式，有人可以很年轻一篇文章红遍大江南北成为明星，有人则可以终生研究一个东西一直到九十多岁成为泰斗，别人熬夜七天闯过去了可能创业成功，你却可能熬夜七天心肌梗塞猝死。人生应该有追求，但不应该强求。

安全需求方面：公司经营遭遇困境，面临减薪，裁员，甚至倒闭。这几年，由于国际经济形势不佳，很多大型公司都在裁员，必将导致公司内部人心惶惶，很多人都开始准备跳槽，以留下后路。

社交需求方面：无法融入团队氛围，与同事无法合作。团队的氛围的形成很大程度上是由团队领导者的领导风格造成的。领导总会自觉或者不自觉的喜欢和倾向于比较符合自己做事风格的员工，从而对团队的氛围起到导向作用。团队中的很多无法合作和冲突往往就是因为各自的做事风格不同造成的，各自都有自己的理由，彼此对对方不屑，但其实平静一想，很难说是谁有错。我经常听到有人抱怨自己的同事如何如何差，如何如何极品，这种人怎么可能有发展，怎么可能交的到朋友，打死我我都不愿意和他再共事。我于是就问：你仔细观察一下他，他在生活中真的没有朋友么？得到的答案往往是否定的。于是抱怨者就很困惑他的那些朋友平时是怎么相处的。于是我说：说不定在他的朋友圈中也是这样评论你的呢。无论什么性格和做事方式的人，都会有朋友，也都会有一定的发展，你不愿和他同事，他也不愿意和你同事，只能说你们是不同维度的两个人，但不可能因为你们的冲突，上天就一棒子打死别人的生活和工作。所以如果你是一个乐观开朗的人，你可能会抱怨一个团队死气沉沉，可是他们也可能抱怨你过于活跃而影响别人集中精力编程；如果你是一个喜欢主动争取的人，你可能会发现一个团队人人等着领导分任务，可是他们也会抱怨你总是争功，出风头；如果你是在大公司工作较长时间，崇尚良好的软件流程，加入一家小公司后，发现各种的不规范，可是别人会抱怨你的那套东西不适合小公司，流程太完善，效率太差，小公司那有空这么玩。总之，当你发现你和你的同事不是一个维度的人的时候，跳槽也就在眼前了。

尊重需求：同上司有矛盾，劳动成果得不到尊重。这往往是离职的一个最主要的原因。　来自盖洛普公司的调查显示，75%雇员的离职是离开他们的主管而非公司。在《首先打破一切常规——世界顶级管理者的成功秘诀》(First Break All theRules: What The Worlds’ Greatest Managers Do Differently)一书中提到：员工不是离开公司，他们是离开老板(people don’t leave jobs, they leave managers)。所谓干活不由东，累死也无功。因为和上司的不和，会使得其他的各个方面都化为乌有，什么加薪升职肯定排在最后，也别想做什么核心的模块，如果有裁员那肯定是首当其冲，所以三十六计走为上。

自我实现需求：职业生涯得不到发展。在上面提到的各种职业发展路径中，对于技术牛人路线或者架构师路线的人，如果发现在某家公司技术进步的速度较慢，则应该选择一个高手更多的更有技术含量的公司，注意这里强调的是速度，而非绝对的量，因为我们知道，在任何一家公司里面学习技术，总是由刚来的时候非常快，到后来慢慢减缓的，有的老板强调绝对的量，也即只要你在这家公司还有的可以学，就不应该跳，当然天外有天，人外有人，怎么可能在一家公司没有任何可以再学的东西呢？所以我强调的是速度，就是当速度下降到一定程度，你发现总是重复在干一些事情的时候，就可以选择去一家更牛的公司，来进行下一轮高速度的学习了。对于走需求分析师路线和管理路线的人，如果发现公司的业务或者规模发展比较慢，或者公司的平台比较小，上面已经坐满了比自己大不了多少的年轻领导，则说明发展空间有限，应该选择一个平台更大，扩张更快的公司。前面说的都是从下游向上游跳，当然也有反其道而行之的，有的人在大公司里面学到了核心技术或者较高层的管理经验，遭遇人生的天花板的时候，反而会选择跳到一些中等的公司进行半创业或者索性自主创业，以期人生获得更大成功。