經常聽人講，我們要建設高效的團隊，如何提高團隊的執行效率等等，空談效率沒有意義，這篇文章結合作者自身的經歷，談談梯度團隊是什麼樣子的，爲什麼一個有梯度的團隊是高效的，以及在管理中如何建設這樣的團隊。
梯度團隊介紹
下圖是我經歷的一家中型互聯網公司的技術團隊組織架構圖，展現了在我離開這家公司之前的一個組織狀態，首先介紹一下這個圖的含義。
這個圖分成兩大塊，事業部和基礎研發部。事業部就指的一個相對獨立的業務線，不同的業務線之間有較大的差異，在業務上沒有關聯和延續。而基礎研發部，是指的技術架構的基礎設施，比如rpc框架、郵件與短信平臺、消息中間件、異常監控等等，這些基礎設施與業務之間通常沒有太大的關係，更關注性能而剝離業務特點。
接下來說事業部，一個事業部可以理解爲一個大的業務線，例如天貓是一個業務線，支付寶是另一個業務線，菜鳥網絡又是另外的業務線等等。這些業務線本身是由不同行業或領域的人組成的，切分成不同的事業部可以很好的理解。
事業部之下，又可以分成多個小組，比如C端組、B端組等等，每個組選取一個小組長爲總負責人，一般的title是技術經理或技術主管。這些小組之間不像業務部那樣非常獨立，小組之間雖然有很多不同，但也有一定的關聯，例如C端的人員列表，可能會展示在B端的後臺裏，B端的企業列表也可以提供給C端的人員瀏覽，B端與C端可以建設一個渠道進行溝通，一些標籤或分類同時適用於B端和C端兩個方向的用戶等等。
小組之下就是人員分工了，我離開公司時已經基本完成了業務線的劃分改造，將前端（FE），測試（QA）以及技術都交給技術經理管理，技術經理通常會管理2-8個人的開發，開發中有資深、高級、中級、初級人員。如果開發人員相對較少，可以由小組長直接管理，如果多於5個，一般就會選取一個“副手”，我們稱之爲memtor，讓他分擔一部分項目管理工作。
UI池在這裏單獨成立一個組，沒有被分擔到事業部中去，主要是因爲這時不僅業務端需要ui設計，有些市場部、公關宣傳部、公衆號等都需要UI，但需求並非那麼緊湊，不像每個項目都需要測試、前端、後端這樣，因此還是一個池子，哪裏有需要，就向UI池提出需求。
現在來說基礎研發部。基礎研發部由1+n組成，1是架構組，n是基礎平臺。他們都向技術總監彙報。架構組負責公司的核心架構，如rpc框架，消息中心，監控系統，工具包封裝等，由一個首席架構師+幾位高級中級架構師組成。架構師在這裏管理成分不高，主要是還是技術開發，基本上沒有業務。圖中的研1組長，研n組長是指的多個基礎平臺小組，例如郵件與短信平臺、搜索小組、爬蟲小組、開放平臺、用戶平臺、訂單系統等，每個小組由2-3個人組成。基礎平臺可能會涉及到一定的業務，但也是相對獨立或可複用的。
最後說運維部。運維部在我離開時已經統一由基礎研發部管理了。運維一般也是有一個總監，但幾個運維工程師，運維工程師中又可分爲運維、dba、運維開發等職位。
梯度管理的起因
梯度管理的內因，我理解的是人的精力的侷限性。上面的圖有些複雜，放到一個幾個人的小團隊裏可以更好的理解。
如果給你一個人，你手把手指導沒有問題，你們倆可以同時工作，你做比較重要的地方，他做相對簡單的地方，你們配合默契，一起完成工作，這時管理沒太大意義，因爲你知道他做所的所有事情，基本上不需要彙報，一起往下走就是了。
如果給你兩個人，當然事情也會多一點，這時你是還有精力去照顧團隊成員的，你依然清楚他們所做的每件事，而你自己會從做事到做把控，做設計這樣過度過來。之後給你三個人，四個人，你發現由你無法在不詢問的情況下知道每個細節，此時你可能需要每天早來上班前招集大家做一個晨會，在晨會上彙報項目進展。
之後團隊人員繼續變多，業務也會飛快的發展，你會發現同時有多個項目運行，而隨着項目的演進，業務變得越來越複雜，你發現你沒有精力像之前那樣對每個細節都那麼熟悉了，而隨着細節瞭解的越來越少，你把控的粒度也會變得越來越粗。而在這個過程中，有些團隊成員逐漸成爲團隊中的骨幹，他們技術過硬，業務嫺熟，有時比你還更瞭解設計的細節，並且對你的一些細節指導產生反感，認爲這個時候你再來攙和就是對他們的不信任。
這個時候，你的梯度團隊就需要提上日程了。你需要選拔一個合適的人，這個人可以獨立帶領項目，進行項目設計，幫助其他同事解決項目問題，因爲這樣的放權，這位同事會變得更爲積極，相對的，你也不會過於疲憊。
總結說來，梯度的產生，是因爲管理者精力的侷限性+適度放權的必要性的綜合結果。你不能一直關注細節，精力不允許，別人也會受限制。記得三國後期有句話描述諸葛亮：事無鉅細鹹決於亮。諸葛亮這種管理方式直接會造成青年才俊得不到學習鍛鍊的機會，自己也會疲勞成疾。諸葛一死，蜀漢政權迅速凋零。
梯度管理的高效性分析
梯度管理一旦形成，團隊運轉將會高速運行。
水平溝通的高效性
從上面的圖上可以看到，劃分團隊時，是按照最小的粒度、業務獨立性進行了拆分，假設項目的迭代多數情況下只會涉及到一個業務線，團隊內部溝通是非常高效的。這個小團隊工位一般都在一起，很多事情不用開會，一擡頭就溝通明白了。而如果是跨團隊的，要麼開會，要麼語音會議，溝通成本非常之高。
項目執行的高效性
項目優先級可以靈活把控，設想一下，如果你的團隊需要開發一個項目，前端或測試卻進行着別的項目，讓別的團隊調整優先級是非常困難的，這樣勢必會造成效率低下，我等你你等我的現象。
充分發揮優秀員工的積極性
梯度管理就意味着放權，把一些不太重要的事情的決策權逐漸交給下屬，讓他們有一個鍛鍊的機會，也減少流程上對他們的束縛。打個比方，如果沒有梯度管理，你就需要對所有成員的所有項目直接負責，所有重要的東西都是你做的，所有的大功勞也都是你的，這樣團隊成員必然會想，既然都是你負責的，我也沒啥機會，我也不用考慮那麼細了，反正最後有你把關，出了事情還是你擔責任，逐漸就會消極起來。有了梯度管理就不一樣了，隨着權力的下放，團隊成員的積極性也會更高，擔的責任也會越大，這本身就是個成長的過程。
縱向彙報的高效性
梯度管理的又一個好處是彙報更快了。還是做一個對比，在一個小團隊裏，如果要做一個彙報的話，沒有梯度，你需要問n個人，有梯度了，你可能只需要讓1到2個人幫你總結一下再做個彙總就行了。這是上傳。相反的，如果上級有個下達的指令，如新的制度，通過這種彙報機制，也能在最短時間內起到傳達效果。
梯度管理與扁平化
在說的梯度管理時，我們也常常聽到某些互聯網公司說他們的管理是扁平化的，這兩者矛盾嗎？我認爲並不矛盾。因爲梯度管理並沒有強制要求不能跨越節點溝通，你依然可以直接給總監、cto、或ceo提你的建議，梯度管理的公司內部，小組長、總監也都沒有辦公室，和大家都做在一起，如果有特殊意見或建議，依然可以直接傾訴或提出的。梯度管理和扁平化管理是可以完好的融合在一起的。
梯度團隊的建設
認真觀察，積極培養
在最基層的小組團隊中，小組長除了日常的項目管理與人員分工，還要認真觀察每個成員的工作表現，對於那些態度積極性高，項目完成度好，不抱怨，多承擔的成員，要給預更多的發展機會，更大的權力，有能者多勞多得，既而讓他去承擔一部分你的管理職責，形成梯度。
仔細梳理，業務獨立與公共部分抽取
作爲總監或cto，要仔細傾聽各小組反饋的問題，其中主要的一點是效率低下的原因，而這種原因往往是跨團隊、或者重複勞動造成的。對於跨團隊的工作，如果業務是相同的可以合併，如果是重複勞動，要把一些業務下沉併成立一個團隊統一負責。
給予認可與獎勵
對於獨立業務的負責人或新提拔培養的員工，要認識到，雖然給予機會是也是一種激勵，但這種激勵伴隨着高負荷勞動和更多責任的壓力，在工作有一定成果的情況下，要實時的給予認可甚至獎勵，讓能者多勞多得，否則這種不持續的激勵，有可能會造成翅膀硬了脫離團隊的風險。