Kuinka suunnittelet organisaation ja tiimin rakenteet?

Question

Accepted Answer

Organisaation suunnittelu on **tiimin rajojen piirtämistä siten, että yhdessä muuttuva työ elää yhdessä** — riippuvuuksien minimoiminen tiimien välillä nopeasti liikkuville asioille. Rakenteen tulee noudattaa strategiaa ja järjestelmää, ei päinvastoin.

## Periaatteet

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

## Virtaan kohdistettu ajattelu

Suosi pitkäikäisiä, virtaan kohdistettuja tiimejä, jotka omistavat työvoiman, joita tukevat alustatiimet, jotka vähentävät muiden kognitiivista kuormitusta. Uudelleenjärjestä, kun rakenne alkaa taistella työtä vastaan — ei mielijohteesta.

## Sudenkuopat

- **Toimintosiilos** ("QA-tiimi", "frontend-tiimi"), joka pakottaa jokaisen ominaisuuden ylittämään monia siirtoja.
- **Conwayn lain huomioimisen puute** ja yllätys, että arkkitehtuuri heijastaa organisaatiokaavioita.
- **Jatkuva uudelleenorganisointi**, joka nollaa luottamuksen ja omistajuuden joka kerta.
- **Epäselväämpi omistajuus**, jossa kaikki on "jaettu" ja siksi kukaan ei omista sitä.

## Miksi sillä on merkitystä

Rakenne määrittää nopeuden hiljaisesti.

Huonot rajat luovat louttomattomia koordinaatiokokouksia ja hämärää vastuunottoa; hyvät rajat antavat tiimeille liikkua itsenäisesti.

Conwayn lain vuoksi organisaation suunnittelu *on* arkkitehtuurin suunnittelu.

Jos saat tiimin rajat väärin, mikään määrä insinööriheroismia ei tee järjestelmää puhtaaksi.