1. 程式人生 > >突然想聊一聊技術經理這件事

突然想聊一聊技術經理這件事

前言

在十二年的職業生涯中,我曾做過兩次技術經理,一次兩年,一次兩年半;很顯然,我不是個成功者,但,我想,我還是可以聊聊這件事的。

一定要做一次技術經理

如果你想在未來的職業生涯中依賴技術生存,那麼,你一定要做一次技術經理,哪怕是跳槽到極小規模的公司也要做一次,而且越早越好。

為什麼這麼說呢?因為做技術經理對於我們自身技術的提升效率實在太高了。

舉個例子,我是個技術經理,現在有一個專案,需要用到Socket,https,Mvc,Entity Framework四個技術點;現在我找了四名研發,給他們兩天時間做技術調查,並寫出demo。

兩天後,我給他們每人兩小時時間,讓他們給我講解技術點的調查demo,這樣,我只付出了一天的時間,但收穫了8天的技術經驗,而且是【絕對正確】且【完整】的技術經驗。

也許有人說,八天的技術經驗不算什麼,我努努力也就追上了,但事實真的是這樣嗎?想一下,我們每天工作結束後,到底能堅持學習幾個小時呢?

假如你每天堅持自學兩個小時,那麼,理論上,16天,你才可以追上。也就是說,你跟我的學習效率是1:16。(話說,每天自學兩小時的程式設計師已經是非常勤奮的了,但效率差依然如此之大)

除了技術經驗外,專案中還存在著一套架構經驗,Web前端+Mvc+資料庫+Socket通訊,很顯然,這套架構經驗只有我學會了。

雖然技術經驗,可以通過努力追上,但架構經驗,卻是你怎麼努力也追不上的。

----------------------------------------------------------------------------------------------------

作為一個普通無產階級,我們是註定無法擁有高效的學習資源的,而【技術經理】,幾乎是現實中存在的,可觸碰的到的,最高效的學習資源了。所以,還是那句話,你一定要做一次技術經理,越早越好。

----------------------------------------------------------------------------------------------------

PS:我本身並不是一個勤奮的人,但我在第一次當技術經理的時期,幾乎完整的掌握了.NetFramework的常用技術、Web前端技術、資料庫設計與管理;並且還具備了一定的架構能力,從而使我直接脫離了菜鳥技術這個身份,而那時我才僅工作3年。

如何最快速的當上技術經理

你可以在招聘網站上應聘技術經理;不過你很快會發現殘酷的事實—沒有一家公司會聘用你。

為什麼?因為他們本身就有一個技術經理了,怎麼可能再招一個嘛。

----------------------------------------------------------------------------------------------------

那麼,作為一個打工者,到底如何最快速的當上技術經理呢? 

等待

僅我個人多年所見所聞而言,在一個結構完整的公司裡,是沒有任何機會做技術經理的;也就是說正常的情況下,你為公司打工,是沒有任何晉升空間的,即便,你肯在那家公司幹個十年八年。

你也許可以做到TeamLeader,但想技術經理那是不可能的。不過,有一種情況是例外的,即,公司出現動盪,由正常情況變成了非正常情況,公司的人員大量流失,而此時,如果你堅守陣地,那麼,你很有可能就做上了技術經理。不過,你很可能面對幾個月沒有薪水,或者面對跳槽同事都大幅度漲薪的情況。。。

在一個公司死守,苦苦的等待公司變動這種行為,其實,等於是在用你人生的十年來賭博—賭一個高管的職位;當然,如果賭成功了,收穫是還很可觀的。

不過,以我目之所及,十年,沒有等待到公司動盪,或者公司動盪了,升職的是其他人的情況更多;更有甚者,十年後被公司變相裁員,不得不去面對自身技術不過硬和找工作困難的現實。

十年,真的什麼事都可能發生,磕頭的兄弟都可能成死敵,何況老闆的承諾呢!

空降

除了等待之外,還有一種做技術經理的方式,那就是空降。

僅我個人多年所見所聞而言,大廠空降真的是一等一快捷途徑;當公司開展新業務,或者公司動盪後重組,真的是非常青睞【被內推】的大廠空降兵(很顯然,大廠空降兵是選擇【等待】的朋友們的最大敵人)。

所以,大家畢業後,真的,能進大廠就趕緊進大廠,第一年進不了,第二年也要爭取;大廠這個背景,在我們職業生涯中的戰略意義實在是太大了。

當然,沒有大廠背景也並非完全沒有機會,我們雖然做空降技術經理的概率比不上大廠空降兵,但做空降後升職的技術經理概率並不比他們低,所以,我們可以多往這個方向選擇。

怎麼才能找到空降後可以升職的公司呢?很簡單,面試時問下公司發展史,就知道了公司是否在動盪期了。問一下入職後的工作內容,就可以瞭解到是不是進入新專案了。然後,只要你技壓群雄鳥,技術經理就順理成章了。

說實話,我工作這麼多年,【技術好】除此之外,真的再無用武之地。

技術好真的沒有用

我曾經有這樣一個故事。

一次我做程式碼優化,將硬體操作和頁面的UI操作進行了一次完全分離,來確保功能的獨立性。

結果,我的領導做程式碼檢查時,認為我寫的程式碼非常亂。。。

然後親切的指導了我一個小時,如何將硬體操作和頁面UI操作融合到了一起,讓程式碼變的更噁心。。。

很顯然,我接受了指導,並沒有懟回去,因為我知道領導是C++出身。。。

我們都知道C++出身的領導意味什麼,這意味他不但程式碼邏輯非常差,而且脾氣也非常差,同時他還絕對不允許被別人指責(除了他的領導),一旦你指出他的錯誤,那肯定要面臨一場吵架。

所以,彼時很成熟的我,面對這種質疑時,自然不會像剛畢業的學生那樣懟回去了,正所謂多一事不如少一事嘛。

而且我知道,這種吵架,就算爭論到大領導面前也是沒有結果的;因為我是沒辦法給大領導解釋明白,為什麼日心說比地心說更正確,畢竟哥白尼都死了嘛。

於是,我接受一個小時的羞辱。。。然後用心的表達:還是領導您技術好,我還需要努力的向您學習。

技術經理與需求

技術經理分為兩種,一種主要負責專案的,一種是主要負責產品的。

做專案的經理是幸福的,因為他們的需求相對明確,他們是在跟有型的客戶打交道。

做專案的經理也是不幸的,因為他們除了要受老闆欺負,還受銷售、市場等等部門的欺負,畢竟在專案中,任何崗位都比技術更牛B。

做產品的經理是不幸的,因為他們是在跟【無型】的客戶—【市場】打交道。

做產品的經理還是不幸的,因為他們也要受老闆、銷售、市場的欺負,而且還非常不穩定,一旦產品失敗,即將面臨背鍋離職。

一個做產品的技術經理能幹多久的,是產品的成敗決定的,而產品的成敗是要看市場的,因此,真正決定一個技術經理能幹多久的,是技術經理的市場能力和運氣。。。

所以,如你是一個做產品的技術經理,那你一定要,多下市場,多下市場,不要搞效率、搞框架、搞管理、就是要多下市場、儘量做雙線研發 ,研發除了銷售與市場的需求外,一定要做你發現的客戶核心需求。因為,做出一個客戶核心需求,比做100個假想需求都管用。

當然,坐而論道是不可避免的。

如果你主動下市場,哪怕只研發成功了一個需求,那你都可以多堅持半年。

但是,如果你不下市場,只是被動接受需求的話,市場認可還好,不認可的話,你的死期也就不遠了。

為什麼市場不認可全都怪研發?

因為人家要的是夜空中的星,不是夜空中的燈,【我又不是研發,我哪知道怎麼搬星星】,所以,不怪你怪誰呢!

什麼?技術經理搞市場,是不是太扯了?拜託,程式設計師修U盤就不扯了?

為什麼不老老實實的聽銷售和市場的需求?拜託,他們99%都是軟體功能說明書啊,他們要是能給你準確的需求,你得擁有多大的運氣啊。

一些心得

以前,我們總覺得有那些沒有技術還到處霍霍公司的領導很討厭。

現在,我發現,其實,有技術的領導也是到處霍霍。

產品:產品的成敗和領導技術好壞的關係並不大,產品的方向才決定成敗主要因素。

專案:專案如果已經簽定了合同,那麼,領導的技術好與壞,通常並不能影響專案結果,頂多影響延期時長而已。

----------------------------------------------------------------------------------------------------

注:此文章為原創,任何形式的轉載都請聯絡作者獲得授權並註明出處!
若您覺得這篇文章還不錯,請點選下方的【推薦】,非常感謝!

https://www.cnblogs.com/kiba/p/11572068.html

 

&n