在 IT 領域摸爬滾打多年，從一個普通程序員到技術主管，到技術經理，再到技術總監，踩過不少坑、加過不少班，也背過不少鍋。
圖片來自 Pexels
在提升自身技術能力與管理能力的同時，我也一直在思考，作為 IT 技術管理者，如何做才能讓我們在這個領域里發展得更好?
在年齡漸長時能從容應對所謂的“中年危機”，或者說 IT 技術管理者的自我修養，應從哪些方面去努力?
本文不是所謂成功人士的經驗之談，而是以一個有幾年經驗的技術管理者的角度做的一些思考與總結，希望能給有志于從事技術管理的同僚以參考，與之共勉。
因為文字寫的有點多，先貼一張思維導圖：
對“管理”的理解
管理，從字面上看包含兩層意思：“管”與“理”。管什么?理什么?怎么管?怎么理?可能把這四個問題弄清楚了，管理這個事也就沒那么難了。
首先，管什么?有些人可能認為管理就是管人，就是盯人干活，在我看來，管人不是管理的目的。
管理的本質應是協調一切可以協調的資源(人力、物力、財力)，努力達成團隊或組織的終極目標。
企業管理的終極目標無非就是成功——行業領先、可持續成長、受人尊重。技術團隊管理的終極目標，就是在服務于企業終極目標的同時，讓團隊有所成長——團隊成員在能力、收入、素養各方面得到進步。
那么為了達成這個目標，技術團隊需要管什么?我總結了以下四點：
- 管執行。就是要持續跟進確認你的決策(制度、流程、任務)是否被執行到位，是否在按正確的方向前進，是否存在問題，并及時撥亂反正，及時提供必要的協助——協助協調下屬協調不了的資源，協助解決他解決不了的問題。
- 管進度。就是要持續確認你的目標是否在一步一步按部就班地完成，是否存在風險，并及時做出必要的調整以應對各種風險。
- 管效果。就是要持續驗證各個階段的成果是否符合當初的預期，并及時制定措施彌補不符合預期的結果。
- 管成長。就是要持續為你的團隊營造一個良好的成長環境與空間，讓每一個人都能發揮自己的能力，并且得到有效的成長。
這里每一點都包含了一個詞——持續。不是把事情梳理完，分配完就可以撒手不管了，就可以“放羊”了。
而是應持續跟進，只有持續跟進，出現問題時，你才能及時發現，及時修正，才能確保最終達成目標。放牛班有春天，“放羊”班一般是沒有春天的。
其次，理什么?如果把“管”理解為實踐，那么“理”就是理論，只有實踐與理論相結合，才能做到有目標，有方法，有效果。
技術團隊需要理什么?我也總結了以下四點：
- 理目標。一般包括兩個層面，由上而下的業務目標，比如產品里程碑，項目階段驗收節點，以及由下而上的技術目標，如服務端重構、Web 頁面優化、架構升級、系統運行監控、用戶體驗的提升等。
- 理制度。為了實現或更高效地實現目標，需要通過哪些手段或環節，規定要做的活動，如例會制度、周(日)報制度、需求評審制度、設計審查制度、代碼審查制度等。
- 理規范。定義怎么來做，包括技術規范、流程規范兩個方面。技術規范規定對某些常見的場景，通過什么樣的方式來統一執行，如前后端對接的協議、異常的處理、日志的規范等。
流程規范對一些活動，指定了什么人在什么階段，應該做什么，怎么做，如轉測流程，要求開發人員在轉測時寫轉測文檔，提供轉測內容、影響因素等信息，測試人員測試完成后，提供測試結論，遺留哪些問題，是否同意上線等。
- 理問題。任何一個團隊都存在這樣那樣的問題，如果一個團隊沒有任何問題，那這本身就是一個問題。
要擅于去發現問題，并建立順暢的問題反饋渠道。同時對問題的處理，不應終止于解決，一般遵循“發現問題→分析問題→解決問題→復盤問題→規避問題”的流程形式。
管理，既要管，也要理，在管的過程中理，理清楚后再應用于管，管與理相輔相成，融為一體，形成管理。
管理是一個比較復雜的事情——只要與人打交道的就沒有簡單的事，既要注意方式方法，又要尊重人性。
比如人都有愛自由的天性，對任何管理與約束都有一種本能的對抗，但同時人也有懶惰的天性，“放牛班”有春天，“放羊”班幾乎不可能有春天。
因此在管理與約束的行為上就要做到既給一定的自由度，又要有相對的控制力，有所為有所不為，做到管控有度。
而這個“度”，可能就是所謂的管理藝術了吧。有人把管理比喻為放風箏，我覺得挺貼切的。
管理者是風箏的操縱者，團隊成員就是風箏，管理者應該給團隊成員一個像風箏一樣發揮主觀能動性的廣闊的空間，把風箏敢于放向蔚藍的天空。
但同時也能把控它的方向，并隨時可以把它收回來。管理能做到像放風箏一樣收放自如，那就是真正的藝術了。
上面梳理總結了管什么、理什么的問題。那么對于技術團隊的管理者來說，怎么管、怎么理，或者沿用上一文的口吻，技術管理者的自我修養，應從哪些方面去努力。
我從提升領導力，構建團隊文化，方法論三個角度進行了思考與總結。
領導力
領導力我的理解就是帶領他人朝著一個目標努力，組織協調最終一起達成目標的能力。
技術管理者如何提高領導力，我認為可以從以下四個方面努力：
技術能力
好的技術團隊管理者，一定是該技術領域的技術專家，具備較強的技術能力。
技術人員一般思想都相對單純，誰比他厲害就服誰，他不懂的你懂，他解決不了的問題你協助他解決了，自然就能提升你的影響力與威信，這對你的管理會帶來極大的幫助。
好的技術能力，不僅要有技術的深度，還要有技術的廣度。因為只有具有技術的深度，才能幫助下屬解決他解決不了的問題，才能在團隊遇到棘手問題時迎難而上，帶領團隊披荊斬棘。
只有具有技術的廣度，才能有效地制定團隊的技術方向，并且在下屬跟你說這個功能實現不了時，才能確認下屬是在忽悠你，還是真的實現不了。
業務能力
只有對業務具有較深的理解，才能更好地使用技術手段來服務于業務。一般我們做架構設計時，包括業務架構與技術架構，技術架構要以業務架構為參考，一切脫離業務的架構設計都是耍流氓。
一些中小企業的技術管理者，去參加了一次阿里云棲大會，回來就跟團隊鼓吹加人搞中臺，對于中小企業來說，很多業務仍處于探索階段，好多產品或項目可能在你中臺還沒搭建完就已經玩完了。
從技術的角度，思路可能是對的，但從業務的角度，沒有結合實際，沒有考慮成本，效率等因素。
不結合具體業務照搬別人的架構，輕則可能把團隊拖死，重則可能把公司拖垮。
同時只有對業務具有較深的理解，才能清楚團隊是否在沿著正確的方向前進，才能了解評估每個人的工作成果。
如果一個技術管理者，既不精于技術，也不去熟悉業務，每次開會都開成了對自己的答疑解惑會，并且一開就是兩三個小時，那就真如舊社會老太婆的裹腳布，又臭又長了。
因此，對于技術管理者，技術能力與業務能力，兩手都要抓，兩手都要硬。
協同能力
協同能力就是協調各類資源(人力、物力、財力)的能力，包括向下協同與向上協同兩個方面。
向下協同能力，就是組織協調下屬的能力，也就是帶隊伍的能力，如果把團隊成員比喻成一個個齒輪。
那么管理者就是既要充當拉動整個組件的皮帶的角色，還要充當各個齒輪之間的潤滑劑的角色。
他既要拉動團隊整體運轉，又要在齒輪之間出現摩擦與碰撞時及時添加潤滑劑讓其減少摩擦平穩運行。
同時要知人善任，要知道把每個齒輪擺在什么位置，才能充分發揮各個齒輪的效用，從而整體動力更強，效益更高。
向上協同能力，就是往上看，與領導處好關系的能力。很多時候，只有與領導處好關系，才能拉到更多更好的資源。
這里的處好關系不是說阿諛奉承溜須拍馬，而是做好工作匯報，讓領導認可你，信任你，從而放心地將資源交付你。
爭取到更多的資源，才能幫助下屬協調他協調不了的資源，團隊跟著你干才有“肉”吃，才能保持工作的動力與熱情。
心胸寬廣
所謂江山易改，秉性難移，上述三點都可以通過努力去外修，而心胸寬廣，卻是需要內修的一個方面。
技術管理者，既要做到以技服人，以能力服人，也要做到以德服人，以心胸服人。
什么是管理者的心胸寬廣呢，我認為主要體現在三個方面，對事不對人，公私分明，有大局觀。
對事不對人就是要就事論事，秉著去解決問題，規避問題的角度來處理事情，而不要對任何團隊成員存在任何偏見，一出問題就質疑指責別人的能力(有時候雖然確實是能力問題，但最好不要直接這么說，是很傷人自尊的)，甚至三觀。
公私分明就是不要在管理工作中攜帶私人情感，對與自己關系好的下屬照顧有加，對與自己關系不好的故意刁難，要公平公正，一視同仁。
有大局觀就是凡事要以實現終極目標為準繩，有利于此的就要宣揚與堅持，無關大礙的就不要斤斤計較，不要都爭個對錯。
所以，管理者的領導力是一個內外兼修的事情，既要有外修以提高管理的能力，也要有內修以提高管理的魄力。
構建團隊文化
企業有企業的文化，一般包括企業愿景、使命、核心價值觀等，同樣，團隊也應有團隊的文化，我理解的技術團隊的愿景、使命很簡單，就是要服務于企業終極目標的同時，讓團隊有所成長。
而技術團隊的價值觀就是團隊行為的是非標準，哪些是應該做的，鼓勵做的，哪些是不應該做的，禁止做的。
如何構建團隊文化，我總結了如下幾個方面：
互相尊重
管理者與下屬的關系，雖然存在管理與被管理的事實，但是不要擺出一副居高臨下、高人一等的姿態，而更多的是應該扮演一個服務者，協調者的角色。
要學會傾聽下屬不同的意見，盡力滿足下屬合理的需求。有些管理者動不動就跟這個懟，跟那個懟，甚至在會議這種公開場合互懟，以此來彰顯他的權威與地位。
殊不知，這種做法不僅解決不了問題，而且有損管理者的威信，給人心胸不夠寬廣，能力水平有限的印象。
如果出現公開場合比如會上個別下屬不配合的情況，我認為正確的做法是先繼續開會，并要求他會后留下私下溝通。
私下溝通建議采用欲抑先揚的方式，先肯定他在某些方面做得很好，你是肯定的。
但是在某某方面做得不對或不夠，并且說明為什么不對或不夠，希望能有所改善。這種方式最容易讓人接受，也體現了管理者的管理魄力。
總之，就是不論是管理者與下屬之間，還是下屬與下屬之間，都要建立起一種互相尊重，互相理解的氛圍。
重視規范
規范就是對一些常見的場景定義一套統一的標準的做法，包括技術規范，流程規范。
技術規范對一些常見的技術實現進行統一，如前后端接口交互規范，異常處理規范，數據庫設計規范，日志記錄規范等。
流程規范就是在各個環節，什么人在什么階段，應該做什么，怎么做，比如開發流程規范，要先設計再編碼，設計需 Review，代碼需 Review，各個 Review 流程具體又是怎么做，都要有明確定義。
規范是保障團隊步調一致的有效方式，用相同的方式處理相同的問題，從而減少錯誤的出現，提高協作的效率。
重視規范，既要制定規范，又要跟進規范的執行，沒有制定，就無從談跟進執行，沒有跟進執行，就會流于形式或執行不到位，也無法對規范逐步進行調整、優化。因此，制定與跟進，兩者缺一不可。
結果導向
很多人認為，結果導向就是只看結果，不管過程，我認為是有點片面的。結果導向，既要看重結果，也要跟進過程。
既要把控整體看成果，也要把控關鍵節點，跟進過程，就是本文開頭所說“管”部分的管執行，管進度。
只有跟進過程，你才能及時知道團隊是否在按正確的方向前進，是否存在需要處理的問題，是否存在可能的風險，從而及時做出應對方案，保障最終導向一個良好的結果，我認為這才是真正的“結果導向”。“放羊”班沒有春天。
輕松高效
IT 技術相對來說是一個具備一定創造性的工作，同樣一個問題，可能有許多種解決方案，解決方案的優劣既依賴于解決者的能力水平，也依賴于解決者的狀態。
因此，營造一個輕松高效的工作環境，充分發揮團隊成員的創造能力水平，也顯得很重要。
技術人員的管理不應像監督車間工人一樣看你某個時刻是不是在偷懶，開小差，只要你把任務保質保量按期完成好，不論你是學習還是看新聞，刷微博，只要不影響其他同事或違反規章制度，我覺得都無可厚非。
這可能也是“結果導向”的另一種解讀。(然而不幸的是，事實上，很多老板或管理者因為無法做好規劃，或者出于自身的焦慮，要求技術人員無時無刻都要在“工作”狀態，甚至有事沒事都要求加班，這種做法，往往也都難有較好的成效)
主動擔當
團隊成員需要有主動擔當，管理者更應有主動擔當。管理者是一個團隊或部門的領頭羊，團隊出了問題，管理者應承擔最大的責任，應主動去為團隊擔當。
如果管理者沒有主動擔當，其團隊內部必然會產生背鍋、甩鍋的文化，所有人都怕背鍋，所有人都在甩鍋，從而導致難做的工作無人敢去做 ，導致各人自掃門前雪，莫管他人瓦上霜的局面。
技術團隊的管理者，從一開始就要做好“背鍋俠”的準備，你是老大，你就是最大的“背鍋俠”。
只有你在前面承擔壓力，團隊成員才會放手去干，并且你的擔當，也會無形中對團隊成員產生正面影響，提高他們自身的擔當意識，把工作做好。
學習分享
技術團隊需要不斷學習來提高，因此營造一種良好的學習、分享氛圍，也是技術管理者的職責之一。
團隊的每個人，只有在團隊中獲得成長，才能獲得一定的成就感，歸屬感，同時，團隊成員成長了，也才能更好地服務于團隊、公司，這是一個雙贏的事情。
技術管理者在平時應該盡可能地鼓勵分享，組織專題學習，做好團隊知識管理。
以上，是我總結的技術團隊團隊文化構建的幾個方面，技術管理者應該在平常有意識地不斷灌輸，并以身作則，讓團隊按這種文化來協作、工作。
方法論
光說不練假把式，以上主要是一些思維方向上的總結，那有沒有具體的方法或套路來踐行這些思路呢。
結合自己的實踐經驗，我從制度、規范、工具三個方面做一點分享，但每個團隊、企業面對的具體問題不同，可能其中具體的方式方法不一定適用，但是整體的思維方式我認為是相通的。
制度
制度就是為了實現或更高效地實現目標，規定要做的活動。技術團隊建立的制度可以包括例會制度、周報制度、需求評審制度、設計審查制度、代碼審查制度、績效考評制度等。
團隊的溝通交流很重要，例會制度可以給團隊一個相互交流、了解的空間，問題反饋的渠道，同時也給技術管理者一個跟進團隊工作狀況，宣揚制度、決策的機會。
所以每周一次或幾次(根據自身情況衡量)的例會是有必要的。周報制度是團隊所有成員對自己一周的工作進行梳理回顧，總結問題經驗，同時對下周主要工作作出計劃的活動。
周報制度一方面有利于團隊管理者了解每個人的工作進度、問題，及時干預保障目標的達成，另一方面也促使團隊成員梳理自己的工作，做到有計劃有步驟有進展。
需求評審、設計審查、代碼審查等制度，可以保障我們對需求的理解是一致的，設計是符合整體架構原則的，代碼是符合編碼規范并且沒有低級錯誤的，從而提高我們的開發效率與質量。
績效考評制度主要是避免吃大鍋飯，干多干少一個樣，干好干壞一個樣的情況。
但績效考評如果不與獎懲機制關聯就有點形同虛設，這有時候可能不止是一個團隊或部門能決策的，而是公司自上而下的制度規定，相對就較為復雜了。
規范
規范就是定義怎么來做，包括技術規范、流程規范兩個方面。技術規范規定對一些常見的通用場景，通過什么樣的方式來統一實現。
如前后端交互協議——接口返回的格式，是否 REST 風格，各個服務應該是一致的，再比如異常的處理——業務異常應該怎么處理，非業務異常應該怎么處理等。
技術規范一方面通過對相同問題采取相同解決方法，來避免出錯的概率，另一方面對一些通用處理進行封裝，避免復制粘貼或重復造輪子。
流程規范對一些活動，指定了什么人在什么階段，應該做什么，怎么做，以保障工作或制度有序、有效地執行。
工具
工欲善其事，必先利其器。制度有了，規范流程也有了，如何來保障高效地執行，就要依賴于有效的工具。
比較常用的團隊管理的工具有：
- Confluence，知識管理工具，可對項目或部門的各類知識文檔進行集中管理，如需求文檔、設計文檔、轉測文檔、上線文檔，技術規范文檔、技術分享文檔、會議記錄等等。
- Jira，任務、Bug 跟蹤管理工具，基于所有問題可跟蹤的原則，將需求任務、Bug、優化都以任務單的形式錄入 Jira，集中跟進管理，并且 Jira 的 Agile 插件可很好地用于項目敏捷管理。
- Worktile，Worktile 應用于 OKR 管理可能比較適用，但對軟件項目的版本管理總覺得不太友好(可能是不夠熟練的原因)，所以對于軟件項目管理，我更傾向于 Jira。
- Gitlab，這作為代碼管理工具沒什么好說的了，但基于它來實現代碼 Review 流程可能不是太多見。
還有比如像 Jenkins 等提高開發部署效率的工具等等，這些工具或其他替代品我相信在很多公司都有相應的應用，這里就不詳述了。
另一個比較特殊的工具，是考核，我們都說考核只是一種工具，而不是目的，并且這種工具還是一把雙刃劍，做得好，效果顯著，做的不好，可能影響團隊的士氣，得不償失。
但是我認為對于一定規模的團隊，比如十幾人，幾十人，不能沒有考核，考核不一定很科學很完善，但只要秉著公平公正客觀的原則，并輔以一定的監督，就是一個聊勝于無的事情。
制度、規范、工具是可以應用于團隊管理的方法，總結一句就是用制度來規定要做什么，用規范來定義怎么做，用工具來讓你做的更輕松。
總結
沒有人天生具備管理才能，只有在平時多觀察，多思考，多實踐，多總結，才能不斷提高對管理的認知與水平。
各個團隊，各個公司面臨的問題不同，也沒有一個放之四海而皆準的模子讓你去套，但是盡管面對問題不同，應對的方式方法各異，整體的思維方式還是相通的。
技術管理者的自我修養，我認為先要有對管理的正確認識，然后從提升領導力，構建團隊文化，方法論三個方面去實踐，思考總結，調整，再實踐，再思考總結，再調整的方式來不斷提高。以上，共勉。
作者：漫話編程來源：空山新雨的技術空間
