Random thought - Think project management from Salary adjustment

今天发现觉先博主发表的外企那点事，有些内容有关项目管理，很有参考价值，转载如下：

转自：http://www.cnblogs.com/forfuture1978/archive/2010/08/04/1791660.html

 

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

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

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

其实加薪的过程从时间上来讲，近则可以追溯到去年年终的绩效评级，远可追溯到过去一年甚至多年每个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个果子……

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

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

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

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

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

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

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

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

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