技術KPI的量化

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

技術KPI

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

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

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

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

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

應用品質：

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

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

設計重構：

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

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

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

技術影響力：

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

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

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

Code Review：

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

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

創新提效：

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

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

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

代碼品質：

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

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

KPI答疑

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

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

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

Q： 你這個設計重構怎麼量化？

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

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

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