近幾年面試了不少新人，當(dāng)問到職業(yè)規(guī)劃時，大多都會說先積累技術(shù)，然后往架構(gòu)師的方向發(fā)展。這可能是技術(shù)人的一個特質(zhì)，喜歡跟機器相處，沉浸在代碼之中，而不喜歡跟人打交道。

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

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

• 仍然把自己當(dāng)成是一個高級的開發(fā)者

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

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

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

經(jīng)過領(lǐng)導(dǎo)的引導(dǎo)和自己的調(diào)整，我覺得已經(jīng)突破了瓶頸，并在這大半年的時間里有了明顯改善和進步，下面分享一點我的體會。

心態(tài)

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

• 如果你覺得8點就能搞定下班，但因為各種非自身原因?qū)е?0點才能完成；

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

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

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

任務(wù)歸類

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

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

• 制定產(chǎn)品的任務(wù)計劃

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

• 合理地安排任務(wù)

• 各部門之間的協(xié)作

• 重難點技術(shù)的攻關(guān)

• 核心代碼的編寫

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

• …

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

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

任務(wù)下放

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

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

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

項目組反饋了一個緊急Bug，這是需要做的是準(zhǔn)備好重現(xiàn)環(huán)境，安排合適的人進行排查和修復(fù)，而不是直接打開VS開始調(diào)試代碼了。

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

善用工具

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。