Cum proiectezi structura organizațională și a echipei?

Question

Accepted Answer

Proiectarea organizației este despre **trasarea limitelor echipei, așa încât munca care se schimbă împreună să trăiască împreună** — minimizând dependențele între echipe pentru lucrurile care se mișcă rapid. Structura trebuie să urmeze strategia și sistemul, nu invers.

## Principii

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

## Gândirea orientată pe flux

Favorizeaza echipele de lungă durată, orientate pe flux, care dețin un flux de muncă, susținute de echipe de platformă care reduc sarcina cognitivă a celorlalți. Reorganizează atunci când structura începe să se lupte cu munca — nu pe o capriciu.

## Capcane

- **Silourile funcționale** (o "echipă QA," o "echipă frontend") care forțează fiecare funcționalitate să treacă prin multe transferuri.
- **Ignorarea legii lui Conway** și surpriza că arhitectura reflectă organigrama.
- **Reorganizarea constantă**, care resetează încrederea și responsabilitatea de fiecare dată.
- **Proprietate neclară**, unde totul este "partajat" și, prin urmare, nu aparține nimănui.

## De ce conteaza

Structura determină tăcut viteza.

Limitele proaste creează ședințe de coordonare nesfârșite și responsabilitate încurcată; cele bune permit echipelor să se miște independent.

Datorită legii lui Conway, proiectarea organizației *este* proiectarea arhitecturii.

Dacă greșești limitele echipei, nici o cantitate de eroism ingineresc nu va face sistemul curat.