提到绩效管理，很多人可能会想到 OKR、KPI、360考核等等，但是绩效管理和绩效考核是一回事吗？OKR 真的适合用来做绩效考核吗？又应该如何对开发团队的人员进行绩效管理？基于以上问题，分享一些方法。

先回答前两个问题，绩效管理不等于绩效考核，OKR 也不是用来考核的衡量标准。

「绩效管理」是一个持续不断的业务管理循环过程，所覆盖的内容有很多，包含制定绩效目标，制定绩效计划，制定相应的制度引导员工朝着正确的目标发展、对实现目标的过程进行监控等等，绩效考核只是其中的一部分。

OKR 为什么不适合做为考核的衡量指标，我们先从 KPI 讲起。KPI 的制定是必须按照 SMART 原则制定的，要达到百分之多少是明确的，这样就会导致两个问题：

一是员工为了能达到 KPI 指定的目标，会设定一个相对较低的目标值；

另一个是，为了达到目标，实际执行手段可能与愿景相反，比如希望用户更喜欢我们的产品，把 PV 写进了 KPI 里，但是为了达到这一目标，把原来在一个页面能完成的事情拆分到了几个页面上，这样 KPI 达标了，可是用户的满意度却下降了。

之所以会出现以上两种问题，原因就在于 KPI 是和考核、奖金挂钩的。

而 OKR（目标与关键成果法，代表Objectives和Key Results）是与绩效考核分离的，它强调的是最终的关键结果必须服从目标，是让人更加聚焦目标和重要的任务。

事实上，OKR 是用来做绩效管理的工具，但绝对不是用来考核的衡量标准。

明确了以上两个问题，沿着绩效管理的过程给出一些参考。

一、制定整体策略

绩效的管理的第一步，首先应该明白整体的策略是怎样的，这一般跟团队和公司的实际情况有关。

比如一个10人以下的小团队和一个100人以上的大团队，前者肯定是要寻求最直接有效的管理方式，而后者就需要更为复杂的、有体制的管理方式。又比如在一个公司创业阶段和平稳发展的阶段，所实行的策略也应该是有所不同的。

二、目标和OKR

绩效目标的制定、引导和监控，就不得不提 OKR 了。OKR 是一种简便且强大的目标管理方法，相对于 KPI 而言，可以帮助员工建立一个更清晰的目标。

一方面，OKR 中的 O 可以使团队在一段时间内保持专注；另一方面，KRs 又为目标如何实现提供了灵活度。

O 是团队一段时间内的目标，成员个人的安排都应该是为了达到这个目标而设置的，这样使团队所有成员目标一致；KR 可以由成员自己设定，调动了员工的积极性。

总体来说，OKR 可以保持专注度和灵活度之间的平衡。

三、绩效考核

对开发人员进行绩效考核是一件很头疼的事情，显然不能简单的依据代码行数、Bug 数来评估，根据不同的团队情况，这些指标也不能是千篇一律的。

虽然在开发方面的考核指标不存在银弹，但是依然有一些可遵循的指南供参考。

在《Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations》一书中概述了两个简单的衡量指南：

1. 使用专注于结果而不是产出的衡量指标；
2. 使用针对全局或整个团队成果而不是局部或个人成果而进行优化的衡量指标。

1. 两个反面案例

先举两个反面的例子来说明这两点指南：

（1）代码行数

如果1000 行代和10 行代码都能解决同一个问题，我们当然喜欢后者。

奖励开发人员编写额外的代码只会让软件变得更加臃肿，这会带来更高的维护成本和变更成本。

那么另一个极端呢？最小化代码行数也不行。虽然有时候可以用一行代码来完成一个任务，但这样的代码别人不好理解，所以很难维护。

将代码行数作为生产力衡量指标违反了第一点指导原则，因为这样关注的是产出而非成果。它只衡量了人们做了什么（代码行数），但通常忽略了真正的目标。

（2）速度

使用速度作为生产力衡量指标有几个不足。

首先，速度是一种依赖于团队的度量，具有相对性。团队通常具有不同的背景，所以在团队间进行速度比较并不合适。

其次，当速度被用作生产力衡量标准时，团队很可能会做出一些与事实不符的事情，他们会夸大他们的估算，并想尽可能多地完成自己的任务，疏于与其他团队合作。

将速度作为生产力衡量指标违反了第二点指导原则，因为它更关注局部指标而非全局指标。为了优化自己的速度，团队通常不会与其他团队合作。这通常会导致组织采用次优的解决方案，因为他们没有关注全局指标。

2. 如何应用

如何应用这两个指南，也给出了一些参考。《Accelerate》一书把软件开发和交付方面使用的度量叫作软件交付绩效。

它可以分为两个类别，每个类别包含两项指标：

（1）节奏

• 交付周期：从提交代码到代码在生产环境中成功运行所需的时间。
• 部署频率：团队部署代码的频率。

（2）稳定性

• 恢复服务的时间：当服务发生服务事故（例如计划外中断、服务损害）时，恢复服务通常需要多长时间。
• 变更失败率：他们对主要应用程序或服务做出的变更有多少（百分比）会导致服务降级或随后需要进行修复（例如导致服务受损或中断，需要修补程序、回滚或补丁）。

以这两个指南为指导，可根据团队实际的情况制定合适的考核指标。

工欲善其事必先利其器，要想将绩效管理切实地执行到实处，可以借助一款高效的研发管理工具更好地对项目的全流程、开发团队人员的绩效进行管理。

参考资料：《Measuring Tech Performance：You’re Probably Doing It Wrong》

本文由 @ONES 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。