Jak navrhujete strukturu organizace a týmu?

Question

Accepted Answer

Návrh organizace spočívá v **kreslení hranic týmu tak, aby práce, která se mění dohromady, žila pohromadě** — minimalizace závislostí mezi týmy pro věci, které se rychle mění. Struktura by měla sledovat strategii a systém, ne naopak.

## Principy

```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šlení orientované na stream

Favoizujte dlouhodobé, na stream orientované týmy, které vlastní tok práce, podporované platformovými týmy, které snižují kognitivní zátěž ostatních. Reorganizujte, když struktura začne bojovat proti práci — ne na základě choutky.

## Úskalí

- **Funkční silos** ("QA tým," "frontend tým"), které nutí každou funkci procházet mnoha handoffy.
- **Ignorování Conwayova zákona** a překvapení, že architektura zrcadluje organigram.
- **Neustálá reorganizace**, která pokaždé resetuje důvěru a vlastnictví.
- **Nejasné vlastnictví**, kde je vše "sdílené" a proto vlastněno nikým.

## Proč to má vliv

Struktura tiše určuje rychlost.

Špatné hranice vytváří nekonečné koordinační schůze a rozmazanou odpovědnost; dobré hranice umožňují týmům pohybovat se nezávisle.

Kvůli Conwayovu zákonu je návrh organizace *je* návrh architektury.

Pokud se mýlíte v hranicích týmu, žádné množství inženýrských hrdinství nesjednotí systém.