Hogyan tervezel meg egy szervezeti és csapatstruktúrát?

Question

Accepted Answer

A szervezeti tervezés arról szól, hogy **úgy húzol meg csapathatárokat, hogy az együtt változó munka együtt maradjon** — minimalizálva a csapatok közötti függőségeket azoknál a dolgoknál, amelyek gyorsan mozognak. A struktúrának a stratégiát és a rendszert kell követnie, nem fordítva.

## Alapelvek

```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
```

## Folyamattal igazított gondolkodás

Favorizálj hosszú élettartamú, folyamattal igazított csapatokat, amelyek a munka folyamatát birtokolják, és platformcsapatok támogatják, amelyek csökkentik mások kognitív terhelését. Szervezz újra, ha a struktúra a munka ellen kezd harcolni — nem szeszélyből.

## Csapdák

- **Funkcionális silók** (egy "QA csapat," egy "frontend csapat"), amelyek arra kényszerítenek minden funkciót sok átadáson keresztül.
- **Conway törvényét figyelmen kívül hagyni** és azt megtapasztalva, hogy az architektúra tükrözi a szervezeti diagramot.
- **Állandó átszervezés**, amely minden alkalommal alaphelyzetbe állítja a bizalmat és a tulajdonjogot.
- **Homályos tulajdonjog**, ahol minden "megosztott" és ezért senki sem tulajdonosa.

## Miért fontos

A struktúra csendesen meghatározza a sebességet.

A rossz határok végtelen koordinációs értekezleteket és elmosódott felelősséget teremtenek; a jó határok lehetővé teszik a csapatoknak, hogy függetlenül mozogjanak.

Conway törvénye miatt a szervezeti tervezés *az* építészeti tervezés.

A csapathatárokat helytelenül rajzolod meg, és semmilyen mérnöki hősiességre nem lesz szükség a rendszer tisztázásához.