如何对开发团队的人员进行绩效管理？

关注

发布于: 5 小时前

「绩效管理」是一个持续不断的业务管理循环过程，所覆盖的内容有很多，包含制定绩效目标，设置绩效计划，制定相应的制度引导员工朝着正确的目标发展、对实现绩效目标的过程进行监控（过程管理）。需要强调的是，绩效管理的最终目标不是 KPI 考核，而是激发团队潜力，提升团队效能。那么管理者应如何对开发团队的人员进行绩效管理呢？

1. 制定整体策略

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

2. 目标和 OKR

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

一方面，OKR 中的 O 可以使团队在一段时间内保持专注；另一方面，KRs 又为目标如何实现提供了灵活度。O 是团队一段时间内的目标，成员个人的安排都应该是为了达到这个目标而设置的，这样使团队所有成员目标一致；KR 可以由成员自己设定，调动了员工的积极性。总体来说，OKR 可以保持专注度和灵活度之间的平衡。

3. 考核指标

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

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

1. 使用专注于结果而不是产出的衡量指标。

2. 使用针对全局或整个团队成果而不是局部或个人成果而进行优化的衡量指标。

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

代码行数。如果 1000 行代和 10 行代码都能解决同一个问题，我们当然喜欢后者。奖励开发人员编写额外的代码只会让软件变得更加臃肿，这会带来更高的维护成本和变更成本。那么另一个极端呢？最小化代码行数也不行。虽然有时候可以用一行代码来完成一个任务，但这样的代码别人不好理解，所以很难维护。

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

速度。使用速度作为生产力衡量指标有几个不足。首先，速度是一种依赖于团队的度量，具有相对性。团队通常具有不同的背景，所以在团队间进行速度比较并不合适。其次，当速度被用作生产力衡量标准时，团队很可能会做出一些与事实不符的事情，他们会夸大他们的估算，并想尽可能多地完成自己的任务，疏于与其他团队合作。

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

如何应用这两个指南，也给出了一些参考。《Accelerate》一书把软件开发和交付方面使用的度量叫作软件交付绩效。它可以分为两个类别，每个类别包含两项指标：

节奏：

交付周期：从提交代码到代码在生产环境中成功运行所需的时间。

部署频率：团队部署代码的频率。

稳定性：

恢复服务的时间：当服务发生服务事故（例如计划外中断、服务损害）时，恢复服务通常需要多长时间。

变更失败率：他们对主要应用程序或服务做出的变更有多少（百分比）会导致服务降级或随后需要进行修复（例如导致服务受损或中断，需要修补程序、回滚或补丁）。

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

4. 绩效及效能管理工具

研发数据统计的统一性、客观性和权威性直接影响了绩效与效能度量的有效性，因此，研发团队需要借助一站式的研发管理工具，以避免数据分散导致的度量标准不统一、度量成本高等问题。ONES Performance 研发效能管理，打通 ONES Project 项目管理过程中的研发与工程数据，提供项目全周期的度量报表，有效解决团队绩效及效能度量痛点问题。此外，ONES 还提供了缺陷分析报表、工时统计报表等多维度数据，辅助管理者分析项目及团队成员的工作质量及效率情况。