如何量化考核技術人的KPI？

對技術人來說，技術是成長的“核心”。然而，在實際工作協作中，技術的重要性常常被業務所掩蓋，造成先業務後技術的現象。

針對這個痛點，阿裡進階技術專家張建飛提出了自己的解決思路，希望能與大家一起探讨交流。

一、為什麼需要技術KPI？

在業務技術團隊，有一個不好的趨勢就是團隊越來越業務，越來越沒有技術味道。每個人都在談業務，技術大會上在談業務，周會上在聊業務，周報裡寫的是業務項目......

唯獨少被談及的是技術本身。此處并不是說業務不重要，而是說了解業務和把控業務需求是技術人員的Base，而不是全部。

1、将就的代價

這種技術味道的缺失對技術團隊來說是非常可惜的，也不利于技術人員的成長和發展。因為很難想象一個沒有技術追求的團隊能開發出一個健壯的、可維護性好、可擴充性好的系統。相反，這種業務代碼的堆砌，從短期看也許是“較快”實作了業務需求，但是從長遠來看，這種爛系統的增加會極大阻礙業務的發展，形成一個個的黑洞應用，而工程師被裹挾在業務需求和爛系統之間，疲于應對，心力交瘁。

這種将就将導緻系統腐化，技術債越壘越高，像惡性良性腫瘤一樣消耗你所有的能量。

我不是藥神，隻能嘗試開出一方——那就是在不影響業務的情況下（特别是相對穩定的業務，請拒絕業務方的時間倒排），Tech Story應該和User Story有同等的重要性，要把重構優化提到和業務需求相等的優先級去處理。我們不僅要對業務需求負責，我們更要對應用的品質，系統的可維護性負責。

因為我們技術人員是應用的父母（有些是親生父母，有些是養父母），你不照顧它們，不治理它們，它們就會生病，你忍心看到這樣的局面嗎？

2、技術管理者（TL）的失職

造成這種局面，我們的技術管理者，我們的TL要負有主要責任。如果一個TL從來不關注系統架構和設計，從來不寫Code，對技術沒有熱情也不學習，甚至其本身技術就很爛，那麼在這個TL上司下的技術團隊，又怎麼會有技術味道，團隊成員又怎麼能進步和成長？

現在很多的TL每天都混迹在各種會議上，很忙，做着各種溝通協調的事情，可是我們真的需要這麼多的會議、這麼多的溝通嗎？

如果溝通的結果隻是做業務和PD對團隊的傳話筒，沒有業務創新，沒有用技術和資料系統化的解決業務問題，沒有在技術方向和架構上給團隊指引，沒能切實的幫助系統優化、團隊提效，請問這樣的溝通給業務帶來了什麼價值，給團隊帶來了什麼價值？還是沉下心來，多看看書，哪怕非技術的書也好。多寫寫代碼，哪怕跟業務無關的代碼也好。

是以，我們要回歸技術本身。我們不需要這麼多“高高在上”、“指點江山”的技術Manager，而是需要能真正深入到系統裡面，深入到代碼細節，給團隊帶來實實在在改變的技術Leader。

二、技術KPI的量化

提升技術氛圍，打造工程師文化不能僅停留在口頭上，可搭配一定的強制手段，比如和技術人員的利益綁定。這種綁定就需要我們能對技術貢獻進行一個相對公平的分解和量化。

1、技術KPI

基于此，我将技術人員的KPI分解為業務貢獻、技術貢獻和團隊貢獻三個大的部分，其詳細内容如下：

 ●  業務貢獻：包括需求把控、業務項目和業務創新。

 ●  技術貢獻：包括設計重構、技術影響力、Code Review、創新提效和代碼品質。

 ●  團隊貢獻：包括招聘、新人培養和團隊氛圍。

那麼技術貢獻中的這幾個次元要怎麼了解呢，用我們工作中的一些案例來描述一下吧。

應用品質：

 ●  你負責或者共同負責的應用品質分（可以從代碼重複率，圈複雜度，分層合理性等次元考察）。

 ●  你做了哪些提升應用品質分的工作。

設計重構：

 ●  我在客戶通項目中，對CRM銷售域進行了領域模組化和設計，并且抽象合理。

 ●  我發現Infrastructure中Package分類不合理，進行了重新設計并重構完成。

 ●  我發現現在系統中錯誤碼比較混亂，我梳理制定了新的錯誤碼規範，并完成了代碼重構。

技術影響力：

 ●  在團隊内分享10篇幹貨，點贊數1000。

 ●  團隊分享政策模式，得到同學好評 。

 ●  我接受邀請，在行業會議上分享了SOFA架構。

Code Review：

 ●  我在Review某某代碼的時候發現，可能存線上程不安全的隐患。

 ●  我在Review某某代碼的時候發現，存在設計不合理的現象，此處使用責任鍊可以很優雅地解決問題，并具備一定的擴充性。

創新提效：

 ●  我發現本地測試啟動PandoraBoot比較浪費時間，是以寫了一個TestContainer大大提升了自測效率。

 ●  我發現有一些Boilerplate代碼不需要寫，是以對樂觀鎖、分頁進行了Annotation支援，簡化了代碼。

 ●  在某個項目或者技術點上面，我産出了一篇專利：基于領域模型的業務配置化。

代碼品質：

 ●  提測後的Bug數，線上故障數（系統可以提取，不用自己填寫）。

 ●  我完善了某某子產品的單元測試，并多次在自動化回歸中發現問題。

2、KPI答疑

對于上面的KPI大部分的技術同學是表示認可的，當然質疑的聲音也很多，我這裡挑一些典型的回答一下。

Q1：技術KPI的提出，會不會導緻技術同學隻關注技術不做業務項目了？

A1：關于績效，肯定是綜合看業務貢獻，技術貢獻和團隊貢獻。但是作為一個重要參考和風向标，技術KPI是有積極意義的。

Q2： 您說的設計重構怎麼量化？

A2： 這個很難用系統标準化，更多的還是要依賴TL的專業能力進行評分，但即使是這樣，也比以前什麼都沒有，完全黑盒要強。至少在傳達一個資訊，我們鼓勵好的設計，鼓勵不斷地重構優化。

Q3：我們現在的業務需求已經在堆積，一線同學根本沒有時間去做重構優化。

A3：這個問題開篇其實已經說過了，你是要不斷地裹挾在業務需求和爛代碼裡面呢，還是花時間Improve，然後更快地支援業務。這個權衡應該不難做，關鍵是要看決心和能力。對于很多業務，我沒有看到推遲幾天上線就會影響業務格局的業務場景，是以作為技術團隊，我們就應該在User Story之外，加上我們的Technical Story，把完成業務需求和系統重構都當成我們的核心任務。

原文釋出時間為：2018-11-15

本文作者：張建飛

本文來自雲栖社群合作夥伴“

DBAplus社群

”，了解相關資訊可以關注“

”。