我们经常讨论绩效考核这个话题，有不少人为如何考核程序员产出这件事烦恼。我旗帜鲜明的提出观点，绩效考核只是绩效管理的一环，如果抛弃绩效管理谈绩效考核，无异于舍本逐末。本文尝试聊几个大家关心的话题：绩效考核有哪些痛与伤、绩效管理与绩效考核的关系、目标与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(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年，业务领域兴趣在支付、金融风险、监管科技。同时经常就高可用分布式架构、研发管理、内建质量等发表观点。维护公众号：技术琐话。著有《深入分布式缓存》一书。