|
每年过年后的一段时间内，便是一年一度论功行赏的时候了。
年终奖一般设置在年前，而加薪设置在年后，却是一种蛮不错的设计，从而年前大家皆大欢喜，一片祥和，年后又带来新的一年的希望，并激起竞争的欲望。
很多人在讨论加薪的时候，如何同上司或者老板谈方能获得更高的涨幅成为了一个热门的话题。
其实加薪的过程从时间上来讲，近则可以追溯到去年年终的绩效评级，远可追溯到过去一年甚至多年每个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一下，重新进行下一个小的任务，也算是针对管理者这个客户的敏捷开发吧。当遇到技术难题的时候，仅仅埋头苦干是不行的，要多和同事进行技术讨论，甚至向此方面擅长的技术专家进行请教，要知道，别人替你说一句"这个模块有很多技术难点啊"比你自己喊有多难有分量的多，也是一种沟通的手段
| 
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
