今天的文章是我個人對過去6,7年技術管理經驗的一個簡單總結，每一個點都經過我的實踐，並試圖找到一些可供參考的方法，特別感謝過去幫助我的朋友和前輩們，文中提到很多方法也來源於他們。
技術管理的不安全感
技術管理的一大特點就是必須要深入到技術細節中去，在我剛做技術經理時，那時候團隊還在10人的規模，團隊成員用的框架或者工具都是我親自搭起來的，而且我還有時間親自上陣寫代碼，所以，細到項目中每一行代碼，我都能清楚的瞭解，每個組裏同事每天完成的工作我都可以做到親自過問一遍，細節把控自然不在話下。
然後當團隊擴大後，我需要投入更多精力到全局上，需要花更多的時間做好對內對外的溝通上，和產品及業務方對產品進行更深入的研究，還需要花更多時間在招人上面，我逐步發現我已經不能像過去一樣，把細節掌握得那麼清楚了。
此刻，在我內心裏產生了明顯的不安全感：
團隊在好的方向發展，還是往壞的方向倒退？
大家的代碼質量怎麼樣？
系統穩定性怎麼樣？
大家的工作效率怎麼樣？
可以使用的抓手
對技術團隊而言，涉及到我們日常的研發流程，可以簡單歸納爲：工程效率和工程質量。說到這兩點，我一直認爲這絕非簡單是開發工程師或者測試同學的事，而是整個技術團隊共同要爲之努力的事情。
接下來講講這兩件事，分別有哪一些抓手：
工程效率的抓手
對於技術管理者，需要帶領團隊對當前的各個項目進行有效的拆分，並明確對應的里程碑，給出合理的排期。
對項目進行分析：
若有延期，需要有充分的理由
若有失誤，需要有詳盡的覆盤
若有臨時性需求，需要扛得住壓力
其次，關注工程效率的指標
按時交付的比例，分析每個月發佈的項目中的交付率。
處理線上bug的時效，是否能及時修復
響應緊急需求的時間，能否快速實施
最後，團隊自動化的應用比例，是否建立起有效的自動化測試+發佈+報警體系
工程質量的抓手
1. 建立業務指標
服務的穩定性、延時等等指標需要有統一的標準。例如：支付成功率、下單成功率等等
例如，對於每天對外暴露的API調用情況，需要有單獨的報表統計，如果發現問題，需要及時響應和處理。
2. 控制故障數量
每週和每月統計故障數量，每個故障都有詳細的總結和回顧。故障密集出現的服務凸現出來服務質量有問題。
3. 關注代碼質量
每次提測後發現的bug數量，包含bug的分佈和等級，更快速反饋團隊每位同事的代碼質量，控制bug的發生趨勢。
梯隊建設的抓手
人才培養是技術管理中一大難點
首先，改變要一個人本身就非常困難，所以從面試環節，就需要挑選願意改變自己的同學
其次，培養的週期特別長，很有可能半年纔會看到效果
最後，每個人的個性不一樣，欠缺的點各不相同，由此需要增強的地方也不相同。
由此，人才培養的抓手需要從以下地方入手：
定期覆盤：定期覆盤的習慣是個人快速成長的必由之路。可以通過『週報的個人反思』作爲着手點，讓團隊養成定期覆盤自己的工作的習慣
技術輸出：讓團隊中的優秀成員將項目中的經驗和好的實踐記錄下來，達到融會貫通的效果，建立團隊的技術影響力，例如高質量的wiki + 定期的技術分享也是抓手。
新人培養計劃：對於新人，培養計劃是很好的加快融入以及嚴格考覈的工具。
人才培養成本極高，絕對不要期望一下子將團隊中的每個人都向上拉一層，需要先篩選出一小部分有潛力的成員來重點培養，努力將他們變成團隊中的中堅力量，形成人才梯隊。具體的做法如下：
定期1V1的聊天，解答困惑，指出他們的不足，給他們更有效的工作方法。
不斷分配有挑戰的工作，加速成長，讓團隊充滿飢餓感。
最後
技術管理就是帶着大家將項目通過技術落地，並拿結果。而管理的兩個着眼點就是：成事、育人。把事情搞定，把人培養起來，團隊就帶起來了。
描二維碼或手動搜索微信公衆號【架構棧】：ForestNotes
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【架構棧】近期的架構文章彙總
↓↓↓