如何擴展開發團隊(轉)

原文標題：How To Scale a Development Team

原文連接：http://adam.heroku.com/past/2011/4/28/scaling_a_development_team/

 

做者經過本身在Heroku的經驗，討論了開發團隊是如何從家庭式做坊發展到專業化團隊的過程，在每一個階段中都給出了關鍵注意點，本文對於想創業和正在創業以及創業成功的人士都有能夠學習的地方，讓咱們從頭開始吧！

做爲黑客，咱們對於擴展web服務器、數據庫和其餘軟件系統的需求已經得心應手。對於成長型公司的一個同等重要的挑戰是擴展你的開發團隊。

大多數的科技公司在發展到大約10位開發人員時會遇到隊伍可擴展性的棘手問題。有了前幾年在Heroku成功指導這個過程的經驗，這篇文章將呈現開發隊伍成長過程的各個階段中我所看到的以及每一個階段遇到的問題和潛在的解決方案。

第1階段：家庭式做坊（Homebrewing）

一開始，你的公司有2-4男的/女的，大家在某人的住所、咖啡廳或者能夠協同工做的地方工做。溝通和協調是很容易的：僅僅幾我的挨個坐着，每一個人都知道其餘人在作什麼。創始人和早期的員工傾向於自我引導的，所以幾乎是不存在管理的需求。每一個人都是通才，每件事都多多少少的插手。你有一個單獨的組聊天頻道和單獨的all@yourcompany.com的郵件列表。沒有任務跟蹤甚至是bug跟蹤的真正需求。整個公司狀況以及大家的產品每一個人都能記的清清楚楚。

這個時候，你試圖建立並檢查你的最小可行性產品，這是一個你試圖想弄清楚你在這裏到底作什麼的奇特方式。這個時候任何一種組織機構或者流程的存在都將是極其不利的。每一個人不得不是個通才而且可以解決各類類型的問題——專家們會在某種程度上（最好狀況)專注而又（最壞狀況）高度分散，由於他們想要引導產品到他們擅長的領域。

第2階段：第一批員工

一旦你有了一點資金而且可以僱用更多的開發人員，讓團隊發展到共5-9人時，你可能會發現點對點方式的協調（但願坐的靠近隊友從而可以聽到每件重要的事）開始被打破。你要多作一些事（關注其餘六我的的工做是耗時的）還要放棄一些事（你結束了試圖修復相同bug，回答相同的支持郵件或者回應相同的Nagios頁面的衝突）。

這時候，你想添加僅僅一小點的組織機構：也許一個週一的迭代計劃、平常的短時會議、跟蹤大的待辦項目以及白板上或者簡單工具（如Lighthouse）中的bug。也許你轉而使用像Zendesk可分配傳入支持請求的支持系統，並經過Pagerduty爲頁面添加一個簡單的呼叫旋轉。大家單獨的內部聊天頻道和電子郵件列表仍然能夠正常運行。

這時候必定要抑制引入太多的組織機構和流程的衝動。一些剛起步的公司在到達這一步的時，宣稱「咱們已經長大了，如今咱們能夠像真正的公司那樣去作了」而且當即嘗試切換到難以承受的戰術戰略上。例如：成熟的SCRUM、重量級工具如Jira、聘用項目經理或者設計管理人員。不要作這些事。你已經有了一個在特定方式下你們一塊兒工做、運做良好的團隊；在團隊裏你可能有一些天生的領導者，當他們忙於本身手頭工做的時還能夠指導不少的工做；同時當你推出產品到用戶手中時，在不少方面你仍然在嘗試弄清楚你的公司到底意義何在。引入官僚主意到這個環境中幾乎能夠確定阻止你真正想作的任何事情，這是探索你的可擴展商業模式的關鍵。

這個階段，專一是關鍵。每一個人還是通才，可是在特定的時間（即里程碑）整個開發團隊應該向着同一個目標。若是你嘗試一心多用，每件事都會作的很糟糕。大公司更有可能死於機會太多形成的消化不良而不是因爲機會太少致使的餓死。細心的選擇本身戰鬥領域並一直保持專一！

第3階段頻臨危機

成長到10-15位開發人員時，你正處於大團隊結構變更的邊緣。有人告訴我許多有前途的創業公司未能在這些階段中經受住轉變而失敗。

有這麼多的開發人員、迭代計劃、短時會議或者任何其餘類型的開發團隊會議已經讓這些與會者花費了太多的無聊時間。任何身處他人繁瑣的工做明細中掙扎的開發者我的將會很難找到目標感或者共享的方向。

在編程中，當一個類或者源文件開始變大，解決的方案就是分解成小模塊。擴展開發組織使用相同的原則，你須要把組織分解成具備針對性的團隊。

第3階段：分解團隊

劃分一支通才的團隊比提及來要難的多，劃分不得當，將會產生協調問題從而讓事情更糟糕。劃分合適，你將會看到幸福和生產力的大幅增長。

一支好團隊的關鍵是劃分好職權範圍，擁有清晰的接口供其餘團隊使用。團隊應該對他們所工做的產品部分擁有前景和方向。團隊應該擁有最大自主權來操做所擁有的一切，無需獲取許可或者來自其餘團隊的信息，除非少見的功能或者bug與其餘隊伍有了交叉點。

軟件架構與團隊架構的緊密對應將會是個很大的幫助。到這個時候，你可能已經把你的龐大應用程序轉換成了多個組件經過REST、AMQP、或者其餘RPC機制通訊的分佈式系統（若是沒有，你應該強烈建議這樣作，和分解的開發團隊步調一致）。軟件組件之間應該有明顯的映射——每個都有它們本身的源碼庫和部署位置/過程——和你的新生團隊。

起初決定什麼樣的人分配到哪一個團隊在某種程度上有點武斷。個人解決辦法就是你們坐下來而且深刻的理解系統的哪部分是他們最有激情的。從這點我盡最大的努力來分配團隊。第一次團隊的分配，有些人找到了完美的家，其餘不滿意的人須要公平快速的轉移到其餘隊伍。隨着時間的推移，團隊的領域就很好的造成，所以就能更容易的把新聘的員工插入到正確的崗位。讓開發人員跟隨他們本身的激情，他們將會天然的融入到團隊而且作出最好的工做。

另外，這個時候你應該找到了合適的產品/市場。若是你的公司發展到這個規模而且仍在尋找公司的意義所在，那麼大家的麻煩就大了。若是是這種狀況，抓緊中止規模的擴大並縮減規模，直到你捕捉到了合適的產品/市場。

專業化

分解團隊的另外一個緣由是專業化。工程類專家包括OPS工程師/系統管理員、基礎構架開發人員、前端web開發人員、後端web開發人員、業務工程師/數據分析師以及開發人員，他們關注特定的語言。語言專家愈來愈廣泛，由於許多網絡規模的公司使用像Erlang、Scala或者Clojure函數語言編寫高併發的組件，一般由不一樣的一組開發人員來處理而不是Ruby、Python或者PHPweb組件的做者。

在早期，專家是不多使人嚮往的。相對能作出貢獻的人的數量，在產品線上有太多人工做在不一樣層次上。所以每一個人在每件事上都作出了貢獻。這種狀況可能把一個開發人員分配到很是寬泛的工做崗位上，例如：在操做系統上更新內核的OPS項目，爲用戶界面編寫JQuery效果的前端項目。

一旦你達到了擁有十幾個開發人員的時候，你的產品已經達到了使用性和成熟度問題變得更難的層次。所以縮放數據庫不只是一個全職的工做，並且若是這我的同時經過學習成爲一個JQuery的專家、iOS專家和Erlang的專家，更須要一個不可被收購的深層次的專業知識。

你須要的僅僅是幾個能夠並願意密切關注相關領域的人，所以他們能夠在這些領域創建很是深厚的造詣。其中一些將會是現有通才中決定專業化的人並且還會有一些新員工。如今，當你的公司還比較小的時候，你能夠聘用這類並非相稱的專家。通才在身邊一般是頗有用的，其中有些可能進入了管理層——爲團隊灌輸企業全部者的角色，而不是親自動手開發。

Heroku公司的第一批團隊

Heroku的初始團隊分類看起來像這樣：

• API團隊——擁有面向用戶的web應用程序和匹配Heroku的客戶端gem。
• Data團隊——構建並運行咱們PostgreSQL做爲一種服務數據產品。
• Ops團隊——指導並保護產品系統的可用性。
• Routing團隊——管理一切必要的路由到用戶web的HTTP請求過程。
• Runtime團隊——處理部署的包裝碼和開始/中止/管理用戶進程。

這些隊伍擁有一到五個組件，例如，API團隊擁有運行在api.heroku.com和Heroku客戶端上的Rails的應用程序gem。Data團隊擁有數據庫服務的配置和監測工具，以及全部單獨運行的數據庫。（Peter van Hardenburg是位有膽識的內部管理者，他創立數據團隊而且如今領導着咱們。在這個視頻後部分他談到了一點相關的故事。）

團隊的規模和角色

對於咱們來講，理想的團隊構成由兩個開發者和一個公司的老闆組成。一位開發人員長期來講是不足夠的（他們須要在代碼上的第二雙眼睛，另外，一我的是孤單的）。三位開發人員也能夠工做的很好。發展到四至五位事情開始變得有點擁擠；未必有足夠的空間區域讓他們所有工做而不踩到其餘人的腳。幾乎全部的Heroku的團隊都有兩位開發人員。

「企業老闆」在某成程度上是愚笨的術語，可是它是咱們描述這我的爲團隊作一些產品管理、項目管理和通常管理組合的最好詞彙。企業老闆在瞭解團隊的工做對於企業的價值以及如何適用較大的產品中充當重要的角色。他們能夠跨團隊溝通交流，經過商業價值幫助合理處理項目和任務，還能夠提供團隊的進展及表現狀態報告給高級行政人員和/或整個公司來斷定團隊的持續存在性。

在企業家中我是一個黑客企業家的粉絲：強大的技術背景意味着他們對將要開始的工做擁有深刻的瞭解，並有能力贏得被指揮人員的敬重。這種人並非全部的團隊都能找到的，可是若是能，盡力找出他們。在許多狀況下，它涉及到須要具備至關的說服力才能讓黑客放棄他們重要的編碼生涯。

防止開發人員屬於多個團隊。他們是製造者，須要可以專一於他們團隊的當前項目，避免分心或者試圖參與多任務。然而，有時，公司老闆能夠屬於多個團隊。這並不老是一個全職的工做，經過同一個老闆的兩個或者多個相關的團隊進行跨團隊交流是有益處的。

凝聚力

在早期階段，你應該避免一心多用，爲了公司應該保證全部的開發人員關注單一的目標。隨着每一個團隊領域的創建，這種狀況已經改變。如今你能夠而且應該選擇多個目標。每一個團隊應該朝着本身的目標執行本身的任務，不用擔憂別的團隊在幹什麼。

同時可以進行三個、四個、五個大的目標真是太棒了。在Heroku劃分團隊後的幾個月，咱們有一天三個不一樣的團隊同時發佈了主要的新功能。真是一種難以置信的感受。

可是如今你有了一個新問題：缺少凝聚力。你的鬆散的團隊正在制定各自的路線圖以及各自的功能決定。可是爲了不你的產品零零碎碎，有人須要來決定整體的方向及產品的功能集。更簡潔的說：你須要一個戰略方案。

可是，這篇文章已經足夠長，就像團隊的成長。另有時間咱們再討論凝聚力和戰略方案吧。