Team Topologies: cztery typy zespołów i trzy tryby współpracy
Team Topologies to podejście do projektowania zespołów produktowych i technologicznych, opisane przez Matthew Skeltona i Manuela Paisa w książce z 2019 roku. Artykuł opisuje cztery typy zespołów, trzy tryby współpracy, rolę obciążenia poznawczego oraz przeliczony przykład decyzji o zespole platformowym.
Kwoty i wartości w przykładach są danymi ilustracyjnymi, które pokazują sposób obliczeń. W projektach stosujemy dane klienta.
Dominik Dębski · Lemur Media · · czas czytania: 4 min
Sprawdził: Dominik Dębski, 1.11.2026
Czym jest Team Topologies?
Team Topologies to model organizacji zespołów, który ustala typ każdego zespołu i sposób jego współpracy z innymi tak, aby praca płynęła do klienta z jak najmniejszą liczbą przekazań. Autorami są Matthew Skelton i Manuel Pais, a książka „Team Topologies: Organizing Business and Technology Teams for Fast Flow” ukazała się w 2019 roku nakładem IT Revolution; drugie, rozszerzone wydanie ma datę 23 września 2025 roku. Model opiera się na prawie Conwaya (Conway's law), czyli obserwacji Mela Conwaya z 1968 roku, że systemy powielają strukturę komunikacji organizacji, która je tworzy. Z tego powodu strukturę zespołów projektuje się świadomie, zanim powstanie architektura systemów.
Jakie są typy zespołów i tryby współpracy?
| Typ zespołu | Rola |
|---|---|
| Zespół strumieniowy (stream-aligned) | Dostarcza wartość w jednym strumieniu pracy, np. dla segmentu klientów lub etapu drogi klienta |
| Zespół wspierający (enabling) | Pomaga zespołom strumieniowym przyswoić nowe umiejętności i praktyki, a potem się wycofuje |
| Zespół złożonego podsystemu (complicated subsystem) | Utrzymuje część wymagającą wąskiej specjalizacji, np. silnik wyceny lub model predykcyjny |
| Zespół platformowy (platform) | Udostępnia usługi wewnętrzne, z których zespoły strumieniowe korzystają samodzielnie |
Zespoły współpracują w jednym z trzech trybów. Współpraca (collaboration) oznacza wspólną pracę przez ograniczony czas, np. przy nowym produkcie. Usługa (X-as-a-Service) oznacza korzystanie z gotowej usługi innego zespołu przy minimalnej komunikacji. Ułatwianie (facilitation) oznacza pomoc w usunięciu przeszkód lub nauce nowej praktyki.
Dlaczego obciążenie poznawcze ma znaczenie?
Autorzy traktują obciążenie poznawcze zespołu (team cognitive load) jako jedno z głównych kryteriów projektowania: zespół odpowiada za tyle domen, ile jest w stanie zrozumieć i utrzymać. Przeciążony zespół podejmuje gorsze decyzje i staje się wąskim gardłem dostaw. W praktyce oznacza to ograniczenie liczby systemów, technologii i obszarów biznesowych przypisanych jednemu zespołowi oraz przeniesienie powtarzalnej pracy infrastrukturalnej do platformy.
Z prawa Conwaya autorzy wyprowadzają tak zwany odwrócony manewr Conwaya (reverse Conway maneuver): zmianę struktury zespołów i ścieżek komunikacji przed budową systemu, tak aby powstająca architektura odpowiadała architekturze docelowej. W praktyce oznacza to, że decyzja o podziale systemu na moduły i decyzja o podziale zespołów zapadają razem. Jeśli firma chce niezależnie rozwijać moduł płatności i moduł katalogu, każdy z nich potrzebuje osobnego zespołu z jasną odpowiedzialnością.
Jak zaprojektować zespoły w praktyce?
Projekt zaczyna się od strumieni wartości dla klienta, a dopiero potem ustala się typy zespołów i tryby współpracy. W naszej praktyce stosujemy pięć kroków.
- Strumienie wartości: lista segmentów klientów, produktów lub etapów drogi klienta, w których firma dostarcza wartość.
- Zespoły strumieniowe: jeden zespół na strumień, z kompletem kompetencji potrzebnych do dostarczenia zmian bez przekazań.
- Obciążenie poznawcze: przegląd systemów i domen przypisanych każdemu zespołowi oraz przeniesienie nadmiaru do platformy lub zespołu złożonego podsystemu.
- Tryby współpracy: zapis, które zespoły współpracują, w jakim trybie i do kiedy.
- Miary przepływu: czas od pomysłu do wdrożenia, liczba zależności między zespołami, odsetek pracy zablokowanej przez inne zespoły.
Model dotyczy także zespołów spoza IT. Strumień wartości dla segmentu klientów może obejmować produkt, marketing, sprzedaż i obsługę, a zespół danych często pełni funkcję platformy dla pozostałych.
Kiedy zespół platformowy się opłaca?
Zespół platformowy opłaca się, gdy czas, który oszczędza zespołom strumieniowym, jest większy niż jego własna obsada.
| Składnik | Obliczenie | Wynik |
|---|---|---|
| Czas na infrastrukturę przed zmianą | 6 zespołów × 7 osób × 20% | 8,4 etatu |
| Czas na infrastrukturę po zmianie | 6 zespołów × 7 osób × 5% | 2,1 etatu |
| Czas oszczędzony | 8,4 − 2,1 | 6,3 etatu |
| Obsada zespołu platformowego | 5 etatów | |
| Zysk netto | 6,3 − 5 | 1,3 etatu |
Przy czterech zespołach strumieniowych oszczędność wyniosłaby 4 × 7 × 15% = 4,2 etatu, czyli mniej niż obsada platformy. Wtedy lepszym rozwiązaniem jest zespół wspierający na kilka miesięcy albo usługa zewnętrzna.
Jakie są ograniczenia i typowe błędy?
- Zmiana nazw istniejących działów na typy zespołów bez zmiany odpowiedzialności i przepływu pracy.
- Stała współpraca między zespołami: tryb współpracy powinien mieć termin zakończenia.
- Zespół platformowy, który przyjmuje zlecenia zamiast udostępniać usługi do samodzielnego użycia.
- Pominięcie zespołów biznesowych: model dotyczy także sprzedaży, marketingu i danych, jeśli uczestniczą w tym samym strumieniu wartości.
- Brak miar przepływu, np. czasu od pomysłu do wdrożenia, przed reorganizacją i po niej.