我工作近 10 年，是程式設計師出身，有大概 5 年的管理經驗，最多管理過 40 人的技術團隊。本文是個人的一些觀點和建議，以及這些年的一點感悟，希望對於管理人員，特別是中層管理者有點用處。
管理技術團隊，其實也是管理的一種。我個人認為，管理能力的核心包含兩方面，一是針對人，對人性的瞭解程度以及溝通能力。二是對事，是否有強大的統籌規劃協調能力。
當然，這是對於廣義上管理能力的定義，對於技術團隊，其本身有一些特殊性（不同性質的團隊都有特殊性），所以在管理技術團的時候，要充分考慮到這些特殊性，然後通過管理上的一些手段，才能使技術團隊在正常的秩序下有高水平的發揮。下面，我們就技術團隊管理的幾個方面來探討一下。
首先，我們來看看技術團隊成員有些什麼樣的特徵。一般，搞技術的人，例如軟體攻城師，前端攻城師， UI 設計師，運維攻城師等等，他們都是典型的技術型人才，你問我什麼是技術型人才？那我問你什麼是業務型人才？這樣一比較，就出來個大概。技術型人才性格內斂，臉皮比較薄，性格高傲，不喜歡被制度限制，不善交流溝通，喜歡獨立思考，契約精神較強，對 IT 圈的資訊比較敏感，崇尚科學技術甚至迷信科學技術等等。（我這裡列舉的這些特徵是對大多技術人員性格的抽象，一定會有例外，但是並不會影響整體。）如果你帶領這樣一個團隊，卻採用管理行政人員或者業務人員的方式去管理，那肯定最後會把團隊整垮，還落個壞名聲。那麼，對於這樣一群技術型人才，究竟應該怎麼管理呢？
1.能去除的制度限制儘量全部去除。
比如，上下班打卡，不能再座位上打盹兒，不準在座位上吃零食、喝飲料，上班必須穿正裝等等。為什麼要去除這些限制呢，因為研發的工作本質上來說屬於一種創作，和作家寫文章，畫家畫畫是一樣的。在創作的時候，需要保持一種最佳的“舒適狀態”，才能發揮最極致。另外，既然是一種創作，肯定有“靈感來了”“狀態好”這些因素，所以在一天工作 8 小時內，不可能和車床工人或者其他常規工作者一樣，不停地做，做完就好。可能中午別人在休息，我的狀態比較好，寫了一中午程式碼，到了下午 2 點多想休息會，如果這時候有硬性規定不讓休息，那麼勢必會影響到下個階段的發揮，甚至會招來不滿。更有些攻城師喜歡在下班後相對安靜的環境中碼程式碼，可能晚上會工作到比較晚，但是第二天如果有硬性規定必須 9 點打卡，肯定是不合適的。
2.糧草的保障。
對於技術團隊來說，大多數人都是拿死工資，最多有點專案獎金，而且大家都是打工的，不就是為了這份工資麼。如果管理者一天到晚畫大餅，結果每個月發的和說的又對不上，那麼這個團隊遲早完蛋。所以對於技術團隊的管理者來說，無論是多麼慷慨激昂的動員會，還是天花亂墜的期權規則，都不如每個月實實在在的按時按量發放工資來的有效。當然，如果季度有些獎金，年底有年終獎那就更好了。畢竟對於 IT 行業來說， 13 薪幾乎已經成了行規。
3.要結果導向而不要過程導向。
我們在管理 IT 團隊的時候，最出現的幾個詞彙就是：進度，需求，變化。其實管理者相當於一個司令，你的任務是下命令，而不是下了命令跟著軍隊去行軍。對於一項任務，管理者只需要分配給責任人，並且評估出預計完成時間即可。在每個檢查點，需要檢查一下完成進度，對於大的需求，可能時間跨度比較大，所以檢查點比較多，對於小的需求，可能一週之內就 OK ，所以管理者需要做的是關心完成的狀況與質量，以及是否按時完成，而不是去關心責任人在完成過程中又上了幾次廁所，午飯時間又超過了幾分鐘等等。可能在過程中管理者唯一要介入的理由，就是過程中出現了比較大的異常，這個時候就需要你出來把局面拉入到正常軌道。
我舉個例子，有次我把一個比較重要且比較大的需求交給團隊裡面的一位資深工程師，時間點，進度，等等都確認沒問題，總體時間大概 3 周。結果開始一週後，他告訴我最後那一週他需要請婚假，我的第一反應就是能不能找人接手，後來發現不行，這一塊一直都是他在負責。後來他跟我說不用擔心進度，他會利用空閒時間完成任務並且保證質量，我也就籤批了他的請假申請。後來需求 2 周就完成了，最後一週他人不在現場，但是總算需求完成的比較好，測試下來遇到些問題他也可以通過電話溝通來解決。總之，我想說的意思就是，只要最後能保證成果，過程中的不合理或者你認為的不對頭，都不太要緊。
4.認真傾聽下面的聲音，不要太自我。
很多管理者習慣獨斷獨行，認為自己所掌握或者自己所瞭解的就是真實的，正確的。其實這是管理的大忌。如果把管理比作一杆天平，那麼天平的兩端分別站著穩定和民主（這個比喻是不是很熟悉？）。如果管理者絕對的獨斷獨行，那麼整個團隊表現出來的狀態是相當穩定的，但是，要搞清楚，穩定不代表認同。但是如果反過來，一個團隊事事都是大家一起決定，那一定出大亂子，管理者的決策權何在？誰來為問題買單？所以，作為團隊管理者，必須要傾聽來自底層的聲音，並且加以考慮，有些情況，確實存在問題，就必須要糾正，有些人，對團隊有影響，就要解決，不能一味的沉浸在自己的認知裡面。
溝通其實是一門大學問，溝通的方式也多種多樣。作為團隊的管理者，在面對不同的人的時候，需要採用不同的溝通方式，完全強勢，或者完全商量肯定不行。溝通的最終目的就是雙方或者對方達成一致，得到一個共同認可的結果，如果每次溝通達不成一致，也出不了結果，反而跟吵架似的，那就失去了意義。
5.事前做計劃，事中做追蹤，事後做分析。
其實這一條並不僅限於團隊管理。我們在做任何事情的事後，都應該養成這樣的習慣。我們開發一個專案，或者簡單的實現一個需求，都需要做計劃。為什麼？計劃就像一根尺子，用來比對你在實際完成過程中的狀態是否正常。所以事中的追蹤，就是比對過程。當實際情況與計劃誤差較大時，我們就可以判定是異常，這個時候我們需要分析具體原因。（分析的過程暫且不討論，在專案管理的書籍和教材中有詳細的介紹。）事中追蹤的意義在於，當發現與計劃的差異時，分析原因，找到問題，讓整個事情回到原來的軌道上，不至於失控。事情完成以後，對事情進行回顧和分析，從而得到經驗教訓，如果團隊有自己的經驗庫或者知識庫，那是再好不過了，可以讓這些精華得以儲存。
6.為團隊成員解決問題，讓團隊成員完成任務。
一個好的管理者與團隊成員的關係，應該是管理者解決成員的問題，成員完成管理者佈置的任務。我舉個例子，比如現在決定做一個 B2C 電子商務網站，那麼團隊的架構師告訴你要考慮高併發，並且採用負載均衡啊，快取啊，叢集啊等等一系列技術。那麼你首先要評估一下這些解決方案是否合適，如果合適，需要怎麼去達到方案的要求：買伺服器，買軟體，買 license 等等，這些就是你需要去跟上級申請的工作，說白了，是你需要厚著臉皮去搞定老闆掏錢的事情。再比如，某個工程師跟你說最近某個 Job 跑的很不穩定，需要在半夜監控，那麼是不是可以調一下班甚至加一些補貼。在你評估這是個合理要求後，就又該你上場了，一方面你要向工程師表態，放心的做，後面的事情你會幫他搞定，另一方面，你要說服老闆，這些東西都是必要的，確實要為工程師調班並且加一些補貼等等。只有這樣，你的團隊成員才會放心的全身心的投入到工作中，因為他們知道你會去解決他們的後顧之憂。當然，這裡的後顧之憂指的是合理的，確實需要的要求，如果一個員工跟你說一個普通週末要加班並且要 3 倍工資，那你完全可以拒絕並且附上一句 “ 你咋不上天呢？ ” 。
後話
其實管理是一件很複雜的事情，但是我認為管理技術團隊相對並不複雜。可能是大多數技術人員都還是比較單純吧。技術團隊的管理者，特別是中層管理者，其實就是個夾心層，經常受夾包氣。其實你想想，作為一個承上啟下的職位，壓力同時來自於下面和上面，收夾包氣也就正常了。但是如果我們能夠科學的規劃任務，分配工作量，調動團隊積極性，我想再困難的任務也能夠分解成一個一個不困難的小任務，分而破之。而對於團隊內的一些聲音，能夠耐心傾聽，加以思考，再彙報給上面，從而採取一些對應措施，那麼團隊成員也會因為問題得到解決而欣慰。總之，想把技術團隊管理好，多看，多聽，多想，讓老闆滿意你的執行力，讓團隊成員有歸屬感，你就成功了。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
