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

對技術人來講，技術是成長的「核心」。然而，在實際工做協做中，技術的重要性經常被業務所掩蓋，形成先業務後技術的現象。

針對這個痛點，阿里高級技術專家張建飛提出了本身的解決思路，但願能與你們一塊兒探討交流。

1、爲何須要技術KPI？

 

在業務技術團隊，有一個很差的趨勢就是團隊愈來愈業務，愈來愈沒有技術味道。每一個人都在談業務，技術大會上在談業務，週會上在聊業務，週報裏寫的是業務項目......

 

惟獨少被談及的是技術自己。此處並非說業務不重要，而是說理解業務和把控業務需求是技術人員的Base，而不是所有。

 

一、將就的代價  

 

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

 

這種將就將致使系統腐化，技術債越壘越高，像腫瘤同樣消耗你全部的能量。

 

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

 

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

 

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

 

形成這種局面，咱們的技術管理者，咱們的TL要負有主要責任。若是一個TL歷來不關注系統架構和設計，歷來不寫Code，對技術沒有熱情也不學習，甚至其自己技術就很爛，那麼在這個TL領導下的技術團隊，又怎麼會有技術味道，團隊成員又怎麼能進步和成長？

 

如今不少的TL天天都混跡在各類會議上，很忙，作着各類溝通協調的事情，但是咱們真的須要這麼多的會議、這麼多的溝通嗎？

 

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

 

因此，咱們要回歸技術自己。咱們不須要這麼多「高高在上」、「指點江山」的技術Manager，而是須要能真正深刻到系統裏面，深刻到代碼細節，給團隊帶來實實在在改變的技術Leader。

 

 

2、技術KPI的量化

 

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

 

一、技術KPI  

 

基於此，我將技術人員的KPI分解爲業務貢獻、技術貢獻和團隊貢獻三個大的部分，其詳細內容以下：

 

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

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

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

 

那麼技術貢獻中的這幾個維度要怎麼理解呢，用咱們工做中的一些案例來描述一下吧。

 

應用質量：

 

• 你負責或者共同負責的應用質量分（能夠從代碼重複率，圈複雜度，分層合理性等維度考察）。

• 你作了哪些提高應用質量分的工做。

 

設計重構：

 

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

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

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

 

技術影響力：

 

• 在團隊內分享10篇乾貨，點贊數1000。

• 團隊分享策略模式，獲得同窗好評 。

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

 

Code Review：

 

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

• 我在Review某某代碼的時候發現，存在設計不合理的現象，此處使用責任鏈能夠很優雅地解決問題，並具有必定的擴展性。

 

創新提效：

 

• 我發現本地測試啓動PandoraBoot比較浪費時間，因此寫了一個TestContainer大大提高了自測效率。

• 我發現有一些Boilerplate代碼不須要寫，因此對樂觀鎖、分頁進行了Annotation支持，簡化了代碼。

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

 

代碼質量：

 

• 提測後的Bug數，線上故障數（系統能夠提取，不用本身填寫）。 

• 我完善了某某模塊的單元測試，並屢次在自動化迴歸中發現問題。

 

二、KPI答疑  

 

對於上面的KPI大部分的技術同窗是表示承認的，固然質疑的聲音也不少，我這裏挑一些典型的回答一下。

 

Q1：技術KPI的提出，會不會致使技術同窗只關注技術不作業務項目了？ 

A1：關於績效，確定是綜合看業務貢獻，技術貢獻和團隊貢獻。可是做爲一個重要參考和風向標，技術KPI是有積極意義的。

 

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

A2： 這個很難用系統標準化，更多的仍是要依賴TL的專業能力進行評分，但即便是這樣，也比之前什麼都沒有，徹底黑盒要強。至少在傳達一個信息，咱們鼓勵好的設計，鼓勵不斷地重構優化。

 

Q3：咱們如今的業務需求已經在堆積，一線同窗根本沒有時間去作重構優化。

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