我腦海中的優秀技術團隊

當一個開發糾結於本身作的一些初級實現的事情的價值時，不如多思考對於團隊和業務的價值。

文中的「我」，其實不是一個單純的角色，它可能會包含多層含義，不論是我做爲一個團隊的管理者，仍是我做爲一名技術團隊的普通員工，都會對本身的團隊有一些期許，一些定義，一些要求，而這就是今天咱們要談論的話題。但願這些思考可以對管理者或者求職者有些幫助。

 

團隊的首先組成就是人，那我理想中的技術團隊中的人應該是怎樣的呢？做爲團隊的負責人，其實對於人這方面的把關我一直是很是嚴格的，對於進入到我團隊裏的成員，一般須要有如下品質，這就是我對技術人的理解。

1.好奇心。

你爲何作技術？一些人是爲了餬口，一些人只是不知道本身能作什麼，而另一羣人，則是由於好奇心，對未知領域的探索，用技術來作不少神奇的事情，例如炫酷的動畫？碉炸的算法？人工智能？遊戲？物理引擎？漂亮驚豔的頁面？想一想你是否是由於這些技術而義無反顧的衝入編程大軍的。我以爲這種編程才能持續的作下去，而不是撈一筆就走的心態，或者想着靠編程實現財務自由。有些同窗在作技術一段時間以後，會開始迷茫，我以爲這時候回過頭去看看你的初衷很是重要，若是你的初衷是平庸的，那我以爲你不適合作這行，若是是你的初衷是用技術探索應用價值，那我以爲你能夠順着這個思路想想你的如今的價值點在何處？

 

2.鍥而不捨的學習。

 

我面試的時候一般會特別關注這一點，有時候若是實在看不到一我的對於持續學習的熱情，我甚至直接生硬的問對方，「你業餘時間會作些什麼跟技術相關的事情」，而後獲得的回答，一般是「看書」「看論壇」「看源碼」。其實這就是敷衍了事了，這些事情只是一個程序員最基本的一些學習方法，我其實想知道的是，你是如何「持續學習」的，你看過一篇文章以後，對於其中涉及的一些知識點，你如何去強化？如何去實踐？甚至如何引入到工做中來？你的工做或者是項目都作得平平無奇，那你看書看論壇都是在看什麼呢？看了以後又解決了什麼問題？

3.分析解決問題的方式。

最基本的，你在遇到技術難題的時候，如何解決？google？爆棧網？這些是最基本的，你如何判別一個解決方案的正確性？你如何一步一步分析問題？如何debug你的代碼？而後，解決問題以後，你作了什麼思考？是不是你的知識面有問題，須要系統補充下某個方面的技術點？你是否研究了它周邊的知識？寫一篇博客，備忘順便分享給網友？這裏又涉及到知識管理的方面。總之每次遇到問題其實都是一次對你的知識面的擴充時機，最終這些都會變成你的經驗。在工做多年以後，這些潛移默化的知識會讓你可以快速對一個問題做出判斷，會在你腦海中造成一套體系，幫助你快速分析和解決問題，不論是你的方向是架構師，仍是業務leader，都須要這些能力。

一般，你作事的方式態度，就決定了你的將來。

爲何咱們須要一個團隊中的成員具有這些素質？最終目的都是經過這些細節發現一我的的潛力：好奇心決定了你能在技術這條道路上走多久；學習方式決定了你可以在這條道路上越走越高；而解決問題的方式則決定了你可否造成方法論，成爲一位真正的資深工程師。

除了上述的三點，對於團隊中的人，做爲一名普通員工，我還指望有這些關鍵字：

• 樂於分享，讓我能夠被動擴充知識面；

• 和藹真實，不爲人情世故操心專心作個寫代碼的美男子；

• 牛逼哄哄，讓我大開眼界的牛人那是最好不過的，光聽那些名詞就足夠我出去吹半天了，對於開闊思路視野有奇效；

人知足需求了，接着講我理想中的團隊是什麼樣的第二部分：事。

1.團隊是否在朝着一個更好的方向成長？

我見過不少團隊，基本沒有「管理」。所謂管理，不是說有個老大管着你，指揮你作這個作那個，而是你這個團隊是否有「目標」「規劃」「預期」。就如最近面試的一些比較優秀的同窗同樣，他很是關注咱們團隊的「管理」，會提出一堆關於此方面的問題，這就是他對團隊的一種期許，你的團隊是單純的實現業務？仍是有所規劃？你理想中的團隊架構是如何的？人員分配如何？技術棧如何？規範如何？流程如何？如今有何不足，做何改進？這些其實就是對「管理」的拷問。一個有管理思路的團隊，經得起這些拷問。而這些拷問，其實關注點主要就是你的團隊是在健康成長，仍是放養或者原地踏步？若是進入沒有方向的團隊，恐怕自身的成長也不會有大的進步。

2.團隊作事方式是否規範？

近一年，我對團隊管理最大的方法論也是指導方針，就是規範化。這裏的規範化有幾種含義。

• 代碼規範，這個不用多說，最基本也是最容易達成的，方法能夠有eslint等，加上按期的代碼review，以及團隊內的規範文檔等。

• 方法規範，如何引入新技術？多人開發如何進行？如何保障代碼可用性？如何保障發佈安全？如何有效利用日誌？等等，這些問題都須要造成方法論，有一套流程來保障。例如引入新技術，咱們須要 調研試用 - 產出優劣報告 - 產出腳手架 - 多人review腳手架 - 分享+文檔 - 新項目試驗 - 問題總結分享 - 優化 - 全面投入使用，過程當中會要求一些產出，目的都是爲了評估好優劣，而且造成一套規範，而不是隨意引入一些不可控的技術。上面說起的其餘問題，咱們都會造成本身的一套規範，落地分享和文檔，跟蹤執行。這就是團隊規範的方法論。

• 流程規範，一個需求如何產生？如何評估其用戶價值和可行性？如何進入開發手中？如何排期？是否有完善的項目管理流程？測試發佈如何進行？一個團隊的開發若是是亂哄哄沒有標準秩序的話，開發會很累，這些實際上是項目經理的職責，從開始對需求的把關，到產品經理的把關，到交互視覺把關，到技術方案排期評估，到聯調跟進測試發佈。作好不易，作很差你們就會很累。

規範化的最終目的，一個是提升開發效率，另外一個是確保團隊開發的可持續性，減小「坑」出現的概率。這些問題一般是創業公司技術團隊的通病。

3. 共同成長和價值定位

以我團隊爲例，最近在作一個事情，全公司公用組件的開發，這個事情我不許備讓負責架構的同窗去作，我將其分解爲兩部分： 架構組的事情：制定組件規範，制定腳手架，把關代碼質量，出標準組件的實例，推進計劃進行，文檔和組件索引網站等。 業務組的事情：根據架構組的周邊和規範分工實現組件。

我但願經過這樣的分工達成兩件事情：架構組發揮其做用讓事情朝着正確的方向前進；業務組的每位同窗都能知道一個標準組件是怎樣產出的，都瞭解npm是如何管理組件的，組件的週期維護是如何的，更經過嚴格的review經過制度來讓你們共同成長。 能夠看到這件事情的三個意義：一，讓你們共同成長；二，你們各司所致，找到本身在整件事情中的價值定位；三，事情自己推進了團隊開發效率，這是其最基本的價值。

做爲一個我的，其實對團隊的指望大致還有：

• 有足夠的挑戰，有機會接觸各類問題並解決以此得到經驗積累。

• 團隊承認個人價值，而不是把我當成工具來使用。

• 團隊有足夠的成長空間，對本身有個清晰的定位。