Perché spendiamo i primi giorni a mettere in dubbio il tuo progetto

La prima settimana di lavoro insieme, di solito, delude un po’. Ti aspetti entusiasmo e ti ritrovi qualcuno che ti chiede perché quella funzione ti serve, chi la userà davvero e cosa succede se non la facciamo. Non è scetticismo per posa: è il lavoro. L’analisi di fattibilità di un progetto software serve esattamente a questo, a mettere in dubbio l’idea finché non resta solo la parte che regge. È la fase che costa qualche giorno e che, quando funziona, ne fa risparmiare mesi.

Non è una cosa che facciamo per rallentare. È che l’alternativa la conosciamo bene: si parte subito, si scrive codice per quattro mesi, e la domanda scomoda arriva alla fine, quando costa dieci volte tanto.

Cosa succede davvero nei primi giorni

Nei primi incontri non parliamo di tecnologie. Non serve sapere se sarà un’app, un gestionale o una web app: sono risposte, e le risposte vengono dopo. Quello che ci interessa è capire il problema con abbastanza precisione da poterlo riconoscere quando lo vediamo risolto.

In pratica ascoltiamo come lavora l’azienda oggi — anche nelle giornate in cui va storto tutto — e scriviamo tre cose: qual è il problema, chi lo subisce, quanto costa lasciarlo com’è. Poi, solo poi, si guarda cosa si può costruire.

Se un progetto non sopravvive a una settimana di domande, non sarebbe sopravvissuto a sei mesi di sviluppo. Meglio scoprirlo adesso.

Le quattro domande che facciamo prima di qualsiasi preventivo

Sono sempre le stesse quattro, e sembrano banali finché non provi a rispondere.

Chi userà questa cosa, con nome e cognome? Non «l’ufficio acquisti»: la persona. Se non riusciamo a identificarla, il software verrà usato male o non verrà usato. Capita più spesso di quanto sembri che la funzione più richiesta sia per un ruolo che nessuno ha ancora assunto.

Cosa succede se non la facciamo? È la domanda che divide le funzioni vere da quelle decorative. Se la risposta è «continuiamo come adesso» e nessuno si scompone, quella funzione può aspettare. Se la risposta è «si blocca la produzione», siamo nel cuore del progetto.

Come si fa oggi questa cosa? Ogni processo esiste già, anche quando esiste sotto forma di un file Excel che si passano in tre e di una telefonata alle sette di sera. Guardare il metodo attuale dice più di qualsiasi elenco di requisiti, perché mostra i passaggi che le persone hanno inventato per farlo funzionare.

Come faremo a sapere che ha funzionato? Serve un segnale osservabile, deciso prima: le ore di riconciliazione dei dati che scendono, gli ordini sbagliati che spariscono, la pratica che si chiude in giornata. Senza un criterio scritto all’inizio, alla fine si discute a sensazione — e a sensazione vince chi parla più forte.

La ricerca dell’MVP: la versione più piccola che risolve il problema

Quando le quattro risposte ci sono, il lavoro cambia direzione: da «cosa potremmo fare» a «qual è la cosa più piccola che risolve davvero il problema». È quello che in gergo si chiama MVP, versione minima utilizzabile, e la parola minima è la parte che disturba di più. Non è una versione al risparmio, e non è un prototipo da buttare: è il progetto ridotto all’osso che deve funzionare in produzione, con persone vere che ci lavorano dentro.

Il criterio che usiamo è semplice: se togliendo una funzione il problema resta risolto, quella funzione esce dalla prima versione. Non muore — finisce in una lista, con la data in cui la riguarderemo. Quasi sempre, quando arriva quel giorno, metà della lista non interessa più a nessuno: il software vero, nel frattempo, ha mostrato dove serviva davvero intervenire.

Questo è anche il momento in cui capita di scoprire che la tecnologia immaginata all’inizio non è quella giusta — succede spesso con le app, tanto che ci abbiamo scritto un articolo su quando un’app non serve e cosa serve al posto suo.

Le funzioni che togliamo (e che nessuno rimpiange)

Ci sono categorie di richieste che, nell’analisi di fattibilità software, saltano fuori quasi ogni volta.

La prima è la dashboard con tutto. Grafici, filtri, indicatori: bella da vedere in demo, guardata per due settimane e poi mai più, perché le decisioni vere si prendono su tre numeri che si possono mandare per mail il lunedì mattina.

La seconda è il caso limite che capita una volta l’anno. Gestirlo dentro al software può costare quanto un terzo del progetto. Gestirlo a mano costa venti minuti, una volta l’anno. Si scrive nella procedura e si va avanti.

La terza è la configurabilità totale: rendere tutto parametrico «così poi lo cambiamo da soli». Nella pratica nessuno lo cambia mai, e intanto il software è diventato più complicato da usare per tutti.

La quarta è l’integrazione con il sistema che state per cambiare. Se il gestionale verrà sostituito fra un anno, collegarlo adesso significa pagare due volte lo stesso lavoro.

Tre progetti che sono andati meglio dopo essere stati rimpiccioliti

Gli esempi che seguono sono situazioni ricorrenti, raccontate senza nomi perché il punto non è il caso singolo ma lo schema, che si ripete quasi identico.

Il portale clienti diventato una pagina sola. La richiesta iniziale era un’area riservata completa: profilo, storico, documenti, messaggistica, notifiche. Alle quattro domande è emerso che i clienti chiamavano per una cosa sola, sapere a che punto era il loro ordine. La prima versione è stata una pagina con lo stato dell’ordine e la data prevista. Le telefonate sono calate subito; il resto del portale, tre anni dopo, non è mai stato chiesto.

Il gestionale su misura che è rimasto un modulo. Un’azienda voleva rifare tutto da zero perché il software esistente «non andava bene». Guardando il lavoro reale, il problema stava in un punto solo: la preparazione delle offerte, fatta a mano ricopiando dati. Abbiamo costruito quel pezzo e lo abbiamo collegato al gestionale esistente, che per tutto il resto funzionava. Costo e rischio di un decimo rispetto alla sostituzione totale.

L’app che è diventata un sito da telefono. Serviva ai tecnici in cantiere per registrare gli interventi. Un’app significava due sviluppi, gli store, gli aggiornamenti e — il vero ostacolo — convincere le persone a installarla. È diventata una web app che si apre dal browser del telefono, con un collegamento sulla schermata iniziale. Nessuno si è accorto della differenza, e i mesi di sviluppo risparmiati sono finiti nella parte che contava: la sincronizzazione quando il cantiere è senza campo.

Cosa ci guadagni: rischio più basso, budget protetto

Il vantaggio non è filosofico, è aritmetico. Un progetto piccolo si consegna prima, e un progetto consegnato prima comincia prima a restituire qualcosa. Ma soprattutto: le cose che non hai costruito non le devi mantenere, correggere, aggiornare, spiegare a chi arriva nuovo.

Poi c’è la parte del budget. Quando la prima versione è piccola, la quota di soldi esposta all’errore è piccola. Se qualcosa non va come previsto — e ogni tanto succede — te ne accorgi dopo otto settimane e non dopo otto mesi, con la maggior parte del budget ancora disponibile per correggere la rotta. È l’esatto contrario di quello che accade quando un progetto parte senza un obiettivo fermo e si gonfia a ogni riunione.

Il modo più affidabile per non sforare un budget non è stimare meglio. È avere meno cose da stimare.

C’è anche un effetto meno ovvio: le priorità cambiano da sole. Dopo tre mesi di software in uso, la lista delle funzioni «indispensabili» scritta all’inizio è quasi sempre diversa da quella che scriveresti oggi. Averla congelata in un contratto di sei mesi ti avrebbe fatto costruire la lista sbagliata.

Quando l’analisi dice di non farlo

Va detto anche questo, altrimenti il discorso è comodo solo per noi. Ogni tanto la fase di validazione porta a una conclusione scomoda: il progetto non va fatto. Perché il problema si risolve con una procedura invece che con del codice, perché il risparmio non ripaga l’investimento, o perché l’azienda sta per cambiare qualcosa a monte e conviene aspettare sei mesi.

È il risultato più difficile da comunicare, e paradossalmente il più utile: un lavoro non fatto è denaro che resta in cassa. In altri casi la conclusione è «sì, ma non adesso e non tutto»: si parte dal pezzo che fa più male, si guarda come va, si decide il resto con dati veri invece che con previsioni.

Se stai valutando un progetto e vuoi capire da dove si comincia, la fase di analisi e validazione è il momento in cui farsi queste domande costa poco. Dopo, per farle, si paga in mesi. Puoi anche partire dal quadro completo di quello che facciamo, ma il consiglio resta lo stesso: prima il dubbio, poi il codice.