浅谈团队的绩效管理机制
前言
本文要谈一个令人要头疼的问题，貌似一线工程师总是烦恼为啥自己这么努力还是背锅，领导的脑袋一定是被驴踢了，而各层的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了。