Come evitare lo scope creep in un progetto software
Lo scope creep è la crescita lenta di un progetto dopo l'avvio. Come lo tengono sotto controllo ambito scritto, richieste di modifica e approvazione.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Lo scope creep è ciò che accade quando un progetto software, a lavoro iniziato, cresce oltre quanto descriveva il preventivo, mentre calendario e budget non vengono aggiornati di conseguenza. Non nasce da una grande decisione, ma da piccole aggiunte accumulate: una schermata in più, un report in più, un'opzione extra in questo campo. Il modo di prevenirlo non è vietare le aggiunte, ma stabilire una routine di modifica che renda visibile per iscritto l'effetto di ciascuna su tempi e costi.
Lo scope creep nasce di rado dalla malafede. Il cliente capisce meglio ciò che vuole man mano che vede il prodotto prendere forma, e il team, in buona fede, esegue una piccola richiesta senza segnalarla. Il guaio è che nessuna di queste aggiunte viene annotata da qualche parte. Tre mesi dopo ciascuna parte ha capito un progetto diverso, e la discussione verte su chi ricorda che cosa.
Perché si verifica lo scope creep?
La causa più comune è un ambito scritto in modo vago all'inizio. Il preventivo dice sito web aziendale, ma non è chiaro quante pagine, quali lingue o quali moduli si intendano. Una frase vaga permette a ciascuna parte di interpretarla a proprio favore.
La seconda causa è che le nuove idee nascono nel momento in cui il prodotto si vede per la prima volta in forma concreta. È naturale: appena il cliente vede il design o la prima demo, le lacune diventano evidenti. La terza causa è un decisore poco chiaro. Se più persone trasmettono le richieste ciascuna per conto proprio, ognuna allarga un po' l'ambito.
Come va scritto l'ambito per ridurre lo scope creep?
Un buon documento di ambito dice non solo che cosa verrà fatto, ma anche che cosa non verrà fatto. Mettere per iscritto i lavori esclusi chiude fin dall'inizio la maggior parte delle dispute successive. Servono anche formulazioni misurabili: non 'pagina prodotto', ma 'modello di pagina prodotto, al massimo dieci campi prodotto e una sola lingua'.
Il documento di ambito non va scritto una volta e dimenticato. Deve essere l'unico foglio a cui entrambe le parti fanno riferimento durante tutto il progetto. Quando cliente e team guardano la stessa pagina, la frase 'Pensavo che fosse inclusa' diventa molto più rara.
- Scriva ogni deliverable per nome e per numero.
- Indichi i lavori fuori ambito sotto un titolo a parte.
- Scriva i criteri di accettazione: che cosa deve vedersi perché il lavoro sia considerato finito?
- Nomini l'unica persona, lato cliente, che decide sull'ambito.
- Elenchi i presupposti: chi fornisce i contenuti, ed entro quando?
Come si imposta una routine per le richieste di modifica?
Una richiesta di modifica è un semplice documento che fa percorrere a ogni nuova richiesta la stessa strada. La richiesta viene annotata, il team valuta il suo effetto su tempi e costi e, se il cliente la approva, entra nell'ambito, altrimenti viene lasciata a una fase successiva. L'importante è che il processo non sia pesante. Bastano un modulo di una pagina o un breve scambio di e-mail.
Questa routine è il modo gentile di dire di no. Il team non rifiuta la richiesta. Ne mostra semplicemente il prezzo. Quando il cliente vede che ogni richiesta ha una controparte, comincia a stabilire le priorità senza che glielo si chieda.
Ogni modifica è un male, e quando serve flessibilità?
La gestione delle modifiche esiste per tenere il cambiamento sotto controllo, non per impedirlo. Se durante il progetto cambiano il mercato, le normative o il comportamento degli utenti, modificare l'ambito è la decisione giusta. Un ambito rigido può significare consegnare, puntualissimi, un prodotto che non serve più all'azienda.
La flessibilità funziona dentro una cornice scritta. In alcuni progetti l'ordine delle priorità può essere cambiato a budget e tempi fissi: se entra una nuova funzionalità, ne esce una di pari dimensione. Questo approccio mantiene costante il valore anziché l'ambito.
Quali errori sono comuni nella gestione dell'ambito?
L'errore più frequente è accettare a voce le piccole richieste. Ognuna sembra banale, ma insieme si sommano in settimane. Il secondo è che nemmeno il team tiene una traccia. Un team che non sa quale schermata è cambiata in quale data e perché non ha dati in mano quando sorge un disaccordo.
Il terzo errore è rinviare la conversazione sull'ambito alla fine del progetto. Se la differenza emerge solo alla consegna, entrambe le parti si sentono nel giusto e il rapporto ne soffre. L'ambito va messo all'ordine del giorno di ogni riunione come punto breve.
- Lavorare su approvazioni verbali: ogni richiesta aggiuntiva dovrebbe essere messa per iscritto.
- Non rivedere l'ambito con regolarità: basta un controllo breve ogni due settimane.
- Ignorare i ritardi su contenuti e riscontri: anche il ritardo allunga il calendario.
- Consegnare senza criteri di accettazione: il significato di finito resta vago.
Cosa fare quando lo scope creep è già iniziato?
Quando ci si accorge della deriva, il primo passo è mettere ciò che è stato fatto accanto all'ambito originale. Elenchi che cosa è stato aggiunto e che cosa è stato spostato. L'elenco non serve a incolpare qualcuno. Serve a vedere il terreno comune.
Poi si sceglie una di due strade: le aggiunte vengono formalmente portate nell'ambito e tempi e costi vengono aggiornati, oppure le aggiunte vengono spostate a una seconda fase. Non esiste una terza strada. Gli extra inghiottiti in silenzio danneggiano la fiducia nel progetto successivo.
Lo scope creep non è un problema di carattere. È un problema di registrazione. Un ambito scritto, un elenco di ciò che è fuori ambito, un solo decisore e una semplice routine di richieste di modifica proteggono la maggior parte dei progetti da questa discussione. Se desidera chiarire insieme l'ambito del Suo progetto prima dell'inizio dei lavori, può fissare un colloquio di scoperta con rabbitclip.
Domande frequenti
Che cos'è lo scope creep?
È quando un progetto, a lavoro iniziato, cresce oltre quanto descriveva il preventivo e tempi e costi non vengono aggiornati di conseguenza. Di solito si costruisce con piccole aggiunte che non sono mai state annotate.
Una richiesta di modifica comporta sempre un costo aggiuntivo?
Non sempre. Alcune modifiche non incidono su tempi o costi, e altre vengono compensate togliendo un'altra parte del lavoro. L'importante è che l'effetto venga reso visibile per iscritto.
L'ambito va scritto nel contratto o nel preventivo?
Va scritto nel documento che entrambe le parti firmano o approvano, che nella maggior parte dei progetti è il preventivo con il suo allegato di ambito. Per i dettagli legali è opportuno consultare un avvocato.
Nel lavoro agile non esiste lo scope creep?
Esiste. Il lavoro agile è aperto al cambiamento, ma non senza limiti. Senza un elenco di priorità, un ambito di sprint fisso e una cornice di tempo e budget, anche il lavoro agile può andare alla deriva.
Chi dovrebbe gestire l'ambito?
Ciascuna parte dovrebbe avere una persona responsabile. Un unico decisore lato cliente e un responsabile di progetto lato team che tenga l'ambito a verbale rendono il lavoro molto più semplice.
