技術人本身的KPI

爲何須要技術KPI
在業務技術團隊，有一個很差的趨勢，就是團隊愈來愈業務，愈來愈沒有技術味道。每一個人都在談業務，技術大會上在談業務，週會上在聊業務，週報裏寫的是業務項目......
惟獨少被談及的是技術自己。此處並非說業務不重要，而是說理解業務和把控業務需求是技術人員的base，而不是所有。

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

這種將就將致使系統腐化墮落，技術債越壘越高，醜陋的代碼瘋狂助長，像腫瘤同樣消耗你全部的能量。就像Robert C. Martin說的「無論大家有多敬業，加多少班，在面對爛系統時，你任然會步履維艱，由於你大部分的精力不是在開發需求，仍是在應對混亂。」

做爲技術人員，咱們不能忘記咱們技術人的首要技術使命是治理軟件複雜度。

技術Leader的失職
形成這種局面，咱們的技術管理者，咱們的TL要負有主要責任。說的重一點，是工做上的失職，這種失職主要體如今兩個方面，一個是技術不做爲，另外一個是業務不思考。

技術不做爲
如今不少的技術同窗，一旦晉升到TL崗位，就開始脫離技術工做，儼然一副道法天然的模樣。試想一下，若是一個TL歷來不關注技術，歷來不寫code，對技術沒有熱情也不學習，甚至其自己技術就很爛，那麼又怎麼能期望在此TL領導下的團隊能有技術味道呢？！

因此當阿里技術副總裁玄難提出要看P8的代碼開發量（此處應該給玄難的務實點個贊）的時候，雖然很簡單粗暴，但某種程度上的確能夠反應出不少TL脫離技術工做的現實。也是在明確傳達一個信號——即咱們要回歸技術自己，由於咱們不須要這麼多「高高在上」，「指點江山」的技術Manager，而是須要能真正深刻到系統裏面，深刻到代碼細節，給團隊帶來實實在在改變的技術Leader。

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

不是說溝通不重要，只是咱們如今的會議太多了，就我我的的經驗來講，不少的會議都是低效無心義的。因此TL須要更多的獨立思考，而不是人云亦云。

雷軍說過：「永遠不要試圖用戰術上的勤奮，去掩蓋你戰略上的懶惰。」，這句話用在形容大部分的PD（產品經理）是再貼切不過了，因此，我寧願PD們「無爲」，總比處處亂抓，搞出不少無價值的產品要好。由於不少系統上的複雜性都是由於這些亂七八糟無心義的需求形成的。

因此給PD同窗的意見是，請必定要深刻理解業務，必定要深度思考，不要退化成一個PPT Designer和業務需求的傳話筒，不要只停留在寫PRD、畫Demo，要用系統化的思惟來規劃產品、來解決業務問題，從而贏得技術人員的尊重。

技術人員的疲於奔命，內因上是因爲上面分析的團隊技術味道的缺失，外因上主要是PD的亂做爲。

因此咱們的TL也必需要深刻思考業務，嚴格把控PD YY出來的「客戶需求」，把這些僞需求，無價值需求擋在門外，防止它們侵佔團隊原本就頗有限的技術資源。從而，纔有更多的精力投入到系統優化和複雜度治理上去。

技術KPI的量化
玄難說：「人的本性都是自私的，趨利的」，因此提高技術氛圍，打造工程師文化不能僅停留在口頭上，須要必定的強制手段，好比和技術人員的利益進行綁定，這種綁定就須要咱們能對技術貢獻進行一個相對公平的分解和量化。作過晉升評委的同窗應該都知道，今年在同窗的Profile裏面多了一個ATA文章的參考，這也是對技術影響力量化的一種嘗試。

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

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

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

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

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

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

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

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

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

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

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

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

做者簡介：張建飛，阿里巴巴高級技術專家，2007年雲南大學計算機應用工程碩士，12年軟件設計和應用架構經驗。熱衷於複雜業務分析和代碼複雜度治理，在外企工做6年，阿里工做5年。