摘要:技術的量化提升技術氛圍,打造工程師文化不能僅停留在口頭上,可搭配一定的強制手段,比如和技術人員的利益綁定。但是作為一個重要參考和風向標,技術是有積極意義的。
為什么需要技術KPI?
在業務技術團隊,有一個不好的趨勢就是團隊越來越業務,越來越沒有技術味道。每個人都在談業務,技術大會上在談業務,周會上在聊業務,周報里寫的是業務項目......
唯獨少被談及的是技術本身。此處并不是說業務不重要,而是說理解業務和把控業務需求是技術人員的base,而不是全部。
將就的代價這種技術味道的缺失對技術團隊來說是非常可惜的,也不利于技術人員的成長和發展。因為很難想象一個沒有技術追求的團隊能開發出一個健壯的、可維護性好、可擴展性好的系統。相反,這種業務代碼的堆砌,從短期看也許是“較快”實現了業務需求,但是從長遠來看,這種爛系統的增加會極大的阻礙業務的發展,形成一個個的黑洞應用,而工程師被裹挾在業務需求和爛系統之間,疲于應對,心力交瘁。
這種將就將導致系統腐化,技術債越壘越高,像腫瘤一樣消耗你所有的能量。
我不是藥神,只能嘗試開出一方——那就是在不影響業務的情況下(特別是相對穩定的業務,請拒絕業務方的時間倒排),Tech Story應該和User Story有同等的重要性,要把重構優化提到和業務需求相等的優先級去處理。我們不僅要對業務需求負責,我們更要對應用的質量,系統的可維護性負責。
因為我們技術人員是應用的父母(有些是親生父母,有些是養父母),你不照顧它們,不治理它們,它們就會生病,你忍心看到這樣的局面嗎?
技術管理者者(TL)的失職造成這種局面,我們的技術管理者,我們的TL要負有主要責任。如果一個TL從來不關注系統架構和設計,從來不寫code,對技術沒有熱情也不學習,甚至其本身技術就很爛,那么在這個TL領導下的技術團隊,又怎么會有技術味道,團隊成員又怎么能進步和成長?
現在很多的TL每天都混跡在各種會議上,很忙,做著各種溝通協調的事情,可是我們真的需要這么多的會議、這么多的溝通嗎?
如果溝通的結果只是做業務和PD對團隊的傳話筒,沒有業務創新,沒有用技術和數據系統化的解決業務問題,沒有在技術方向和架構上給團隊指引,沒能切實的幫助系統優化、團隊提效,請問這樣的溝通給業務帶來了什么價值,給團隊帶來了什么價值?還是沉下心來,多看看書,哪怕非技術的書也好。多寫寫代碼,哪怕跟業務無關的代碼也好。
所以,我們要回歸技術本身。我們不需要這么多“高高在上”、“指點江山”的技術Manager,而是需要能真正深入到系統里面,深入到代碼細節,給團隊帶來實實在在改變的技術Leader。
技術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,把完成業務需求和系統重構都當成我們的核心任務。
本文作者:張建飛
閱讀原文
本文來自云棲社區合作伙伴“阿里技術”,如需轉載請聯系原作者。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/11913.html
摘要:但流程不是死的,尤其在互聯網公司,只要有助于我們的目標達成,那么流程只是一陣東風。工作中并不是所有事情都可以依賴流程去保證萬無一失。所以不要怪罪流程,這并不是流程的問題,而是人的問題。所以請不要再怪罪流程啦,以人為本,才是長久之計。 本文由作者周巧芬授權網易云社區發布。 筆者所在的團隊這段時間正在兩個版本的交接期,前一個版本馬上要上線了,但后一個版本的需求早在三周前就已經啟動,卻遲遲沒...
摘要:創業公司往往會發放限制性股票和期權。特別是像在深圳這樣房價越來越高的地方,許多同事也面臨著需要買房成家的問題,可能會需要提前支取他的股票期權收益。同時,給在工作了一段時間的員工提供了五十萬元的無息住房貸款,幫助一些同事在深圳安個家。 作者簡介:張海龍,CODING 創始人。復旦大學軟件工程學士,CMU計算機碩士,曾在 Oracle 任職高級軟件工程師。2010年回國創業,2014年創辦...
摘要:年月日,第屆技術管理工作坊將在深圳華僑城洲際酒店舉行。壹佰案例在開始前采訪了沈劍老師,先行劇透架構師轉型做管理的感悟。 showImg(https://segmentfault.com/img/bVxMfU);2016年6月25-26日,第27屆MPD技術管理工作坊將在深圳華僑城洲際酒店舉行。本次工作坊,我們邀請了58到家技術總監沈劍老師,分享《技術團隊的接手、搭建與發展實踐 》, 講...
摘要:大家好,我叫,江湖人稱吃土小叉,目前擔任公司的前端負責人半年多了,一路上摸爬滾打,歷經團隊人員變動,近日頗有感觸,于是結合自己近半年的前端負責人實踐經驗,權當作一個學習記錄,整理歸納一下小作坊團隊前端負責人的修煉要點大部分只是記錄了關鍵詞, 大家好,我叫XX,江湖人稱吃土小2叉,目前擔任公司的前端負責人半年多了,一路上摸爬滾打,歷經團隊人員變動,近日頗有感觸,于是結合自己近半年的前端負...
閱讀 1868·2021-11-22 09:34
閱讀 1141·2021-10-09 09:44
閱讀 3001·2021-09-29 09:35
閱讀 3617·2021-09-14 18:01
閱讀 1465·2021-08-16 10:49
閱讀 1084·2019-08-29 14:11
閱讀 849·2019-08-29 12:47
閱讀 3068·2019-08-26 13:47