軟體工程團隊的基於領域的結構 - snaptravel

banq發表於2022-05-06
軟體工程APT

2021年初，在Snapcommerce，我們有25名工程師在班組工作。每個小組都有一個工程經理（EM）作為所有專案的負責人和技術負責人（TL），一個產品經理（PM），一個設計師，一個QA團隊成員，以及最多七個個人貢獻者（IC）工程師。對於工程師來說，從一個IC成長為TL可能是一條具有挑戰性或不明確的道路。每個小組有一個TL，這並沒有為IC創造一個自然的成長機會，以發展他們的技術領導和所有權技能。

我們的團隊在結構上遇到的一些其他挑戰包括。
  • 缺少重點。我們的衝刺階段更多的是將高優先順序的任務混合在一起，而不是為明確的衝刺目標而努力。
  • 在會議上花費太多時間。每個人都出席了所有的團隊敏捷會議（站立、衝刺計劃和積壓工作），但只有一部分會議與他們的工作和專長相關。
  • 共同的OKR所有權。團隊的OKR交付責任是由團隊共同承擔的，這往往導致了責任感的缺失。
  • 單一的失敗點。沒有一個有意識的努力來確保單一的失敗點不會自然形成。
  • 價值流被阻斷。影響的結構越來越大，超出了EM或任何一個人能夠掌握的範圍；顯然需要更多的分散式專業知識。

我們的解決方案是將我們的小隊組織成一個基於領域的結構，我們將在下面討論。這有助於團隊和組織的整體成功，同時也構建和增加了我們的IC增長機會。

自從推出基於領域的結構以來，我們的團隊規模增加了一倍，超過了50名工程師，我們在2022年第一季度的銷售額突破了10億美元。以下是我們如何使用基於領域的班組結構來擴大我們的軟體工程團隊。

領域的功能和結構
一個領域是一個小隊的重點領域或專業。透過每個小隊擁有多個領域，小隊可以細分他們的工作，以專注於不同的業務、產品或技術重點領域。每個領域通常包含一個或多個OKRs或epics。

每個領域由以下角色組成。

1、領域領導（DL）
對該領域的成功負責的工程師。他們與PM一起工作，領導計劃會議、儀式和實施。這是一個技術領導的機會，因為他們作為領域的TL發揮作用，幫助分配領域內的工作。這不是一個正式的導師或領導職位，它通常由團隊中的中級或高階工程師擔任。

2、領域貢獻者（DC）
當涉及到計劃會議、儀式和執行時，為領域做出貢獻的工程師。每個領域至少會有一個，一個工程師可以同時是一個領域的DL和另一個領域的DC，或者是一個以上領域的DC。

我從第一原則出發，透過觀察我們對傳統團隊的挫敗感，看到了改進的機會，從而開發了領域。關於類似的結構，如團隊拓撲結構，有一些文獻正在出現。領域與流對齊的拓撲結構有關，也就是工作流與業務領域對齊。他們都在一個領域內推動簡化的、快速流動的溝通。

領域結構的好處
將我們的小隊分為領域，帶來了以下好處。

  • 多個IC可以增長他們的TL技能
    與每個小隊只有一個TL相比，有多少領域就有多少DL職位（通常每個小隊有3-4個）。DL獲得了領導敏捷儀式的機會，而工程師們也有了更大的主人翁意識，在這個結構中成長得更快。我們已經看到工程師成長為高階工程師，高階工程師成為經理。
  • 減少會議時間
    有了領域，我們不僅減少了會議（因為敏捷儀式是在領域層面上組織的），而且會議更加集中，與個人工作相關。每個工程師的會議時間減少到M/N，其中M是他們所在領域的數量，N是團隊中領域的總數量。例如，如果團隊有4個領域（N=4），每個工程師最多屬於2個領域（M=2），那麼與傳統的團隊模式相比，他們花在會議上的時間應該減少約50%。
  • 減少單點故障
    在我們以前的團隊中，積體電路往往會發展成單點故障/知識孤島，因為很多人最終會自己去做專案。在一個領域裡有多個工程師，沒有人應該單獨工作。我們增加了協作和知識共享，也降低了匯流排係數。
  • 避免單一經理人負擔過重
    期望一個單一的EM/TL知道整個團隊的所有事情，可能會使他們不堪重負或導致疏忽。有了領域，團隊中有多個DL，他們各自負責領導自己的領域並在其中分配工作。EM支援DL。
  • 更大的所有權意識
    作為團隊，對團隊OKRs有共同的所有權。領域建立了一個專門的工程師小組，為該領域提供最大的背景、所有權和連續性。在Snapcommerce，它為業務團隊提供了明確的聯絡物件，許多團隊很高興有一個領域專注於他們的倡議。
  • 平衡可持續性和生產力
    知識共享有助於我們的可持續發展和避免孤島，但端到端的所有權會推動生產力。透過領域，我們根據工程師所處的領域的多少來調整這種平衡。並非每個人都需要了解我們所監督的所有內容；相反，他們可以深入到監督的一個子集，但不是作為一個單一的故障點。
  • 密切協作和目標導向的交付感
    現在，我們有更小的工程師單位，有更強的共享所有權和協作意識，而不是一個大的團隊，有些人最終會單獨工作，以便將我們的努力分配到各個業務需求。我們對團隊衝刺目標的最佳實踐是，每個領域都有自己的高度集中的目標，並有明確的所有權。


領域結構的問題與挑戰
我們對領域的第一次體驗是在我們的資料和分析組織中成功地推出了它們。這讓我們對建立領域的挑戰有了一些經驗，比如說。

1、定義好領域
領域往往是按照OKRs來組織的，然而，領域最好能超過季度的界限，以便有更多的技術領導的連續性和專業知識的積累。

無論是基於產品線、目標線，還是技術/架構線，都有必要對領域的定義進行批判性思考。一個以基礎設施或架構為競爭優勢的高度技術性組織，很可能需要在技術路線上定義領域，因為它需要在一個較窄的領域有深厚的專業知識。初創企業和業務交付組織更有可能在產品或目標線上定義領域。

2、團隊結構檔案的正規化
自然地，領域在團隊層面上創造了一個稍微複雜的結構，這就需要對領域以及它們的DL和DC進行明確的記錄。關鍵是要建立一個團隊章程或類似的檔案，清楚地說明什麼是領域，誰是每個領域的一部分。幸運的是，所有的工程師仍然向EM報告，所以報告結構仍然簡單。

 

相關文章