Jak škálujete inženýrské praktiky, když tým roste?

Question

Accepted Answer

Praktiky, které fungují pro 3 inženýry, selhávají při 30. Neformální koordinace, tacitní znalosti a ruční procesy se neškálují. Senior TL musí **vyvíjet praktiky předem před křivkou růstu**, formalizovat jen tolik struktury, aby se zachovala rychlost bez byrokracie.

## Co se musí škálovat

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

## Konkrétní příklad

Při 5 lidech každý zná celý systém a nasazuje ručně. Při 25 lidech je to chaos, potřebujete skutečný CI/CD pipeline, vlastnictví služeb, napsané runbook a normy pro code review, jinak se tým zasekne v interních konfliktech.

## Přidávejte strukturu včas

Neukládejte těžký proces malému týmu (udusí ho) a neulpívejte na startup neformálnosti u velkého (zhroutí se). Přidávejte každý kus struktury *jak se bolest objevuje*, ideálně těsně předtím. Pozorujte signály: rostoucí merge konflikty, úzká místa znalostí, nestabilní nasazení.

## Trade-off

Více procesů vyměňuje flexibilitu za konzistenci a škálování. Málo a velké týmy se trápí; moc a udusíte rychlost, která vás udělala úspěšnými. Kalibrujte průběžně.

## Proč je to důležité

Praktiky, které dostaly malý tým k úspěchu, aktivně zadusí větší tým.

TL, který proaktivně škáluje praktiky, udržuje rostoucí tým rychlý; ten, který to nedělá, sleduje, jak se rychlost zhroutí, jak tým roste – klasická past škálování.