近幾年面試了不少新人，當問到職業規劃時，大多都會說先積累技術，然后往架構師的方向發展。這可能是技術人的一個特質，喜歡跟機器相處，沉浸在代碼之中，而不喜歡跟人打交道。

現實的情況是，一些中小公司可能沒有專職的架構師崗位，即便有，也是需要身兼多職，很多時候程序員都在沒做好準備的情況下，卻被公司推到了管理崗位，即便是冠上了架構師的頭銜，也需要做很多管理的工作，通常會面臨下面的一些問題：

• 初次接觸管理崗，需要和人打交道了，難以適應

• 仍然把自己當成是一個高級的開發者

• 需要多任務并行處理事情，分不清主次

• 團隊成員從3、5人發展到10來人時，流程、做事方式等都需要轉變，也會面臨巨大的考驗

今年年初，我就面臨了一次很大的考驗，團隊的成員越來越多，公司的項目也越來越多，產品團隊這邊壓力非常大，我也幾乎到崩潰的邊緣，甚至還給領導寫了一封“訴苦”信，歸根結底，還是能力的提升速度沒有公司的發展速度快。

經過領導的引導和自己的調整，我覺得已經突破了瓶頸，并在這大半年的時間里有了明顯改善和進步，下面分享一點我的體會。

心態

做任何事情，心態都非常重要，不好的心態會使你對完全能夠勝任的事情也產生排斥的想法，最終做出非常糟糕的結果。舉一個加班的例子：

• 如果你覺得8點就能搞定下班，但因為各種非自身原因導致10點才能完成；

• 提前考慮的比較周全，認為需要到11點才能完成任務，但因為配合的很好，10點就完成下班了。

同樣是10點下班，后一種點心態就會好很多，因為在事前心里就有了預期，而實際結果比預期的好。

所以我們在進入管理崗位后，就要有隨時會遇到各種問題的預期，解決一個個點問題就是我們升級打怪的過程。就像我們領導說的，必須經歷痛苦才能夠成長。

任務歸類

作為一個開發人員，領導安排的任務按時交付就算合格了，如果能再考慮下擴展性、重用性、性能等問題就算是很優秀了，做的事情相對單一，平時也不會受到很多外界的干擾。

一旦走上技術管理崗位，會感覺事情突然翻了很多倍：

• 制定產品的任務計劃

• 需要考慮團隊成員的成長

• 合理地安排任務

• 各部門之間的協作

• 重難點技術的攻關

• 核心代碼的編寫

• 解決團隊成員遇到的各種問題

• …

如果沒有一個合理的安排和歸類，就會像無頭蒼蠅一樣，到處亂竄，一天下來感覺非常忙碌，但好像又什么事情都沒做。所以任務的歸類非常重要。

事情再多，都可以按照，重要緊急、緊急不重要、重要不緊急和不重要不緊急這四個象限來進行分類。類分好了，先做什么，后做什么，就一目了然了。

任務下放

程序員通常都很自信，覺得自己寫的代碼是最好的，看別人的代碼總覺得有各種各樣的問題，在排查一些歷史問題的時候，經常會說，這誰寫的代碼，這么爛，最后一看Git記錄，發現是自己寫的。

所以到了管理崗位后，任何事情都喜歡親力親為，就造成了自己忙死，而團隊成員工作不飽和。帶領團隊后，對團隊中每個人的性格和優缺點都要了如指掌，這樣才能做到知人善用。

在上面一步做了任務歸類后，就可以清楚地知道哪些是可以分配下去，哪些是需要自己處理。例如：

項目組反饋了一個緊急Bug，這是需要做的是準備好重現環境，安排合適的人進行排查和修復，而不是直接打開VS開始調試代碼了。

懂得合理地分配任務，才能有更多的精力去做更重要的事情。

善用工具

不同的時期，有不同的做事習慣和風格，最早我團隊只有3個人的時候，平時的溝通和任務的分配基本都是口頭轉述，因為這樣效率最高，但僅限于團隊成員足夠少，并且每個人都能夠配合默契，這樣口頭轉述的內容才能不失真，真正地做到有效率。

慢慢地團隊中加入了很多新鮮血液，再用口頭轉述就會存在很大的問題，同樣的一句話，一個新人的理解和你想要達到的效果可能相差很遠。這時就需要有文檔了，我們現在使用語雀來寫需求文檔，更多的時候，我是讓開發人員自己來寫這個文檔，然后我再來復審，看需求的理解是不是完全清楚了，這樣做有一個好處，開發人員不是被動地接受任務，而是主動地參與思考。

團隊成員增多，每天的需要提測的任務也越來越多，如果還是手動地發布部署會浪費大量的時間，這時就需要使用Jenkins、Docker等自動化構建的工具了。還有需求和任務的管理也必須工具化、流程化，這一塊我們采用的是我們自己做的產品搭建出來的任務系統。

善用工具，可以將繁瑣的，重復性的工作交給機器來做，就會有更多的精力去做更重要的事情。

最近一段時間的新的體會，希望對您有所幫助。

總結

以上是生活随笔為你收集整理的技术管理者怎样跳出“泥潭”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。