前言

2016年元旦假期結(jié)束了，那應該回到正常的工作狀態(tài)了。今天分享的這篇文章來自贊助跑男的美麗說前端團隊負責人@Alien童鞋分享的技術工程師成長之道。

該文作者授權(quán)前端早讀課以原創(chuàng)標志，感謝信任。

正文從這開始～

近來有業(yè)內(nèi)朋友與我討論一些工作方法，聊得碎了些，今天閑來無事，索性再用文字的方式，簡單描述一下我的工作方法（Alien style）。當然，每個工程師都有自己的獨特的成長之道，所以，本文標題擬為其中之一道，下文如果您如果感興趣，就當消遣看看罷了。

一、找準興趣點：認識自己

作為新手程序猿，首先要清楚的認識到，從什么開始做起，才能讓自己覺得，工作，是一件非常開心的事情！

作為技術工程師，能選擇作為職業(yè)方向的也不少，比如：

1）Web前端工程師（也稱FE，有的公司分的更細，比如Html/Css工程師、Javascript工程師等）

2）后端工程師（也稱RD，諸如：PHP工程師、Java工程師等等）

3）客戶端工程師（較多公司也將其歸為RD，諸如：iOS工程師、Android工程師等）

4）數(shù)據(jù)分析與挖掘（一些公司叫做BI或DI，平時產(chǎn)品業(yè)務會少一些，主要做一些大數(shù)據(jù)分析和處理，C或者Shell等腳本用的會多些）

5）測試工程師（也稱QA，主要負責各種產(chǎn)品功能的白盒/黑盒測試，發(fā)現(xiàn)其中潛在的Bug，即質(zhì)量檢測）

6）數(shù)據(jù)庫工程師（也稱DBA，屬線上運維工程師的一種，不過是著重負責各種數(shù)據(jù)庫的管理）

7）運維工程師（也稱OP，主要負責各種開發(fā)、測試、線上環(huán)境的運維，對線上服務穩(wěn)定性提供保障；也是命令行用的最多的一個角色）

每一種角色，平時的工作狀態(tài)必然都是不一樣的，通過寫碼得到的成就感也是不一樣的。

作為一個新碼農(nóng)，如果你希望自己寫的代碼，能最直觀的變現(xiàn)成用戶看得見摸得著的東西，因此而獲得工作上的成就感，并且因此而愛上這份工作，那么選擇Web前端工程師或者客戶端工程師，定是較好的。

倘若你更希望每天通過命令行，在線上各個服務器之間跳來跳去，并且敲一堆別人看不太懂的命令，寫一堆別人看不太懂的腳本，并因此獲得成就感，感覺更具有高逼格，那么選擇運維工程師，一定沒錯了！

一些剛畢業(yè)的學生，很有必要在投簡歷求職之前，搞明白自己想做什么；當然，也有大部分學生是通過校招進入到公司的，具體進去以后做什么，可能都是公司隨機進行分配；對于這一部分的同學，如果在入職后一段時間內(nèi)無法在工作上找到興趣點，就真該考慮申請transfer到其他Team了。

工作不應該僅僅是是掙錢養(yǎng)家糊口的一個工具，更應該是做人做事、成長道路上的一種樂趣。做自己喜歡的事情，再辛苦，也值得（切莫誤解：不是推薦大家加班，哈哈）。

二、注重沉淀：充實自己

沉淀，是能最直接證明自己有收獲的一種方式，可以是文檔沉淀、技術沉淀，等等

工作過程中，我們肯定會去做一些技術調(diào)研、方案分析與評審，這些東西便可以細細整理成文檔，統(tǒng)一匯總到一個地方，比如團隊的wiki專欄下，自己能去review，組里其他同學也能查看到。

在一些大項目開展過程中，或多或少會針對某一類問題創(chuàng)造出比較優(yōu)越的解決方案，可能是一種高性能的實現(xiàn)方式、也可能是一種高效率的調(diào)試技巧，這些東西，稍微花點心思，都能將其作為一個類庫或工具提供給組內(nèi)其他同學，以此作為技術點，沉淀下來。

簡單來說，可以把握這樣一個原則：

1）能用文字記錄的做事方式方法，就一定不要只靠口口相傳！用嘴巴傳來傳去，慢慢的也就走了形了，俗話說的好，好記性不如爛筆頭！

2）好用且實用的技術實現(xiàn)方式，能抽取成組件或類庫的，就盡量讓它最大限度的復用起來，并伴之以盡量詳細的使用文檔！切莫針對類似的功能，在組內(nèi)還不停的造輪子！

3）多看多寫多調(diào)研（有時候需要以玩兒的心態(tài)去學習）；但做技術的，若無實際產(chǎn)出，那只叫瞎折騰，知其然而不知其所以然，效果并不佳

就我個人而言，無論是在百度，還是美麗說，所有我能夠去沉淀或者幫助大家一起去沉淀的東西，一定都不會放過。

如文檔方面，我們搭建了團隊專屬了文檔平臺，有項目設計與實現(xiàn)方案的評審文檔、有項目總結(jié)的分享文檔、有大型項目的排期節(jié)奏跟進文檔、有技術的調(diào)研文檔、有團隊技術分享的文檔、更有團隊周報的歸檔專欄等等。

在技術方面，有符合團隊開發(fā)規(guī)范的集成解決方案、編譯工具、開發(fā)工具、前后端線上服務監(jiān)控與報警系統(tǒng)、后端服務性能監(jiān)控與分析平臺等等。

在玩兒技術的這一點，比如Web前端助手(FeHelper)就是在百度做前端的時候，玩兒Chrome擴展，一步步沉淀下來的。記得當時CSDN還舉辦了一個Chrome瀏覽器插件開發(fā)中國區(qū)大賽，這FeHelper也迷迷糊糊拿了個三等獎。

再后來微信公眾號興起，在朋友圈鋪天蓋地的轉(zhuǎn)發(fā)都是只有一個標題，很土；正碰上那一段時間2048小游戲在PC和Wap上特別火，于是我也寫了一個放到自己公眾號，本著讓大家一起能夠在微信里玩兒起來的心態(tài)，于是搞了一套基于微信公眾號分享的SDK，應用到這個小游戲里；這就是大家后來一直在使用的WeixinApi。在微信一直沒有推出官方版的js-sdk之前，WeixinApi造福了許多人。

任何形式能讓別人看得見摸得著的東西，才叫做沉淀，更是可以用來衡量價值的參考。

三、做一個項目負責人：歷練自己

接受Leader的命令，并能單槍匹馬的把產(chǎn)品功能做完上線，這頂多能夠算得上能做事，離會做事、懂做事還差得遠

如果有一天你覺得自己能夠獨當一面去負責一個產(chǎn)品功能，不再需要導師和Leader的協(xié)助，那么，是時候從更全的維度去歷練自己了：主動挑起一個項目，作為項目負責人，將其推行到底！

你至少可以從這幾個方面，得到更多的收獲，找到更多的成就感：

1）分析需求，判斷該項目需要涉及到的相關角色

2）組織各角色進行項目需求評審，并分析產(chǎn)品功能上的技術可行性、時間成本等

3）對需求進行功能模塊合理拆分，落實前后端工程師的工作范圍

4）組織前后端工程師進行技術方案評審，并結(jié)合需求指定的上線時間判斷是否需要分優(yōu)先級分批次開展

5）合理分工，產(chǎn)出研發(fā)排期，并匯總聯(lián)調(diào)、自測、以及QA的測試工期，統(tǒng)一輸出項目的排期

6）跟進項目進展，結(jié)合排期Review項目產(chǎn)出，及時發(fā)現(xiàn)風險點，及時調(diào)整并通報

7）較大的項目，更有必要組織定期的站立會，以確保項目整體進展順利

8）項目過程中有臨時新增需求、或需求變更、或技術實現(xiàn)方案調(diào)整，更要能條理清楚的與所有角色進行分析，放眼大局觀，結(jié)合項目的整體上線要求，輸出最終的調(diào)整方案，保證項目穩(wěn)健開展

9）測試前期，需要和QA明確其中的核心測試點，對于技術實現(xiàn)較復雜的地方，需要明確告知測試的力度，以免測試用例覆蓋不全

10）項目上線前，需要與運維工程師完成一切線上環(huán)境部署與配置，確保項目上線毫無障礙；對于涉及到邊緣產(chǎn)品較多的項目，更需要考慮到災備預案情況

11）項目完成測試后，如果是較大的產(chǎn)品需求，需要和產(chǎn)品同學討論，是否進行公司內(nèi)部體驗，或者線上小流量（灰度）測試；并提供合理的問題反饋渠道，收集并整理用戶反饋，快速優(yōu)化

12）項目上線后，需要密切關注服務穩(wěn)定性，關注用戶反饋，穩(wěn)定后，能進行項目上線通報

13）組織項目組所有角色進行項目總結(jié)，分析各角色在項目配合過程中出現(xiàn)的問題，總結(jié)經(jīng)驗教訓；同樣也記錄項目中良好的問題處理方式，最后將項目總結(jié)分享到團隊；以此結(jié)束整個項目！

槍打出頭鳥，只要你是帶頭大哥，項目出現(xiàn)任何問題，Leader必然都會唯你是問，整個項目過程中，必然是會產(chǎn)生壓力的！但是，如果你永遠都不敢邁出這一步，又怎能知道自己能力究竟有多大呢？胸懷都是用委屈撐大的，大膽承擔，沒事兒！

所以，大膽去做吧，團隊一定都是更喜歡敢于主動挑起責任擔子的人的！

四、做一個導師：學會育人

將所有成熟的工作方式，傾囊相授，也從新人身上做自我反省

優(yōu)秀的做事方式，應該得到傳播，讓更多的人花更少的時間去變得優(yōu)秀。工作中，最好的方式，就是在自己成長以后，做一個導師，協(xié)助新人一起成長，比如：

1）結(jié)合新同學的工作能力、業(yè)務范圍、技術興趣點，一同分析Ta成長過程中真實存在的阻力（或盲點）

2）為新同學量身定制短期、中期、長期的成長規(guī)劃，定期Review成長得失，及時糾偏

3）帶著新同學一起去嘗試一些大于Ta現(xiàn)階段工作能力的事情（業(yè)務功能、技術Topic等），幫助新同學挑戰(zhàn)自己，逐步突破自身的能力極限

4）學會放手，做好引導和后備支撐，讓新同學完完整整的去搞定一件事；栽了跟斗也不要緊，任何人成長的過程中都應該經(jīng)歷一些坎坷；不經(jīng)風雨，又怎見彩虹？

5）引導并督促新同學進行文檔和技術各方面的沉淀，協(xié)助新同學在團隊里找準自己的定位，站穩(wěn)腳跟

6）引導新同學學會分享、學會與其他角色的溝通技巧、并逐漸學會把控項目的全局觀

當然，你也需要從新人成長的過程中，不斷的反思自己，新人做的不夠好，是我的原因嗎？新人做的很好，我有功嗎？

新人某個功能沒做好，是不是自己沒有提前Review他的項目實現(xiàn)方案？或者自己給他的方案本身就是有問題的？

新人某個項目Delay很嚴重，是不是自己沒有多去Review他項目的進展？或者自己也沒搞明白項目的上線計劃是什么？

新人某個項目Bug太多，是不是自己沒有盡到一個導師的指責，為他做好Code Review？或者自己平時的項目就是Bug頻出，新人只是效仿而已?

新人在其他角色面前總是沉默寡言，是不是自己沒有告訴他，應當大膽表達自己的想法？或者自己也不敢在人前多說話，自己也怕被拍？

新人在與其他角色溝通過程中，沖突不斷，是不是自己沒有教給他更好的溝通方式？或者自己也不會與人溝通，自己也經(jīng)常與其他角色鬧得不愉快？

新人用一些很巧妙的方法把某件事情完成的很漂亮，得到大家的贊許，是不是自己給了他很好的引導？或者從這件事上面，你發(fā)現(xiàn)自己也有不如新同學的地方，你們需要互相學習？

新同學主動找你一對一溝通，進行成長總結(jié)，自我批評，這又是不是你平時的做事方式，讓他學會了積極領悟？再或者，你需要思考自己是否具備這樣的一個主動性，以及能夠批評和自我批評？

你對你的新同學足夠了解嗎？你對自己足夠了解嗎？

一個好的導師，永遠都不要擔心青會出于藍而勝于藍，因為這是好事，這是他的能力，更是你的本事！他若真能勝之于藍，說明他足夠優(yōu)秀；我們要學會與優(yōu)秀的人在一起，那樣才能更快的成長。

五、密切關注行業(yè)動態(tài)：站得高才能看得遠

技術的革新都是非常迅速的，我們絕不能僅靠項目上的產(chǎn)出來充實和提高自己；碼農(nóng)界聰明的人太多，必須把好的技術思想都吸收進來

逐漸的，需要將自己視作一個技術負責人。當然，若條件允許，可作為團隊技術負責；若團隊各方向劃分較細，可作為某業(yè)務方向技術負責人。

多分析團隊工作上遇到的一些技術難題，總結(jié)并歸類，互聯(lián)網(wǎng)行業(yè)發(fā)展至今，你所在團隊遇到的絕大部分問題，在別的公司必然都經(jīng)歷過了。跳出來，想方法從各渠道了解發(fā)展較為成熟的公司、較成熟的技術Team都在用過什么樣的方式來解決這一類的問題；雖然不能照搬照抄，但最起碼能從中得到更多的啟發(fā)。

新技術更新的很快，尤其在Web前端方面，不過多久就又出來一種新的解決方案。你應該作為一個技術癡迷者，密切關注行業(yè)的動態(tài)，看看人家都在搞什么，為什么會出現(xiàn)這么多新的框架、類庫、工具等。舉個例子，搞明白：

1）在沒有jQuery之前，大家用原生的DOM也能把功能開發(fā)的很好，那為什么會出來jQuery？它是為了解決什么樣的問題而出現(xiàn)的？用它與不用它，在項目上會有什么不一樣的地方？

2）jQuery已經(jīng)很好用了，那百度WebFE以前為什么還要在公司內(nèi)部搞一個Tangram？是單純的造輪子，還是因為它的確可實現(xiàn)各種Api定制化打包？對于jQuery的老手，如果使用Tangram，會有些什么不一樣的地方？

后來大家又一致吹捧的AngularJS、Backbone.js、Ember.js這些又是什么鬼？都是哪個公司哪個團隊基于什么樣的問題才造出來的？他們用這些工具只是因為某一個產(chǎn)品功能，還是說這貨可作為一類通用的解決方案而存在？倘若要把它們引進到自己的項目組，是否真正適用？你能從中得到什么啟發(fā)，大家又能學到什么？

Nodejs為什么會出現(xiàn)？io.js為什么又會作為其分支，單獨發(fā)展？后來為什么又還是merge到了一起？

再比如跨平臺的移動開發(fā)工具，PhoneGAP、Titanuim、Xamarin、以后今年火起來的React Native，為什么解決同樣問題的東西，會出來如此多，更新如此的快？最后出來的東西，是否都已經(jīng)具備了先輩的優(yōu)良品質(zhì)？它們所針對的用戶群體是什么？為何能得到大眾的青睞？它們和原生Native有何區(qū)別？

PHP 7都發(fā)布了，為什么你們先上服務還在使用PHP 5.3.29？升級PHP到最新版，在代碼上是否需要做些兼容？開發(fā)上是否和以前有變化？帶來的性能提升是否可大幅度減少服務器的數(shù)量？

全文的搜索引擎，Sphinx和Solr都是啥？索引的效率、搜索的性能、對中文分詞的支持、以及對實時索引的支持，這些維度都有什么不同？如果項目上需要使用，結(jié)合實際的需求，選擇哪一個更為合適？

再比如，你的團隊需要對線上服務進行多維度監(jiān)控，市面上已經(jīng)存在的Zabbix、Nagios、OpenTSDB、或者Open Falcon，是否都知道這些東西能監(jiān)控到那個層級？線上部署與應用的成本如何？后期的水平可擴展性又是如何？假如你要自己寫一個，你能否先畫出一張清晰的監(jiān)控布局圖？

總之，閑暇的時候，把技術眼界放寬些，多逛逛Github，或者一些國內(nèi)外牛人的Blog，看看別人都遇到了什么問題，都在解決什么樣的問題，多做一些假設：如果這個問題是你遇到了，你會怎么做？

六、多思考多做事：多一些證明自我能力的機會

公司不是養(yǎng)老院，發(fā)你工資，你就必須創(chuàng)造價值。任何一份工作（一個產(chǎn)品功能、一個技術系統(tǒng)、一套開發(fā)規(guī)范、抑或一套工作流程）都必然有它的問題所在，多思考多分析，發(fā)現(xiàn)問題并解決問題，這樣才能創(chuàng)造價值，我們也才能成長！

也許你所在的團隊就好比一坨漿糊，一團糟，同事們都已懶得抱怨，只在乎工作能干完上線就成。也許你所在的團隊一切都順風順水，同事們一團和氣，工作之余有說有笑，開心的不得了，甚是滿足。

但是，世上沒有100分的人，必然也沒有100分的團隊；凡人皆有缺點，團隊亦然。不要被亂七八糟的團隊嚇到，也不要覺得團隊看起來太好了，便無從下手！

大家平時的開發(fā)方式是什么樣的，是否都在重復的做一些體力勞動？如果是，是否可通過開發(fā)一些工具來自動化完成？

如果每位同學都自成一套開發(fā)體系，這樣的代碼必然是很難維護的，團隊里舊人去新人來，看著各式各樣的代碼，哪有不抱怨的理？在開發(fā)流程和規(guī)范上必須要有統(tǒng)一的標準，推動并協(xié)助切實執(zhí)行！

一個線上的技術系統(tǒng)，是不是都因為它是一個龐然大物，不敢輕易調(diào)整，所以對于新功能都是不斷的打補??？久而久之，團隊里的每位同學必然都只知道補丁，而不知道它真正的功能，真正的工作原理！所以必須要邁出第一步牽頭去重新梳理、歸置，將核心的部分獨立出來，展現(xiàn)它應有的功能！并伴之以詳盡的文檔說明！

對于一個臃腫的業(yè)務系統(tǒng)，是不是大家都因為已經(jīng)習慣了現(xiàn)在的開發(fā)、測試、部署等方式，所以不愿意去做縱向拆分？如果這樣的一個系統(tǒng)已經(jīng)拖慢了工作效率，那就必須動手梳理整治，讓它變成多個功能獨立的子系統(tǒng)，小而美，業(yè)務分明，項目之間更不易產(chǎn)生沖突，可維護性也能大大提高！同時推動團隊給每個子系統(tǒng)安排不同的owner！

如果以上技術團隊本身的問題不存在，則可以從產(chǎn)品功能的線上服務穩(wěn)定性著手考慮。線上是否有頻繁的報警？各業(yè)務日志是否都正常？用戶是否對某些常用功能有頻繁的反饋或吐槽？總之，能用工具自動監(jiān)控報警的，就一定不要用體力解決。能夠通過工具平臺讓運營或產(chǎn)品同學自助查詢問題原因的，就一定不要再讓研發(fā)手工去操作。

只要愿意靜下心來，從細小的點著手開始分析，發(fā)現(xiàn)問題，并利用一切可利用的資源，推動去解決它，不怕事小，只要一件件逐漸積累下來，定能體現(xiàn)出自己的價值，老板們要的就是：因為有你，所以團隊變得更好！然而，你這樣的收獲，是無法簡簡單單只用金錢就可衡量的，更是別人拿不去的財富。

七、帶一個團隊：規(guī)范化流程化

當然，這也不是每個人都有這樣的機會能被提升為Team Leader；工作上可沒有裙帶關系，哥兒倆感情好就把團隊也交給你；必須是你平時的工作已經(jīng)能充分證明，你具備了帶領這個Team一起發(fā)展的能力！

當然，在我看來，更重要的是做事，而不是在行政位置上的那個Title；只要你現(xiàn)在正在做的事情，就是帶一個團隊，至于是否是經(jīng)理職稱，根本不重要。有時候一個小公司的技術總監(jiān)，到了大公司，也得老老實實的做一線研發(fā)，不是嗎。你若真牛逼，公司又虧待你了，你走了，那只能是公司的損失。所以，還是老老實實的做事吧，該來的自然會來。

作為一個業(yè)務&技術團隊的管理者，至少需要做這些事情：

1）按照團隊所負責的各業(yè)務進行清晰地規(guī)劃，切莫吃大鍋飯，還是小團隊作業(yè)的好；一支精銳的部隊，責任感會更強，每個人會更清楚自己要做什么。

2）每條業(yè)務線，需求范圍明確，跨部門的需求，必定要有清晰的界限，保證組內(nèi)各Team的工作能更順利開展

3）組內(nèi)各小Team必須有統(tǒng)一的開發(fā)規(guī)范，攘外必先安內(nèi)，如果自己Team內(nèi)部的開發(fā)規(guī)范都一團糟，提供給第三方部門的接口還如何統(tǒng)一？

4）組內(nèi)各小Team必須有統(tǒng)一的項目全流程，在每個環(huán)節(jié)都應該注重實實在在的產(chǎn)出（沉淀）

5）組內(nèi)需要沉淀公共的組件庫、類庫、公共服務層，它必將形成一個團隊的主心骨，絕大部分的開發(fā)工作都能圍繞著它轉(zhuǎn)。如果有一個需求，團隊里任何人不需要思考，直接就能完成，那就夠了。

八、團隊培養(yǎng)與發(fā)展：健康并可持續(xù)發(fā)展

一個大于10人的團隊，必須考慮有效的梯隊建設，各方向的業(yè)務&技術負責人培養(yǎng)

在各業(yè)務方向上培養(yǎng)小組負責人，并讓該負責人培養(yǎng)自己的Backup

在團隊內(nèi)培養(yǎng)技術方向負責人，源源不斷在團隊內(nèi)輸出更多可供選擇的技術方案

團隊內(nèi)形成良好的導師制度，Leader帶方向負責人，方向負責人帶一線研發(fā)；同時也需要將梯隊扁平化，打造一個無障礙的溝通和匯報機制

有團隊周例會制度，每周至少保證有一次機會，能讓大家聚集在一起，知曉團隊過去一周的項目整體狀況，以及下周的工作節(jié)奏

團隊內(nèi)部必須形成良好的技術分享機制，至少每周一次，可以是大型項目的技術實現(xiàn)方案分享與評審、可以是大型項目的項目總結(jié)分享、可以是項目上某技術點的深入分析與應用介紹、可以是某工具平臺的構(gòu)建思路或工作原理分析、可以是工作中必備小技能（奇淫技巧）的發(fā)散討論、也可以是行業(yè)前沿技術的調(diào)研報告分析、也可以是一些新技術的嘗后感、更可以是跨團隊甚至跨公司的技術交流。總之，需要讓大家切實感受到：在這個團隊，有東西可做，有東西可學！

與同學們進行不定期的一對一溝通，助其排憂解難，有問題也要直接指出來，并授之以漁！幫助同學們成長，這是做導師做Leader的職責！

明確合理的獎懲原則，公司不養(yǎng)閑人，也不養(yǎng)不長進的人；與優(yōu)秀的人一起，團隊才能健康可持續(xù)的發(fā)展

不定期進行團隊建設（Team Building），可大可小，需要創(chuàng)造一些條件，能夠讓大家能夠聚在一起，討論一些工作之外的東西。身心愉悅了，哪還怕代碼寫不好？

做Leader的，無論哪個Level，就應該想著：你何時才能把自己現(xiàn)在正在做的這些事情，都交給自己的Backup？

只有你自己能完全從團隊現(xiàn)在的事情上抽離出來了，你才有機會去考慮對團隊來說，更多更重要的事情，這是給Backup的機會，也是給自己的機會。

九、學習一些其他的技術：跨界、全棧

俗話說，技多不壓身，用更多的技術知識來武裝自己，真有一天要上一個陌生的戰(zhàn)場，那也完全不在怕的。

當然，技術工程師成長過程中，全棧并不是必須要走的一條路，不過在深入掌握其中一門技術以后，眼界看得更開些，總是好事。

假設你是做前端的，一個前端Team能完全Hold住了，可以逐漸涉入后端，服務端、客戶端，做事的方式其實都一樣。不用花心思再去把每一門技術都重新學一遍，只要把該領域內(nèi)的核心技術摸熟了、其中的工作原理掌握了、與其他領域的區(qū)別搞明白了，就夠了。

如果自身能力有限，領域，精一門兒足以，用同樣的做事方式，融會貫通，其他的技術領域必定不會太難。

回想自己工作的這么幾年，先做Java，再做VB.Net、在做C#.NET、接著再做Web前端，一做就是三年；后來又學iOS、再轉(zhuǎn)Android；回過頭來又繼續(xù)帶Web前端Team、再帶PHP后端Team；說實在的，方法對了，事情也就好辦了。

十、關注業(yè)務發(fā)展

很多行業(yè)大佬可都是技術出身??！

技術改變世界，但沒有好的產(chǎn)品意識、沒有清晰的產(chǎn)品思路、沒有明銳的產(chǎn)品洞察力，不能將技術變現(xiàn)，總覺得自己技術很牛逼，又有多大用？感動了自己，感動不了別人。

文章來源：公眾號前端早讀課