L’analisi iniziale di un progetto software costa giorni di lavoro, compare come voce in preventivo e non produce nulla che si possa vedere. Non c’è una demo, non c’è una schermata. Si fanno domande e si scrivono documenti. Per chi paga, è ragionevole chiedersi se serva davvero, e la risposta non è sempre la stessa.
Dove finisce il costo di un requisito mancante
Un esempio ipotetico. Un’azienda chiede un gestionale su misura per gli ordini e si parte subito, senza un’analisi vera. Il lavoro si concentra su ciò che è stato detto: inserire ordini in modo più rapido.
Dopo qualche settimana emerge che il problema non era soltanto inserire gli ordini più rapidamente, ma sapere a che punto si trova ciascuno. Una domanda apparentemente semplice, che ne porta con sé altre: chi aggiorna lo stato e quando? Che cosa succede a un ordine bloccato o evaso solo in parte? Chi deve poter vedere queste informazioni? Il sistema funziona come era stato specificato, ma non raggiunge l’obiettivo per cui era stato chiesto.
Si rifà una parte del lavoro. Nel contratto e nel registro del progetto, però, quel costo ha un’etichetta diversa: “variazione di requisito”, “funzione aggiuntiva”, “incomprensione”.
Nessuno scrive “questo costo dipende dall’analisi che non abbiamo fatto”. La spesa esiste, ma non viene collegata all’origine, e il confronto con il costo dell’analisi non avviene mai.
Non è una situazione solo teorica. In un articolo pubblicato su questo blog, Raffaele Bologna, sviluppatore, ricorda come momento più critico un progetto già avanzato in cui il cliente ha cambiato in modo sostanziale i requisiti, con la scadenza invariata. Una parte dell’applicazione andava riscritta, e scrivere più in fretta non riduce il lavoro necessario per valutare cosa cambia nell’architettura, quali funzioni esistenti sono toccate e quali test vanno rivisti.
Che cosa porta alla luce l’analisi
Quando la richiesta è “un sistema su misura”, il sistema è la risposta, non il problema. Spesso la personalizzazione è il mezzo con cui il cliente spera di lavorare più in fretta, spendere meno o controllare meglio un processo, e sono obiettivi che non sempre esplicita, anche perché per lui possono sembrare impliciti.
L’analisi li rende visibili, e può emergere che non stanno insieme: volere una soluzione su misura e voler ridurre i costi non è una contraddizione in assoluto, ma lo diventa quando non si è chiarito quale dei due prevalga. Questa decisione spetta al cliente. Chi sviluppa può spiegare le alternative, stimarne i costi e mostrarne le conseguenze, ma non può stabilire al suo posto quale compromesso sia accettabile.
Lo stesso sviluppatore racconta che, da quando lavora con l’AI, dedica più attenzione alla definizione dei requisiti, perché una richiesta vaga produce un risultato vago. La regola vale anche tra persone, solo che con l’AI si vede più in fretta.
A volte l’esito dell’analisi è che serve meno software di quello richiesto: modificare un processo prima di automatizzarlo, oppure partire da una soluzione già disponibile. È un risultato che in un preventivo non compare.
Quali decisioni si possono rimandare
Non tutti i requisiti devono essere definiti prima di iniziare. Alcune cose si capiscono lavorando, e per un prototipo o un progetto circoscritto può essere sensato partire con poco. La differenza sta nel distinguere le decisioni che si possono correggere facilmente da quelle su cui poggia il resto del sistema.
Nell’esempio degli ordini, modificare l’aspetto di una schermata è generalmente semplice. Cambiare gli stati che un ordine può attraversare e le regole che ne governano gli aggiornamenti, invece, può costare molto di più una volta che altre parti del sistema dipendono da quelle scelte.
Il rischio non è partire con informazioni incomplete, ma farlo senza sapere quali decisioni si stanno rimandando.
