Come gestisci lo scope creep in un progetto?

Question

Accepted Answer

**Scope creep**, l'accumulo costante di "solo una cosa in più", è come i progetti in linea scivolano silenziosamente. La soluzione non è dire no a tutto; è fare di **ogni aggiunta un trade-off visibile ed esplicito** rispetto al tempo, invece di un assorbimento silenzioso.

## Perché è importante

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

## La mossa chiave

Non rifiutare le nuove richieste in modo categorico, questo ti rende il blocco. Invece rendi visibile il trade-off: "Possiamo aggiungere quello. Significa o la scadenza si sposta di una settimana o eliminiamo la feature X. Cosa preferisci?" Ora è una decisione *di business*, presa dalla persona giusta, con gli occhi aperti.

## Un esempio concreto

A metà progetto, il PM continua ad aggiungere piccoli ritocchi. Inizi un registro condiviso delle modifiche di scope. All'improvviso tutti vedono che il progetto originale di due settimane ha assorbito tre settimane di aggiunte, e la conversazione sulla scadenza diventa ovvia e facile.

## Perché è importante

Lo scope creep non gestito è il killer silenzioso dei deadline; nessun singolo cambiamento sembra grande, ma insieme portano a un fallimento.

Rendere i trade-off espliciti mantiene il team protetto, gli stakeholder informati, e il biasimo lontano dall'ingegneria quando lo scope, non lo sforzo, era la causa.