Jak spravujete rozsah a vyhnete se rozšiřování rozsahu?

Question

Accepted Answer

**Rozsah** je dohodnutá sada prací, kterou projekt dodá. **Rozšiřování rozsahu** je postupné, nekontrolované rozšiřování tohoto rozsahu — stálý proud "malých přidání", která tiše zpřehlížou harmonogram. Správa rozsahu znamená kontrolu *změny*, nikoli její odmítnutí.

## Jasně definujte rozsah od začátku

```text
✓ Document what's IN scope
✓ Document what's explicitly OUT of scope (the underused half)
✓ Define "done" / acceptance criteria
✓ Get stakeholders to agree before work starts
```

Písemně dohodnutá hranice vám později umožňuje říci "to je změna" s důkazy.

## Zpracovávejte změny záměrně

Změny nejsou špatné — nekontrolované jsou. Když přijde nový požadavek, provjeďte jej jednoduchou branou:

```text
1. Is it really needed now, or is it a "nice to have"?
2. What's the impact on timeline / cost / other work?
3. Make the trade-off VISIBLE → "yes, but it pushes the date / drops X"
4. Get the stakeholder to decide with full information
```

Klíčový krok: nikdy tiše neabsorbujte další práci. Udělejte z každého přidání vědomé kompromisu, který si vlastní stakeholder.

## Konkrétní příklad

V polovině projektu stakeholder požádá "také podporovat hromadné nahrávání — mělo by to být rychlé." Místo toho, aby jste to vtlačili dovnitř, odpovíte: "Můžeme, ale trvá to asi týden. Posuneme datum, nebo přesuneme funkci analýzy na další vydání?" Nyní je to jejich rozhodnutí s jasným náklady.

## Časté úskalí

Říci ano každému požadavku, abyste byli nápomocní, a pak zmeškat termín. Tým vypadá, že selhal, když ve skutečnosti tiše převzal další práci.

## Proč na tom záleží

Rozšiřování rozsahu je nejčastějším důvodem zpoždění projektů — ne proto, že by jedna změna byla velká, ale proto, že se desítky tiše hromadí.

Správa rozsahu udržuje projekt čestný: změna je v pořádku, ale její náklady jsou vždy jasně uvedeny a vlastní ji ten, kdo ji chce.