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領域的點滴