Kako prilagodite inženirske prakse, ko se ekipa povečuje?

Question

Accepted Answer

Prakse, ki delujejo za 3 inženirje, se pokvarijo pri 30. Neformalna koordinacija, племenska znanja in ročni procesi se ne skalirajo. Izkušen TL mora **razvijati prakse pred krivuljo rasti**, formalizirati toliko strukture, da ohrani hitrost brez birokratije.

## Kaj se mora skalirati

```text
✓ CI/CD — fast, reliable, automated; manual deploys don't survive growth
✓ TESTING — automated suites; you can't manually verify everything
✓ CODE REVIEW — clear norms, reasonable turnaround, ownership boundaries
✓ DOCUMENTATION — written knowledge replaces "ask Bob"
✓ ONBOARDING — repeatable, not bespoke per hire
✓ DECISION-MAKING — clear ownership; who decides what
✓ ON-CALL / OWNERSHIP — defined, rotated, not heroic
```

## Konkreten primer

Pri 5 osebah vsi poznajo celoten sistem in ročno nalagajo. Pri 25 je to kaos, potrebujete pravo CI/CD cevovod, lastništvo storitev, napisane runbook-e in norme pregleda, ali se ekipa ustavi in se medseboj bori.

## Dodajte strukturo pravočasno

Ne vsiljujte težke procese mali ekipi (jih zadušijo) in se ne držite startup neformaliziranosti pri veliki (se sesede). Dodajte vsak del strukture *ko se pojavijo bolečine*, idealno malo prej. Pazite na signale: naraščajoči konflikti pri spajanju, ozka grla znanja, nestabilne nalaganja.

## Kompromis

Več procesov zamenja fleksibilnost za konsistentnost in obseg. Premalo in velike ekipe se mečejo; premalo in zadušite hitrost, ki vas je naredila uspešne. Nenehno prilagajajte.

## Zakaj je to pomembno

Prakse, ki so malo ekipo pripeljale do uspeha, bodo večjo zadušile.

TL, ki proaktivno skalira prakse, drži rastujo ekipo hitro; tisti, ki je ne, gleda, kako se hitrost propada, medtem ko ekipa raste, klasična past skaliranja.