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