提到績效管理，很多人可能會想到 OKR、KPI、360考核等等，但是績效管理和績效考核是一回事嗎？OKR 真的適合用來做績效考核嗎？又應(yīng)該如何對開發(fā)團(tuán)隊的人員進(jìn)行績效管理？基于以上問題，分享一些方法。

先回答前兩個問題，績效管理不等于績效考核，OKR 也不是用來考核的衡量標(biāo)準(zhǔn)。

「績效管理」是一個持續(xù)不斷的業(yè)務(wù)管理循環(huán)過程，所覆蓋的內(nèi)容有很多，包含制定績效目標(biāo)，制定績效計劃，制定相應(yīng)的制度引導(dǎo)員工朝著正確的目標(biāo)發(fā)展、對實現(xiàn)目標(biāo)的過程進(jìn)行監(jiān)控等等，績效考核只是其中的一部分。

OKR 為什么不適合做為考核的衡量指標(biāo)，我們先從 KPI 講起。KPI 的制定是必須按照 SMART 原則制定的，要達(dá)到百分之多少是明確的，這樣就會導(dǎo)致兩個問題：

一是員工為了能達(dá)到 KPI 指定的目標(biāo)，會設(shè)定一個相對較低的目標(biāo)值；

另一個是，為了達(dá)到目標(biāo)，實際執(zhí)行手段可能與愿景相反，比如希望用戶更喜歡我們的產(chǎn)品，把 PV 寫進(jìn)了 KPI 里，但是為了達(dá)到這一目標(biāo)，把原來在一個頁面能完成的事情拆分到了幾個頁面上，這樣 KPI 達(dá)標(biāo)了，可是用戶的滿意度卻下降了。

之所以會出現(xiàn)以上兩種問題，原因就在于 KPI 是和考核、獎金掛鉤的。

而 OKR（目標(biāo)與關(guān)鍵成果法，代表Objectives和Key Results）是與績效考核分離的，它強(qiáng)調(diào)的是最終的關(guān)鍵結(jié)果必須服從目標(biāo)，是讓人更加聚焦目標(biāo)和重要的任務(wù)。

事實上，OKR 是用來做績效管理的工具，但絕對不是用來考核的衡量標(biāo)準(zhǔn)。

明確了以上兩個問題，沿著績效管理的過程給出一些參考。

一、制定整體策略

績效的管理的第一步，首先應(yīng)該明白整體的策略是怎樣的，這一般跟團(tuán)隊和公司的實際情況有關(guān)。

比如一個10人以下的小團(tuán)隊和一個100人以上的大團(tuán)隊，前者肯定是要尋求最直接有效的管理方式，而后者就需要更為復(fù)雜的、有體制的管理方式。又比如在一個公司創(chuàng)業(yè)階段和平穩(wěn)發(fā)展的階段，所實行的策略也應(yīng)該是有所不同的。

二、目標(biāo)和OKR

績效目標(biāo)的制定、引導(dǎo)和監(jiān)控，就不得不提 OKR 了。OKR 是一種簡便且強(qiáng)大的目標(biāo)管理方法，相對于 KPI 而言，可以幫助員工建立一個更清晰的目標(biāo)。

一方面，OKR 中的 O 可以使團(tuán)隊在一段時間內(nèi)保持專注；另一方面，KRs 又為目標(biāo)如何實現(xiàn)提供了靈活度。

O 是團(tuán)隊一段時間內(nèi)的目標(biāo)，成員個人的安排都應(yīng)該是為了達(dá)到這個目標(biāo)而設(shè)置的，這樣使團(tuán)隊所有成員目標(biāo)一致；KR 可以由成員自己設(shè)定，調(diào)動了員工的積極性。

總體來說，OKR 可以保持專注度和靈活度之間的平衡。

三、績效考核

對開發(fā)人員進(jìn)行績效考核是一件很頭疼的事情，顯然不能簡單的依據(jù)代碼行數(shù)、Bug 數(shù)來評估，根據(jù)不同的團(tuán)隊情況，這些指標(biāo)也不能是千篇一律的。

雖然在開發(fā)方面的考核指標(biāo)不存在銀彈，但是依然有一些可遵循的指南供參考。

在《Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations》一書中概述了兩個簡單的衡量指南：

1. 使用專注于結(jié)果而不是產(chǎn)出的衡量指標(biāo)；
2. 使用針對全局或整個團(tuán)隊成果而不是局部或個人成果而進(jìn)行優(yōu)化的衡量指標(biāo)。

1. 兩個反面案例

先舉兩個反面的例子來說明這兩點指南：

（1）代碼行數(shù)

如果1000 行代和10 行代碼都能解決同一個問題，我們當(dāng)然喜歡后者。

獎勵開發(fā)人員編寫額外的代碼只會讓軟件變得更加臃腫，這會帶來更高的維護(hù)成本和變更成本。

那么另一個極端呢？最小化代碼行數(shù)也不行。雖然有時候可以用一行代碼來完成一個任務(wù)，但這樣的代碼別人不好理解，所以很難維護(hù)。

將代碼行數(shù)作為生產(chǎn)力衡量指標(biāo)違反了第一點指導(dǎo)原則，因為這樣關(guān)注的是產(chǎn)出而非成果。它只衡量了人們做了什么（代碼行數(shù)），但通常忽略了真正的目標(biāo)。

（2）速度

使用速度作為生產(chǎn)力衡量指標(biāo)有幾個不足。

首先，速度是一種依賴于團(tuán)隊的度量，具有相對性。團(tuán)隊通常具有不同的背景，所以在團(tuán)隊間進(jìn)行速度比較并不合適。

其次，當(dāng)速度被用作生產(chǎn)力衡量標(biāo)準(zhǔn)時，團(tuán)隊很可能會做出一些與事實不符的事情，他們會夸大他們的估算，并想盡可能多地完成自己的任務(wù)，疏于與其他團(tuán)隊合作。

將速度作為生產(chǎn)力衡量指標(biāo)違反了第二點指導(dǎo)原則，因為它更關(guān)注局部指標(biāo)而非全局指標(biāo)。為了優(yōu)化自己的速度，團(tuán)隊通常不會與其他團(tuán)隊合作。這通常會導(dǎo)致組織采用次優(yōu)的解決方案，因為他們沒有關(guān)注全局指標(biāo)。

2. 如何應(yīng)用

如何應(yīng)用這兩個指南，也給出了一些參考。《Accelerate》一書把軟件開發(fā)和交付方面使用的度量叫作軟件交付績效。

它可以分為兩個類別，每個類別包含兩項指標(biāo)：

（1）節(jié)奏

• 交付周期：從提交代碼到代碼在生產(chǎn)環(huán)境中成功運行所需的時間。
• 部署頻率：團(tuán)隊部署代碼的頻率。

（2）穩(wěn)定性

• 恢復(fù)服務(wù)的時間：當(dāng)服務(wù)發(fā)生服務(wù)事故（例如計劃外中斷、服務(wù)損害）時，恢復(fù)服務(wù)通常需要多長時間。
• 變更失敗率：他們對主要應(yīng)用程序或服務(wù)做出的變更有多少（百分比）會導(dǎo)致服務(wù)降級或隨后需要進(jìn)行修復(fù)（例如導(dǎo)致服務(wù)受損或中斷，需要修補(bǔ)程序、回滾或補(bǔ)丁）。

以這兩個指南為指導(dǎo)，可根據(jù)團(tuán)隊實際的情況制定合適的考核指標(biāo)。

工欲善其事必先利其器，要想將績效管理切實地執(zhí)行到實處，可以借助一款高效的研發(fā)管理工具更好地對項目的全流程、開發(fā)團(tuán)隊人員的績效進(jìn)行管理。

參考資料：《Measuring Tech Performance：You’re Probably Doing It Wrong》

本文由 @ONES 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。