聊聊技術團隊的招聘問題
【編者按】很多公司（尤其是創業公司）都發愁如何組建一個理想的團隊，但是他們卻往往沒搞清楚團隊的本質到底在于什么，本文作者以一個程序猿的角度來探討他對于團隊的理解。
過去，關于理想的開發團隊似乎是一個熱門的話題，所以我也來湊湊熱鬧。人們想要理想的開發團隊，只是因為在傳遞知識的時候很痛苦。人們總在說，這個地球多你一個不多，少你一個不少。假如有一天你們團隊中的主力走了，那么你們的團隊會怎樣？
有人會說：塞翁失馬，焉知非福，也許上個月團隊里走了個漢子，卻新來了一個萌妹子；也許下個月會走個老人，那必然也會來個新人……對于個人來說，這是件好事。
但是對于團隊來說就不一定了。
最初的團隊
有時，我會認為最理想的團隊莫過于一些創業團隊了 —— 分工明確。很多創業公司在過去都有著較為理想的團隊，然而隨著業務與團隊人數的增長，恐怕距離理想就會越來越遠。
比如，剛才說到的“分工明確”這一優點，就恐怕會慢慢消失。我認識一些創業公司的前端人員，他們中的大多數可能還同時充當著后臺 API、App 開發的角色。而這些人身兼多職的原因大致可歸類為：
招不到人；
沒有錢；
不知道招什么人（他們自己并沒有意識到自己不知道）。
</blockquote>那些存活下來的團隊（也包含沒有存活下來的團隊）里，一個人可能身兼多職，數個人的工作內容會有小部分的重疊，但是不會太多。在這一個時期，主 導團隊往往是 Idea 的所有者，Owner 找來一個技術人員，這個技術人員再依照短處去尋找需要的人才，比如下圖這樣（別笑）：
隨著公司業務的發展，出于個人、家庭、團隊等等各種因素，總有些人會離職，公司總需要迎進新人。而通常，這些團隊只有在真正受不了的時候才去招人，如果同大公司一樣漫無目的地進行撒網式招聘，那么早晚會死在這條路上。
有序的團隊
如果最初整個宇宙是混亂的、整個系統是混亂的、整個組織是混亂的，那么后邊便是通過不斷地分門別類，使整個系統看上去似乎有序。
所謂“有序”，即是說在這樣的團隊里，A做著A應該去做的事，B做著B應該去做的事。
如果A和B很熟悉，可能產生出 ab —— 可能是一個新的系統，也可能是一個新的事物；
如果A和B不熟悉，那么通過公司的各種各樣活動會幫他們產生 ab；
如果A和B不得已熟悉，那么我想這個 ab 可能是 API。
</blockquote>在最初的團隊里，A和B的座位可能只隔著 10cm，后來他們越來越遠……
職能分明的團隊是一個解耦后的系統（解耦就是用數學方法將兩種運動分離開來處理問題），他們之間的溝通需要比原來花費更大的開銷，在傳統 IT 公司及大部分的互聯網公司都有這樣的問題。
舉例來說：傳統軟件開發流程中，知識傳遞的方式主要在于文檔，而大部分程序員既討厭看文檔，又討厭寫文檔（網上不難找到可以證明這一說法的證據）。
而無論是在系統集成環節，又或者是在交接環節，人們所做的事只有一件，那就是知識傳遞。因為職責所在的緣故，團隊中每個單獨的成員不可能接觸太多的東西。
理想團隊的核心問題
團隊類似于人類的文明，更多地在于文化與知識的傳承。而人們總是希望有一個理想的團隊，但是他們往往并不知道，他們真正的問題不在于團隊的成員本身 —— 而在于團隊是如何協作的。
理想型A
</li> </ul>多數公司總是認為，理想團隊的組成方式類似于這樣：
那么想象一下：如果有一天大牛（圖中那個紅色圓點）出車禍了，中牛（橙色圓點）roll off 了，那么整個團隊就剩下一堆綠帽子了..……（囧 oz）
在這樣的團隊里，只有大牛和中牛比較厲害，下面都是一幫菜鳥，讓菜鳥之間傳遞知識基本是白費力氣。那么我們通常會用下面的方式來培養、教授團隊的成員：
老師（大牛或中牛）說：
你今天去把《Thinking Java》看一遍；
你今天去把《設計模式》看一下；
你今天……
</blockquote>在這時候，那些領悟力比較好的成員就可以走在 NB 的路上了，不過每堆人里也只會有那么1、2 個人……╮(╯_╰)╭
理想型B
</li> </ul>在另外一個理想型的團隊里，成員的組成可以是這樣的結構：
在這樣的團隊里，傳遞知識相當容易，因為大家很容易就懂得別人說的內容（人人都是大牛或中牛）。這樣的團隊并非不可構建，雖然讓團隊中的每一個人都是全棧程序員的難度很大。
構建理想團隊
人類以前（現在基本也是）是通過師徒制來保證師徒間的知識可以傳遞下來。而在多數的軟件開發團隊里并不存在這樣的制度，換句話說，在這樣的環境成長時，你沒有老師，要學什么、怎么學只能依靠你自己。
試著想一想：當團隊里來了一個新人，你會怎么做？
</li>再試著反過來想一想：如果你是一個新人，你來到這樣一個團隊：
</li> </ul>
A教你如何使用各種快捷鍵；
</li>B教你使用一些特定語言的技巧；
</li>C教你一些基本的 DevOps 技能；
</li>D教你怎么追妹子；
</li>……
</li> </ol> </blockquote>說實話，我很懷疑新人是否真的會考慮加入這樣一個團隊。
結對編程
結對編程是指兩位程序員坐在同一工作臺前開發軟件。與兩位程序員各自獨立工作相比，結對編程能編寫出質量更高的代碼。不過也許出于對公司制度和文化的考慮，也許是出于對自己的不明確認知，多數市場主導的公司并不會采用這樣的方式來工作。
這種團隊的組成和協作方式，傾向于下圖（請別問我從哪找的圖，我只是比喻一下）：
在這樣的協作里（也是知識傳遞的過程），兩個人并非每人的技能屬性和強度都需要一致，兩人的技能會出現重疊，但各有所強，并且很可能有一個人的某一個技能點數是滿點。
隨著項目的不斷開發，隨著老人離職新人進來，在這個結對編程的過程中，知識都在不斷地傳遞，兩個人的各項能力也會越來越強。
在這種結對編程的團隊協作中會存在至少三種模式：
Coach 模式：在我現有的經驗里，這個模式對新人的幫助會比較大。通常來說，我們是要分解任務，然后帶領新人一步步完成任務。雖然在這個過程中，新人可以很快了解工作中每一步的情況，但依舊沒擺脫授課模式。
導航模式：在個過程中，有經驗的人更多的是充當觀察者。當能力差一些的那個人不知道往哪個方向走時，另一方就給予提示。但在這個模式中，往往要等新人犯錯之后才能給出提示。
Pair 模式：理想的結對編程是在這樣的模式之中，兩人之間有很好的默契，以及在某方面相接近的能力，要達成共同目標。在個過程中，需要注意的是平衡好兩人的步驟。
</blockquote>采用結對編程的團隊協作模式不僅可以提高菜鳥的水平，大牛的能力也可以有很大輸出，對于程序員這一行業的人來說必然會有很大的提高。
作者介紹
我是黃峰達，1991 年出生于閩南，雙子座，畢業于西安文理學院(電子信息工程專業)，目前就職于 ThoughtWorks (西安)。 農村長大，熱愛大自然，熱愛生活。和哈比特人一樣喜歡土地里長出來的東西。 是一個文藝控。喜歡讀書，喜歡紙的質感，喜歡用筆銘刻記憶和思想。 是一個設計控，一個 DIY 愛好者。喜歡自行設計一些小東西，相比理論而言更喜歡動手實踐，比如拆裝自己的手機、電腦等。 最喜歡折騰與計算機相關的東西：SEO、前端開發、硬件相關(如：Raspberry Pi,51,Arduino,OpenWRT,uCOS...)、搜索引擎。
</blockquote>來自: 雷鋒網本文由用戶 xdld 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！