外企哪些事 笔记

1. 和上司one-to-one

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

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

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

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

2. 新人培训 

    入职培训：老大的自我介绍，重要的位置（公司、研发、你们），光明的前途，优秀的员工，企业的文化，良好的福利，学长的自白，快乐的互动。

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

     一个人绝不会因为加入了某个组织从而鸡犬升天，绝不会埋头做好公司给你的每一件事情(并不一定都是有技术含量的事)从而随着公司的成功而成功，虽然加入一个好的公司是人生的催化剂，然而自己的路还是要自己来规划，自己的技术还是要靠自己一点一滴的积累，公司不会为你的前途负责，哪怕各个公司都有职业规划的系统，唯一对你前途负责的应该是你自己

     当准入制度越严格，越能够激发员工的尊严。履行一个承诺所要付出的努力越多，这个承诺对许诺者的影响越大。与不费吹灰之力就能够得到的那些东西相比，人们更加珍惜那些来之不易的东西。     

    新人培训中，在被设计好的游戏中好好和大家交流，交交朋友吧，一般同一批进来的人比较容易建立更深的感情

3. 向系统一样升级

1） 悟道 ——系统性：系统地学习知识 （已经完成）

2）道生一——开放和坚实

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

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

学习工作中用到技术背后的原理和机制

3）一生二——沟通

    开始带一个实习程序员

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

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

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

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

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

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

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

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

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

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

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

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

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

4）二生三——平衡
   成为一个team leader

   两个目的：

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

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

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

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

3)  三生万物——分层

     层级化管理，升级成为manager

4. 管理路线和技术路线

    技术路线还是分很多的方向的，正如武林有很多的门派。语言，操作系统等属于内功，然而只有内功却不足以行走江湖，必须还要有一定的套路，如Debug tool，profiletool，出现问题后的分析办法，编程时候的各种习惯，一些非常管用的技巧等，都是因语言和平台不同而不同。

   当然当你在上升到项目经理的时候，又可以只谈编程思想的时候了。

5. 做一个优秀的基层

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

• 主动向上司汇报你的工作进度——让上司知道！
• 对上司的询问，有问必答，而且清楚——让上司放心！
• 充实自己，努力学习，才能了解上司的言语——让上司轻松！
• 接受批评，不犯两次过错——让上司省事！
• 不忙的时候，主动帮助他人——让上司有效!
• 毫无怨言的接受任务——让上司圆满!
• 对自己的业务，主动提出改善计划——让上司进步！

1）做得快还是做得好

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

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

2）有问题要尽早喊

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

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

3） 用bug来说不

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

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

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

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

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

4）该干什么的时候干什么

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

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

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

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

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

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

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

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

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

年会

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

6  增加影响力

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

群发邮件

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

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

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

tech talk：

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

给别人光环

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

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

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

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

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

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

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

daily report和weekreport

    试着制定一下计划，越详细越好，工作方面的可以写给上司看，学习，社交等方面的可以自己写给自己

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

给自己留缓存，学会喊累，学会喊忙

一方面，可以在项目有了突发事件的时候，不至于临阵慌乱，尚有调整和处理的时间，不至于第二天demo，当天晚上代码才完成。另一方面，除了每天忙于项目之外，总要有一定的时间进行自我进步，从而提升自己的价值。

            总是喊忙，总是能出成果，确是一种工作努力的表现。有的人认为，只有相互说话才叫沟通，其实不然，殊不知自言自语，凝重的表情，同样是沟通的手段。

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

7. 又是一年加薪时

 1）入职培训中了解绩效体系

    不同的评价方法有不同的注意事项：

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

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

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

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

2）了解评级相关方

了解了绩效体系之后，你就明白了给自己最终的评级将有那些人了。对于不同的人的沟通方式也不尽相同。

过程型还是结果型：

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

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

技术型还是管理型

参考原文档

 

3) 进入team后，打响第一枪

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

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

    如果你有幸被冠以某方面强人的名号，则bonus，加薪，升职，代表Team去开会，演讲等都会慢慢的到来。

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

4） 绩效目标的确定

   一般的说法是SMART原则：

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

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

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

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

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

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

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

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

5）绩效沟通和反馈

   定时对以下方面进行沟通：

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

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

仔细分析工作中的困难和瓶颈。为了解决信息不对称的问题，上司此处应该做一个好的听众，学会站在员工方面看一下问题，甚至充当辅导员的角色，帮助分析遇到瓶颈的原因，是动机问题(对界面工作不感兴趣，希望做底层)，还是职位角色问题(此职位涉及太多不同模块之间的沟通，希望深入写算法方面的东西)，或是工作方法问题(不应该盲式，可借助工具进行分析)，或是能力问题(原来是学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的时候及时的介入指挥行为，随着进度的赶超而慢慢的减缓，在员工士气向下波动的时候及时介入支持行为，随着员工意愿的提高而慢慢减缓。当然在不同的项目，使用不同的技术的时候，员工所处的状态也不尽相同，不可一成不变。

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

6）近因效应的避免

  

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

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

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

7）年终考评——最后的机会

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

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

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

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

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

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

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

促使上司最后鼠标一点的，却不是你是否达到了这些描述，而是他心中的那个排序。

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

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

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

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

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

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

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

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

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

8） one- by -one

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

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

也说跳槽

职业规划

一个人，无论多么不成熟，无论前途多么迷茫，每个阶段，都应该有一个目标，随着自己的路慢慢的走，经验不断的积累，前面的路能够看的清楚一些，可以根据自己的经验，性格特点，做事风格，已有优势，目标可以进行一定的调整。每次调整，可能都会面临选择，没办法，只有像李开复说的那样follow your heart，追随内心，人都有一个特点，追随内心的选择比较不会后悔(至于对不对，人生没走完，谁也不知道)。

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

    技术深度一般会达到一定的程度，大多数人都会成为高级工程师，在这个阶段的后期，一般会再一次面临选择，这是职业生涯中关键的一次选择，将影响职业生涯的第六年到第十年。有的人会选择更细的技术分支进行进一步更深入研究，继续扩大自己在技术深度这一维度的优势，此类人职业规划简单直接，就是成为某项技术的大牛

    是希望整个系统从前端到后端，从底层到上层都能够有一定程度的了解，也即开始扩展架构广度这一维度，此类人对每一项技术都会了解到一定的深度，在各项技术大牛的帮助下，能够搭建起整个系统，他们的职业规划就是成为架构师，由于各个模块的技术都有可能更新，所以架构师需要不断的学习新的技术，不至于架构过老而遭到淘汰。有的人做的软件是面向某个行业的，比如金融，证券，财务，航运，电力等，他们出来技术深度形成一定的优势外，在三到六年这段时间里，也开始慢慢了解这些行业，于是扩展了另外一维——业务知识，他们能够迅速理解这些行业的业务需求，并转换成为软件的需求，他们的职业规划就是需求分析师，他们需要更系统的学习业务方面的专业知识，以期能准确把握需求。

    有的人在成为技术主力后，由于有一定的沟通和组织能力，开始带新人，以及领导一些人完成任务，于是扩展了另外一维——管理水平，他们需要学习项目管理，组织行为学，绩效管理等方面的知识，职业规划是成为技术经理。我的建议是有可能的话，做管理开始尽量在大公司

    在国内，成为大公司的技术总监，中小公司的CTO乃至VP，是大部分的程序员职业生涯的顶端

是时候跳槽了

    当某程序员的市场价格上涨，而公司付出的价格没有跟上的时候，跳槽也就产生了。原因如下：

   加薪幅度不够

   加班时间过长，工作和生活长期失衡

   安全方面：公司裁员

   社交：无法融入团队，与同事无法合作。团队中的很多无法合作和冲突往往就是因为各自的做事风格不同造成的，各自都有自己的理由，彼此对对方不屑，但其实平静一想，很难说是谁有错。

   尊重：和上级有矛盾。因为和上司的不和，会使得其他的各个方面都化为乌有，什么加薪升职肯定排在最后，也别想做什么核心的模块，如果有裁员那肯定是首当其冲，所以三十六计走为上。

   自我实现：职业生涯得不到发展。对于技术牛人路线或者架构师路线的人，如果发现在某家公司技术进步的速度较慢，则应该选择一个高手更多的更有技术含量的公司，注意这里强调的是速度，而非绝对的量。对于走需求分析师路线和管理路线的人，如果发现公司的业务或者规模发展比较慢，或者公司的平台比较小，上面已经坐满了比自己大不了多少的年轻领导，则说明发展空间有限，应该选择一个平台更大，扩张更快的公司。

   前面说的都是从下游向上游跳，当然也有反其道而行之的，有的人在大公司里面学到了核心技术或者较高层的管理经验，遭遇人生的天花板的时候，反而会选择跳到一些中等的公司进行半创业或者索性自主创业，以期人生获得更大成功。

【转载】：http://blog.csdn.net/dananhai381/article/details/41409961?ref=myread