如何對開發團隊的人員進行績效管理?
提到績效管理,很多人可能會想到 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. 兩個反面案例
先舉兩個反面的例子來說明這兩點指南:
(1)代碼行數
如果1000 行代和10 行代碼都能解決同一個問題,我們當然喜歡后者。
獎勵開發人員編寫額外的代碼只會讓軟件變得更加臃腫,這會帶來更高的維護成本和變更成本。
那么另一個極端呢?最小化代碼行數也不行。雖然有時候可以用一行代碼來完成一個任務,但這樣的代碼別人不好理解,所以很難維護。
將代碼行數作為生產力衡量指標違反了第一點指導原則,因為這樣關注的是產出而非成果。它只衡量了人們做了什么(代碼行數),但通常忽略了真正的目標。
(2)速度
使用速度作為生產力衡量指標有幾個不足。
首先,速度是一種依賴于團隊的度量,具有相對性。團隊通常具有不同的背景,所以在團隊間進行速度比較并不合適。
其次,當速度被用作生產力衡量標準時,團隊很可能會做出一些與事實不符的事情,他們會夸大他們的估算,并想盡可能多地完成自己的任務,疏于與其他團隊合作。
將速度作為生產力衡量指標違反了第二點指導原則,因為它更關注局部指標而非全局指標。為了優化自己的速度,團隊通常不會與其他團隊合作。這通常會導致組織采用次優的解決方案,因為他們沒有關注全局指標。
2. 如何應用
如何應用這兩個指南,也給出了一些參考?!禔ccelerate》一書把軟件開發和交付方面使用的度量叫作軟件交付績效。
它可以分為兩個類別,每個類別包含兩項指標:
(1)節奏
- 交付周期:從提交代碼到代碼在生產環境中成功運行所需的時間。
- 部署頻率:團隊部署代碼的頻率。
(2)穩定性
- 恢復服務的時間:當服務發生服務事故(例如計劃外中斷、服務損害)時,恢復服務通常需要多長時間。
- 變更失敗率:他們對主要應用程序或服務做出的變更有多少(百分比)會導致服務降級或隨后需要進行修復(例如導致服務受損或中斷,需要修補程序、回滾或補?。?。
以這兩個指南為指導,可根據團隊實際的情況制定合適的考核指標。
工欲善其事必先利其器,要想將績效管理切實地執行到實處,可以借助一款高效的研發管理工具更好地對項目的全流程、開發團隊人員的績效進行管理。
參考資料:《Measuring Tech Performance:You’re Probably Doing It Wrong》
本文由 @ONES 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
寫的不錯的一篇文章