如何對開發團隊的人員進行績效管理?2個簡單的原則

提到績效管理,很多人可能會想到 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 可以保持專注度和靈活度之間的平衡。

 

三、績效考覈

雖然在開發方面的考覈指標不存在銀彈,但是依然有一些可遵循的指南供參考。

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

1. 使用專注於結果而不是產出的衡量指標。

2. 使用針對全局或整個團隊成果而不是局部或個人成果而進行優化的衡量指標。

兩個反面案例

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

(1)代碼行數

如果1000 行代和10 行代碼都能解決同一個問題,我們當然喜歡後者。獎勵開發人員編寫額外的代碼只會讓軟件變得更加臃腫,這會帶來更高的維護成本和變更成本。那麼另一個極端呢?最小化代碼行數也不行。雖然有時候可以用一行代碼來完成一個任務,但這樣的代碼別人不好理解,所以很難維護。

將代碼行數作爲生產力衡量指標違反了第一點指導原則,因爲這樣關注的是產出而非成果。它只衡量了人們做了什麼(代碼行數),但通常忽略了真正的目標。

(2)速度

使用速度作爲生產力衡量指標有幾個不足。首先,速度是一種依賴於團隊的度量,具有相對性。團隊通常具有不同的背景,所以在團隊間進行速度比較並不合適。其次,當速度被用作生產力衡量標準時,團隊很可能會做出一些與事實不符的事情,他們會誇大他們的估算,並想盡可能多地完成自己的任務,疏於與其他團隊合作。

將速度作爲生產力衡量指標違反了第二點指導原則,因爲它更關注局部指標而非全局指標。爲了優化自己的速度,團隊通常不會與其他團隊合作。這通常會導致組織採用次優的解決方案,因爲他們沒有關注全局指標。

如何應用

如何應用這兩個指南,也給出了一些參考。《Accelerate》一書把軟件開發和交付方面使用的度量叫作軟件交付績效。它可以分爲兩個類別,每個類別包含兩項指標:

(1)節奏

  • 交付週期:從提交代碼到代碼在生產環境中成功運行所需的時間。
  • 部署頻率:團隊部署代碼的頻率。

(2)穩定性

  • 恢復服務的時間:當服務發生服務事故(例如計劃外中斷、服務損害)時,恢復服務通常需要多長時間。
  • 變更失敗率:他們對主要應用程序或服務做出的變更有多少(百分比)會導致服務降級或隨後需要進行修復(例如導致服務受損或中斷,需要修補程序、回滾或補丁)。

以這兩個指南爲指導,可根據團隊實際的情況制定合適的考覈指標。

工欲善其事必先利其器,要想將績效管理切實地執行到實處,可以藉助一款高效的研發管理工具更好地對項目的全流程、開發團隊人員的績效進行管理。

 

參考資料:Measuring Tech Performance: You’re Probably Doing It Wrong

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章