前言

本文要谈一个令人要头疼的问题，貌似一线工程师总是烦恼为啥自己这么努力还是背锅，领导的脑袋一定是被驴踢了，而各层的leader则想我靠这次有X个绩效为C的名额该给谁呢。绩效评价不光关系着每个人的收入而且还影响着晋升和淘汰机制，同时也是组织文化的决定性因素之一。
作者也一直被这个问题所困扰，到底怎么样的绩效评价机制才能更加公平的评价每个团队成员，怎样才能更好地促进团队的成长，建立一个良性的竞争机制呢。因此调研了世界各大科技公司的绩效评价体系和机制，同时找了处在一些国内不同层次的公司的同学了解一下各个公司的实际执行的评价机制，因此在这里讨论一下最近的成果。

到底什么是绩效管理

本文所说的绩效管理指的是对于他人进行评价，从而影响甚至决定他人薪资或其他切身利益的行为。不管是一线的工程师还是中层的小组长还是高层的CTO绩效管理永远是一个挑战，做不好绩效管理下属觉得你是脑残，想留的人留不住，想淘汰的人则很安逸，同时领导觉得你的水平有问题。

绩效管理的目标就是奖优惩劣，筛选有潜力的人员，更大化团队战斗力
总之：
1.林子大了什么鸟都有
2.分不出好鸟坏鸟，林子也会烂掉，最后林子也会没了。

动态的绩效管理

处于不同声明周期的组织的绩效管理的机制是不同的，具体如下所示。

初创阶段(<10)

在团队的初创节点就提绩效管理是不合适的，在初创阶段还是多想想怎么更好的生存下去，充分授权核心团队并给足钱，大家同舟共济。这个阶段中每个人都长时间在一起工作，每个人的工作能力和态度其他人一目了然，这一阶段跟随决策者跟随自己的内心和感觉往往比精确的模型来着好使。

成长阶段(>10&<200)

正好有一些同学是在这类中等组织中工作，处在这一阶段的组织一般会建立一套自己的绩效管理方式：
1.比如每个月固定，年底再大领导进行评价或组成委员会来讨论确定。
2.为每个团队进行打分，这个分数逐层分解到个人，每个人的平均分就是团队的分数。
3.团队直属leader决定对于团队成员的绩效评价，当然保留讨论和交流的通道。

成熟阶段(>200)

成熟阶段一般是指团队已经增长到一定规模，业务比较稳定，领导层已经不能具体的了解每个人的工作，而是需要引入多层中间的leader来进行团队的管理和绩效评价，而团队人员构成也相对固定，岗位和层级的划分也较为成熟。
这时的绩效管理往往需要建立分级的人员模型，较为清晰的评价指标以及定期的评价机制(半年或者一个季度)。

具体方式

OKR

说起OKR不得不说提起Google，Google应该是第一个将OKR真正的推广并投入使用的大型科技公司，与之相对应的Facebook也是OKR的大力推动者。OKR在业界叫的非常响亮，但能真正投入使用的却寥寥无几。因为这个东西实际操作起来确实非常的困难，OKR更适合于指导而非约束，而又想借助这个来进行绩效评价那么就需要建立一套完整而精致的评价模型，来辅助OKR来达成绩效评价的目标。

交叉评价

交叉评价是指的是除了让直属leader对团队成员进行评价外还需要邀请跟直属leader同级的同事对团队进行评价，并且评价也按照一定比例计入绩效考核的分数中。

同事评审

同事评审的起源目前还没有查到，具体是值得是除了让直属leader对团队成员进行评价外，还需要团队成员对其他成员进行评价，并且按照一定比例计入绩效考核的分数中。

这几种方式都是在组织达到相当的规模和成熟度才适合，中小型组织用起来肯定束手束脚。

核心建议

要把不同的人拉到同一个维度来比较

关于如何对从事不同工作的人的绩效进行比较一直是非常困难的问题，比如拿开发和测试进行比较，比如拿财务部的岗位和首席架构师比较，对于这个问题，个人有一个思路就是统一到外包或再招一个人来完成这项工作所需的成本的维度上，比如一个测试人员完成的工作想要外包出去的成本是多少，然后再招一个出纳的成本是多少，这样不同维度的人员和岗位就统一到￥的维度了，剩下的就是把人员都拉出来比较一番了。
当然这个方法不能过度使用

不同阶段要有不同阶段的管理方式

在初创阶段还是多想想怎么更好的生存下去，充分授权核心团队并给足钱，大家同舟共济，后面再逐渐建立公平的考核机制，可以考虑将团队按照1261的SABC或271的ABC模型来划分,这样更便于衡量

SMART&透明

绩效考核指标必须满足SMART原则，即(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound)，
如果绩效评价的指标总是含糊不清，没有明确的界限，还可以随时动态的调整，那还不如没有指标。
同时考核的结果应该也是公开透明的，否则组织成员肯定会滋生出暗箱操作或是黑幕等猜想，这个是人类本性不可避免的。其实透明做起来很简单，直接邮件抄送全员就OK了。

绩效评价不是因为这个人是谁，而是他做了什么，而他又能做什么

一个组织的80%的贡献是由其中20%做出的，因此对于头部资源的支持是绝对不能放松的。

大锅饭型的绩效管理办法，只会造成高端人员的流逝和低端人员的滞留。

浅谈团队的绩效管理机制相关推荐

转：浅谈Linux的内存管理机制
一物理内存和虚拟内存我们知道,直接从物理内存读写数据要比从硬盘读写数据要快的多,因此,我们希望所有数据的读取和写入都在内存完成,而内存是有限的,这样就引出了物理内存与虚拟内存的概 ...
浅谈Linux的内存管理机制
一物理内存和虚拟内存我们知道,直接从物理内存读写数据要比从硬盘读写数据要快的多,因此,我们希望所有数据的读取和写入都在内存完成,而内存是有限的,这样就引出了物理内存与虚拟内存的概 ...
浅谈python的垃圾回收机制以及内存管理
背景介绍 Python语言默认采用的垃圾收集机制是『引用计数法 Reference Counting』,该算法最早George E. Collins在1960的时候首次提出,50年后的今天,该算法依然 ...
浅谈物业信息化对管理的重要性
浅谈物业信息化对管理的重要性在这个信息化飞速发展的时代,我们生活的点点滴滴都与信息化分不开,当然.行业的发展也离不开信息化,信息化的发展是企业发展的关键因素,信息化有以下几个特点:资源整合共享,规范 ...
浅谈SQL Server内部运行机制
原文:浅谈SQL Server内部运行机制对于已经很熟悉T-SQL的读者,或者对于较专业的DBA来说,逻辑的增删改查,或者较复杂的SQL语句,都是非常简单的,不存在任何挑战,不值得一提,那么,SQL ...
浅谈售后服务的备件管理
PS:最近在处理售后坏件报废.售后备件跟踪的相关需求,对于该领域业务背景了解甚少,于是找到了这篇文章,非常受用,分享给大家~ 浅谈售后服务的备件管理 ■韩岷光对外经济贸易大学摘要:本文主要论述了 ...
浅谈产品事业部“技术管理”思路
浅谈产品事业部"技术管理"思路本系列文章由ex_net(张建波)编写,转载请注明出处. http://blog.csdn.net/ex_net/article/details/8 ...
浅谈ASP.NET的内部机制(一)
浅谈ASP.NET的内部机制(一) 前言:当一个Http请求发送给一个aspx页面时,服务器进行了哪些操作?又如何来解析这个请求?ASP.NET在接收请求后是怎么运行的,如怎么编译以及怎么样用托管的代 ...
浅谈ASP.NET的内部机制(二)
浅谈ASP.NET的内部机制(二) 前言:大家知不知道,一个Http Request是如何被传递给ASP.NET的?而且ASP.NET是如何知道一个 Http Request是请求的. ...

浅谈团队的绩效管理机制

前言