【編者按】很多公司（尤其是創(chuàng)業(yè)公司）都發(fā)愁如何組建一個理想的團隊，但是他們卻往往沒搞清楚團隊的本質(zhì)到底在于什么，本文作者以一個程序猿的角度來探討他對于團隊的理解。

過去，關于理想的開發(fā)團隊似乎是一個熱門的話題，所以我也來湊湊熱鬧。人們想要理想的開發(fā)團隊，只是因為在傳遞知識的時候很痛苦。人們總在說，這個地球多你一個不多，少你一個不少。假如有一天你們團隊中的主力走了，那么你們的團隊會怎樣？

有人會說：塞翁失馬，焉知非福，也許上個月團隊里走了個漢子，卻新來了一個萌妹子；也許下個月會走個老人，那必然也會來個新人……對于個人來說，這是件好事。

但是對于團隊來說就不一定了。

最初的團隊

有時，我會認為最理想的團隊莫過于一些創(chuàng)業(yè)團隊了—— 分工明確。很多創(chuàng)業(yè)公司在過去都有著較為理想的團隊，然而隨著業(yè)務與團隊人數(shù)的增長，恐怕距離理想就會越來越遠。

比如，剛才說到的“分工明確”這一優(yōu)點，就恐怕會慢慢消失。我認識一些創(chuàng)業(yè)公司的前端人員，他們中的大多數(shù)可能還同時充當著后臺API、App開發(fā)的角色。而這些人身兼多職的原因大致可歸類為：

招不到人；

沒有錢；

不知道招什么人（他們自己并沒有意識到自己不知道）。

那些存活下來的團隊（也包含沒有存活下來的團隊）里，一個人可能身兼多職，數(shù)個人的工作內(nèi)容會有小部分的重疊，但是不會太多。在這一個時期，主導團隊往往是Idea的所有者，Owner找來一個技術人員，這個技術人員再依照短處去尋找需要的人才，比如下圖這樣（別笑）：

隨著公司業(yè)務的發(fā)展，出于個人、家庭、團隊等等各種因素，總有些人會離職，公司總需要迎進新人。而通常，這些團隊只有在真正受不了的時候才去招人，如果同大公司一樣漫無目的地進行撒網(wǎng)式招聘，那么早晚會死在這條路上。

有序的團隊

如果最初整個宇宙是混亂的、整個系統(tǒng)是混亂的、整個組織是混亂的，那么后邊便是通過不斷地分門別類，使整個系統(tǒng)看上去似乎有序。

所謂“有序”，即是說在這樣的團隊里，A做著A應該去做的事，B做著B應該去做的事。

如果A和B很熟悉，可能產(chǎn)生出ab —— 可能是一個新的系統(tǒng)，也可能是一個新的事物；

如果A和B不熟悉，那么通過公司的各種各樣活動會幫他們產(chǎn)生ab；

如果A和B不得已熟悉，那么我想這個ab可能是API。

在最初的團隊里，A和B的座位可能只隔著10cm，后來他們越來越遠……

職能分明的團隊是一個解耦后的系統(tǒng)（解耦就是用數(shù)學方法將兩種運動分離開來處理問題），他們之間的溝通需要比原來花費更大的開銷，在傳統(tǒng)IT公司及大部分的互聯(lián)網(wǎng)公司都有這樣的問題。

舉例來說：傳統(tǒng)軟件開發(fā)流程中，知識傳遞的方式主要在于文檔，而大部分程序員既討厭看文檔，又討厭寫文檔（網(wǎng)上不難找到可以證明這一說法的證據(jù)）。

而無論是在系統(tǒng)集成環(huán)節(jié)，又或者是在交接環(huán)節(jié)，人們所做的事只有一件，那就是知識傳遞。因為職責所在的緣故，團隊中每個單獨的成員不可能接觸太多的東西。

理想團隊的核心問題

團隊類似于人類的文明，更多地在于文化與知識的傳承。而人們總是希望有一個理想的團隊，但是他們往往并不知道，他們真正的問題不在于團隊的成員本身—— 而在于團隊是如何協(xié)作的。

• 理想型A

多數(shù)公司總是認為，理想團隊的組成方式類似于這樣：

那么想象一下：如果有一天大牛（圖中那個紅色圓點）出車禍了，中牛（橙色圓點）roll off了，那么整個團隊就剩下一堆綠帽子了..……（囧oz）

在這樣的團隊里，只有大牛和中牛比較厲害，下面都是一幫菜鳥，讓菜鳥之間傳遞知識基本是白費力氣。那么我們通常會用下面的方式來培養(yǎng)、教授團隊的成員：

老師（大?；蛑信＃┱f：

你今天去把《Thinking Java》看一遍；

你今天去把《設計模式》看一下；

你今天……

在這時候，那些領悟力比較好的成員就可以走在NB的路上了，不過每堆人里也只會有那么1、2個人……╮(╯_╰)╭

• 理想型B

在另外一個理想型的團隊里，成員的組成可以是這樣的結(jié)構(gòu)：

在這樣的團隊里，傳遞知識相當容易，因為大家很容易就懂得別人說的內(nèi)容（人人都是大?；蛑信＃＿@樣的團隊并非不可構(gòu)建，雖然讓團隊中的每一個人都是全棧程序員的難度很大。

構(gòu)建理想團隊

人類以前（現(xiàn)在基本也是）是通過師徒制來保證師徒間的知識可以傳遞下來。而在多數(shù)的軟件開發(fā)團隊里并不存在這樣的制度，換句話說，在這樣的環(huán)境成長時，你沒有老師，要學什么、怎么學只能依靠你自己。

• 試著想一想：當團隊里來了一個新人，你會怎么做？

• 再試著反過來想一想：如果你是一個新人，你來到這樣一個團隊：

A教你如何使用各種快捷鍵；

B教你使用一些特定語言的技巧；

C教你一些基本的DevOps技能；

D教你怎么追妹子；

……

說實話，我很懷疑新人是否真的會考慮加入這樣一個團隊。

結(jié)對編程

結(jié)對編程是指兩位程序員坐在同一工作臺前開發(fā)軟件。與兩位程序員各自獨立工作相比，結(jié)對編程能編寫出質(zhì)量更高的代碼。不過也許出于對公司制度和文化的考慮，也許是出于對自己的不明確認知，多數(shù)市場主導的公司并不會采用這樣的方式來工作。

這種團隊的組成和協(xié)作方式，傾向于下圖（請別問我從哪找的圖，我只是比喻一下）：

在這樣的協(xié)作里（也是知識傳遞的過程），兩個人并非每人的技能屬性和強度都需要一致，兩人的技能會出現(xiàn)重疊，但各有所強，并且很可能有一個人的某一個技能點數(shù)是滿點。

隨著項目的不斷開發(fā)，隨著老人離職新人進來，在這個結(jié)對編程的過程中，知識都在不斷地傳遞，兩個人的各項能力也會越來越強。

在這種結(jié)對編程的團隊協(xié)作中會存在至少三種模式：

Coach模式：在我現(xiàn)有的經(jīng)驗里，這個模式對新人的幫助會比較大。通常來說，我們是要分解任務，然后帶領新人一步步完成任務。雖然在這個過程中，新人可以很快了解工作中每一步的情況，但依舊沒擺脫授課模式。

導航模式：在個過程中，有經(jīng)驗的人更多的是充當觀察者。當能力差一些的那個人不知道往哪個方向走時，另一方就給予提示。但在這個模式中，往往要等新人犯錯之后才能給出提示。

Pair模式：理想的結(jié)對編程是在這樣的模式之中，兩人之間有很好的默契，以及在某方面相接近的能力，要達成共同目標。在個過程中，需要注意的是平衡好兩人的步驟。

采用結(jié)對編程的團隊協(xié)作模式不僅可以提高菜鳥的水平，大牛的能力也可以有很大輸出，對于程序員這一行業(yè)的人來說必然會有很大的提高。