文中的“我”，其實不是一個單純的角色，它可能會包含多層含義，不管是我作為一個團隊的管理者，還是我作為一名技術團隊的普通員工，都會對自己的團隊有一些期許，一些定義，一些要求，而這就是今天我們要談論的話題。希望這些思考能夠對管理者或者求職者有些幫助。
團隊的首先組成就是人，那我理想中的技術團隊中的人應該是怎樣的呢？作為團隊的負責人，其實對于人這方面的把關我一直是非常嚴格的，對于進入到我團隊里的成員，通常需要有以下品質，這就是我對技術人的理解。
1.好奇心。
你為什么做技術？一些人是為了糊口，一些人只是不知道自己能做什么，而另外一群人，則是因為好奇心，對未知領域的探索，用技術來做很多神奇的事情，例如炫酷的動畫？碉炸的算法？人工智能？游戲？物理引擎？漂亮驚艷的頁面？想想你是不是因為這些技術而義無反顧的沖入編程大軍的。我覺得這種編程才能持續的做下去，而不是撈一筆就走的心態，或者想著靠編程實現財務自由。有些同學在做技術一段時間之后，會開始迷茫，我覺得這時候回過頭去看看你的初衷非常重要，如果你的初衷是平庸的，那我覺得你不適合做這行，如果是你的初衷是用技術探索應用價值，那我覺得你可以順著這個思路想一想你的現在的價值點在何處？對于這個問題，前幾天我發的一個朋友圈挺有代表性，這里貼出來：
2.持之以恒的學習。
我面試的時候通常會特別關注這一點，有時候如果實在看不到一個人對于持續學習的熱情，我甚至直接生硬的問對方，“你業余時間會做些什么跟技術相關的事情”，然后得到的回答，通常是“看書”“看論壇”“看源碼”。其實這就是敷衍了事了，這些事情只是一個程序員最基本的一些學習方法，我其實想知道的是，你是如何“持續學習”的，你看過一篇文章之后，對于其中涉及的一些知識點，你如何去強化？如何去實踐？甚至如何引入到工作中來？你的工作或者是項目都做得平平無奇，那你看書看論壇都是在看什么呢？看了之后又解決了什么問題？
3.分析解決問題的方式。
最基本的，你在遇到技術難題的時候，如何解決？google？爆棧網？這些是最基本的，你如何判別一個解決方案的正確性？你如何一步一步分析問題？如何debug你的代碼？然后，解決問題之后，你做了什么思考？是否是你的知識面有問題，需要系統補充下某個方面的技術點？你是否研究了它周邊的知識？寫一篇博客，備忘順便分享給網友？這里又涉及到知識管理的方面?？傊看斡龅絾栴}其實都是一次對你的知識面的擴充時機，最終這些都會變成你的經驗。在工作多年之后，這些潛移默化的知識會讓你能夠快速對一個問題作出判斷，會在你腦海中形成一套體系，幫助你快速分析和解決問題，不管是你的方向是架構師，還是業務leader，都需要這些能力。
通常，你做事的方式態度，就決定了你的未來。
為什么我們需要一個團隊中的成員具備這些素質？最終目的都是通過這些細節發現一個人的潛力：好奇心決定了你能在技術這條道路上走多久；學習方式決定了你能夠在這條道路上越走越高；而解決問題的方式則決定了你能否形成方**，成為一位真正的資深工程師。
除了上述的三點，對于團隊中的人，作為一名普通員工，我還期望有這些關鍵字：
?樂于分享，讓我可以被動擴充知識面；
?和善真實，不為人情世故操心專心做個寫代碼的美男子；
?牛逼哄哄，讓我大開眼界的牛人那是最好不過的，光聽那些名詞就足夠我出去吹半天了，對于開闊思路視野有奇效；
人滿足需求了，接著講我理想中的團隊是什么樣的第二部分：事。
1.團隊是否在朝著一個更好的方向成長？
我見過很多團隊，基本沒有“管理”。所謂管理，不是說有個老大管著你，指揮你做這個做那個，而是你這個團隊是否有“目標”“規劃”“預期”。就如最近面試的一些比較出色的/卓越的/優異的/杰出的的同學一樣，他非常關注我們團隊的“管理”，會提出一堆關于此方面的問題，這就是他對團隊的一種期許，你的團隊是單純的實現業務？還是有所規劃？你理想中的團隊架構是如何的？人員分配如何？技術棧如何？規范如何？流程如何？現在有何不足，作何改進？這些其實就是對“管理”的拷問。一個有管理思路的團隊，經得起這些拷問。而這些拷問，其實關注點主要就是你的團隊是在健康成長，還是放養或者原地踏步？如果進入沒有方向的團隊，恐怕自身的成長也不會有大的進步。
2.團隊做事方式是否規范？
近一年，我對團隊管理最大的方**也是指導方針，就是規范化。這里的規范化有幾種含義。
?代碼規范，這個不用多說，最基本也是最容易達成的，方法可以有eslint等，加上定期的代碼review，以及團隊內的規范文檔等。
?方法規范，如何引入新技術？多人開發如何進行？如何保障代碼可用性？如何保障發布安全？如何有效利用日志？等等，這些問題都需要形成方**，有一套流程來保障。例如引入新技術，我們需要調研試用-產出優劣報告-產出腳手架-多人review腳手架-分享+文檔-新項目試驗-問題總結分享-優化-全面投入使用，過程中會要求一些產出，目的都是為了評估好優劣，并且形成一套規范，而不是隨意引入一些不可控的技術。上面提及的其他問題，我們都會形成自己的一套規范，落地分享和文檔，跟蹤執行。這就是團隊規范的方**。
?流程規范，一個需求如何產生？如何評估其用戶價值和可行性？如何進入開發手中？如何排期？是否有完善的項目管理流程？測試發布如何進行？一個團隊的開發如果是亂哄哄沒有標準秩序的話，開發會很累，這些其實是項目經理的職責，從開始對需求的把關，到產品經理的把關，到交互視覺把關，到技術方案排期評估，到聯調跟進測試發布。做好不易，做不好大家就會很累。
規范化的最終目的，一個是提高開發效率，另一個是確保團隊開發的可持續性，減少“坑”出現的幾率。這些問題通常是創業公司技術團隊的通病。
3.共同成長和價值定位
以我團隊為例，最近在做一個事情，全公司公用組件的開發，這個事情我不準備讓負責架構的同學去做，我將其分解為兩部分：架構組的事情：制定組件規范，制定腳手架，把關代碼質量，出標準組件的實例，推動計劃進行，文檔和組件索引
網站等。業務組的事情：根據架構組的周邊和規范分工實現組件。
我希望通過這樣的分工達成兩件事情：架構組發揮其作用讓事情朝著正確的方向前進；業務組的每位同學都能知道一個標準組件是怎樣產出的，都了解npm是如何管理組件的，組件的周期維護是如何的，更通過嚴格的review通過制度來讓大家共同成長?？梢钥吹竭@件事情的三個意義：一，讓大家共同成長；二，大家各司所致，找到自己在整件事情中的價值定位；三，事情本身推動了團隊開發效率，這是其最基本的價值。
作為一個個人，其實對團隊的期望大體還有：
?有足夠的挑戰，有機會接觸各種問題并解決以此獲得經驗積累。
?團隊認可我的價值，而不是把我當成工具來使用。
?團隊有足夠的成長空間，對自己有個清晰的定位。
結語
其實今天還跟大家講，為什么做分享，很難做一些方**或者是管理思路的分享？一個是因為還不夠成熟，大家都在摸索；另一個重要的原因是，很多方**其實就是一句話或者幾句話，更重要的是執行到位，否則說出來都會很虛，但是團隊到了一定階段之后，一定要有目標和方**，否則還是原始的行軍狀態，大家都會迷茫，內耗也會非常高。其實這些總結也是挺虛的，但是算是我內心對團隊和人的一些見解。
