英文原文：adam.heroku.com，翻譯：CSDN
導讀：我們清楚管理網路伺服器、資料庫和其他軟體系統的必要性。在成長型企業，管理開發團隊同樣重要。大部分科技公司在管理10人左右的開發團隊會遇到瓶頸。過去幾年，Adam wiggins（Heroku的創始人之一）在 Heroku 相當成功地探究過這個管理困境，這篇文章將呈獻他在管理團隊的經驗和每一階段所遇到的問題和可能的解決方法。
階段一：自釀
在開始階段，你的公司有2-4個人在客廳、咖啡廳或者一個共同工作空間工作。溝通協調是很容易的，大家坐在一起，每個人都知道其他人在幹什麼。公司的創始人和早期的員工都很有自主性，貌似沒管理的必要。每個人都是多面手，參與公司的各項事務。你有一個單獨的群聊頻道和單獨的郵寄名單all@yourcompany.com。沒有什麼迫切需要去跟蹤任務和發現什麼漏洞。整個公司的運營狀態和產品現狀都在每個人的腦海中。
在這個階段，你在試圖創造或者說是呵護你那剛起步的產品，說的通俗點就是你要知道你自己在幹什麼。任何形式的框架或者固定的程式都是極其有害的。每個人必須是個多面手才能解決任何出現的問題，專家的話，在遇到棘手的問題時就會很厭煩，更有甚者會轉移團隊的重心。他們想把產品發展固定到某一個自己所熟悉的領域。
Heroku logo
階段二：初始聘用
一旦你擁有了一點資金，能夠僱傭多一些的開發者，達到5-9人，你也許會發現“無線協調辦法”開始失效，有些人會坐到別人旁邊，希望知道所有重要的資訊。你有時會密切關注其他幾個人的工作，這是很耗時間的，或陷入溝通不暢，結果所有人都在修復同樣的漏洞，回覆同樣的郵件或是響應同樣的程式頁面。
到了這個階段，你會想到構建一點公司架構：也許是在週一做重複計劃、每日的站立會議和用白色書寫板跟蹤一些大的待辦事項和一些漏洞，或利用一些簡單的工具，例如Lighthouse。也許你會轉向Zendesk一樣的支援系統，可以指定傳入式的支援請求。你也可以通過Pagerduty增加簡單的輪流加班。你的單獨內部溝通和郵箱通道就能夠繼續正常工作。
不要引入太多的組織結構和工作流程。一些創業公司在這一發展階段會宣傳自己已經成長為一個真正的公司，立馬想要切換到一些笨手笨腳的策略。例如使用羽翼豐滿的Scrum，重量級工具如Jira，或是僱傭專案管理經理和技術經理。不要做這樣的事情。你的團隊以“無線”模式運轉的很好，團隊或許有一些天生的領袖人物在掌控大量的工作，而且他們都參與其中。即使你的產品釋出後，到了消費者手中，你仍在某種程度上摸索你公司的未來。引入官僚主義無疑會阻礙你做成自己真正想做的事情，而這個初衷會在不斷的創業過程漸漸浮出水面上來。
這一階段的關鍵是專注力。每個人仍是多面手，但是開發團隊應該目標一致，一步一個腳印。如果想多線作戰，你什麼也做不好。偉大的公司多是衰落於多線作戰而不是在某一領域失敗。慎重地選擇你的戰場，然後保持專注力。
進入階段三前的危機
達到10-15個開發者，你要著手調整大的團隊建構了。有人告訴我說很多有希望的創業公司沒能從第二階段安全過度到第三階段。
擁有了如此多的開發者之後，反覆計劃，站立會議和其他形式的開發者團隊會議都頗具規模，而參加者與會期間會感到厭煩。每一個獨立的開發者很難在別人事無鉅細的工作展示中發現意義和共識。
在公司規劃中，當一個階層或是來源檔案變得很大時，解決方案就是把他們分解成小塊。管理一個開發團隊也是如此。你需要把團隊分解成定向的幾支隊伍。
階段三：分解團隊
分解單一的多面手團隊不是看起來那麼容易的。陣營劃分錯誤會造成更大的協調障礙。劃分得當會增加團隊的專注力，幸福感和效率。
一個好的團隊的關鍵在於權責分明。團隊對自己負責的部分擁有遠見和方向感。她能夠全權在自己的領域運作，不需要別的團隊的許可或資訊，除了一些跨團隊的罕見的案例。
軟體架構和團購架構間的精密籌劃會很有益處。到現在為止，你也許已經把整體的團隊變成了由多個部分組成的分散式系統，通過REST、AMQP或者其他RPC機制溝通交流。如果你現在沒這麼做，你應該馬上考慮這樣做，與分散開發隊伍同時進行。在各個軟體構件和原始團隊中間應該有一個顯而易見的籌劃，每一個構件都有自己的資源庫和部署位置和流程。
決定人員分佈有些武斷的成分在。我的辦法是跟每個開發者坐下來談心，深入瞭解他們最喜歡工作的領域。因此我人盡其能地分配我的團隊。一些人發現第一次團隊分配很適合他們，而另一些人不是很滿意，他們需要馬上轉到別的團隊。隨著時間的推移，團隊的分工日益明確，我們能更加容易地人盡其才。讓開發者追隨自己的內心，然後他們將會到最適合自己的團隊做自己最擅長做的工作。
到這個節點，你應該很清楚自己的產品和市場的契合點。如果公司發展到這個規模。你還在尋找公司存在的意義，你就遇到大麻煩了。如果事實果真如此的話，你應該停止公司的業務擴充套件，停下腳步直到發現切合市場的產品。
Adam Wiggins
專門化
另一個分組的動機是專門化。工程專家的分類包括ops工程師高階系統管理員、基礎設施開發者、前段網路開發者、後端網路開發者、業務工程師、資料分析師和聚焦特定編碼語言的開發者。編碼語言專家越來越普遍，因為越來越多的網際網路公司使用諸如Erlang、 Scala或Clojure等函式程式語言寫入高併發元件。這些函式程式語言由不同的開發者負責，而不是 Ruby、 Python、或是 PHP網路元件的創始人。
在早些時候，專家很難令人滿意。釋出軟體產品工作有很多層級，關係到很多有貢獻的人，每個人都有貢獻。這使得開發者兼顧非常廣泛的領域，從ops專案例如OS上的kernel更新到前端專案例如為UI編寫jQuery效果。
一旦你擁有了12個開發者，你的產品已經有了一定的使用量和成熟度，同時也出現了一些問題。管理資料庫不僅是個全職工作，更需要很強的專業知識背景，如果這人同時學習jQuery 、iOS和Erlang ，他是不能夠勝任這份工作的。
你需要這樣的員工，他們能夠而且樂於專注於某一領域，這樣他們才能成為這一領域的專家。一些人將是目前的多面手，他們願意專注於某一領域，而另一些將是新僱傭的員工。你現在能夠僱傭些專家，這些人在公司規模縮小後將不會再適用於公司。有多面手在身邊總是有用的，一些多面手也許能進入管理層，成為公司團隊的股東而不是親力親為的開發者。
Heroku的首批團隊
Heroku的初始團隊分佈如下;
● API-擁有面向使用者的網路應用和與之相配套的Heroku客戶品質
● 資料— 建構運營資料庫系統 作為資料庫服務產品
● Ops-維護執行系統的有效性
● Routing–管理 能協助使用者Web流程 獲得HTTP路由請求
● 執行時間—處理包裝程式碼 為了 部署、開始、停止、管理 戶程式
每個團隊都由1-5個部分組成。例如，API團隊擁有Rails app，在api.heroku.com和“Heroku客戶品質”執行。資料團隊擁有為資料庫服務的開通和監控工具，還有個人執行資料庫。Peter van Hardenburg 是資料組的創始人和現在的領導者，他在視訊的後半段談到了這一點。
團隊規模和角色
對我們而言，理想的團隊結構式2名開發者，一個業主。一個開發者長期來看是不夠的，我們需要另一雙眼睛來看程式碼，一總是一個寂寞的數字。三個開發者也能執行的很好。到了4-5個人時事情就會變得複雜了，因為沒有足夠的空間讓所有的工作不重疊。幾乎所有的 Heroku團隊都有2名開發者。
業主是有些拙笨的一個詞彙，但這又是最好的一個詞，用來形容一個人同時做著產品管理、專案管理和團隊的綜合運營等工作。業主為團隊注入了商業認知和價值觀，還有如何才能擴大生產規模。他們能夠促進跨團隊溝通，通過商業價值區分專案和任務的優先順序，或許還能夠為高管和整個公司提供團隊進展的現狀報告，這也許會決定這個團隊的生存。
我是網際網路創業公司“業主”角色的愛好者：很強的技術背景意味著他們對自己所做的工作有很深刻的理解，而且能夠很好的控制他們團隊對自己的敬意。這型別的領導者不是在每個團隊都找得到，但我們應該儘可能的去找。在很多情況下，這就在說服的功力，使一個技術人員放棄自己最初的夢想——編碼。
不要讓開發者隸屬多於一個團隊。他們是創造者，需要在團隊現行的專案上持續保持專注度，不能夠為了別的任務分心。然而，業主又是可以多工操作，也不總是一個全職工作，一個業主在2個以上團隊工作對跨團隊交流溝通是有益處的。
凝聚力
在前幾個階段，你應該讓所有的開發者專注於一個單獨的目標，避免多線作戰。當為單獨的團隊設定了專業領域之後，情況就有變化了。你應該開闢多個戰場。各個團隊獨立作戰，不需要關心別的團隊在幹什麼。
同時追3-5個大專案是很酷的。在Heroku分組後的幾個月之後的某一天，我們三個不同的團隊都有了重大的進展，這是一種難以置信的感覺。
但現在你會有一個新的問題：缺乏凝聚力。分散的團隊會制定各自的路線圖，獨立決定今後的特色。為了避免產品的碎片化，需要有人制定一個總體的規劃和一個總的產品價值體系。更簡潔的說就是需要制定一個戰略。