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

• 2019 年 10 月 3 日
• 筆記

前言

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

一定要做一次技術經理

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

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

舉個例子，我是個技術經理，現在有一個項目，需要用到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