72 lines
9.7 KiB
Markdown
72 lines
9.7 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
170 高琦：如何给研发打绩效不头疼而又公正？（下）
|
||
你好，我是搜狐社交产品中心总经理高琦，上一篇文章中我跟大家聊了如何给研发打绩效的问题，我们团队在实践敏捷的过程中意外发现，敏捷带来团队整体透明度的提升，使得相互之间的评价变得更为客观，给绩效考核带来了非常正面的影响，让给研发打绩效变得更为简单、公正。
|
||
|
||
但不同公司对于研发团队的绩效考核都有不同的方式和标准，我们之前也尝试过不少其他方法，因此，本文想再谈谈一些其他绩效方式的实践以及我对这些方式的补充和探索。
|
||
|
||
1.用数据说话，把研发的工作量化
|
||
|
||
有这样一种绩效流派是唯数据论，希望把一切工作量化，用数据来评判一切，这样就可以套用KPI的方式来进行考核。那么要想评价研发的绩效，自然会找出一些指标，而研发过程中是不会缺乏指标的，比如代码量、bug数等等。
|
||
|
||
举个例子，曾经有个兄弟团队的Leader突发奇想，用代码量和bug数来进行绩效考核，最后变成了程序员和考核者斗智斗勇，激发出了各种奇思妙想。要代码量就加注释，考核加入了去掉注释的功能，程序员就引入大量废代码，考核又加入自动分析有用代码覆盖率的功能，程序员就把各种一行可以解决的问题，写成多行，很像古龙为了多拿稿费，非得写成“风”换行“冷风”换行“冷风吹”换行。古龙这种写法多少还有其特殊的艺术价值，而程序上一行换多行，没有任何价值。
|
||
|
||
这种博弈充分体现了互联网的迭代思维，而且迭代速度之快，让人目不暇接，脑洞大开。可笑的是最终这个想法被放弃并不是因为考核者觉得斗不过程序员了，而是由于产品经理崩溃了。
|
||
|
||
因为另一个指标是bug数，而程序员为了bug少，那就得保守，少做需求，原来一个需求3天可以完成，现在打死5天也完成不了了，项目进度突然变得异常缓慢。终于在产品经理的抗议声中，这个计划土崩瓦解。实际上这些程序员都是非常优秀的人，之所以有这样的反应是因为感觉人格受到了侮辱，被人怀疑总是想偷懒。
|
||
|
||
虽然这种尝试失败了，而且从根本上看这种方式就是错误的，但我认为数据在研发绩效考核中是可以发挥作用的，只是各种数据应该仅作为辅助参考，而不可以作为核心考核指标。一旦数据成为核心指标，必然会导致其中的参与者动作变形，人为做一些事情来干扰指标。而且，由于数据肯定会存在一定的偏差，即使作为参考也只适用于发现极端的情况，比如筛选出表现非常出色的员工和表现非常不理想的员工，如果用数据来衡量一般表现的员工之间的差别，会非常容易出现误差。
|
||
|
||
我曾经使用代码量、bug数、bug reopen数、接需求量、优化性能需求占比和加班时长这六象限雷达图来统计研发数据，如下图 所示(数据做了归一化处理)。
|
||
|
||
图中列出的是两个差别较大的程序员，可以看出红色代表的程序员和蓝色代表的程序员相比，在代码量和bug数上都没有优势，在加班时长上明显要更少，但他实际完成需求量更多，bug被reopen数也少很多，说明他的代码质量更好，勇于承担优化性能且较难的任务。
|
||
|
||
|
||
|
||
这张图其实是我在大家都不知情的情况下，偷偷用系统数据跑出来的，而且我也并没有用这样的数据进行绩效考核，但是这个数据仍然让我较为客观的发现了问题员工。例如这个蓝色的程序员，看起来非常辛苦，每日忙忙碌碌，如果每个人独立开发，不知道他人的工作，那么这样的人也有可能会得到一定的肯定。有句话叫没有功劳也有苦劳，功劳不容易比个高下，而苦劳却容易得多，然而这类研发者属于低效者，是团队战斗力不良的关键因素。
|
||
|
||
同时，由于不会将数据作为绩效考核的标准，那么即便大家知道我有时会抽数看这些数据，但真实改变这些维度的数值需要花费大量的精力，没有必要为了还不确定能影响结果的事情做太多事情，员工进行人为干预的动力就不足，最终得出的结论也就更能接近实际情况。
|
||
|
||
2.360度环评
|
||
|
||
360度环评在外企使用得比较多，初衷是想创造出一种相对公开透明的企业文化。优点是可以减小绩效只由直属领导主观评定导致的严重偏差。
|
||
360度考察的信息来源包括：来自上级监督者的自上而下的反馈（上级），来自下属的自下而上的反馈（下属），来自平级同事的反馈（同事），来自企业内部支持部门和供应部门的反馈（支持者），来自公司内部和外部客户的反馈（服务对象），以及来自本人的反馈。
|
||
|
||
总体而言，这种方式确实可以将主观认知偏差，通过更加民主的方式进行有效抑制，最终的评价也更接近团队均衡的客观。应用于研发，就是自我评价、同组研发人员的评价、其他研发组人员的评价、直接下属评价、相关的产品人员评价、测试团队人员评价等等。
|
||
|
||
虽然看起来360度环评是一种非常好的绩效实践手段，但在执行的过程中，这种绩效考核方式最大的问题还是在于主观因素过多，且上级、下级、同部门、相关部门共同打分之后各自的权重不好界定。取一样的权重显然不合适，最终不同公司的权重选择仍然非常依赖规则的制定者，通常公司会给出一个统一的标准，但部门不同，实际情况也是千差万别，结果是最有发言权的人，未必有足够的权重。
|
||
|
||
但无论如何这种方式是利大于弊的，更需要反思的是为什么360度环评没有被国内的公司大量采用。我个人认为最大的困难在于各leader希望可以对自己的小团队有更好的控制，而且也并不愿意把自己置于这样环评的境地中，这需要公司整体自上而下进行推动，所以实施的关键在于顶层决策。
|
||
|
||
3.对OKR的误解
|
||
|
||
很多公司都对OKR存在误解，他们推进OKR，希望OKR能同时解决很多问题，包括绩效考核。从目标分解的角度看OKR和KPI是两种不同的方式，但从绩效考核的角度看，KPI能和360度环评等概念并列，而OKR并不在其中，它并不解决绩效问题，所以在这里不多讨论OKR，例如谷歌就是使用OKR作为目标管理框架，360度环评作为绩效考核工具。
|
||
|
||
4.靠技术领导者的个人感觉
|
||
|
||
这种绩效考核方式是大部分团队所采用的，有一定的合理性，在没有更优的办法出来之前，这种办法通常是较为合理的，宁肯用主观评价，也千万不要引入错误的量化指标。
|
||
|
||
这种方式的优点是，如果技术领导者能深入到各个团队，倾听各种意见和反馈，自己也能尽可能的把自己的好恶抛在一边，最终的结果就会相对公正和公平。但是弊端也非常明显。
|
||
|
||
首先深入了解每个人是非常耗费时间的，技术领导者还有很多重要的事情，而且团队越大，这种深入就会占用更多的时间，这是不现实的。但我会推荐小的团队负责人，应该尽可能的深入了解团队中每个成员的情况。
|
||
|
||
另外每个人都有很大的认知偏差，这是人性的弱点，没人能完全克服。很有可能的一种情况是，某个员工工作中的某件事情没有做好，就被领导打了个不靠谱的标签，后续一直受到严重的影响，甚至在一些情况下不得不选择辞职换个环境重新来。大家不妨仔细想想曾经自己的领导，哪些人是让你感觉伴君如伴虎的？那些让你有这种感觉的人，通常会更喜欢给人打标签，所以这样领导的下属通常就会谨小慎微，怕说错话，做错事。
|
||
|
||
这种类型的领导者也最容易看不到真实情况，因为他团队中的每个人都在尝试包装自己，给自己调整出一个比较好的人设。最后，那些聪明的、会包装自己的人会得到更多的机会，但整个团队实际上是受损的。对技术管理者而言，这样的结果尤为致命。
|
||
|
||
或许你会觉得自己不会成为这样的人，但这是人性的弱点，作为一个普通人，大家都会存在这样的问题，只是程度不一样而已。克服偏听是一种反人性的操作，就像对抗习惯，大多都无功而返一样。但只要有这样的意识，积极审视自己的决定，就会有更多调整的机会。
|
||
|
||
总结之前提到过的诸多绩效考核实践和方法，比较好的一种方式是让敏捷团队自己评价成员，技术领导者主要参考这个评价指标，再以各种数据进行辅助，识别出最优成员和表现不佳成员，同时要多深入团队防止自己的主观误判，最终让绩效结果更加公正透明，让人信服。
|
||
|
||
感谢你的收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
|
||
|
||
作者简介
|
||
|
||
高琦，搜狐社交产品中心总经理，TGO鲲鹏会会员，2014 年加入搜狐，负责搜狐集团移动广告业务，负责搜狐移动端广告系统架构和性能优化，有效提升了业务指标，2017 年起，从零开始构建了搜狐资讯团队，产品在一年内日活突破百万。2018年负责搜狐社交业务。
|
||
|
||
|
||
|
||
|