Capire le nuove richieste prima di cambiare il perimetro
Chiarimento mancante, bisogno cambiato e offerta aggiuntiva richiedono confronti diversi.
Esamini perché nasce la richiesta
Un requisito successivo può essere una nuova priorità. Può anche rivelare un ruolo utente o passaggio rimasto poco chiaro all’inizio. GOV.UK raccomanda nella discovery di mettere in discussione ipotesi e comprendere gli utenti lungo tutto il percorso. Non impedisce ogni modifica futura, ma offre una base migliore al confronto.
L’etichetta «fuori perimetro» non spiega ancora la causa. Esamini obiettivo, descrizione precedente e nuova motivazione prima di valutare costi e tempi.
Esempio: richieste per un portale clienti
Le situazioni sono interamente inventate. L’obiettivo iniziale è consentire ai clienti di seguire le richieste di servizio. La tabella propone classificazioni e passi successivi, non decisioni su controversie contrattuali.
Osservazione | Lettura nell’esempio | Passo successivo |
|---|---|---|
Si chiede un accesso con account cliente; l’accesso dei clienti non è stato esaminato all’inizio. | Ruolo utente forse poco chiaro o ipotesi iniziale errata. | Chiarire ruolo e accesso necessari; confrontare con i documenti precedenti. |
Si chiede il francese dopo aver concordato esplicitamente un’interfaccia solo tedesca. | Bisogno cambiato rispetto al limite linguistico documentato. | Valutare utilità, perimetro di traduzione, manutenzione, impegno e priorità. |
Il fornitore propone un’area aggiuntiva di analisi. | Offerta facoltativa; il monitoraggio dello stato non ne ha bisogno nell’esempio. | Esaminare bisogno e utilità separatamente; non aggiungerla automaticamente all’incarico. |
Nel primo caso, la menzione tardiva non prova diritto a lavoro gratuito né un sovrapprezzo giustificato. La lacuna va chiarita insieme. Nel secondo, il precedente limite linguistico è esplicito. Nel terzo, il servizio è inizialmente un’opzione; una proposta non è un ordine.
Registri una decisione tracciabile
Confronti obiettivo iniziale, risultati concordati, ipotesi e nuovi riscontri. Verifichi con le persone interessate se la richiesta sia necessaria a completare il compito. Distingua correzione necessaria, ampliamento rinviabile e aggiunta dispensabile quando i fatti lo consentono.
Registri gli effetti su impegno, costo, tempi, test e manutenzione futura. Concordi come trattare la richiesta e aggiorni i documenti coinvolti prima dell’implementazione. Analizzare la causa non sostituisce l’accordo; rende visibile la decisione effettiva.
Fonti
Scritto da
- Katharina WeberRedattrice per software e tecnologiaKatharina Weber cura per ASES gli articoli sullo sviluppo software. Scrive delle questioni che le aziende affrontano nella scelta del software, nello sviluppo di nuove applicazioni e nella modernizzazione dei sistemi esistenti.
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile