提公升技術氛圍，打造工程師文化不能僅停留在口頭上，可搭配一定的強制手段，比如和技術人員的利益繫結。這種繫結就需要我們能對技術貢獻進行乙個相對公平的分解和量化。
技術kpi
基於此，我將技術人員的kpi分解為業務貢獻、技術貢獻和團隊貢獻三個大的部分，其詳細內容如下。
業務貢獻：包括需求把控，業務專案和業務創新。
技術貢獻：包括設計重構、技術影響力、code review、創新提效和**質量。
團隊貢獻：包括招聘、新人培養和團隊氛圍。
那麼技術貢獻中的這幾個維度要怎麼理解呢，解釋的話我就不多說了，用我們工作中的一些案例來描述一下吧。
應用質量：
你負責或者共同負責的應用質量分（可以從**重複率，圈複雜度，分層合理性等維度考察）。
你做了哪些提公升應用質量分的工作。
設計重構：
我在客戶通專案中，對crm銷售域進行了領域建模和設計，並且抽象合理。
我發現infrastructure中package分類不合理，進行了重新設計並重構完成。
我發現現在系統中錯誤碼比較混亂，我梳理制定了新的錯誤碼規範，並完成了**重構。
技術影響力：
團隊分享策略模式，得到同學好評 。
我接受邀請，在行業會議上分享了sofa架構。
code review：
我在review某某**的時候發現，存在設計不合理的現象，此處使用責任鏈可以很優雅的解決問題，並具備一定的擴充套件性。
創新提效：
我發現本地測試啟動pandoraboot比較浪費時間，所以寫了乙個testcontainer大大提公升了自測效率。
我發現有一些boilerplate**不需要寫，所以對樂觀鎖、分頁進行了annotation支援，簡化了**。
在某個專案或者技術點上面，我產出了一篇專利：基於領域模型的業務配置化。
**質量：
提測後的bug數，線上故障數（系統可以提取，不用自己填寫）
我完善了某某模組的單元測試，並多次在自動化回歸中發現問題。
kpi答疑
對於上面的kpi大部分的技術同學是表示認可的，當然質疑的聲音也很多，我這裡挑一些典型的回答一下。
q：技術kpi的提出，會不會導致技術同學只關注技術不做業務專案了？
q： 你這個設計重構怎麼量化？
a： 這個很難用系統標準化，更多的還是要依賴tl的專業能力進行評分，但即使是這樣，也比以前什麼都沒有完全黑盒要強。至少在傳達乙個資訊，我們鼓勵好的設計，鼓勵不斷地重構優化。
q：我們現在的業務需求已經在堆積，一線同學根本沒有時間去做重構優化。
a：這個問題開篇其實已經說過了，你是要不斷地裹挾在業務需求和爛**裡面呢，還是花時間improve，然後更快地支援業務。這個權衡應該不難做，關鍵是要看決心和能力。對於很多業務，我沒有看到推遲幾天上線就會影響業務格局的業務場景，所以作為技術團隊，我們就應該在user story之外，加上我們的technical story，把完成業務需求和系統重構都當成我們的核心任務。
如何量化考核技術人的 KPI？
如何量化考核技術人的 kpi？原創 張建飛 阿里技術今天 針對這個痛點，阿里高階技術專家張建飛提出了自己的解決思路，希望能與大家一起 交流。為什麼需要技術kpi？在業務技術團隊，有乙個不好的趨勢就是團隊越來越業務，越來越沒有技術味道。每個人都在談業務，技術大會上在談業務，周會上在聊業務，週報裡寫的是...
為什麼需要技術KPI？
在業務技術團隊，有乙個不好的趨勢就是團隊越來越業務，越來越沒有技術味道。每個人都在談業務，技術大會上在談業務，周會上在聊業務，週報裡寫的是業務專案.唯獨少被談及的是技術本身。此處並不是說業務不重要，而是說理解業務和把控業務需求是技術人員的base，而不是全部。將就的代價 這種技術味道的缺失對技術團隊...
專案管理 之技術KPI
提公升技術氛圍，打造工程師文化不能僅停留在口頭上，可搭配一定的強制手段，比如和技術人員的利益繫結。這種繫結就需要我們能對技術貢獻進行乙個相對公平的分解和量化。技術kpi 基於此，我將技術人員的kpi分解為業務貢獻 技術貢獻和團隊貢獻三個大的部分，其詳細內容如下。那麼技術貢獻中的這幾個維度要怎麼理解呢...