网站地图 | RSS订阅 老铁博客 - 专业上海SEO上海SEO优化,分享网站优化知识,同时提供上海SEO服务。
你的位置:首页 » 我评it
ASP程序

我评it-IT外企那点儿事(9):升职的多种方式

我评it-IT外企那点儿事(9):升职的多种方式

   IT外企那点儿事(9):升职的多种方式
  说完了加薪,我们来聊一聊升职。
  升职的方式多种多样,为了升职,不同的人可谓八仙过海,各显神通,每个人有每个人的两把刷子,每个人有每个人的道,这不免是我想象到动物世界中各类生物的生存方式,有的靠力量,有的靠速度,有的靠隐藏,有的靠用毒,林林总总,奇妙无比。
  我总结了几种常见的升职方式,如有其它,欢迎补充。
  当然要想能够使自己在职业生涯当中,不断的得到提升,还是要根据自己的实际情况,选好自己的道。
  1、两情相悦式
  此为最理想的上下级关系,也是可遇不可求的升职方式了。即两个人的背景,经历,观念,行为方式,以至价值观都相对统一,俗话说就是互相看对眼。
  按照著名的《九型人格》理论,如两人都是追求不断进步的完美者,乐于助人的全爱者,追求成果的实干者,追求独特的艺术家,追求知识的观察者,追求忠心的顺从者,追求快乐的享乐者,追求权力的领导者,追求和善的调停者等。
  诚然,人们往往更偏爱与自己的行为或人格相近的人,也常因他人的个人特征或工作表现与自己相同或者不同而对其作出高于或低于实际情况的评价,我们称之为同己性与异己性错误。
  如果在工作中,碰巧遇到了此类的上司,只要好好把握机会,一定会在他手下得到尽快的提拔。
  这不由得我想起《汉武大帝》电视剧中那首歌唱汉武帝和卫青的那首歌:“当时你给我一个笑脸,让我心跳一辈子,使我的目光永远,融进了你的背影”。汉武帝和卫青的确是两情相悦式的正面的典型代表。善于骑兵作战,长途奔袭的卫青,完全符合汉武帝由对匈奴的被动防御转变为主动出击的大政方针,从而可以在元光六年,在仅有很少的战斗经验的情况下,同公孙敖,公孙贺,李广共同出兵四路,迎击匈奴,虽然从最后的结果来看,卫青没有辜负汉武帝的期望,取得了龙城大捷,然而事后想想,却也后怕,从概率来讲,这是一次极具风险的投资,如稍有不利,则会引得无数大汉将士陈尸疆场。自然也更进一步说明了,如果你和上司能够有幸看对眼,则会获得其它人得不到的的尝试机会和风险投资,卫青成功了,在这次项目中,升了职,封了侯,虽然历史不容假设,然而在实际工作中,如果没有成功,扪心自问,你难道不会再给你的卫青另一次机会吗?
  另一个反面的例子则可以说是乾隆爷和我们的和中堂了。和珅堪称乾隆爷的知己了,其能办事,会理财,善书画,明心机,甚至在乾隆弥留之际的所想所念,连嘉庆帝都不清楚,和珅也心知肚明,《春冰室野乘》中纪和珅轶事是这样描述的:
  高宗纯皇帝之训政也,一日早朝已罢,单传和珅入见。珅至,则上皇南面坐,仁宗西向坐一小杌(每日召见臣工皆如此)。珅跪良久,上皇闭目,若熟寐然,口中喃喃有所语。上极力谛听,终不能解一字。久之,忽启目曰:“其人何姓名?”珅应声对曰:“高天德,苟文明。”上皇复闭目诵不辍。移时,始麾之出,不更问讯一语。上大骇愕。他日,密召珅问曰:“汝前日召对,上皇作何语?汝所对六字,又作何解?”珅对曰:“上皇所诵者,西域秘密咒也。诵此咒则所恶之人虽在数千里外,亦当无疾而死,或有奇祸。奴才闻上皇持此咒,知所欲咒者,必为教匪悍酋,故竟以此二人名对也。”上闻之,益骇。
  这也难怪和大人能够飞黄腾达,如日中天了,可不知道为什么,虽然有远见的和大人在嘉庆未当上太子的时候就开始了对其政治投资,可两个人却总也看不对眼,最后的下场也难以仅仅用和珅是否善于逢迎来解释了。
  2、共同利益式
  一提利益两个字,往往会引起IT工程师的反感,似乎太功利了,似乎这不是在技术圈中应该发生的事情。
  的确,在任何行业的职业生涯的初期,技术总是最重要的,比如IT工程师的程序设计,系统架构等知识和经验,比如在四大工作的要考会计资格证书,比如从事律师工作的要考律师资格证书等等,我们姑且称之为生产力。
  掌握了好的技术,是前期职业生涯中升职的一个必备条件,只要技术出众,从工程师升为高级工程师应该不成问题。然而慢慢的,越往上发展,会发现生产力方面的因素(technical)越来越不重要,生产关系的因素(nontechnical, soft skill)越来越重要。
  想必大家一定看到过这样的情形:一个manager从其他的公司跳过来,往往会带来一些追随他的人,而这些人也会随着此manager的升职而很快的升一级。这不是任人唯亲,因为追随者也是通过层层面试进来的,能力不会相差太远,况且谁不喜欢用知根知底的人呢?却反而有一种苟富贵,勿相忘的兄弟情义,你难道没有期盼甚至和挚友谈论过朋友圈中一人得道,鸡犬升天的事情发生吗?
  有人的地方就有江湖,有江湖的地方就有门派,共同门派的人就属于一定程度上的利益共同体,也即我们常说的谁是谁的人。这不是国家公务员的专利,而是人作为组织的一个属性,当你还是初级程序员,高级程序员时不容易感觉出来,因为你根本不掌握任何资源,换谁都一样做,所以没有人在乎你属于哪个门派,所以给人一种IT行业技术至上,没有江湖的感觉,而当你掌握了一定的资源,比如团队,资金,客户的时候,你就必须有一定的立场,为你的团队去博弈。而其他行业之所以江湖气重,就是因为在职业生涯的初期就能够掌握一定的资源,如销售掌握客户,公务员能够掌握一定的权力等。也许你想凭你的技术,像令狐冲一样笑傲江湖,也要看你的技术是不是独孤九剑,其实如果令狐冲是市井无赖,没人在乎他和谁交朋友,可他是华山派的第一执行总裁和未来的总裁,也即掌握了一定的资源,朋友就不能够随便交了。
  其实广义的朋友大概分两种,一种是不需要什么条件就会帮上忙的,我们称之为挚友,如同学,室友,战友等,一种是必须双方都有好处才可能帮你的忙的,如普通朋友,泛泛之交,技术大会上交换过名片的朋友等。
  同上司是几乎做不得挚友的,所以要想尽快的升职,则最好加入共同利益圈。
  在工作中,一方面你要让上司感觉到你是完全可控的,你有的任务来自他的分配,有的则可能不是,其应该掌握你所有的任务状态,一方面你要让上司感觉到你是他的坚定地支持者,在任何公众的讨论会上,坚定地支持并执行其观点,如有异议,则放入团队内部进行讨论,毕竟在外,其是代表整个团队的观点的。
  在工作外,你可以参加业余的自发的聚餐,唱歌,旅游,游戏,运动等,在这些非工作的场合中,更容易得到工作中得不到的信息,也更容易在轻松的氛围中融入团队。
  那么如何判断是否进入了某个共同利益圈呢?就是圈中的人同你除了谈论显规则,如项目,流程,进度,技术等话题,还会谈一些明着不会谈的潜规则,如抱怨公司制度,传递公司八卦新闻,讨论跳槽和离职,讨论薪水和涨幅等。
  最近偶然看到一个关于官场的漫画《屁脸官场》,其中有一幅画是这样画的,
  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、另辟天地式
  如果公司或者团队有新的项目,新的流程需要有人去做,去贯彻的时候,可能不一定是好事,但是如果你敢于承担,一旦新的项目或者流程成功,你自然能够得到较快的升职。
  正如杰克韦尔奇说过的:要想获得提升,有效的办法是拓展你的工作范围。采取大胆和超出期望的行动,不要只是做那些期望之内的事情。
  同临危受命式类似,另辟天地式也需要注意项目,领导,团队三要素,即另外建立的项目或流程需要哪些资源(经费,人员,机器),是否很容易获得,是否能够得到领导的有力支持,能否很快的建立一支自己的队伍。有的情况下,队伍是自己招聘的,则相对好处理,有的时候,队伍是其他部门的资源,来兼职的配合你的工作的,则领导的支持则至关重要。
  比如公司要推广敏捷开发模式,每个团队要选出一个人来,由你带领在每个团队进行推广,这时要清楚,每个团队选出的人作为你的团队成员是临时的,对他们来讲,其真正的绩效和未来是控制在团队领导手中的,如果你不是一个比所有的团队领导都高的职位,除了得到上层的授权,在安排团队成员的工作时,及时的和他们的团队领导进行沟通,数字化的时间点,可衡量的结果,以及合同式邮件都是必须的,别忘了在团队成员有所进展的时候,抄送一封进度及表扬信给他的领导,这也是他的绩效的一部分,如果团队获得进展,则应该抄送上层和其他团队的领导,既是团队绩效的一部分,也是对其他团队的一种压力。当然你不应该摆出颐指气使的架势,有事就拿上面来压,镇不住就请领导也是一种不好的做法,容易被人指为拿着鸡毛当令箭,既不利于以后在团队中的合作,也有可能因为项目的失败成为千夫所指的替罪羊。所谓筚路蓝缕,以启山林,开辟新天地从来就不是容易的事情,既然你没有至高无上的权威,就需要一步一步的去推动,时常过去问问:“上次开会说这个星期一出方案的,应该没问题吧,进展如何?”,“方案不错,太牛了。下午有没有空,我们讨论一下实施吧”(别忘了发封邮件赞扬其方案,并将讨论的实施细节,时间点等也发出来),“大家做了一段时间了,进展比想象的要快,我们明天上午碰个头吧,林总也挺关系进度的。”
  另辟天地的是个典型的例子就是李鸿章:咸丰十年,太平军二破江南大营后,要攻打上海,需要湘军的支援,而另一方面很多湘军主力正准备攻打天京,建立首功,没有人愿意去支援上海。所以这个项目就落在了欲另辟天地的李鸿章身上,李鸿章在老师曾国藩的支持下,招募合肥的团练,并借用了湘军许多的将领和人马,成立了淮军,最终成功完成保卫上海的项目,从此开始了开始了他在晚清政治舞台上纵横捭阖的四十年。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(8):又是一年加薪时

我评it-IT外企那点儿事(8):又是一年加薪时

   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,而对于过程型的领导,这些可以写入时间规划。在项目执行过程中,对于结果型相关方,多汇报进度,如遇到困难,则应有证据证明存在的问题,并估计其对进度的影响,对于过程型的相关方,还可以描述问题的原因,探究及可能的解决方法。在项目结束的时候,对于结果型的相关方,一份详尽的报告逐一用数据表明达到目标很重要,对于过程型的,还可以发起一个knowledge sharing,分享项目中的难点和解决。
  视觉型,听觉型还是感觉型:
  不同的人感知外在世界的方式有所差别,大概分为此三种,当然人们都是这三种类型的综合,只不过更多的偏向于某一种而已。
  视觉型的同事常打印出一部分书籍或者文档,并边看便在空白处或者本子上写写画画,画出思路图,或者标出过程的一二三。其学习技术的方式倾向于看书而非看教学视频,因为看书能够很快的跳过各种废话,直奔主题,当然如果书籍能够形象直接的提炼出要点,则将十分欣喜。和他人沟通,首选用邮件或者文档的方式,写明要点,并附上详尽的框图,其次是到会议室中,把框图在白板上画给你看,最不爱采用的,就是电话的方式。在开会的时候,其喜欢坐在能和会议的举行者可以目光交流的地方,而不是角落里,其似乎随时准备上台提炼出演讲者的一二三,或者把过程画出流程图。
  听觉型的同事也喜欢看书,但是在其觉得重要的句子下面画波浪或者下划线是常用的方式,在其看来,作者的文章字字珠玑,所以划线的地方非常多。其注重细节,相对于视觉型的人,其掌握架构的速度有些慢,然而一旦掌握,将成为此方面的专家,对方方面面都有所了解。其学习技术倾向于看视频,会不厌其烦的一字不落的听着讲座的每一步,相比于看书,讲座者的语气强调更能给他带来深刻的印象。与他人沟通,电话是其最喜欢的方式,简单直接,且能听到对方的语气,开会其次,如果使用邮件或者文档,将写的非常仔细。其开会的时候往往会坐在非中心的位置,相比于视觉型的人,你可能觉得他似乎不太积极,然而后来你会发现,其对会议的很多细节在较长时间后仍能够清晰记忆,"我记得你在一次会上曾经说过"。如果其是会议组织者,其技术讲座,技术方案都会详尽到代码级别,开会超时是经常的事情,如果视觉型的是其领导,将会在其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可看不到你过去的努力,而一个好的评级,是好的印象的开始。有的公司跳槽的时候,reference check也会问及在原公司的表现,一个好的评级显然更利于你在面试中的博弈。所以评级远非一点点钱那么简单,如果你有选择,评级很重要。
  当然如果你的上司替你做了选择,理解他吧。
  八、One on One——一切已经过去
  绩效考评完毕,就是进行绩效反馈的时候了,这个时候,你已经知道了自己的评级,还会组织一次One on One进行沟通,无论你是否满意,一切已经过去了。
  其实如果在一年中经过前面的不断沟通,既不应该有惊喜,也不应该有惊讶,每个人都是应该有自知之明的。
  如果不幸,你很失望,请记住博弈已经不再可能,应该重点面向未来。
  这时候,上司也会和你讨论绩效改进计划,应对自己的不足之处积极的配合制定改进计划,同绩效计划一样的认真执行,千万不要因为情绪原因进一步恶化和上司的关系,陷入恶心循环。
  想想经常被提及的下面这个寓言故事吧:做一棵永远成长的苹果树。
  一棵苹果树,终于结果了。
  第一年,它结了10个苹果,9个被拿走,自己得到1个。对此,苹果树愤愤不平,于是自断经脉,拒绝成长。第二年,它结了5个苹果,4个被拿走,自己得到1个。“哈哈,去年我得到了10%,今年得到20%!翻了一番。”这棵苹果树心理平衡了。
  但是,它还可以这样:继续成长。譬如,第二年,它结了100个果子,被拿走90个,自己得到10个。
  很可能,它被拿走99个,自己得到1个。但没关系,它还可以继续成长,第三年结1000个果子……
  其实,得到多少果子不是最重要的。最重要的是,苹果树在成长!等苹果树长成参天大树的时候,那些曾阻碍它成长的力量都会微弱到可以忽略。真的,不要太在乎果子,成长是最重要的。
  你是不是一个已自断经脉的打工族?
  刚开始工作的时候,你才华横溢,意气风发,相信“天生我才必有用”。但现实很快敲了你几个闷棍,或许,你为单位做了大贡献没人重视;或许,只得到口头重视但却得不到实惠;或许……总之,你觉得就像那棵苹果树,结出的果子自己只享受到了很小一部分,与你的期望相差甚远。
  于是,你愤怒、你懊恼,最终,你决定不再那么努力,让自己的所做去匹配自己的所得。几年过去后,你一反省,发现现在的你,已经没有刚工作时的激情和才华了。
  “老了,成熟了。”我们习惯这样自嘲。但实质是,你已停止成长了。
  这样的故事,在我们身边比比皆是。
  之所以犯这种错误,是因为我们忘记生命是一个历程,是一个整体,我们觉得自己已经成长过了,现在是到该结果子的时候了。我们太过于在乎一时的得失,而忘记了成长才是最重要的。
  当然作为上司,此时也不要太揪住过去不放,对于优秀员工,此时已经信心过于饱满,可以适当谈一些其缺点和可以进一步发展的地方,对于比较差的员工要重塑信心,防止其破罐子破摔,主动倾听他的意愿,从其原意改进的地方入手,哪怕暂且牺牲一下绩效(比如多利用一些工作时间进行学习来提高技术水平,而少做一些任务),只要其能够不对立,采取合作的态度,再对其行为进行正向激励,就能恢复到正轨上来。
  虽然评级基本决定了薪资涨幅,然而同一评级涨幅也不相同,很多上司在同普通员工沟通的时候,无论其涨幅多少,都说是平均涨幅,防止他们产生心理不平衡,其实坦然的沟通更好,永远不要以为薪资保密真的很管用,员工总会知道他们每个人所谓的平均涨幅是不同的,这样反而会使得他们猜来猜去,对上司产生不信任,对绩效好的员工产生怀疑和敌意,从而影响了调薪后一段时间的工作效率,也就是所谓的调薪后遗症,薪水都涨了,效率反而下来了,团队反而不和睦了。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(7):做一个优秀的基层

我评it-IT外企那点儿事(7):做一个优秀的基层

   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 you side 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 good question,其二,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 without authority,然而如果你果真这样做了,多半会招来同事的敌意(你凭什么指手画脚的啊),也可能会招来你的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的情况下,你才能做到充实自己,努力学习,才能了解上司的言语——让上司轻松,你才能够做到对自己的业务,主动提出改善计划——让上司进步。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(6):管理路线和技术路线

我评it-IT外企那点儿事(6):管理路线和技术路线

   IT外企那点儿事(6):管理路线和技术路线
  技术路线和管理路线始终是每个程序员纠结的问题,也是各大论坛经常被辩论的问题。
  然而一个有趣的现象是,在现实生活中,人们多愿意承认自己不精通某项技术,却很少有人愿意承认自己不能做管理。技术方面有问题多能够校正自我,而管理方面有了问题却总认为是对方的错,总之领导怨员工,员工怨领导,闹得不可开交。
  在中国传统的官本位的思想中,不能不说管理路线占了绝对性的优势,尤其是在稳定的外企,管好管坏极难衡量的情况下。
  做技术苦啊,相比于管理路线,有如下的弱势:
  首先,IT业的技术变化太快,弄的技术人员疲于奔命。
  年轻人可以每天晚上几个小时的看新技术的书籍,而年纪偏大的你上有老下有小,做饭,洗衣,陪老婆,照顾老人小孩,逛超市,每天能有一个小时的学习时间十分不易了。如果是你已经很熟悉的领域,你自然可以用较少的时间就能达到年轻人较长时间看完的东西(理想状态下),然而公司的项目所用的技术方向可不是随你心愿的。如果你是一个Java高手,碰巧公司买的一个第三方的库是用C++写的,需要对其进行封装,如此艰巨的任务,工程师中你的薪水最高,你不入地狱谁入地狱啊。你总不能说:我只负责Java的部分,C++的别来找我吧。
  也许你经常听领导说:“编程主要靠思想,语言和平台无所谓”。然而如果你跳槽的时候,却经常听到面试官这样说:“好像你没有太多这方面的经验嘛”,你却不能以我很有编程的思想来回答。此矛盾之处着实使人困惑许久。技术路线还是分很多的方向的,正如武林有很多的门派。语言,操作系统等属于内功,然而只有内功却不足以行走江湖,必须还要有一定的套路,如Debug tool,profile tool,出现问题后的分析办法,编程时候的各种习惯,一些非常管用的技巧等,都是因语言和平台不同而不同。虽然对于初级的工程师来说,这些不是很重要,然而工作三年五年之后,是否能够熟练运用这些套路来准确的定位问题和解决问题,却是区别你是初级工程师,还是高级工程师的一个标志。当然当你在上升到项目经理的时候,又可以只谈编程思想的时候了。一句实话,一个要饭的不要因为听富人说吃青菜养生就见肉也不吃。周易中,同样在乾卦,同样元亨利贞,初九则应潜龙勿用,九五则可飞龙在天了,不同的位,同样的话,意义不同。
  其次,没有优先知情权。
  当任务到来的时候,美国那面的老大一般是先发邮件给项目经理的。项目经理会进行一系列统筹考虑后再选择发给那些人。作为同项目经理同一级别的技术人员,是否提前或同时,甚至晚于与其他技术人员收到邮件,取决于你技术外的能力(你的reputation, 你和项目经理的关系等)。上面的文章也说过了,在外企,邮件是一门很大的学问,也决定了从属关系。把本来你擅长的任务先发邮件给他人,从而变成了他人的任务,也不是不可能的事情。当然当美国老板过来的时候,陪同和展示成果的,也多是管理人员的事情,虽然里面全是你的心血。
  其三,没有资源支配权。
  项目经理一般可以支配多种资源的,如买硬件,Team building的经费,培训的机会等。但是相同级别的技术人员却没有。
  其四,没有绩效评定权。
  任何员工的绩效都是基本由其report得顶头上司起决定作用的。相同级别的技术人员可能会有一些评价做参考,但是你不会知道和你平级甚至下级的薪水和绩效。
  最后,没有人事任免权。
  一个员工是否能够进某个项目组,也基本是项目经理起决定作用的。一般的外企都会有推荐的制度,而通常会发现一般状况下(被推荐人不是明显的差),管理路线的人推荐到其他组的人比较容易录取(同组推荐没有推荐费啊)。大家总要多少照顾个面子嘛,万一哪天要向对方的组推荐自己的人呢?
  基于上述几点,经济基础决定上层建筑,你也就怪不得基层员工对你仅仅是因为技术而产生的尊敬,而对manager则是因为既威且信而产生的敬畏了。也许其实是你的建议是正确的,大家却都同意按照manager的来做;也许你一把年纪还要和年轻人因一个小小的设计争得面红耳赤,而他在manager面前总是yes, ok, i am 100% agree;也许你因一项新技术不很精通而被新人鄙视;也许就没有也许。
  当前的中国是浮躁的,以上的原因造成大批大批的人涌入管理路线的独木桥,也造成了一些不合格的管理者走上了管理岗位。也许有这样的现象,明明在国外仅够做高级工程师的在中国做了Team lead,却在和普通工程师争功劳;在国外仅够做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小时,也有大批程序员欣然而往。也就可以理解各个公司的老总总是不定时的出现在电视上,不断重复着自己成功的故事。
  程序员不应该老待在自己的圈子里面,埋头做着自己的事情,而是要想办法扩大自己的影响力,多交朋友,多参加技术会议,多参加各种聚会。
  有很多人抱怨,刚毕业就要工作经验,诸葛亮没有工作经验,不也成功就业了吗?《三国演义》中是这样描述诸葛亮的"或驾小舟游于江湖之中,或访僧道于山岭之上,或寻朋友于村落之间,或乐琴棋于洞府之内,往来莫测,不知去所"。这那是隐居啊,不出茅庐而名声在外,工作也是至交徐庶鼎力推荐的,卧龙先生可不仅仅是束发读史书啊。
  总而言之,窃以为,做一个程序员,一要钻下去,积累技术,二要跳出来,影响世界(虽然只是一点点)。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(5):像系统一样升级

我评it-IT外企那点儿事(5):像系统一样升级

  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? serialized object? 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,使得组织也成为了一棵树装。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(4):激动人心的入职演讲

我评it-IT外企那点儿事(4):激动人心的入职演讲

   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上的每个人都是充满的快乐的笑容,预示着你将来美好的生活。
  这些活动永远应该是你在公司活动的一小部分(否则你就大错特错了,买椟还珠,捡了芝麻,丢了西瓜),而这些福利真的对你的职业生涯一点都不重要。
  学长的自白
  当然仅老大一人的独白不足以有说服力,员工们多比较相信和他们年岁,经历差不多的人的话。
  所以有时候,会请你的学长现身说法,描绘他在公司里的美好生活和光明前程。
  人在屋檐下,不得不低头,屁股决定脑袋,人站的位置决定了他说的话,当老大还站在旁边以期待的眼神看着学长在新员工面前侃侃而谈的时候,学长说的话除了在老大的描述上锦上添花,也别无选择了。所以你尽可将学长的话打五折去听,如果想进一步了解,请留联系方式,你们可以私下交流,这样就可以打八折听了。人生其实就像一场杀人游戏,唯一大概可以相信的就是被杀后的跳警,如果想了解最真实的情况,私下去问离了职的学长,再和在职的学长的描述融合一下,就基本可以描述客观的情况了。
  快乐的互动
  入职培训还常有的一项就是新员工之间的互动,让你早日得融入集体,感受主人翁的精神。
  在被设计好的游戏中好好和大家交流,交交朋友吧,一般同一批进来的人比较容易建立更深的感情,而且当后来你们被分到不同的组里后,就很难有这种机会相互交流了,这毕竟是你在此企业中积累人脉,增加影响力的第一步,朋友将是职业生涯中最宝贵的财富。想想谁能够在一家企业待很久呢?可曾听说过跳槽的时候:一等人才找朋友,二等人才找猎头,三等人才网上搜。
  先写到这里吧,下一篇写啥还没想好。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(3):奇怪的面试

我评it-IT外企那点儿事(3):奇怪的面试

   IT外企那点儿事(3):奇怪的面试
  外企的面试都面写啥?不同的企业也是不一样的,总的来说可以归结为以下几句话:
  三类企业面实战,二类企业面基础,一类企业面算法。
  在此声明,此处所谓的一二三类,绝没有轻视其他企业的意思,这里的一二三类基本上是按照本科毕业的时候起薪来划分的,一类企业指的是年薪15万以上的企业,二类企业指的是年薪10万左右的企业,三类企业指的是年薪5万左右的企业。当然按照上两次的描述大家可以知道,并不是起薪高的企业的程序员一定最好发展的最好,而进入创业企业的人最后可能后来居上,成为IT达人。当然此规律也不仅仅适用于外企。
  三类企业
  三类企业起薪不高,招聘的目的也相对的明确,是要找那种来了就能真枪实弹的把东西作出来的人。
  他们多不太关心员工的培训和成长,不太关心员工是否对技术有浓厚的兴趣和深入的钻研,他们就是一个想法,他们要做一个东西,做这个东西需要某方面的技术,所以要找这会方面的人。
  他们不知道,大多数的程序员其实喜欢做一些在自己能力以上20%的东西,也即研究研究可以做出来,但不是太熟练,而不喜欢做一些自己已经非常熟,毫无挑战的东西。
  但是他们需要这样的人,所以在面试中,面试的问题比较具体,甚至具体到一个个的配置项,也有当场给你环境,让你搭一个框架,做一个东西的。
  他们希望,最好你以前做过的项目和他们现在的项目十分相似,来了就能够上手。
  其实很多程序员跳槽,就是因为原来的工作已经没有了挑战,想找一个更有挑战的,有更多大牛的地方,如果原来的项目我干的不亦乐乎,还来你这里干什么?
  但是现在工作难找啊,所以他们总是能够找到需要的人,毕竟出来混,大家都是混口饭吃,不容易啊。
  要想进入此类企业,一个最好的办法就是上手做,在学校里就可以找个实习的公司,哪怕不给钱也去(强烈谴责这种企业,剥夺劳动者的基本权利,也就在中国他们能干的出来,放到欧美罚不死他们),先混些实践经验,做些边角料的活,然后跟着lead一步一步进入核心模块,相信只要认认真真的做过,面过这类企业应该不成问题。
  此类企业的流动性相对较大,往往被用作程序员的跳板,跳到二类甚至一类的企业中去。所以不幸进入此类企业的兄弟们,在实战的过程中,别忘了多看看源码,多想想背后的原理,多补充一下计算机科学的基本知识,早日脱离苦海。
  二类企业
  二类企业其实薪水已经非常不错了,毕业就能进入此类企业的程序员也多是学校中的优秀分子。
  此类企业注重程序员的基础,认为只要基础好,他们愿意培训并培养程序员,给你机会进行学习。
  此类企业招聘的时候,职位有可能是不太确定的,可能是Java,可能是C++,可能是windows,可能是Linux,他们认为只要你基础好,语言不是问题,平台不是问题,培训一下上手会很快。
  记得面试一家与通信有关的欧企,面试官开始问了很多C/C++的基础知识,后来问了很多操作系统和计算机网络的基础知识,最后说,他们是需要有通信背景的,然后连问我三个有关通信方面的问题,我都说不知道,最后只有坦然承认,通信我确实一点都不懂。后来我认为我是彻底没希望了,没想到后来竟收到了他们的offer,并在入职后进行了长达两个月的通信方面的培训,后来我问我的面试官怎么回事,他说,你的C/C++,操作系统,计算机网络的面试题几乎都对了,我觉得你的基础不错。
  所以要进入此类的企业,有关基础方面的书还是要认认真真,仔仔细细的看,下面推荐一部分:
  C: 《The c programming langage》
  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 Programming in the UNIX.Environment》,《Understanding Linux Network Internals》,《UNIX Network Programming》
  network:《TCPIP Illustrated Volume I》,《The Linux Networking Architecture》
  我没有在装B,也不是看过以上所有的书,不过上述书籍的确是程序员必藏书,我也只不过是在用到的时候翻开相关章节看看。
  然而给大家的建议是,在做项目的时候,千万不能够做什么就只知道什么,与此相关基础知识也应该多看一些。面试的时候也经常遇到这种情况,就是面试者号称做过socket,问到tcp/ip拥塞控制却一无所知,会简单使用socket client端和server端几个简单函数人太多了,如何保证你能够脱颖而出呢?
  其实很多事情我们觉得不可能,但是这个世界上就是有牛人确实做到了,比如英语六级能够考99分(满分100),就是把答案全给我,就让我写作文,我也做不到啊,再如高考满分750分,山东的状元730+分,也就意味着数理化全对,语文140+,英语140+,我的天,也是把答案给我,就让我写语文和英语的作文,我也做不到啊。
  然而读以上书籍却没有上面两个例子难的不可想象,我所知道的身边的人就有C, C++, linux, network这几个分支全读过的,而且不止一个。
  能进入二类的企业,混个中层,也能过上满不错的生活了。
  一类企业
  一类企业薪水非常高,毕业就能进入的可以说是学校中的佼佼者了,一般会名校背景,名企实习,甚至有过获奖的才能够进入。
  此类企业除了注重程序员的基础之外,更加重视程序员的思想,算法及聪明程度。
  所以很多奇奇怪怪的面试题在网上都流传出来了,这些题目真可谓费尽心机。面试过程长达n轮,每轮都可能因为疏漏和状态不佳被刷掉,最后剩下的几近完美。
  在面试中,程序是要当场在黑板上写出来的,很短的时间,要求很强的健壮性,面试官还会在旁边施加心理压力,你确定吗?要注意XXX。
  虽然问题是经常外流的,然而新的问题却是不断的会出,可能是因为工作中有些需要解决的问题,自己想了一天多才想出的解决方案,却抽象出来考别人,让别人在很短的时间作出来,这种心理开始很爽,后来觉得很罪恶,多少有些原来自己穷,受富人欺负,后来富了又欺负穷人的味道。
  有些人会质疑,这些精巧的算法在工作中真的能够用到很多吗?答案当然不是。
  这其实是一个供需的问题。马克思告诉我们,商品的价格是由价值量决定的,商品应该以价值量为基础,实行等价交换。西方经济学告诉我们商品的价格会随着供需关系的变化而变化。当供需矛盾相当大的时候,商品的价格就会远离价值量。
  《经济学的思维方式》一书中写到,所有的稀缺品都需要以某种方式分配,必须建立某种规则和制度,对那些要求得到稀缺品的人加以甄别,决定谁该得到多少。价格只是最常用的一种方式。
  想想我们的高考吧,那些千辛万苦考上清华的学子毕业后又有多少高中的知识留在脑子里呢?学到的东西又有多少是能够在实际中用到的呢?其实很少,高考分数不过是进入清华的一个价格而已,已经由于清华只有一所,考生却有千百万这样的供需差别远远的偏离了使用价值,毕竟能够轻松看懂教科书的人太多了,他们只能够不但要全会,还要全对。
  进入一类企业也是同样的,能把我上述书籍都看完的人是大有人在的,仅仅基础知识已经不能够甄别想进入一类企业的人们,所以需要奇奇怪怪的算法题。
  要进入一类企业,《算法导论》这本书必不可少,要前前后后仔细的看,而且应该不止一遍。《编程珠玑》也是一本不错的书,其中的例子可以常常的回味。《编程之美》也不错,更贴近面试,更实用一些。其实更重要的是Top coder,就是多看多练。
  其实考入名校基本就是一种方法,多做题,以便在考场中看到题目就能够有思路,考场的时间仅仅用于保证正确率就可以了。
  进入一类企业也是一样,要想很短的时间,在很大的压力下写出健壮的程序,其实只有一种方法,就是类似的题目遇到过,思路是马上就有的,在会议室的时间仅仅用于保证健壮性就可以了。
  曾经一段时间,对精巧的算法十分的崇尚,甚至引以为豪,然而后来慢慢发现,天天沉浸在算法之中,沉浸在计算机的小天地里面,又对社会做了什么贡献呢?难道自己的才能,抱负就仅仅放在这些数字的技巧当中吗?
  我们不应该像孔乙己一样研究茴香豆有几种写法,而是应该如阿朱《走出软件作坊》中描述的一样,虽然方案不是完美和精巧,然而逢山开路,遇水搭桥,真正的解决一个个的问题,作出一些可以影响人们生活的软件。
  先写到这里,下一章要开始写入职了。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(2):多种多样的外企

我评it-IT外企那点儿事(2):多种多样的外企

   IT外企那点儿事(2):多种多样的外企
  不是所有的外企都是一样的,外企也分多种,基本按照地域和文化的划分可以分为日韩外企,欧企,美企。
  日韩企业
  日韩企业是十分强调等级观念的,这可能和这两个民族的文化有关。
  上级在下级面前总是一副严肃或者装深沉的样子,虽然其在外面有可能花天酒地,什么都做。
  上层和下层很少有哪怕表面上的互动,比如开玩笑,打球,年会一起表演等,所以工作环境相对的压抑,安静。
  甚至在伴有生产性的企业中,中午的食堂都是按照等级来的,先是管理层,然后是办公室人员如IT,行政,HR等等,最后才是蓝领的工人阶级同志,不能不说到最后像样的饭菜都比较少了,虽然自己是较先吃饭的一部分,但是看到这种情形仍然不是滋味,毕竟我们的父辈也是普普通通的工人。
  员工的绩效是完全由上司指定的,甚至没有解释为什么,不知道别人是多少,也很少存在如欧美企业一样哪怕形式主义的反馈,其时只有默默接受,或者走人。
  员工的入职薪水在外企来讲相对是很低的,每年的加薪也少可怜,其解释也是振振有词:当你的水平和贡献没有提高,凭什么公司付给你更多的薪水?所以要想薪水有较大的改善,唯一的途径就是升职,用他们的话来讲就是能做更多的贡献。
  日韩企业中,级别与级别之间的薪水差距是比较大的,所以一旦能够做上去,拿到的薪水可能不比欧美企业差。这也就造成了一种现象,就是日韩企业中最底层是非常不稳定的,每年大批的毕业生几乎像换水一样,一批一批几乎都走了,留下的基本就是当年就升了职的,而中层是相对稳定的,所以公司的管理也不会出什么问题。
  无论在哪里,一旦有了很深的等级观念,伴随而来的是管理者相对比较累,所有的决定权都在上司的手里,所以其会忙的不可开交(所有的猴子都在他的身上,请参照《哈佛经典:谁背上了“猴子”?》),甚至管理的蛮大的Team的时候,还可能亲自写一些代码,并对每一个细节都心中有数,不像欧美的项目经理一样只管流程就可以了,甚至做的时间长一些,技术都忘了很多了。
  这也难怪,当下属每年流水一样几乎全走了的时候,Team lead总要保证项目能够继续下去。这多少让我想起清朝的皇帝,由于对大臣们极度的不信任,最后不得不一个个殚精竭虑,连县一级的官员都亲自任命,而明朝的皇帝很多将政务抛给宰相后,就可以逍遥自在,过自己的无厘头的生活了。
  说到外企,一个不可回避的问题就是天花板问题,也即多高的职位还会属于本土的中国人。
  日韩企业的天花板是相对较低的,不太大的官就已经是日韩人士了,因为对中国人,这两个民族似乎总是不放心的,其民族文化中多少存在一些非我族类,其心必异的倾向,所以中国人在这些企业中做不到太高的位置。
  所以有一种说法是,和欧美企业不同,日韩企业不能算作真正意义的跨国公司,而是分派在不同国家很多分部的日韩公司,这些分支不能够很好的本地化,不能够融入本地文化,不能包容多元文化,不能实现真正的国际化,而仅仅是接受日韩总部的指令的分支机构而已。
  在这里还要提及的是台湾的企业,台湾是中国领土不可分割的一部分,但是很奇怪的是,在大陆登记的时候,台企是被登记为外资企业的,而且可能是台湾被日本统治了一段时间的原因,在台企中多少有一些日本企业的影子,如等级化,天花板等,同是炎黄子孙,台湾企业似乎也对大陆的人才不能够完全的信任,看了多少心中有些不舒服。
  欧企
  欧企是三者之中最人性化的一类企业,尤其是北欧企业,大概和这些地区的高福利,共产主义化有关。
  当然天花板肯定是有的,只是相对较高,中国区的总经理一般会是是外国人,好一点的还可能是美籍华人,香港人,甚至可以使中国国籍但在美国留过学的人,然而总监一级就可能是本土的中国人了。这样的组织架构既能够和外国人很好的交流,又能够很好的本地化,适应中国文化,和本地政府交流,何乐而不为呢?
  欧企的等级观念也是三者之中最不明显的,管理多个Team的line manager还会在旅游之中和我们最底层的员工打牌,娱乐。公司内部的相互称呼也是叫名字,hi jack,hi peter这样的叫,无论其是多么高的高层,不会称其为王总监,刘经理此类的。
  欧企的加班也是比较少的,他们强调work life balance。
  工资相对日韩企业比较高,但相对美企来讲要低,但是福利比较好,公司会经常有吃蛋糕,开Party,旅游等活动,如果赶上公司的经营状况很好,公司给的旅游的budget是比较多的,经常可以近郊旅游,每年还能有一次出国旅游。
  由于较好的福利,公司是非常稳定的,每年跳槽的人很少,有的人甚至放弃美企的高薪,因为那儿比较累,舍不得这里的福利,环境,以及较好的培训机制。
  一个欧洲人在培训中讲,美国人是喜欢跳槽的,并不是公司不好,而是他们喜欢挑战,如果五年待在一个地方,别人会问:what is wrong with you?,而在他们国家,人们是不怎么跳槽的,他在这家公司待了20多年,他的父亲就是在这家公司退休的。这多少让我想起了我们原来的国有企业的制度,父辈退休,孩子在这个岗位接着干。难道欧洲已经到了劳动已然成为一种需求的阶段?
  想必这种日子说的大家心驰神往,这的确是个养老的好地方,然而对于年轻人打拼来讲,却不一定好。在此类地方,系统已经是很大很稳定的,技术进步是不太快的,可能很长时间才能修改很小一部分代码,而由于人员稳定,向上升职也是比较慢的,这样你的竞争力其实是在一步一步的下降。
  当公司经营状况好的情况下,大家一好百好,彼此都很开心,但是一旦遇到金融危机,公司经营状况变差的情况下,福利会急剧下滑,资本家终究是资本家,哪怕披着绅士外衣,在欧洲,由于有健全的法律,高额的赔偿,强大的工会,公司一般是不怎么敢大幅度裁员的,而中国地区就成了他们开刀的地方。
  当大幅度裁员后,获得了比较可观,但其实比裁一个欧洲人少得多的赔偿金后,你会发现找工作比较难了,日韩和国企你已经不适应了,那里天天的打拼如同地狱,美企好一点的则需要比较强的技术,而可能你发现你的技术能力不如刚毕业的时候了,你还记得多少的算法,操作系统,计算机网络呢?
  美企
  美企是三者之中薪水最高的企业,然而压力也相对比较大。
  在这里你会发现,美国人有时候会很拼的,很认真的,甚至很较真的。美国人总是会规定一个任务完成的时间点,然而却常常是非常紧的。而且由于流程又长又复杂,时常弄得你焦头烂额。
  美国人会一遍一遍拉着你和你reveiw文档,很认真的揪出其中任何不合理的地方,甚至拼写错误。
  在美企,加班是经常的事情,虽然第二天早上你可以来的比较晚。
  所以美企也会有和欧企一样的福利制度,然而真正享用的时间比例要小的多。
  美企的天花板和欧企差不多,相对于欧企,美国企业多少还是有些等级在里面的,只不过不是如日韩企业显而易见的在外面,等级之间平时说笑,娱乐的时候是几乎看不出来的。
  然而美企心中的等级是存在的,主要体现在两个方面:邮件和开会。如果一件事情所发出的第一批邮件就包括你,则说明你属于处理这件事情的主要人员,如果你被别人转发,则在这件事情中你属于辅助地位,哪怕你和他是同一个level的,因为先知情的他可以做很多的准备,更全面的信息。如果一件事情需要开会,你在第一次的邀请中,则你也属于处理这件事情的主要人员,如果这件事情分成了多个小部分,然后让你再拉上另外一些人另外开会讨论如何处理这个小部分,在这件事情上,你就是那些人的核心,哪怕他们和你都是同一个level。
  这两点所有的人都心知肚明。美企有时候是强调管理扁平化的,也即事情的参与者大家没有level的差别,在这件事情上可能你是lead,在另外一件事情上他是lead,然而如果你能够很好的处理和上司及同事的关系,较多的出现在第一批发出的邮件或者第一次召开的会议中,则恭喜你,你很快就能够升职了,很快就能够脱离现在的层次,融入到另一个层次的人员的邮件和开会的博弈中去了。
  先知情权如此的重要以至于可以当做政治斗争的手段,在美企,用level压人到哪里都是说不过去的,然而如果事先没有足够全面的信息用邮件发给你,在开会的时候即便临时叫上你,在没有任何思考,准备和证据的情况下,哪怕你level再高,又如何能够说服别人使用你的方案呢?你总不能说:我是高级工程师,你们都是普通工程师,你们要听我的吧。
  都说中国人是讲面子的,其实美国人也是讲面子的,在大庭广众之下,他们总是对你的项目一口一个good,一口一个great, impressive。
  然而在项目中,美国人可是不讲面子的,经常challenge你,作为被领导的中国一方,经常要做的一件事情就是寻找"证据",确确实实的证据来保证自己不会被challenge。
  有很多人质疑,为什么外企总是那么喜欢写文档,一遍又一遍,写到十分的细节,为什么总是喜欢写邮件,哪怕两个人就挨着坐,开会要写meeting minutes,每天要写daily report,每周要写weekly report,测试完要cc all发送测试报告,功能实现完要cc all发送邮件报告,这些都是证据啊。
  当问题出现的时候,每个部门不是第一时间想着如何解决这个问题,而是首先寻找证据证明自己的清白,有时候来来回回很长很长的邮件,回复了n多人,才能解决问题。
  美国大老说了,销售那面反应,这个功能不好用,则开发部门首先应该回:我们的design document早就发出去了,而且都review过了,当时的会议记录就是决定这样做的啊。性能测试部门说:昨天测下来,性能突然变差了,某个部门昨天提交了代码,应该是他们的问题,那个部门马上回:我们后端在代码提交之前已经做过性能测试了,报告昨天就发出去了,性能没有变差,可能是前段的问题吧。后端发现前段发来的消息不能够解析,前端应该解释:昨天我们商量的通信协议,在邮件中都能够找到啊。
  当有成绩了,哪怕一点小的成绩就cc all来增加影响力,当有问题的时候cc all来证明自己的清白,实在是一道美丽的风景线。每天在开会,邮件,文档,扯皮中度过,也难怪开发效率相对民企要低的多了,好在大公司有钱,不怕时间长,不怕客户恼。而对于程序员来说,技术提高不了多少,情商却是大幅度提高了,也难怪《杜拉拉升职记》能够如此的畅销。
  下一篇来讲外企的面试。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

ASP程序

我评it-IT外企那点儿事(1):外企也就那么回事

我评it-IT外企那点儿事(1):外企也就那么回事

  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 it into 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。
  一般要到下午晚些时候才能够清净些写代码,晚餐后才是代码的高峰期。
  这也是为什么小公司半年作出来的东西,大公司要做几年。当然大公司这样做自然有它的道理,大公司稳定,不愁客户资源,不差钱,今年做出来或是明年做出来,客户别无选择,员工也养得起。这些小公司都做不到,必须尽快的满足客户的需要,必须在钱花完之前拉到下一个项目。
  然而这对程序员的职业生涯来说好么,我不敢评价。只是在和很多朋友讨论的时候,他们发现,自己一直在忙啊忙,当跳槽试图总结自己做了啥的时候,却发现就不多的东西,不多的技术,当他们去面创业公司的时候,经常会被问,你们这么长时间,怎么就做了这么个东西?
  大公司完善的流程还有一个特点,就是这个流程是完全为此公司定制的,当然公司大,自然可以有钱从头到尾弄自己的东西,既不用常用的,也不用开源的,无论是开发工具,测试工具,代码管理工具。这也导致了员工的粘性特别强,当走出这家公司,就像换了一片天地,原来会的别人用不到,别人常用的,却不怎么会,最后只好在公司养老,好在薪水也不错,福利也不错。
  设施
  最后提及的是各种美好的设施,这是很有吸引力的。然而为了您的前途,虽不能说敬而远之,也要注意享用的时间,如中午,晚上。
  尽量不要在工作时间娱乐,甚至喧哗,人民的眼睛是雪亮的,领导的眼睛也是雪亮的,尤其是对于软件这种成果极难量化的产品,有时候表现和态度反而成了一种指标,不像销售一样,给公司带来的是真金白银,我无论怎么玩,能拿回单子就行,然而对于软件,你有绝对的证据证明成果超越别人吗?
  所以外企有个很有意思的现象,一个团队的座位,离食品的距离越近越好,离娱乐设备的距离越远越好。离食品近,取用方便,领导看到你拿吃的也不会说什么,然而离娱乐设备近,领导办公室的门都开着,有谁胆敢长时间玩耍啊。所以娱乐设备上面玩耍的人一般都是座位离得比较远的。
  此篇就写到这里的,在外企多年,其实发生了很多有趣的事情和现象,当走过几个外企的时候,发现有很多相似的潜规则。
  进入中国的外企,其实是有中国特色的外企。中华文化的强大,使得所有的东西一到中国就会中国化,甚至改变了味道。很多民族如满族,回族的很多人都失去了原来民族的特色。也只有在中国,才可能存在儒释道三教合一的说法,不知道释迦摩尼有何感想。上学的时候,一个我很佩服的大物老师,年纪很大,他是坚定的马克思主义者,但是他曾经说,上个星期我病的厉害,差点就去见马克思了。我笑道,马克思是唯物的,是不相信死后有鬼的,死后去见阎王是迷信,去见马克思就不是了?
  等有空的时候,再接着给大家讲外企的故事。

发布时间:2018年6月17日 | 评论:0 | 浏览: | 标签:我评it  

«1»