技術專家 or 技術管理？程序員職場規劃中如何定位？

作者｜陳靖華

編輯｜小智

戳「 閱讀原文 」，獲得簡訊提醒，不錯過下次 InfoQ 大咖說直播！

寫在前面

大家好，我是 Wood，來自聽雲。畢業於東南大學儀器科學與工程專業，畢業工作兩年之後就一直和好友一起自主創業，先後經歷過 2.5 次創業，從最初的 4 個小夥伴發展到幾百人的團隊，個人也從程序員逐漸轉變成技術管理者的角色。本次直播將向大家分享這 19 年創業中的一些小故事，聊聊技術管理轉型之路上的坎坷。希望能為大家的職業規劃提供參考建議。

程序員需要什麼條件去創業？

先說說自己創業的初衷吧。96 年從東南大學畢業之後到了廈門信達公司從事網站建設工作，非常幸運 95 年在學校的時候就早早地接觸到了互聯網，第一份工作也是和互聯網相關。所以剛開始工作就開始使用第一代的互聯網網站技術：Perl, CGI, HTML, Java Applet 等等，也第一次接觸到了 Linux 和大量的開源軟體，並很快地對 Linux 和開源軟體入迷了，這些開源的操作系統和軟體可能算是兩年後促使我走上自主創業的道路的原因之一。

在這個公司做了兩年的網站開發之後，1998 年就和 4 位同事和好友開始了自己的第一次創業，從事 Linux 下企業郵局和企業虛擬主機管理軟體的開發。

所以說起創業的原因，不喜歡被控制可能是主要的原因。那個時期接觸的兩本書給我創業的動機影響比較大，一本是《開源軟體文集：開源革命之聲》，彙集了當時開源和自由軟體運動的先鋒們（包括 Linus Torvalds, Brian Behlendorf, Larry Wall …）的思想，對我後期的技術發展和職業規劃產生了比較大的影響。裡面自由軟體的思想和精神也促使我在自主創業的路上一直走下去。

另一本書其實是一本雜誌《Linux Journal》, 當時除了國外的網站，這本雜誌算是我更深入和便捷了解 Linux 生態圈的一個最主要的途徑，當時還是託了在國外的同學幫忙訂的。這本雜誌除了為我拓展 Linux 生態圈方面的技術視野之外，在那個時期的 Slogan 也令我印象深刻。

大家如果還有印象的話應該記得那段時間微軟有一句非常著名的 Slogan 「Where do you want to go today」，而當時這本雜誌的廣告詞就是「Where do you want to go tomorrow」，一個關注的是現在，一個關注的是未來，從這 20 年 Linux 類操作系統的發展來看，也驗證了這句話。這句話從那個時候到現在依然是我的 QQ 簽名。

再回到我們的話題上來，程序員需要具備什麼條件才適合去創業？我感覺並沒有什麼條件限制著程序員去創業，如果有，更多的還是自己內心的想法和訴求。關於這個問題，我們之前在 EGO 小組中討論過一次，洪強寧洪教授給出的一個觀點感覺比較受大家認可，通常是下面四種情況：

想做某個事情，在別的公司做不了的；

喜歡賭未來的不確定性；

有控制欲；

不喜歡被人控制。

可能每個創業的人都會有自己的初衷，而我個人而言可能佔了其中的 3 點。情況基本上是第 4 個，第 1 個和一部分的第 2 個原因。其中 4 的原因可能更多一些，喜歡相對的自由一點的工作狀態以及技術上的獨立，不受商用軟體技術的限制，然後就是 1，想做某件自己喜歡做的事情，最後就是 3，賭未來的發展和趨勢，但是我不太喜歡不確定性。如果你屬於這四種情況中的一種或幾種，那麼我覺得未嘗不可嘗試一下自主創業。

當然創業的艱辛只有真正去做過的人才有深刻的體會，而幸運的是，如果你能堅持下來並且你的公司還活著，作為程序員，通常你在這個過程中學習到的東西和成長的速度要比在其他公司里工作多得多，快得多。

程序員向技術專家的轉型

在一個初創的創業團隊中工作，由於人員較少，有些程序員往往需要身兼數職，而這個人通常就會快速地成長為技術專家。這裡我們說的技術專家，並不單單指的是某一個技術領域的專家，而是可以更好地使用技術來解決各種問題的專家，應該是解決問題的專家。

在我自己這 2.5 次創業經歷中，自己也是從這條路走過來的。第 1 次創業，一共就 5 個小夥伴，其中就我們兩個寫代碼的，所以自己基本上什麼都干：產品設計，美工切圖，代碼實現，測試，打包，現場實施部署，售後支持等等。那個時候剛剛畢業兩年，並沒有太多的技術積累和經驗，也沒有人帶，基本上都是靠看書和網上的資料自學。那段時間接觸並閱讀了不少相關的開源軟體代碼和書，包括 apache httpd, sendmail, pam, 還有 Linux 內核等等。

當時剛開始做的第一個企業軟體是企業郵箱系統，選的是 sendmail 來做 MTA（Postfix 到了那一年年底才發布，不然可能不會這麼折騰了），而 sendmail 的配置文件又是出了名的難讀難寫，據說本來就不是設計給人讀的。為了搞定這個東西專門買了那本著名的蝙蝠書（Bat book，O』Reilly 出的 Semdmail 的書，封面是一隻倒掛著的蝙蝠）來啃，花了不小的功夫學會了配置文件的讀寫。那段時間可以算是我技術成長最快的時期之一。

第 2 次創業是從第 1.5 次失敗的創業過程中開始的，創始團隊的 7 個小夥伴也都是上一個公司的同事，和第一次一樣，剛開始也是什麼活都得自己干，只是這次還包括了售前和運維的工作。這次的創業到現在已經 10 年了，研發團隊也從原來的 7 個人發展到了現在的 100 多人，團隊里成長出了不少技術專家，大部分也都是從初級和普通程序員成長起來的，在有這些技術專家在的小團隊里，整個團隊的效率和自驅動力都會比較強。後來招聘的時候也專門留意去招有類似潛質的人員。

這裡面給我印象最深的是一起工作了十多年的甄志會同學，我們是在上一家公司開始做同事的，當時招聘他進來就是一位普通的 Delphi 工程師，他很快地在團隊里脫穎而出，代碼的質量和開發速度都很高，我們給他稱號叫快槍手，所以我們開始新的創業的時候就拉上了他。

這十幾年來，他始終保持著對技術的熱情，技術牛而且樂意幫助和輔導別人，團隊成員有問題也都自然而然地會去找他請教，這也讓他自己的技術能力更快的成長。在團隊需要去開拓新的業務和突破新的技術難點時，他始終是最積極的那一個，並且學習能力也超強，從單一的 Delphi 到後來的 C/C++, Java, .NET, Go 的各種開發語言，沒有一個不是現學現用，並且都做得不錯的。

去年我們公司做 Go 語言探針的時候，公司沒有一個會 Go 的，他就是主動請命和另外一位同樣出色的同學一起從 0 開始現學，倆個人用兩個多月時間把 Go 語言探針搞出來了。就在上個月他們倆又開始新的探索，挑戰一個新的語言平台的探針技術了。讓我比較自豪的是，在現在這個團隊里，這樣的類型的技術專家還有好幾個。

從程序員向技術專家的轉型往往都是自然發生的，只要個人在技術上的投入足夠多，這個轉型相對比較容易，但是並不是每個程序員都能變成出色的技術專家或技術領導者的。我發現最終會變成出色的技術專家或技術領導者的人通常會有以下的特質：

超強的學習能力，旺盛的學習熱情

願意接受挑戰，嘗試自己不擅長的事情和未知領域

樂於助人，樂於分享，有較好的全局觀和團隊意識

自驅動力強，勇於承擔責任

技術專家到技術管理者的轉型

從程序員向技術專家或技術領導者的轉型往往比較容易和順利成章，但是要再轉型成為技術管理者就比較困難了，要趟過不少坑，甚至可能轉型失敗。

1. 團隊失控的故事：談談技術管理者與技術專家的職責

第 1 次創業 2 年後，我們的團隊依然保持著 4，5 個人的規模，後來一家上市公司投資我們團隊，整個團隊就從廈門搬到北京來組成立了一個新的公司，實際上是投資的上市公司的子公司，從事企業軟體和電子政務軟體的開發。這就是我第 1.5 次的創業經歷。為什麼叫做 1.5 次呢？一個原因是因為這次的創業實際上是第一次創業的自然順延，另一個原因是這次創業最終是沒有結果的。

來到北京之後，在幾年的時間裡，團隊的規模從原來的 5 個人也快速增長到了上百人，我自己的職位也變成了總工程師，負責管理研發團隊。可怕的是，在這個過程中，我一直沒有意識到自己工作性質和工作職責的變化，依然將把自己定位為技術專家，大量的工作時間依然是花在編寫代碼和研究技術上。實際上，我個人一直是不擅長與人溝通和交往，恐怕是有輕度的社交恐懼症，所以對整個研發團隊的建設並沒有投入足夠的時間來進行管理，而只是沉迷於對技術的研究。

直到有一天，團隊中有個人帶走了一半的研發團隊成員去自立門戶，也帶走了公司的業務，我才幡然醒悟。雖然說這次團隊的失控和分裂還有很多外在的因素，但我認為疏於對團隊的管理是其中最重要的因素之一。這次事件給我的打擊非常大，我自己也因此低落了一段時間，開了一段小差後才回到團隊里，後來幾年也在重建團隊，努力去挽回失敗的局面，但是始終不見起色，最終這次創業算是以失敗告終。

這個事件給我的教訓非常深刻，讓我在後來的工作過程中能更清晰的去定位自己的角色。實際上在後面的這次創業中，自己依然又重新走了一次從程序員到技術專家再到技術管理者的轉型之路，在團隊還很小的時候，特別是自驅動性比較強的團隊，不需要太多的管理，可以把所有的精力都投入到技術的研究和代碼編寫里。當團隊規模逐漸增大的時候，就需要逐漸放掉一些技術上的投入，把時間的投入往管理上去傾斜。這個轉變的過程可能比較漫長，直到現在，我感覺依然還在學習和努力轉變的過程中。

在我們的團隊里，從技術專家向技術管理崗位的轉變是很多技術人員都經歷過，但是失敗率很高的事情。我認為這個轉變過程中，最重要的是個人一定要清楚這兩個角色的職責的差別。作為技術專家，你的職責是做深度的技術研究和實現，以技術能力和技術領導力為你的團隊和業務提供強有力的支持。而作為技術管理者，你的職責是團隊的組建、培養人員，做技術發展和人員規劃，以各種管理手段來明確技術發展方向，保持團隊的穩定和活力，為業務提供可靠的支持。

明確了職責之後的履行階段實際上對很多人來說也是相當困難的。困擾比較大的兩個問題一個是性格問題，是否喜歡和擅長與人溝通協調在這個過程中非常重要，而很多程序員包括我在內在這方面都是不太擅長的，不少人都也是在這一點上沒法轉變過來最終無法轉型的。但這個性格問題並不是無法轉變的，在內心主動尋求改變和外部條件的壓力下，我感覺在這幾年來還是發生的很大的變化的，有時候就需要自己逼自己去做一些自己不擅長的事。

另外一個問題就是管理時間和精力的投入問題。大部分的程序員和技術專家在向技術管理轉崗的時候往往都會在這裡掉坑裡，我自己之前的案例就是一個慘痛的教訓。很多人在這個過程中往往都會捨不得放下對技術的研究和寫代碼，害怕自己一旦離開技術太久就會代碼能力下降，被技術浪潮拋棄。

因為放不下寫代碼和技術研究，花在這上面的時間越多，自然投入的管理上的時間就會越少，最終很可能無法完成到管理崗位的轉變。一旦你確定了自己未來的職業發展方向是管理崗位，一定要儘早學會放手，把代碼和技術研究交給其他人去做，至少保證有足夠的時間投入到管理上。

2. 團隊組建的故事：如何組建合適的技術團隊

技術團隊組建是技術管理者最主要的職責之一，在技術創業公司里，技術團隊的組成是決定一個創業成敗的關鍵因素。第一次開始創業的時候，並沒有太多的經驗，根本也沒有做團隊規劃，5 個小夥伴完全是因為親密的朋友關係走到一起來做事情，後果就是 5 個人里只有兩個苦逼的寫代碼的程序員。團隊的組成非常不合理，互相之間也沒有很好的互補性。

這種狀態一直持續在第 1 次和第 1.5 次創業的過程中，團隊沒有規劃，有需求做不過來就加人，有認識的好朋友過來也加崗位加人。說到底還是之前說的問題，團隊管理沒有做好，並且在胡亂加人的過程中也在一些重要的崗位加入了價值觀完全不一致的人，所有這些都為這次創業的失敗埋下了伏筆。

第二次創業之前關於團隊組建我們就吸取了教訓，做了比較充分的準備。首先從可能涉及到的業務出發反推需要哪些技術和技能的人員和比例，例如做探針客戶端需要什麼人，做後端報表需要什麼人，做業務系統的需要什麼人，做後端數據處理架構需要什麼人，一一理清楚，有了最小配置的人員數量之後再去挑選合適的人員。

因為又是一次從頭開始的創業，而且初期的資金有限，並沒有辦法把原有的整個團隊都帶走，所以我們非常仔細地挑選初創團隊的人員，首先肯定是選技術能力的強的；其次是對每個技術合適的人員評估性格，主動性和價值觀是否符合要求，在這個階段加入的團隊成員能否保持一致的價值觀非常重要，因為這些人很可能將來會成為公司核心骨幹的技術專家或管理者，他們的價值觀最終將影響公司的文化。

這個過程中，我們在一個崗位的人選上，確實出現了不同的意見：有一個技術能力非常強的，但是在任何關係到他利益的事情上都會斤斤計較的員工，另外一位是技術能力很弱的剛畢業不久的員工，但是做事踏實認真。最終我們還是選了後者。後來證明我們的選擇應該是正確的，因為剛開始的兩年里，由於資金的問題經常有幾個月發不出工資來，如果選前者估計早就離開了，而後者到現在依然在我們團隊里並擔任著技術專家的角色。最後還要一個一個確認是否可以承受創業的不確定性。

這次團隊的組建我認為是成功的，所有的初創研發團隊都依然在聽雲的各自崗位上擔任著核心技術專家和管理崗位。

在過去 10 年的發展中，我們的團隊也加入了越來越多的成員，在這十年的團隊組建過程中，我們招到過能力超強性價比非常高的人（這些人非常稀少，一定要想方設法創造好的環境和條件留下來），我花過半年的時間各種軟磨硬泡挖來過技術一流的技術專家（感覺比追老婆還難），也跑到候選人的公司附近去做過面試。這裡面有太多的故事和技巧就不一一分享了，其中最重要的一點是關鍵崗位上的核心骨幹人員，一定一定要確認與團隊的文化和價值觀的一致。

3. 團隊整合的故事：價值觀的討論

說到價值觀的問題，再分享一個失敗的團隊整合的故事。還是上一家公司的經歷，當時團隊剛剛來到北京不久，由於新產品剛剛開始開發，又接了幾個項目人手不夠，所以通過朋友的關係從南京臨時找來了一個做外包開發的團隊一起做。後來做著做著就把兩個團隊整合到一起了，感覺還是挺自然而然的過程。但是卻忽略了非常重要的一個事情，就是被整合的團隊的頭的價值觀與原有團隊是否一致。

可能是由於外包開發團隊的原因，後來細想起來兩個團隊在對待產品和對待客戶等問題上觀點非常難保持一致，由於這些問題也導致矛盾越來越大，最終導致整合到一起的團隊又分裂了。不過團隊的價值觀也只是團隊整合里的一個重要根本因素，影響的因素還有非常多，這些年來也看過太多太多的失敗案例，成功的卻非常少。

以上是我今天的分享，希望能對大家在職業的發展規則中有所幫助。最後做個廣告，聽雲將在 8 月 10-11 日在北京舉辦 APM 行業會議APMCon，歡迎大家關注和參加。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！