Jak projektuje się strukturę organizacyjną i zespołu?

Question

Accepted Answer

Projektowanie organizacji to **rysowanie granic zespołów, aby praca, która zmienia się razem, żyła razem** — minimalizowanie zależności między zespołami dla rzeczy, które poruszają się szybko. Struktura powinna podążać za strategią i systemem, a nie odwrotnie.

## Zasady

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## Myślenie zorientowane na strumień

Faworyzuj długoterminowe, zorientowane na strumień zespoły, które posiadają przepływ pracy, wspierane przez zespoły platformowe, które zmniejszają obciążenie poznawcze innych. Reorganizuj, gdy struktura zaczyna walczyć z pracą — nie z kaprysu.

## Pułapki

- **Funkcjonalne silosy** ("zespół QA", "zespół frontend") które zmuszają każdą funkcję do przejścia przez wiele przekazań.
- **Ignorowanie prawa Conwaya** i zdziwienie, że architektura odzwierciedla schemat organizacyjny.
- **Stała reorganizacja**, która za każdym razem resetuje zaufanie i odpowiedzialność.
- **Niejasna własność**, gdzie wszystko jest "współdzielone" i dlatego należy do nikogo.

## Dlaczego to ważne

Struktura po cichu określa prędkość.

Złe granice tworzą niekończące się spotkania koordynacyjne i niejasną odpowiedzialność; dobre granice pozwalają zespołom działać niezależnie.

Z powodu prawa Conwaya projektowanie organizacji *to* projektowanie architektury.

Jeśli źle określisz granice zespołów, żadna ilość heroizmu inżynieryjnego nie sprawi, że system będzie czysty.