从去年开始我就一直在摸索团队的绩效考核方面的实践，去年还为此做了一套简单的绩效考核统计系统，虽然最终使用起来似乎效果没有达到我的预期，但是整个探索过程还是让我获益匪浅。
刚好这个时间点很多公司都已经发了年终奖或者将要发年终奖，趁此机会跟大家分享一下我对于产品经理的绩效考核方面的一些心得感悟等。
1、产品经理是否要做绩效考核？
关于这个问题网上有很多争论，我前前后后也看了好多个答案。从我个人观察来看，一般持反对意见的往往是一些基层员工或者是曾经被一刀切的绩效考核而伤过的人。而持支持意见的往往是是有过管理经验的或者享受过绩效考核带来的福利的人。
站在我的角度（管理者）来看，我会认同要做绩效考核，而且要做好，做公平，理由如下：
反对或者拒绝绩效考核者，大多数都是“屁股决定脑袋”。原因有两点，其一是反正自己没有得到利益，而看到别人得到了好处反而更加不舒服，还不如吃大锅饭来的好；其二是站的视野和高度不一样，持有此观点的人思考的出发点往往是自己，很难站在团队的角度来思考。
绩效考核是一面难得的镜子。以人为镜，可以明得失，但是很多时候这面镜子不太客观，也不太准确。绩效考核相比之下其实比自己“以人为镜”更加准确，即使这个观点有些难以让人接受，但是长期来看，外界的评价语应该是会被自我评价更加准确的。
产品经理的绩效考核虽然不太容易用直观的数据或者成果来论证，但是并不意味着它不重要或者不值得去做。恰恰相反，正是因为不太容易用直观数据和成果来论证，所以我们会从多个维度，多个因素去制定规则，防止过于片面的个人感情因素来影响评判的结果。
绩效考核能加速“优胜劣汰”，虽然这个词听起来很残酷，但是现实就是优秀者确实会因为及时的激励而走得更快、更远。任何人都希望自己得到激励，得到肯定，但是不可否认的是在相同的环境下就是有长有短，站在团队管理者的角度，大家都更加希望能多取一些长的，而少取一些短的。
2、绩效考核的几个误区
误区一：一刀切思维
在去年调研绩效考核系统的时候，发现很多公司或团队都会有这样一种想法：期待人事部门可以指定一套通用的考核方案，然后其他部门直接照搬套用就好了。
但是事实往往很残酷，这种一刀切的方式做出来的绩效考核太过于通用化，网上随手一找就可以找到，然后大家互相抄一点，裁剪一点，最后就应用到公司制度上去了。
对于IT团队来说，应该根据岗位的特殊性而设定不同的考核方式，不能为了追求一致性，而罔顾岗位特性。强行生搬硬套，只会引起大家的不快。
误区二：激励不够及时
去年外出参加管理知识培训的时候，我印象很深刻的一个知识就是：激励具有时效性，一定要及时。
这个道理我们都懂，也听过很多次，但是实践起来的时候却不是那么容易。很多管理者会有这样的一种心态，如果你不听话或者表现的很不好，那我就给你打低分，然后月底或者季度末的时候你就知道了，看你下次还敢不敢这样……
这种心态和思维方式有很大的问题，因为不论是正向激励还是负面激励（批评和指责），都应该要及时实施。有做得好的，应该及时激励，趁热打铁；做得不好的，要及时谈话，当面指出，不要留着秋后算账。
还有很多公司会采用年度绩效考核的方式，一年考核一次，然后和年终奖挂钩，最后年终奖还留到次年4、5月份来发。看似是很精明的手段，压缩了人力、物力，但是打工人也不是傻子，长期以往下去，必然物极必反，祸及自己。
当潮水退去时，才知道谁在裸泳！
这句话也适用于上述这种情形。
误区三：绩效大过天的压迫思维
很多人很反感绩效考核，其中很重要的一个原因就是因为公司或者领导总是用绩效考核来压迫自己，在公司绩效大过天，低绩效就处处受到打压。
例如不加班，那绩效考核的评分就会很低；和领导抬杠、顶着干，那月底就给你打低分；脏活累活强制分配，不接受就给低绩效，然后有成果了，领导就自己提前揽功，把下面的人踢到一边……
上述情况，作为当事人但凡经历过一件就会觉得很恶心，如果一直是这样的环境，那说明是公司制度有问题。企业文化有问题……
绩效考核对人有一定的约束性和压力是合理的，也是可以接受的，但是以此为权利用来作威作福，那么就变了味了。
所以在制定一些考核规则和手段的时候要注意规避这一块的问题，加入一些相互制约、申诉的通道等，避免出现这种独裁式压迫、令人压力巨大的现象。
误区四：强行数据化的考核
上面提到产品经理的工作内容不是很容易用一些直观数据来衡量，不仅仅是产品经理的考核难以衡量，开发，测试还有其它工种也有类似的难题。
而很多团队制定的考核制度就非要用数据化来衡量绩效的高低，于是乎就演变成了网上流传各种段子中的内容。
产品经理的绩效考核指标之一就是需求的个数，所以一个简单的需求会拆得特别细，改文案是一个需求，改颜色是一个需求，挪动按钮是一个需求，调整标题大小是一个需求……
程序员的考核指标之一是代码行数，于是大家不以代码简洁高效为荣，反而是各种小心机，多换行，多写注释，多写荣誉代码来获取高绩效。类似的还有按代码提交次数来考核，于是乎写两行就提交一次代码，再写两行再提交……
测试的考核指标是测试过程中的BUG数，于是乎各种转牛角尖，一点点不对劲就提BUG，然后和开发撕逼，和产品撕逼，搞得团队协作一团糟……
以上虽然听起来是段子，但是现实中也确实存在许多这样实施的公司和团队。为了考核，为了所谓的数据化、量化操作，而折腾了这么一场闹剧。
所以，才会有那么多人对绩效考核望而生畏。
3、产品经理的绩效考核怎么做？
查理芒格有句名言：”如果我知道我会死在哪里，那么我永远不会去那个地方。”
产品经理的绩效考核没有标准方案，只有合适与不合适的方案，但无论怎么样，我都建议要避开上面提到的四个误区。
接下来我分享一下，前段时间我刚做完的一套针对产品经理的绩效考核方案。此方案有明显的个人感情色彩和偏好，同时也仅适用于小团队，只为抛砖引玉之用，请各位理性看待。
考核的核心思想
1.以公司绩效考核要求为主体
一般的公司都会由人事部门制定相应的考核方案初稿，然后由其他部门同事给出相应的看法和意见等。所以当面对此类机会的时候一定要好好把握，争取给自己的部门和相应的岗位争取到更多公平性的利益。
在给出的通用型的考核方案上，针对不同的岗位制定不同的考核方案。例如不同部门间的考核方式应该有所不同，即使是同部门间的不同岗位也要不同，例如产品经理的考核方案就应该有别于开发、测试等。
通用型考核方案
2.不同级别也要差异化考核
不同级别的产品经理的考核方案也应该有不同，但是绝大多数内容应该要一致，在一些需要做区分的地方用不同的考核要求和权重比值来切割。
同时也要强调一点，初级产品的考核得分不一定低于中高级别的产品。因为初级产品的绩效考核对比参照的是初级的水平和要求，而中高级对应的水平和要求则会更高一些。
产品经理的岗位技能水平考核
绩效考核也要讲究一个“德位相配”，“名副其实”。
3.考核周期要适宜
最开始时候我们制定的考核周期是一个月，每个月月初系统自动发放考核填写表，然后开始评分。
但是渐渐地发现一个月的时间看起来很长，但是实际应用起来的时候发现一个月体现不出什么价值或者特别明显的效果。而且一些团队人数较多的领导们，在评估和打分的时候往往需要花费比较多的时间，本来月初要填完的绩效，一下子就拖到了中旬，导致大家对填写绩效的热情慢慢地就降下去了。
后来我们改变了策略，改成了一个季度考核一次，同时沿用OKR的指导思想，每个月月初制定一两条核心的月度或者季度目标，然后下个月的时候再来回顾实际的结果是否完成。如果完成了则继续制定下个月的，如果没有完成则再次进行新的规划……
总体而言，一个季度一次的考核不长也不短，还能趁此机会组织团队内部做一个季度的个人总结回顾，既能提升自己的总结复盘能力，还能借此机会让大家互相了解对方的业务知识，产品心得等。
4.不可量化则多谈话
之前我在《樊登读书》上看到过一篇文章讲绩效考核，大体的意思就是：很多人以为绩效考核就是我给你打个分，然后让你知道自己多高多低，然后就完事了。高了的就自己偷着乐，低了的就自己反思。
这也算是一种绩效考核的误区，尤其是中国人都特别爱面子，有些难听的话或者一些尴尬的场景会特别的畏惧，和低绩效的下级谈话就算是一种尴尬的场景。
但是正是因为有一些指标是不可量化的，所以打分高与低更多的是在直属领导的一念之间。如果打完分了或者将要打低分的时候不跟当事人沟通，那么逃避这个尴尬的场景这个举措就会积攒越来越多的风险和不满。
所以，如果有些指标不好量化，那么最好是在打分之前就多谈话，坦白地向下级指出你的考量，你的想法以及建议等，最后再打出确定性的分数。
5.分数需要转化为等级
这是一个小心思，也是一个常用的小套路。例如89分和90都是属于同等级的绩效（85分以上都是A），那么两个同级别的人享受到的福利应该也是一样的。但是如果让当事人知道了具体的分数，那么就很容易产生一些心理上的不平衡。
- “为什么他比我多一分？”
- “为什么我表现的那么好，只比那个人多三分？”
- “为什么他都可以有xxx分？”
- ……
所以为了避免类似的问题，一般会将最后转化后的等级告知当事人，例如绩效为A，绩效为3.75，绩效为S等等。
4、总结
本文没有具体的从考核的指标和内容上与大家分享，例如产品经理应该考核需求分析、设计能力，还是应该考核项目管理能力，产品规划能力，竞品分析能力，向上管理能力等……
因为这些指标和内容因公司而异，因团队而异，因业务而异，千人千面，参考意义并不大。所以还不如直接用第一性原理去思考：绩效考核哪些地方容易踩坑，然后制定一份绩效考核的时候应该多注意哪些方面。
绩效考核方案没有完美，也没有标准答案，只有合适与不合适，而且合适与不合适随着时间的变化，团队的发展也会变化。
去年制定的绩效考核标准可能到了今年就会有新的变化，因为大家都在成长，对应的激励措施和考核方式也应该就此改变。
绩效考核是一把典型而又常见的双刃剑，用得好的，则可势如破竹，带领团队锐意进取，蒸蒸日上；用得不好的，则搞得团队内乌烟瘴气，一团乱麻，勾心斗角的，全是负面影响。
以上内容纯属个人观点，本人才疏学浅，可能观点有失偏颇，望大家辩证性看待。
