Jak spravujete rozšiřování rozsahu projektu?

Question

Accepted Answer

**Rozšiřování rozsahu**, plynulá akumulace "ještě jedné věci", je to, jak se projekty na správné cestě tiše zboří. Řešení není říci ne na vše; je to udělat **každé přidání viditelným, výslovným kompromisem** v čase, místo tichého absorbování.

## Jak řídit rozsah

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## Klíčový tah

Nezamítejte nové požadavky přímo, to vás dělá překážkou. Místo toho zpřehledněte kompromis: "Můžeme to přidat. To znamená, že se deadline posunul o týden nebo vynecháme funkci X. Co chcete?" Nyní je to *obchodní* rozhodnutí, učiněné správnou osobou, se otevřenýma očima.

## Konkrétní příklad

V polovině projektu PM neustále přidává "malé" úpravy. Spustíte sdílený protokol změn rozsahu. Náhle všichni vidí, že původní dvoutýdenní projekt absorboval tři týdny přidaných funkcí a diskuse o termínu se stává zjevnou a snadnou.

## Proč na tom záleží

Neřízené rozšiřování rozsahu je tichým vrahem lhůt, žádná jednotlivá změna se nezdá velká, ale součet je selhání.

Učinění kompromisů výslovnými chrání tým, informuje zainteresované strany a strhává vinu z inženýrství, když byl rozsah, ne úsilí, příčinou.