【51CTO.com原創稿件】IT工程師的職業規劃讓很多人為了選擇技術路線還是管理路線很糾結，技術還是管理，程序員應該如何規劃自己的職業道路？技術崗轉管理崗會面臨哪些問題？如何充分展現自己的價值？技術出身的創業者該提前做好哪些準備？讓我們和左華棟老師一起探討工程師的職業發展路線選擇與規劃。

專家簡介

陜西本初網絡科技有限公司創始人，西安交通大學城市學院工商管理專業，大學時即成立簡凡工作室，團隊以給學校開發網站為主，在 phpwind9.0發布時，簡凡工作室制作了許多插件，成為了當時 phpwind9.0 插件模板最多的第三方開發商。后創立本初網絡，從事于網站建設等相關服務，涉及軟件、硬件，對于產品、技術、運營一體化都有非常豐富的經驗。

分享主要從以下四個方面展開

一、   技術還是管理，程序員應該如何規劃自己的職業道路？

1、  性格評估——適合做管理嗎？

2、  職業路線評估——是否必須做管理？

二、   技術崗轉管理崗會面臨哪些問題？

1、  技術選型。

2、  是否適合敏捷開發。

3、  如何避免人治。

4、  執行是管理成敗的關鍵。

三、   如何充分展現自己的價值？

1、  團隊協作能力。

2、  進度把控能力。

四、   技術出身的創業者該提前做好哪些準備？ 

1、  做好人心會比技術復雜多的充分準備。

2、  管理成本會隨人數的增加而大幅增加。

3、  做好管理成本與開發成本的權衡。

首先，很感謝 51 CTO 能給我這次分享的機會，感謝大家給我啰嗦的機會，也感謝碼云Gitee 一直以來對我們項目的支持。很慚愧的說，我并不是一個成功者，而是有著不少失敗的經驗的失敗者吧，我把我們團隊在技術和管理過程中所遇到的一些坑和解決方式分享給大家。由于是我這邊是 Linux Mint ，QQ 可能會有崩潰的情況，希望大家多多包容。

以上是我今天大概要說的內容

一、   技術還是管理，程序員應該如何規劃自己的職業道路？

第一個大問題： 技術還是管理，程序員應該如何規劃自己的職業道路

首先做性格評估——適合做管理嗎？

關于這個問題，網上可能已經有上百種答案了，很多都是一些比較有道理的廢話。而我想從經驗角度來談談這個問題。

優柔寡斷，有選擇困難癥，朝令夕改的，使被管理者摸不著頭腦，對公司的管理層的公信力產生質疑。

可能在最初的管理中，由于缺乏自信，多少會出現這樣的情況。在我們初期也遇到了這個問題，凡是涉及全公司的制度和政策，都統一口徑通知，先做一段試行，看整體情況，即使要修改，也必須等到下一次全員通知。不過這點不用過度擔心這是屬于可克服的缺陷。平時的工作中要多注意這些問題。

悲觀情緒嚴重，缺少安全感，凡事總先看到缺點，悲天憫人，總有刁民想害朕的妄想型。這種情緒問題是比較嚴重的，往往會給團隊帶來負面影響，團隊更需要一些積極向上的正能量，如果管理層都充滿悲觀情緒的話，被管理者肯定也不會有太多的積極性。這個問題比較嚴重，建議先克服心理因素。

這種情緒會影響開發團隊，所以遇到事先往好處想。

不喜歡擔責任，遇事先找個替死鬼的。容易動怒，經常責怪被管理者沒有執行力，一心想找人給被管理者培訓打雞血的?？梢哉f，這種很常見，也很普遍，有很多中型的企業，也喜歡給員工培訓洗腦，讓有被管理者執行力，但是這種打雞血行為恰恰是管理者不想承擔責任的借口。這種情況在中型公司比較常見，實際原因來說：一是管理者沒有多次強調，二是被管理者利益與公司利益矛盾。這個問題在初期影響不明顯，建議在工作中逐漸克服。有些企業還動不動就搞培訓，搞講座，想通過這種方式提高執行力，實際最需要提高的是管理者本身。我之前有看到一個說法是：日企的執行力高是因為他們經常把任務重復三遍以上。

注重人情關系，工作生活不分，憑感覺做事，獎懲不明的。首先，在工作上盡量撇開人情關系，如果確實難以取舍，建議還是不做管理，否則會導致公司拉幫結派嚴重，內部腐敗等問題。獎懲也好，一定要建立在公司制度上，在此之外需要特批的，也得走流程進行申請，然后不斷完善制度。這個問題比較嚴重，我建議還是能盡量先克服。

這個問題比較嚴重，我建議還是能盡量先克服。我們團隊之前也發生過類似情況，覺得相處時間比較久了，不忍心辭退比較負能量的員工，結果最終影響到了核心成員的離職。總的來說，對公，該干什么還是干什么，爭執也好，獎懲也罷 ；對私，該吃飯吃飯，該玩樂玩樂，能準確處理好這種關系十分重要。

我們公司離職的員工有時候也會來一起吃個飯什么的，管理者的心態應該是：反正上輩子又沒有仇，哪里來那么多怨。

在我們團隊初期由于缺乏統一的統籌規劃以及各自過于獨立，導致大家一直在做自己認為對企業正確的事情，結果造成了嚴重的資源浪費。兵熊熊一個，將熊熊一窩也說明了管理者性格的重要性。

所以做事也不能一直特立獨行，我行我素，縱使很有能力，也有可能起到負面作用。

2、  職業路線評估——是否必須做管理？

做完性格評估后，接下來，要知道是否必須做管理，或者說走管理的路子。

管理是很多程序員的路線之一，但不是必然路線，管理也不是高高在上享清福，權力越大，責任也越大，比如要求后天上線，而你有十幾個程序員苦于修 BUG，這時候你應該怎么辦？找外援，加班？外援如何快速熟悉公司項目，加班薪資怎么算？怎么避免不滿情緒，如果加班都沒做完又怎么辦？如果看到這已經焦頭爛額了，就重新思考下，是否真的那么想做管理吧。

好的管理不一定有好的技術，但起碼要讓被管理者信服，尤其是存在程序員鄙視鏈的情況下，舉例來說，比如某公司的商城系統，據說 PHP 全部換為 JAVA，原因是技術總監熟悉 JAVA，覺得管不了 PHPer 。

當然，也有一些喜歡傳統的，用FTP 管理代碼，導致大家每天要下載5G 左右的代碼和文件做同步，經常相互覆蓋文件，而且公司不做代碼規范。這種情況的話，如果還想對自己技術有所提升，要么自己參與管理，要么還是盡早離職吧。

最終路線評估，我還是希望大家能做個表對比下，看看哪些是可以舍棄，哪些是可以克服的。
|-------好處--------|-----壞處-------|
|--能提升自我--|--人情關系可能不那么融洽了--|
|--能夠嘗試一些新的技術棧--|--對項目管理沒有經驗--|

順便插一句，用FTP 管理代碼的那哥們的團隊后來集體開了個迅雷會員，來解決下載問題。

二、   技術崗轉管理崗會面臨哪些問題？

然后第二個大問題： 技術崗轉管理崗會面臨哪些問題？

1. 技術選型

技術選型是作為一個技術管理者不得不考慮的問題，除了結合現在公司情況和業務與市場情況，還應該了解人才招聘情況。

我們一開始主要做 web ，后端選用了 PHP ，為了代碼質量，用了 Laravel 框架，但是在西安，Laravel 特別難招。隨著 vue 的發布，我們公司后端 Laravel 前端 vue ，一定程度上減輕了后端工作量，但 Laravel 招聘問題一直沒得到很好的解決，人員流動比較大。

后來隨著業務范圍的拓展，發現 純 PHP 越來越難以單獨勝任一些高并發以及嵌入式的場景，尤其是單頁應用盛行的今天，更需要后端提供 API 。這期間也了解了swoole 和 reactphp ，但是相對來說招人就更困難了，培養成本更高。

node.js  招人也十分難，于是最后決定招 java 轉node （考慮成本等原因，招的并不是成熟的 java 工程師），為了減少不適應的情況，同時我們也期望有更好的架構，我們選用了 nest.js 框架，這是一個 node 版的 spring，同時也用 typescript 統一了前后端語言，為了更好地適配 typescript ，我們最終選用了 React （下載量使用量多，社區成熟穩定）。

通過這次轉型，我們實際開發成本下降了有30-40% ，開發效率提升了20% 以上，同時性能還有大幅度的提升（業務場景下，node.js 異步非阻塞機制表現十分出眾），當然不是說 PHP 不好，只是說如果想用一些好的技術和框架，還是應該考慮當地人才市場情況。

有技術選型困惑的倒是可以一起交流交流，只是技術選型這個問題上，不建議盲目追新，要考慮實際情況，當然也不推薦太過于守舊，嘗試一些新的技術，對自己以后發展還是有好處的。不用過分糾結于語言的好壞，主要還是看市場需求。

2、是否適合敏捷開發。

敏捷開發基本上是一個好公司的標配了，盡管如此，我還是不建議一些小團隊使用敏捷開發，一方面他對管理要求特別高，尤其是在公司項目管理還沒成型的情況下，盲目推崇敏捷開發可能適得其反，最終導致相互推卸責任。另外，團隊人員不穩定的情況下，敏捷開發也不適合。當然如果以上問題都不存在的話，那我強烈建議轉型為敏捷開發。我們目前是敏捷開發和瀑布流開發混合使用。

另外，不管使用不使用敏捷開發，我都建議使用 git 來做代碼管理。不論是 GitHub 還是還是更符合國內使用習慣的碼云Gitee 都可以實現，最重要的是：碼云創建私有庫是免費的，這點比較良心，做個代碼“網盤”不錯。以我們團隊情況來說，主要有三個分支，一是對內開發，二是對外開發（接的一些外包），三是我們開源項目 Notadd ，相當于三個團隊，用碼云企業版管理和分配任務，以及查看任務統計大大方便了我們。

這是我們團隊的 Notadd 開源倉庫：  https://gitee.com/notadd/  

（基于新技術棧的開源模塊化開發框架，能大大減少項目構建成本，目前開發有 PHP版和 node.js 版），這是我們團隊的主要項目，我們期望未來開發都是可拓展，可大量減少重復工作量的模塊化開發方式，同時又使用一些新的技術不斷提升用戶體驗，歡迎大家給我們提交 PR。

根據我們的使用經驗，碼云更適合中小型開發團隊，除了能滿足基本的代碼托管外，還能方便的支撐項目管理和文檔協作方面的需求。當然小型團隊可以使用個人版本的碼云，創建私有庫就可以。

3、  如何避免人治。

對事和對人的看法一定要分開，對管理者來說，這是很難能可貴的品質。對事不對人，這點十分重要。關于法治問題，這個我倒是推薦看看 《大秦帝國：裂變》 關于商鞅變法這段，想對于齊國而言，只有商鞅的法制能夠最終得以延續。

講個典型的人治例子： 我之前有個朋友8點去公司，老總8點10分發通知，說是所有人必須8點40之前到，由于他沒看手機，然后“遲到”，老總為了立威扣了他200元工資，扣不扣，扣多少都是老總說了算，沒有相應制度，于是他選擇了離職。

在管理上，存在漏洞是正常的，但是應該正確認識到問題，修改相應的規則，并進行通知，而不是全部特殊處理。

[[218079]]

另外，平等并不代表絕對的公正，管理上還應該考慮個人差異。

4、  執行是管理成敗的關鍵。

這里的執行說的是管理者的執行，作為管理者應當對制度進行嚴格的執行，制度可以寬松，但是執行必須嚴格。初期一定不要怕麻煩，形成習慣以后就是良性循環了。

即使不是自己去執行，也應該對執行者做深入的考核，保證執行的有效性。

不談獎懲的制度都是耍流氓，如果違反相應的制度，應該接受怎樣的懲罰，這是應該提前定好的，否則后續執行會有很多坑。

三、   如何充分展現自己的價值？

1、  團隊協作能力。

作為管理來說，應該培養的是一支團隊，而不是某個人才。團隊協作能力是一個基礎，使用git，制定代碼規范，命名要求，環境統一等 都是盡可能減少團隊成員之間差異的方式。

實際上由于個人能力差異，經常會出現 A 寫的代碼，B 得費很大勁才能看懂，那這時候就應該考慮每個成員必須在開發過程中應不斷完善開發文檔和說明了。

還有一類情況特別普遍，尤其是對于一些沒有經驗的程序員，比如一個小功能，他首先不是去 GitHub 碼云 Gitee去搜，而是自己寫，等填完各種坑后才發現，網上有大神寫好，并且開源的東西了，很多工作都等于白做了，一定要培養搜索的習慣，，當然也不建議什么都搜，我們公司之前也有，搜了以后糾結用哪個好，然后又查了幾個小時。公司建立一個常用開源庫也是不錯的，大家把自己常用到的好的庫鏈接都放上去。

2. 進度把控能力

如果做項目管理不做好進度把控，這會導致在很多公司不受待見。進度是很多開發公司的生命線。

一方面做好時間的評估，項目允許的時間，項目管理安排的時間，由于個人能力差異可能完成的時間，并且預留大把的時間做 BUG 修復工作以及應對可能存在的項目延期。開發者所給的時間經常不靠譜。

過程中要做好按天管理的進度把控，在時間評估上不建議包含周末，而在實際開發調整過程中，可以根據項目情況決定是否要包含晚上和周末（加班）。如果加班比較頻繁的話，建議在項目完成后多給開發者休假時間。

緊急補救，一般來說，這時候找外援補救，除非對方經驗十分豐富，否則很難做好補救措施。我們也遇到過補救團隊跑路的情況。另外一方面也要盡可能跟銷售和市場方溝通，盡量平復甲方的情緒，同時可以先上線一部分主要功能。如果這樣的情況較多，可以找靠譜的團隊長期合作（救火專用）。

不要做過多的進度承諾，盡量預留較為充足的時間，千萬不能對項目進度迷之自信。同時保證項目代碼的的安全性，項目代碼全部以 git 提交為準，既方便了協作防止代碼沖突，也能防止一些意外發生，我們是有硬盤損壞的血淚史的。

代碼管理是自建系統還是用云平臺？實際上，中小型企業自建 gitlab 的成本較高，而且也不能保證代碼不被丟失。而云平臺會做多份存儲與定期備份，即使本地和遠端倉庫被誤刪也可恢復，這是自建所無法媲美的。建議有條件的團隊購買一些付費版的 Git 托管平臺，一般都有協議保障，我們團隊 Notadd 項目 之所以會使用碼云，也是為了防止上述悲劇的重演。

四、   技術出身的創業者該提前做好哪些準備？ 

最后一個大問題： 技術出身的創業者該提前做好哪些準備？ 

1. 做好人心會比技術復雜多的充分準備
即使是如此全能如此復雜的 AI 也難以判斷人的喜怒哀樂，那么作為管理者要面對的這些問題更加復雜了。舉個比較有意思的例子，說是有個皇帝喜歡石頭，就派官員去全國各地找漂亮的石頭，起初，很多平民也上交一些奇異的石頭換取金錢。再到后來，形成了一股挖石頭的熱潮。最后淪為了一些官員的濫用職權的借口，說你家地底下有好石頭，需要把房子扒了，挖石頭。

做管理也是一樣，很多事情，可能初心是好的，但執行起來卻最終變了味，最終的結果就是好心辦壞事。

我們也經常遇開發者踢皮球的事，前端甩鍋給后端，后端甩鍋給前端，也有怕得罪人，自己背鍋的情況。權責劃分一定要明確，有問題一定要當時提出（比如后端接口沒寫完），防止踢皮球的現象。

2. 管理成本會隨人數的增加而大幅增加

起初幾人的團隊管理，可能這個問題還不明顯，但是一旦人數上漲，管理成本會很快上漲。

我舉個簡單的例子：比如要解決一些銷售人員的貪污問題，做了一個銷售監察小組，然后為了解決監察小組的貪污問題，又做了一個監察 監察小組的 小組，如此循環，管理成本必然大幅提升，而最終創造價值的卻是銷售人員。

知乎有一篇文章比較有意思，值得一看：

https://www.zhihu.com/question/22977065/answer/236152323

刷盤子的故事，為了解決洗滌靈被偷拿的問題（小成本），而最后動用的管理成本已經遠遠超過了洗滌靈的成本。

3. 做好管理成本與開發成本的權衡

管理是手段，并不是目的，小團隊做過度的管理是極不推薦的，跟上面提及的一樣，別為了管理而忘了最初的目的。

實際上要做好管理成本和開發成本的權衡，要考慮這樣做能帶來多少效益和價值，同時損失多少人力用做了管理。這樣做的目的是什么，有沒有更簡單的方式？

總之，管理上增加小的成本，解決大的開發成本，是比較推崇的。

在結尾，我還想扯點別的，作為管理者，我總聽到有人在說 “存在即合理”，但這是一句被人誤解的話，這里的合理也并不是合乎人倫道理，要結合原文哲學思想來看，而是說合乎它存在的絕對精神，不然法律和犯罪同樣存在，為什么法律還要制裁犯罪？今天就到這里，感謝 51CTO 提供的平臺，感謝開源中國以及碼云的大力支持，最后，對我們項目有興趣的童鞋，歡迎star 我們的開源項目 Github： https://github.com/notadd/notadd 碼云（Gitee）： https://gitee.com/notadd/notadd （Node.js 版正在開發喲）后續也期望和大家能探討出適合的管理方式，再次感謝大家聽我啰嗦。今天由衷地感謝 51CTO 的小官，沒有他就沒有精彩的推送。

以下問題是來自51CTO開發者社群小伙伴們的提問和分享

Q：Java-果凍-沈陽：老師你認為，程序員轉管理崗位最大的難點是什么？

A：本初網絡-左老師：克服自我性格缺陷。技術可以提升，能力可以培養，性格缺陷改起來比較困難。

---

Q：Java-藏洗：我現在比較迷茫，不知道怎么提升了，中級的。又感覺基礎差 然后新技術也不知道咋樣去學習 就反反復復 不知道學習哪方面對自己提升大。感覺是不是搬磚太多導致的？

A：本初網絡-左老師：迷茫在哪里？ 是覺得開發累，還是覺得領導2？先找一個方向先學， 比如 做業務，注重架構，那就java 寫接口 node ，深度學習 python 做web ——php?？蚣艿脑?，建議還是先學比較通用的，然后再學比較先進的，學會一個，其他的就比較容易融會貫通了。

---

Q：Java-藏洗：老師，自考的學歷，有用么？

A：本初網絡-左老師：中小企業學歷沒那么重要，但問問題你得要回答得上。之前貼吧有人面試吹牛說自己能寫分布式搜索，結果16K錄用了，但是....

---

Q：Java-藏洗：貌似現在問的問題好多都是底層原理，這個應該咋整？

A：建議先從 linux 看起，然后多了解一些技術文～ 興趣對這方面的提升會特別快。

---

Q：寥寥1157：中專生應該往哪個方向？

A：本初網絡-左老師：說個比較現實的情況，很多企業還是比較看中學歷，尤其是500強。如果你有能力帶一個團隊，可能情形會好很多。

---

Q：C#-LMY-煙臺：應屆生在公司沒人帶，做起來很費力，這時候應該怎么提高自己？

A：本初網絡-左老師：如果有技術負責人，可以多請教他，另外可以找領導去談心。另外，也可以自學一些課程，我身邊也有一些電視臺學編程的，電視臺工作的。

---

Q：Java-果凍-沈陽：程序員轉項目經理先考一個PMP靠譜嗎可行嗎？

Q：移動安全-軍閥-北京：老師，我也比較好奇，PMP靠譜么，值得考么？

A：本初網絡-左老師：可行，但也要注意積累項目經驗，實際的情況會比較復雜。

---

Q：小白-Commander-深圳：我現在零基礎，該怎么學？想做web。

A：本初網絡-左老師：還是看方向，你是想做web 還是想做接口什么的?？梢钥纯?node.js 或者 php，有js基礎，打算深入學web，就選前者，反之選后者。但是PHP目前情況來說， 只會 thinkphp一個框架 的程序員比較多， 整體水平會偏低，如果你做的比較深入一些的話， =薪資也會很高。

---

Q：java-亞風-合肥：為什么要用nodejs？

A：本初網絡-左老師：看github 的年度報告，一是 JS 的開源項目越來越多，二是大公司越來越喜歡 js 及衍生產品。三是 npm 上包的數量。node 現在的優勢，一是前端好上手，二是相對 php 存在性能優勢，三是生態。當然 php 的web 地位暫時不會有語言能撼動，很多公司也會考慮開發成本。這個看企業情況，招人是成本，開發效率是成本，維護也是成本。

如果你是技術負責人的話，我建議你在企業成本增加不是那么明顯的情況下，使用新技術。公司角度看的話，也看業務了，如果是做外包，維護一堆系統的話，那還是不要盲目升級。

---

Q：網管-獨奏-貴州：@本初網絡-左老師 老師 能說說你自己的職業規劃嗎 我們學習下

A：本初網絡-左老師：每個人情況不同，存在個體差異。

---

Q：小白-Commander-深圳：自學該怎么學？

A：本初網絡-左老師：慕課網、騰訊課堂都可以。

---

Q：后端-陳醫生-北京：關于技術選型 上面說到是團隊決定 那業務怎么去考慮這個問題？

A：本初網絡-左老師：比如你搞嵌入式，能選的就只有C、C++，你搞web 能選的就PHP、node.js、java。你搞接口node、golang，搞算法python、golang、C++。不同語言都有自己的適用范圍，然后再權衡成本和副業的情況。

---

Q：后端-陳醫生-北京：業務發展到一定程度是技術從新選型還是增加擴展性？

A：本初網絡-左老師：也是看業務情況，如果歷史包袱比較重的話，優先考慮拓展性。歷史包袱不重，而且重新選型能解決現有的很多問題，那就考慮重新選型。沒有絕對的對錯。

---

Q：網管—獨奏—貴州：技術，由于金融行業的關系，已經不養自研團隊了。年齡也是個檻，正好學習下，重新找到方向。

A：本初網絡-左老師：您那邊具體情況我不是很清楚，但是我也建議您列個表做個對比，自研團隊有自己的好處。不自研，也有它的好處。

---

Q：C++-豐息-西安：想請教左老師，怎么培養團隊的技術氛圍

A：本初網絡-左老師：先解決產品和技術的關系，讓產品了解技術。我舉個例子，武漢深度科技，周五會有BUG大賽，看誰消滅的BUG多，如果平時有時間的話，可以做個內部的技術分享會，一方面讓開發者學新的東西，另外一方面讓他講出來和大家討論。

---

Q：架構-熊大-成都：看誰消滅的BUG 多怎么操作？

A：周四讓產品把 BUG 整理出來，周五依據 解決的 BUG 數量做排名，然后可以有小禮品，我只是舉個例子。

---

Q: 網管—獨奏—貴州:32歲，銀行程序員，轉做業務崗嗎？銀行大部分都是外包的，管理層很少有晉升通道跨行業轉崗呢？還是跳槽？舍不得銀行待遇。管理只有業務人員能上任 目前20k，但是沒有晉升通道。

A：本初網絡-左老師：銀行體系我不是很清楚，但是 1是你精力得耗得起，2 是你現在追求穩定不？ 尤其是考慮家庭方面。

---

Q：網管—獨奏—貴州：跳槽出去，很多公司還要30多歲的程序員嗎？幾乎銀行的很多系統都是我牽頭對接的，懂很多東西。

A：本初網絡-左老師：我覺得你那個位置的人際關系要比你說的那個能力更重要。

---

Q：Java-深圳-Fandy：我關注了一些招聘要求，目前IT行業招聘項目經理都對技術要求比較高，但是實際開發過程中，很多項目經理一般只做統籌、設計或技術選型，不參與實際代碼編寫或技術問題處理，這是不是一個矛盾的問題，招聘要求會不會限制了技術項目經理的職業發展，或者是提高了跳槽或深入發展的門檻？對于項目經理到底是偏管理還是偏技術，我感覺現實中對技術要求高一點。

A：本初網絡-左老師：一般的外包公司除外，只要這個企業在正常發展，接觸的技術一定是越來越多。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】