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