Kako upravljate opsegom i izbjegavate proširenje opsega?

Question

Accepted Answer

**Opseg** je dogovoreni skup rada koji će projekt isporučiti. **Proširenje opsega** je postupno, nekontrolirano proširenje tog opsega — neprekidni tok "malih dodataka" koji tiho raznose vremensku liniju. Upravljanje opsegom znači kontroliranje *promjene*, ne odbijanje je.

## Zašto je to važno

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

Pisana, dogovorena granica je ono što vam kasnije omogućava da kažete "to je promjena" s dokazom.

## Rukovati promjenama namjerno

Promjene nisu loše — nekontrolirane su. Kada stignu novi zahtjev, prođite ga kroz jednostavnu vrata:

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

Klučan potez: nikada ne apsorbirajte tiho dodatni rad. Ucinite svaki dodatak svjesnom kompromisu koji je vlasnik dionika.

## Konkretan primjer

U sredini projekta, dionik pita "također podržavate masivno učitavanje — trebalo bi biti brzo." Umjesto da ga stisnete, odgovorite: "Možemo, ali dodaje oko tjedan dana. Pomičemo li datum ili gurnemo li analitiku na sljedeće izdanje?" Sada je to njihov poziv, s troškima na stolu.

## Česta zamka

Reći da na svakom zahtjevu budete korisni, a zatim propustiti rok. Čini se da je tim propao, kada je zapravo tiho preuzeo dodatni rad.

## Zašto je to važno

Proširenje opsega je najčešći razlog što projekti krenu krivo — ne zato što je svaka promjena velika, već zato što se deseci skupljaju nevidljivo.

Upravljanje opsegom čuva projekt pošteno: promjena je u redu, ali njezin trošak je uvijek eksplicitan i posjeduje ga onaj koji je traži.