IT技術管理者的自我修養

　　1. 前言     

　　原本寫《IT技術管理者的自我修養》與《IT技術人員的自我修養》是一開始就有的想法。但發表《IT技術人員的自我修養》後，收到了很多良好的反饋，博客園的編輯對該文進行了置頂推薦，迅速帶來了4000多的瀏覽量，阿里菜鳥國際的大牛也經過私信投來了橄欖枝，如今都還沒來得及回覆，也有網友留言申請了轉載，雖然被改的面目全非。在此很是感謝你們的承認，只要有共鳴，有收穫，就不枉我敲這麼多字了（^_^）。但同時，也對我繼續寫《IT技術管理者的自我修養》帶來了很多的壓力，怕寫很差，怕辜負你們的指望，遲遲不敢下筆。但又一想，我又不是什麼公衆人物，何須有這個心理負擔，權當本身的思考梳理，放置於網上，任其評說。再者，醜媳婦總有見公婆的時候，因而，就有了本文。同前所述，本文不是所謂成功人士的經驗之談（做者離本身理解的成功還有十萬七千九百九十里—— 一週的時候仍是能前進十里吧），而是以一個有幾年經驗的技術管理者的角度作的一些思考與總結，但願能給有志於從事技術管理的同僚以參考，與之共勉。

 

　　由於文字寫的有點多，先貼一張思惟導圖，若是看了有興趣則可繼續，若是沒有也可就此打住，不浪費時間了。

  　　

 

 

　　

　　   ！！！長文預警 ！！！

 

　　2. 對「管理」的理解   

　　管理管理，從字面上看包含兩層意思：「管」與「理」。管什麼？理什麼？怎麼管？怎麼理？可能把這四個問題弄清楚了，管理這個事也就沒那麼難了。

 

　　首先，管什麼？有些人可能認爲管理就是管人，就是盯人幹活，在我看來，管人不是管理的目的，管理的本質應是協調一切能夠協調的資源（人力、物力、財力），努力達成團隊或組織的終極目標。企業管理的終極目標無非就是成功 —— 行業領先、可持續成長、受人尊重。技術團隊管理的終極目標，就是在服務於企業終極目標的同時，讓團隊有所成長 —— 團隊成員在能力、收入、素養各方面獲得進步。那麼爲了達成這個目標，技術團隊須要管什麼？我總結了如下四點。

　　1. 管執行。就是要持續跟進確認你的決策（制度、流程、任務）是否被執行到位，是否在按正確的方向前進，是否存在問題，並及時撥亂反正，及時提供必要的協助—— 協助協調下屬協調不了的資源，協助解決他解決不了的問題。

　　2. 管進度。就是要持續確認你的目標是否在一步一步循序漸進地完成，是否存在風險，並及時作出必要的調整以應對各類風險。

　　3. 管效果。就是要持續驗證各個階段的成果是否符合當初的預期，並及時制定措施彌補不符合預期的結果。

　　4. 管成長。就是要持續爲你的團隊營造一個良好的成長環境與空間，讓每個人都能發揮本身的能力，而且獲得有效的成長。

 

　　這裏每一點都包含了一個詞 —— 持續。不是把事情梳理完，分配完就能夠撒手無論了，就能夠「放羊」了，而是應持續跟進，只有持續跟進，出現問題時，你才能及時發現，及時修正，才能確保最終達成目標。放牛班有春天，「放羊」班通常是沒有春天的。

 

　　其次，理什麼？若是把「管」理解爲實踐，那麼「理」就是理論，只有實踐與理論相結合，才能作到有目標，有方法，有效果。技術團隊須要理什麼？我也總結了如下四點。

 

　　1. 理目標。通常包括兩個層面，由上而下的業務目標，好比產品里程碑，項目階段驗收節點，以及由下而上的技術目標，如服務端重構、Web頁面優化、架構升級、系統運行監控、用戶體驗的提高等。

　　2. 理制度。爲了實現或更高效地實現目標，須要經過哪些手段或環節，規定要作的活動，如例會制度、周（日）報制度、需求評審制度、設計審查制度、代碼審查制度等。

　　3. 理規範。定義怎麼來作，包括技術規範、流程規範兩個方面。技術規範規定對某些常見的場景，經過什麼樣的方式來統一執行，如先後端對接的協議、異常的處理、日誌的規範等；流程規範對一些活動，指定了什麼人在什麼階段，應該作什麼，怎麼作，如轉測流程，要求開發人員在轉測時寫轉測文檔，提供轉測內容、影響因素等信息，測試人員測試完成後，提供測試結論，遺留哪些問題，是否贊成上線等。

　　4. 理問題。任何一個團隊都存在這樣那樣的問題，若是一個團隊沒有任何問題，那這自己就是一個問題（沒有複製上文，仍是一個字一個字敲的）。 要擅於去發現問題，並創建順暢的問題反饋渠道。同時對問題的處理，不該終止於解決，通常遵循「發現問題 => 分析問題 => 解決問題 => 覆盤問題 => 規避問題」的流程形式。

 

　　管理，既要管，也要理，在管的過程當中理，理清楚後再應用於管，管與理相輔相成，融爲一體，造成管理。管理是一個比較複雜的事情——只要與人打交道的就沒有簡單的事，既要注意方式方法，又要尊重人性，好比人都有愛自由的天性，對任何管理與約束都有一種本能的對抗，但同時人也有懶惰的天性，「放牛班」有春天，「放羊」班幾乎不可能有春天。所以在管理與約束的行爲上就要作到既給必定的自由度，又要有相對的控制力，有所爲有所不爲，作到管控有度。而這個「度」，可能就是所謂的管理藝術了吧。

 

　　有人把管理比喻爲放風箏，我以爲挺貼切的。管理者是風箏的操縱者，團隊成員就是風箏，管理者應該給團隊成員一個像風箏同樣發揮主觀能動性的廣闊的空間，把風箏勇於放向蔚藍的天空，但同時也能把控它的方向，並隨時能夠把它收回來。管理能作到像放風箏同樣收放自如，那就是真正的藝術了。

 

　　上面梳理總結了管什麼、理什麼的問題。那麼對於技術團隊的管理者來講，怎麼管、怎麼理，或者沿用上一文的口吻，技術管理者的自我修養，應從哪些方面去努力。我從提高領導力，構建團隊文化，方法論三個角度進行了思考與總結。

 

　　3. 領導力     

　　領導力個人理解就是帶領他人朝着一個目標努力，組織協調最終一塊兒達成目標的能力。技術管理者如何提升領導力，我認爲能夠從如下四個方面努力。

 

　　1. 技術能力。好的技術團隊管理者，必定是該技術領域的技術專家，具有較強的技術能力。技術人員通常思想都相對單純，誰比他厲害就服誰，他不懂的你懂，他解決不了的問題你協助他解決了，天然就能提高你的影響力與威信，這對你的管理會帶來極大的幫助。好的技術能力，不只要有技術的深度，還要有技術的廣度。由於只有具備技術的深度，才能幫助下屬解決他解決不了的問題，才能在團隊遇到棘手問題時迎難而上，帶領團隊披荊斬棘；只有具備技術的廣度，纔能有效地制定團隊的技術方向，而且在下屬跟你說這個功能實現不了時，才能確認下屬是在忽悠你，仍是真的實現不了。

　　2. 業務能力。只有對業務具備較深的理解，才能更好地使用技術手段來服務於業務。通常咱們作架構設計時，包括業務架構與技術架構，技術架構要以業務架構爲參考，一切脫離業務的架構設計都是耍流氓。一些中小企業的技術管理者，去參加了一次阿里雲棲大會，回來就跟團隊鼓吹加人搞中臺，對於中小企業來講，不少業務仍處於探索階段，好多產品或項目可能在你中臺還沒搭建完就已經玩完了。從技術的角度，思路多是對的，但從業務的角度，沒有結合實際，沒有考慮成本，效率等因素。不結合具體業務照搬別人的架構，輕則可能把團隊拖死，重則可能把公司拖垮。同時只有對業務具備較深的理解，才能清楚團隊是否在沿着正確的方向前進，才能瞭解評估每一個人的工做成果。若是一個技術管理者，既不精於技術，也不去熟悉業務，每次開會都開成了對本身的答疑解惑會，而且一開就是兩三個小時，那就真如舊社會老太婆的裹腳布，又臭又長了。所以，對於技術管理者，技術能力與業務能力，兩手都要抓，兩手都要硬。

　　3. 協同能力。協同能力就是協調各種資源（人力、物力、財力）的能力。包括向下協同與向上協同兩個方面。向下協同能力，就是組織協調下屬的能力，也就是帶隊伍的能力，若是把團隊成員比喻成一個個齒輪，那麼管理者就是既要充當拉動整個組件的皮帶的角色，還要充當各個齒輪之間的潤滑劑的角色，既要拉動團隊總體運轉，又要在齒輪之間出現摩擦與碰撞時及時添加潤滑劑讓其減小摩擦平穩運行。同時要知人善任，要知道把每一個齒輪擺在什麼位置，才能充分發揮各個齒輪的效用，從而總體動力更強，效益更高。向上協同能力，就是往上看，與領導處好關係的能力。不少時候，只有與領導處好關係，才能拉到更多更好的資源，這裏的處好關係不是說阿諛奉承溜鬚拍馬，而是作好工做彙報，讓領導承認你，信任你，從而放心地將資源交付你。爭取到更多的資源，才能幫助下屬協調他協調不了的資源，團隊跟着你幹才有「肉」吃，才能保持工做的動力與熱情。

　　4. 心胸寬廣。所謂江山易改，秉性難移，上述三點均可以經過努力去外修，而心胸寬廣，倒是須要內修的一個方面。技術管理者，既要作到以技服人，以能力服人，也要作到以德服人，以心胸服人。什麼是管理者的心胸寬廣呢，我認爲主要體如今三個方面，對事不對人，公私分明，有大局觀。對事不對人就是要就事論事，秉着去解決問題，規避問題的角度來處理事情，而不要對任何團隊成員存在任何偏見，一出問題就質疑指責別人的能力（有時候雖然確實是能力問題，但最好不要直接這麼說，是很傷人自尊的），甚至三觀。公私分明就是不要在管理工做中攜帶私人情感，對與本身關係好的下屬照顧有加，對與本身關係很差的故意刁難，要公平公正，一視同仁。有大局觀就是凡事要以實現終極目標爲準繩，有利於此的就要宣揚與堅持，無關大礙的就不要斤斤計較，不要都爭個對錯。

 

　　因此，管理者的領導力是一個內外兼修的事情，既要有外修以提升管理的能力，也要有內修以提升管理的魄力。，

 

　　4. 構建團隊文化     

　　企業有企業的文化，通常包括企業願景、使命、核心價值觀等，一樣，團隊也應有團隊的文化，我理解的技術團隊的願景、使命很簡單，就是要服務於企業終極目標的同時，讓團隊有所成長。而技術團隊的價值觀就是團隊行爲的是非標準，哪些是應該作的，鼓勵作的，哪些是不該該作的，禁止作的。如何構建團隊文化，我總結了以下幾個方面。

 

　　1. 互相尊重。管理者與下屬的關係，雖然存在管理與被管理的事實，可是不要擺出一副居高臨下、高人一等的姿態，而更多的是應該扮演一個服務者，協調者的角色。要學會傾聽下屬不一樣的意見，盡力知足下屬合理的需求。有些管理者動不動就跟這個懟，跟那個懟，甚至在會議這種公開場合互懟，以此來彰顯他的權威與地位，卻不知，這種作法不只解決不了問題，並且有損管理者的威信，給人心胸不夠寬廣，能力水平有限的印象。若是出現公開場合好比會上個別下屬不配合的狀況，我認爲正確的作法是先繼續開會，並要求他會後留下私下溝通。私下溝通建議採用欲抑先揚的方式，先確定他在某些方面作得很好，你是確定的，可是在某某方面作得不對或不夠，而且說明爲何不對或不夠，但願能有所改善。這種方式最容易讓人接受，也體現了管理者的管理魄力。總之，就是不管是管理者與下屬之間，仍是下屬與下屬之間，都要創建起一種互相尊重，互相理解的氛圍。

　　2. 重視規範。規範就是對一些常見的場景定義一套統一的標準的作法，包括技術規範，流程規範。技術規範對一些常見的技術實現進行統一，如先後端接口交互規範，異常處理規範，數據庫設計規範，日誌記錄規範等。流程規範就是在各個環節，什麼人在什麼階段，應該作什麼，怎麼作，好比開發流程規範，要先設計再編碼，設計需review，代碼需review，各個review流程具體又是怎麼作，都要有明肯定義。規範是保障團隊步調一致的有效方式，用相同的方式處理相同的問題，從而減小錯誤的出現，提升協做的效率。重視規範，既要制定規範，又要跟進規範的執行，沒有制定，就無從談跟進執行，沒有跟進執行，就會流於形式或執行不到位，也沒法對規範逐步進行調整、優化。所以，制定與跟進，二者缺一不可。

　　3. 結果導向。不少人認爲，結果導向就是隻看結果，無論過程，我認爲是有點片面的。結果導向，既要看重結果，也要跟進過程。既要把控總體當作果，也要把控關鍵節點，跟進過程，就是本文開頭所說「管」部分的管執行，管進度。只有跟進過程，你才能及時知道團隊是否在按正確的方向前進，是否存在須要處理的問題，是否存在可能的風險，從而及時作出應對方案，保障最終導向一個良好的結果，我認爲這纔是真正的「結果導向」。「放羊」班沒有春天。

　　4. 輕鬆高效。IT技術相對來講是一個具有必定創造性的工做，一樣一個問題，可能有許多種解決方案，解決方案的優劣既依賴於解決者的能力水平，也依賴於解決者的狀態，所以，營造一個輕鬆高效的工做環境，充分發揮團隊成員的創造能力水平，也顯得很重要。技術人員的管理不該像監督車間工人同樣看你某個時刻是否是在偷懶，開小差，只要你把任務保質保量定期完成好，不論你是學習仍是看新聞，刷微博，只要不影響其餘同事或違反規章制度，我以爲都無可厚非。這可能也是「結果導向」的另外一種解讀。（然而不幸的是，事實上，不少老闆或管理者由於沒法作好規劃，或者出於自身的焦慮，要求技術人員無時無刻都要在「工做」狀態，甚至有事沒事都要求加班，這種作法，每每也都難有較好的成效）

　　5. 主動擔當。團隊成員須要有主動擔當，管理者更應有主動擔當。管理者是一個團隊或部門的領頭羊，團隊出了問題，管理者應承擔最大的責任，應主動去爲團隊擔當。若是管理者沒有主動擔當，其團隊內部必然會產生背鍋、甩鍋的文化，全部人都怕背鍋，全部人都在甩鍋，從而致使難作的工做無人敢去作 ，致使各人自掃門前雪，莫管他人瓦上霜的局面。技術團隊的管理者，從一開始就要作好「背鍋俠」的準備，你是老大，你就是最大的「背鍋俠」，只有你在前面承擔壓力，團隊成員纔會放手去幹，而且你的擔當，也會無形中對團隊成員產生正面影響，提升他們自身的擔當意識，把工做作好。

　　6. 學習分享。技術團隊須要不斷學習來提升，所以營造一種良好的學習、分享氛圍，也是技術管理者的職責之一。團隊的每一個人，只有在團隊中得到成長，才能得到必定的成就感，歸屬感，同時，團隊成員成長了，也才能更好地服務於團隊、公司，這是一個共贏的事情。技術管理者在平時應該儘量地鼓勵分享，組織專題學習，作好團隊知識管理。

 

以上，是我總結的技術團隊團隊文化構建的幾個方面，技術管理者應該在日常有意識地不斷灌輸，並以身做則，讓團隊按這種文化來協做、工做。

 

　　5. 方法論     

　　光說不練假把式，以上主要是一些思惟方向上的總結，那有沒有具體的方法或套路來踐行這些思路呢。結合本身的實踐經驗，我從制度、規範、工具三個方面作一點分享，但每一個團隊、企業面對的具體問題不一樣，可能其中具體的方式方法不必定適用，可是總體的思惟方式我認爲是相通的。

 

　　1.  制度。制度就是爲了實現或更高效地實現目標，規定要作的活動。技術團隊創建的制度能夠包括例會制度、週報制度、需求評審制度、設計審查制度、代碼審查制度、績效考評制度等。團隊的溝通交流很重要，例會制度能夠給團隊一個相互交流、瞭解的空間，問題反饋的渠道，同時也給技術管理者一個跟進團隊工做情況，宣揚制度、決策的機會。因此每週一次或幾回（根據自身狀況衡量）的例會是有必要的。週報制度是團隊全部成員對本身一週的工做進行梳理回顧，總結問題經驗，同時對下週主要工做做出計劃的活動，週報制度一方面有利於團隊管理者瞭解每一個人的工做進度、問題，及時干預保障目標的達成，另外一方面也促使團隊成員梳理本身的工做，作到有計劃有步驟有進展。需求評審、設計審查、代碼審查等制度，能夠保障咱們對需求的理解是一致的，設計是符合總體架構原則的，代碼是符合編碼規範而且沒有低級錯誤的，從而提升咱們的開發效率與質量。績效考評制度主要是避免吃大鍋飯，幹多幹少一個樣，幹好幹壞一個樣的狀況，但績效考評若是不與獎懲機制關聯就有點形同虛設，這有時候可能不止是一個團隊或部門能決策的，而是公司自上而下的制度規定，相對就較爲複雜了。

　　2.  規範。規範就是定義怎麼來作，包括技術規範、流程規範兩個方面。技術規範規定對一些常見的通用場景，經過什麼樣的方式來統一實現，如先後端交互協議——接口返回的格式，是否REST風格，各個服務應該是一致的，再好比異常的處理——業務異常應該怎麼處理，非業務異常應該怎麼處理等，相關內容可參考個人其它技術分享文章。技術規範一方面經過對相同問題採起相同解決方法，來避免出錯的機率，另外一方面對一些通用處理進行封裝，避免複製粘貼或重複造輪子；流程規範對一些活動，指定了什麼人在什麼階段，應該作什麼，怎麼作，以保障工做或制度有序、有效地執行。以前的《軟件項目研發流程該怎麼規範》對項目協做流程作了基本的介紹，可查閱參考，《研發團隊如何藉助Gitlab來作代碼review》對代碼review流程作了詳細介紹，也歡迎參考交流。

 　　3.  工具。工欲善其事，必先利其器。制度有了，規範流程也有了，如何來保障高效地執行，就要依賴於有效的工具。比較經常使用的團隊管理的工具備

• Confluence，知識管理工具，可對項目或部門的各種知識文檔進行集中管理，如需求文檔、設計文檔、轉測文檔、上線文檔，技術規範文檔、技術分享文檔、會議記錄等等。

• Jira，任務、bug跟蹤管理工具，基於全部問題可跟蹤的原則，將需求任務、bug、優化都以任務單的形式錄入Jira，集中跟進管理，而且Jira的Agile插件可很好地用於項目敏捷管理。

• Worktile，worktile應用於OKR管理可能比較適用，但對軟件項目的版本管理總以爲不太友好（多是不夠熟練的緣由），因此對於軟件項目管理，我更傾向於Jira。

• Gitlab，這做爲代碼管理工具沒什麼好說的了，但基於它來實現代碼review流程可能不是太多見，《研發團隊如何藉助Gitlab來作代碼review》介紹了經過Gitlab結合釘釘機器人實現代碼review的具體實踐步驟，可參考交流。

   

　　還有好比像jenkins等提升開發部署效率的工具等等，這些工具或其它替代品我相信在不少公司都有相應的應用，這裏就不詳述了。另外一個比較特殊的工具，是考覈，咱們都說考覈只是一種工具，而不是目的，而且這種工具仍是一把雙刃劍，作得好，效果顯著，作的很差，可能影響團隊的士氣，得不償失。可是我認爲對於必定規模的團隊，好比十幾人，幾十人，不能沒有考覈，考覈不必定很科學很完善，但只要秉着公平公正客觀的原則，並輔以必定的監督，就是一個聊勝於無的事情。

制度、規範、工具是能夠應用於團隊管理的方法，總結一句就是用制度來規定要作什麼，用規範來定義怎麼作，用工具來讓你作的更輕鬆。

 

　　6. 總結    

　　沒有人天生具有管理才能，只有在平時多觀察，多思考，多實踐，多總結，才能不斷提升對管理的認知與水平。各個團隊，各個公司面臨的問題不一樣，也沒有一個放之四海而皆準的模子讓你去套，可是儘管面對問題不一樣，應對的方式方法各異，總體的思惟方式仍是相通的。技術管理者的自我修養，我認爲先要有對管理的正確認識，而後從提高領導力，構建團隊文化，方法論三個方面去實踐，思考總結，調整，再實踐，再思考總結，再調整的方式來不斷提升。

　　以上，共勉。

 

 

　　做者：空山新雨

　　本文發表於微信公衆號：「空山新雨的技術空間」，歡迎關注，一塊兒交流企業技術實戰與IT領域的點滴