Molti progetti software partono troppo presto. Non perche' manchi il codice, ma perche' manca chiarezza. Quando il team inizia a sviluppare senza aver messo ordine tra processi, ruoli, dati e vincoli, il rischio non e' solo tecnico. E' strategico: si costruisce qualcosa che sembra coerente in backlog ma non regge il lavoro reale.
La discovery tecnica serve a rendere il progetto leggibile. Non e' documentazione burocratica. E' il punto in cui si capisce che problema stiamo davvero risolvendo e quale parte del sistema va progettata prima.
Cosa deve emergere da una discovery fatta bene
- I processi critici che generano valore o attrito.
- I ruoli coinvolti e le differenze reali tra le loro operativita'.
- I dati necessari, da dove arrivano e dove devono finire.
- Le integrazioni obbligatorie e quelle che possono aspettare.
- I vincoli: compliance, permessi, audit, migrazione, SLA.
- Il perimetro della prima release e cio' che va volutamente escluso.
Perche' riduce davvero il rischio
Il beneficio piu' forte della discovery non e' produrre un file in piu'. E' allineare le decisioni. Senza discovery, ogni funzione sembra urgente. Con una discovery ben fatta, le priorita' diventano piu' evidenti e le complessita' inutili emergono prima.
Questo riduce i classici problemi di delivery: rework, scope che si allarga male, stime fragili, integrazioni scoperte tardi e interfacce che non riflettono il linguaggio del business.
“Sviluppare senza discovery non e' partire piu' veloci. E' partire con meno visibilita' su dove andrai a sbattere.”
Davide Gentile