[[245539]]

謝 朱峰 提供靈感來源 。 感謝霍老爺為所有場景寫代碼，寫得不好請找他。

吐槽了HR

我們繼續討論技術人員的KPI應該怎么設。

阿里技術有一篇文章《如何量化考核技術人的KPI》，作者是張建飛，他認為技術人員的KPI可以分解為“三個貢獻”：業務貢獻、技術貢獻和團隊貢獻：

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

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

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

重點拆解了第二個“技術貢獻”，作者用工作中的一些案例來描述：

1、應用質量：

負責或者共同負責的應用質量分（可以從代碼重復率，圈復雜度，分層合理性等維度考察），技術人員做了哪些提升應用質量分的工作。

2、設計重構：

技術人員在客戶通項目中，對CRM銷售域進行了領域建模和設計，并且抽象合理；

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

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

3、技術影響力：

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

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

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

4、Code Review：

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

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

5、創新提效：

發現本地測試啟動Pandora Boot比較浪費時間，所以寫了一個Test Container大大提升了自測效率。

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

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

6、代碼質量：

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

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

接下來給大家分享一組拉勾的圖，作者是比格（大數據工程師）制作的技術KPI、

比格認為，雖然技術人員更希望自由的環境，但是對創業團隊來說，如果大家都不按規范，那這個公司的技術團隊就是一盤散沙。

技術人員到底應該用什么KPI？

基于前面阿里技術文章的評論，作者Ming認為：

KPI是活動的，在不同的階段KPI應該是有側重點的。

1、創業階段，KPI應盡可能的往業務傾斜，當生存都是問題的時候談技術理想根本就是烏托邦。

2、當收入逐漸穩定下來后，則應盡量往技術傾斜，這個時候談健壯性才有條件。當整體都已經走上正軌了，系統健壯性也足夠強的時候，則是持續保持一個6/4（業務/技術）的比例會比較恰當，當然這個也要根據每家企業的現實狀況來靈活調控。

這也就對TL自身的業務、技術、市場提出一個多維度的考核標準，純粹的技術或者純粹的業務都是不可取的，畢竟大家待的都是商業機構，商業利潤才是***位的，其他的都要圍繞這個，技術優化也是為商業利潤服務的。

所以，竊以為撇開技術談業務或者撇開業務談技術都是一種烏托邦式的思考。