如何擴充套件開發團隊(譯)

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

作為黑客，我們對於擴充套件web伺服器、資料庫和其他軟體系統的需求已經駕輕就熟。對於成長型公司，一個同等重要的事是擴充套件你的開發團隊。

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

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

一開始，你的公司有2-4人，工作在某人的住所、咖啡廳或者某個可以協作的地方。溝通和協調是很容易的：僅僅幾個人挨個坐著，每個人都知道其他人在做什麼。創始人和早期的員工往往是非常自主的，因此管理的需求幾乎是不存在的。每個人都是通才，每件事都多多少少得做點。只有一個單獨的組聊頻道和單獨的all@yourcompany.com的郵件列表。沒有真正需要任務跟蹤甚至是bug跟蹤的需求。整個公司以及你們的產品情況每個人都耳熟能詳。

這個階段，你們正在試圖建立並檢查你們的最小化可行產品（MVP），這個奇特方式將說明你們到底在做什麼。這個時候任何一種組織機構或者流程的存在都將是極其不利的。每個人必須是通才並且能夠解決各種型別的問題——專家們會在某種程度上（最好情況)專一而又（最壞情況）高度分散，因為他們想要引導產品到他們擅長的領域。

第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劃分團隊後的幾個月，我們有一天三個不同的團隊同時釋出了主要的新功能。真是一種難以置信的感覺。

但是現在你有了一個新問題：缺乏凝聚力。鬆散的團隊正在制定各自的路線圖以及各自的功能決定。但是為了避免你的產品零零碎碎，有人需要來決定總體的方向及產品的功能集。更簡潔的說：你需要一個戰略方案。

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

原文標題：How To Scale a Development Team

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