Kako skaliraš inženjerske prakse dok tim raste?

Question

Accepted Answer

Prakse koje funkcioniraju za 3 inženjera slome se na 30. Neformalna koordinacija, plemenske znanja i ručni procesi se ne skaliraju. Senior TL mora **razviti prakse ispred krivulje rasta**, formalizirajući dovoljno strukture da bi se održala brzina bez birokratije.

## Što se trebalo 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
```

## Konkretan primjer

S 5 osoba svi znaju cijeli sustav i raspoređuju ručno. S 25, to je kaos, trebate pravi CI/CD cjevovod, vlasništvo nad servisima, pisane runbooks i norme pregleda, ili će tim zastati boreci se jedni s drugima.

## Dodaj strukturu upravo na vrijeme

Ne nameću težak proces malom timu (guši ga), i nemoj se hvatati startup neformalnosti na velikom (pada se). Dodaj svaki dio strukture *kada se pojavi bol*, idealno malo prije. Pazite na znakove: rastuće merge konflikte, uska grla znanja, nestabilne rasporede.

## Kompromis

Više procesa zamjenjuje fleksibilnost za dosljednost i mjerilo. Premalo i veliki timovi se muku; previše i gušiš brzinu koja te je učinila uspješnom. Neprekidno usklađuj.

## Zašto je važno

Prakse koje su malu grupu dovele do uspjeha aktivno će zagušiti veću.

TL koji proaktivno skalira prakse drži rastući tim brzim; onaj koji to ne čini gleda kako brzina pada dok tim raste, klasična zamka skaliranja.