第21讲 | 绩效管理的目标不仅仅是绩效考核

May 21, 2018

第21讲 | 绩效管理的目标不仅仅是绩效考核-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

第21讲 | 绩效管理的目标不仅仅是绩效考核

2018-05-21 蚂蚁金服资金运营技术部负责人、TGO会员于君泽来自北京

《技术领导力实战笔记》

课程介绍



讲述：黄洲君

时长12:14大小8.40M



我们经常讨论绩效考核这个话题，有不少人为如何考核程序员产出这件事烦恼。我旗帜鲜明的提出观点，绩效考核只是绩效管理的一环，如果抛弃绩效管理谈绩效考核，无异于舍本逐末。本文尝试聊几个大家关心的话题：绩效考核有哪些痛与伤、绩效管理与绩效考核的关系、目标与 KPI、OKR 的关系等。
绩效考核有哪些痛与伤我们先回顾一下绩效考核都有哪些常见问题。
第一类问题，我们姑且称为”工作量考核”。顾名思义，工作量考核的关键点在于工作量评估。工作量评估，又会绕到一些常见的问题：
Java 开发工程师的工作产出如何衡量？
前端工程师的工作产出如何衡量？
产品经理的产出如何衡量？
DBA 的工作产出如何衡量？
有人提到过代码行评估，但代码行评估其实在业界的争议非常大。代码行多是绝对代表产出更好吗？不同语言之间对比代码行也是一个有点滑稽的事情。
第二类是绩效考核，可以称之为”全面指标考核”。全面指标考核可以说在”考核”本身这件事上已经做得足够了，一般会关注多个维度的评估以保障全面性。我曾在一家电信业务的 IT 公司做部门经理，当时公司是采用平衡计分卡来做绩效考核。
平衡计分卡是从财务、客户、内部运营、学习与成长四个角度，将组织的战略落实为可操作的衡量指标和目标值的一种新型绩效管理体系。我后来反思，绩效目标要突出拉动力，而不是面面俱到。否则很容易导致全面指标考核在实操过程中走向失败，绩效考核的维度和实际运营维度不 match。
我们再看一个例子。在项目研发中往往以研发过程数据、业务结果、公司制度（比如考勤）、主管主观评价等构成程序员的绩效考核体系。如下图所示，示例了一个绩效考核的指标体系。
业务结果、研发过程、制度考勤、主观评价 4 个维度有对应的权重，来体现不同的岗位角色和各项指标的关联紧密程度。比如，活跃用户数超出预期，研发人员自然是有贡献，但产品和运营所起到的作用更是重要。我认为，研发过程的指标应该作为观测指标，真正的考核指标是业务在线上运营的故障和缺陷，以及研发人员对于需求响应、客户服务方面的满意度。由外而内，避免自嗨。
绩效考核还有一类问题，出在绩效指标设定上。绩效指标要和组织目标对齐，不要为了设置而设置。我们来看一个例子。某测试同学的绩效指标设定：1：所负责的模块无线上缺陷；2：辅导应届生进行功能测试；3：完成一次性能测试。
到考核季的前一个月，这位同学发现我的第三个指标 (完成一次性能测试) 还没做呢？于是急急忙忙去做了。当主管评估该同学绩效指标的时候，发现所有指标都完成了，包括性能测试的指标。但这个指标是不是当下最重要紧急的，甚至这个个人绩效指标跟项目目标、团队目标没有强关联。目标没有对齐的危害，可能是树木和森林没有很好的对应，甚至可能南辕北辙。
通过这个 case 可以思考一个问题，绩效目标设定和所属团队目标的关系，以及和上级组织目标的关系。
我们跳过绩效考核应该如何做，先回头来看看绩效管理是怎么回事。
绩效管理闭环有个专家叫戴明，他发明了一个快速反馈的工具叫戴明环，又称为 PDCA 环。PDCA 环实际是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及。PDCA 循环的含义是将质量管理分为四个阶段，即计划（plan）、执行（do）、检查（check）、行动（Action）。
绩效管理其实质也是一个 PDCA 循环。
第一步是目标设定。目标来自于哪里？技术团队的目标一定是来自于业务。我经常讲不服务业务的技术都是耍流氓。阿里巴巴 CTO 行癫也有句话，所谓的工程师文化就是”让好技术驱动业务腾飞”。比如一个业务负责人把一款 app(如极客时间) 的目标设定为：
活跃用户数达到 10 万
单品专栏成交量超过 20000
按照增长黑客的思路，引新、留存、促活、转化这些套路都会用起来，那么对于技术平台就可能有一些对应的技术指标。比如：
App7*24 小时可用（实际上可以放宽一点，深夜 4 点还在学习的用户极少）
App 稳定性 (安装包大小、启动时间、崩溃率、App 耗电等)
易于分享和传播（比如分享步骤不超过 3 步，过于复杂会让用户失去兴趣，当然还可以通过返利一定程度上平衡）
第二步是设置计划，亦即是 PDCA 环中的 P(Plan)。设置计划来自于目标的分解。比如：
8.31 完成 A 业务线的全部业务接入
9.30 完成 B 业务线的全部业务接入
10.31 完成 C 业务线的全部业务接入
第三步是执行 (Do)，执行过程中进度风险、人员流失、技能不够、需求变更频繁等风险都有可能存在，甚至是不止一个因素同时发生。那么我们要做好的就是缩短反馈环，解决问题。每日立会、缩短迭代发布频度等有助于掌握项目实际的风险和完成状况。参与项目的同学，项目整体目标与个人目标息息相关，可以通过主动反馈主管来做阶段性检查 (check) 对齐。
第四步是检查（Check）。对于个人而言，日常过程中的绩效管理尤其重要，及时发现偏差，及时清晰的沟通，落地有效的改进计划或方式。同时如果涉及绩效目标的变更，也要及时沟通调整。
第五步是给出 Action。根据 check 结果给出 Action 帮助目标进行改进。同时进入到新的 PDCA 循环。
由此可见，绩效管理是一个闭环过程，而绩效考核是其中一个阶段。如果等到考核期才发现问题就晚了，应该保持按周、月、季做 check 有利于早发现、早纠正。
目标与 KPI、OKR 的关系首先辨识一些基本概念。
什么是目标？目标是要去的方向，并且转换为可衡量的数据指标。目标不是孤立存在的。
KPI(Key Performance Indicator) 是关键绩效指标，来自自上而下的分解。各部门的主管需要依据企业级 KPI 建立部门级 KPI，并对相应部门的 KPI 进行分解，确定相关的要素目标。KPI 的好处就是分解清晰，力出一孔。
OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，主要目标是明确公司和团队的“目标”以及明确每个目标达成的可衡量的“关键结果”。OKR 首先确定 O(Objectives)，然后从 O 分解出 KR(Key Results)，然后用 KPI 或者 Milestone 的形式来表示 KR。
有论者批评唯 KPI 论，一切都是 KPI 惹的祸。我觉得关键的问题不是出在 KPI，而是出在 KPI 的制定者，或者是 KPI 的执行者。KPI 顾名思义，是关键绩效指标，指标不等于目标，所以 KPI 应该在目标的指导下工作。
举例来讲，在 2011 年的时候，我们大团队曾经做了一个产品叫悬赏交易，如果我没记错的话，大概业务指标是做 100 万笔交易。热心的运营同学想了各种办法来完成这 100 万笔，包括给旺旺用户推送消息，然后跳转到对应页面，获得一个赠送的商品，默认点击则完成一笔交易。我认为这样的 KPI 在执行层面是有害的，设定 KPI 背后的 why 是什么？是让这个产品被用户知道，让用户愿意来使用，有用户留存。如果用户在引流过来对产品毫无感知，单纯完成的交易并不能说明什么问题。总结来说，KPI 没有错，在使用 KPI 的时候，要了解背后的 why，要了解我们要去的方向在哪里，目标在哪里。在灯塔的照耀下，KPI 就能被合理的应用于考核。
有时候方向对了，KPI 设定错了，还可以走一段之后去调整它，所谓“不忘初心”，在行进途中别忘了，我们为什么出发？而 OKR 的美丽在于，对于目标提出了可度量的关键结果。所以无论 KPI 还是 OKR 都需要强目标驱动，单纯谈 KPI，可能会丢掉目标和初心。
我们参考一下吴军老师 2017 年初给自己设定的 OKR，下面仅引用目标 1。
目标 1. 完成《数学之美》的英文版和韩文版，《大学之路》第二版
关键结果 1.1  找到英文版的出版商 ；（1.0，已经签了合同）
关键结果 1.2  寻找合适的、母语是英语的合作者，修改英文版的书稿 ；（0.3，试了两个翻译者，都不满意，在联系第三个翻译者，让她试着翻译一章。）
关键结果 1.3  完成英文版的写作；（0.1，因为翻译者还没有找到，因此我自己翻译了一章、前言、目录，以后要由翻译者做）
而我在工作中，习惯了增强 KPI 的设置模式，这个模式里面有关键绩效指标, 但关键绩效指标仅仅是一个评估结果。于是又增加了过程关键指标。过程关键指标如同温度计，它不是用于惩罚和制裁。而是去发现可能的异常，通过高频快速的反馈促进团队和个人改进，以便于满足阶段性 KPI 的达成。下面就提供一个设置增强性 KPI 的示例。
夯实底盘（稳定性、资金风险）：通过 XXX 手段加强事前、事中、事后的风险防控。
【衡量标准】：
最终结果：
无重大故障
无 P1 级故障
线上总故障数 <=5
过程关键指标：
线下缺陷，缺陷密度、紧急发布等作为观察指标 (详细指标此处省略)
应急体系：（衡量指标：变更导致线上的问题的发现时效、主动发现线上问题比例等）
业务分钟级异动感知， 5 分钟内止血消除影响。
加分项：
1：创新解决问题方案，有案例支撑并具备跨子域或者更大范围的推广价值。
2：在问题的解决过程中追求极致，有典型案例支撑。
大家可以思考一下，如果把上面的例子修改为 OKR 应该如何做？我认为 KPI 本身并不 low，关键在使用这个工具的人。在使用 KPI 的时候要紧扣目标，绩效管理闭环有助于产出的改进。OKR 创造性的提出了 Key Results，但也要防止 Key Results 陷阱。随着公司业务发展和规模扩大，越来越多的团队面临的是不确定性问题域，很可能 3 个 Key Results 结果都很好，但关键目标并未达成。
结语绩效管理的目标不仅仅是绩效考核，绩效考核只是绩效管理 PDCA 的其中一环。考核的目的是为了改进，而不仅仅是做一个评价。技术团队设定目标的方向非常重要，目标应该来自于组织目标分解，同时为了保有创新和自主性，组织目标不宜确定过细、让团队拥有一些创造性解决 key result 的机会。KPI 是关键绩效指标，关键绩效指标要在目标的作用下工作。OKR 在目标的基础上分解出关键结果，有利于目标的过程跟踪。
作者简介
于君泽，蚂蚁金服资金运营技术部负责人，TGO 鲲鹏会成都分会会员。从业超过 16 年，业务领域兴趣在支付、金融风险、监管科技。同时经常就高可用分布式架构、研发管理、内建质量等发表观点。维护公众号：技术琐话。著有《深入分布式缓存》一书。

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

赞 8

提建议

大咖对话 | 技术人真正需要的是升维思考

第22讲 | 验证研发团队价值的绩效考核机制

 写留言

精选留言(4)

少帅
2018-05-21
KPI是手段，没有问题，变质在于人心，偏离了初衷
7
远古的咖啡
2020-04-03
很棒，考虑“关键”指标是为了达成目标，而不仅仅是为了完成指标。
2
谢军
2018-06-14
在管理工作中，我特别希望下面的员工能够拥有子驱力，并且能够从产品公司的角度去解决思考问题，但一直没有什么好的方案，后面了解到了okr，事实上就是我们把公司阶段目标和方向和部门中的人都做了传达，大家知道公司现在要做些什么，然后才知道自己做的事哪些是最重要的，优先级最高的，这时候他就拥有了独立思考自己驱动自己完成工作的能力了
2
janson
2020-03-24
很棒！

