如何对开发团队的人员进行绩效管理？(团队目标绩效管理衡量代码)

先回答前两个问题，绩效管理不等于绩效考核，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）代码行数

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

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

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

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

（2）速度

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

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

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

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

2. 如何应用

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

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

（1）节奏

（2）稳定性

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

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

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

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

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