Questa è l’obiezione che impedisce a più persone di iniziare, ed è fondata su un’ipotesi errata: che la descrizione venga tradotta direttamente in codice, senza possibilità di tornare indietro. Non è questa la sequenza prevista. La vostra descrizione genera innanzitutto un PIANO, l’elenco dei dati, degli schermi e del loro tipo, che vi viene mostrato e che potete correggere PRIMA che venga scritta una sola riga di codice: rinominare un’entità, modificare il nome di un campo, aggiungere o rimuovere un valore di stato, persino cambiare il tipo di uno schermo. A questo stadio, sbagliare non costa nulla. Dopo la generazione, è comunque possibile apportare modifiche descrivendole in italiano, ma queste comportano la ricostruzione completa dell’applicazione e una nuova validazione automatica: è un’operazione più impegnativa, non un semplice aggiustamento.
L’errore che si teme non è quello che accade
Si teme di fornire una descrizione poco precisa e ricevere uno strumento fuori tema, senza possibilità di correzione. Nei progetti tradizionali questa paura è giustificata: il cahier des charges viene affidato a un fornitore, il primo schermo arriva settimane dopo e lo scostamento si paga in giorni di sviluppo. È proprio questo ritardo, non la difficoltà di scrivere, a rendere l’esercizio angosciante.
Anche la letteratura sull’espressione del bisogno dice la stessa cosa da un’altra prospettiva: la difficoltà non sta nel mettere nero su bianco, ma nel sapere cosa si vuole prima di aver visto qualcosa. Non si intuiscono le proprie abitudini operative; le si riconosce solo quando sono visualizzate chiaramente.
Il piano viene mostrato prima del codice ed è modificabile
Tra la vostra descrizione e l’applicazione c’è un passaggio intermedio: un piano. Esso elenca i dati che lo strumento gestirà, i relativi campi e gli schermi, con il loro tipo specifico: una tabella, un calendario, una dashboard o una mappa. Questo piano viene visualizzato ed è pienamente modificabile.
Concretamente, in questa fase potete rinominare un dato e la sua etichetta, correggere i campi che lo caratterizzano, aggiungere o rimuovere un valore da una lista di stati («In attesa», «Approvato», «Annullato»), rinominare uno schermo, cambiarne l’icona, e persino cambiarne la natura: una lista che avrebbe dovuto essere un calendario si corregge qui, in un’unica operazione.
È proprio questo passaggio a rendere l’obiezione infondata. Una descrizione approssimativa non vincola a nulla: produce una proposta che voi leggete e approvate, e correggere una parola nel piano equivale esattamente a averla scritta correttamente fin dall’inizio.
Dopo la generazione: possibile, ma non è più lo stesso tipo di modifica
Una volta generata l’applicazione, ogni modifica continua a essere richiesta in italiano, «aggiungi un campo per la data di follow-up», «separa preventivi e fatture». La differenza sta altrove: questa richiesta rigenera il piano, ricostruisce l’applicazione e la sottopone nuovamente alla validazione automatica prima di riportarla in servizio. È affidabile, ma non istantanea.
Da qui deriva l’unico consiglio pratico di questa pagina: rileggere il piano merita cinque minuti di attenzione reale. Sono i cinque minuti meno costosi dell’intero progetto.
Cosa è meglio sapere prima di modificare un’applicazione già in produzione
Due aspetti non sono intuitivi e conviene chiarirli prima di lanciare una modifica su uno strumento che contiene già i vostri dati reali.
Il primo: cosa succede ai dati già inseriti quando cambia la struttura (un campo rimosso, un dato suddiviso in due). Non lo affermo qui, è una domanda da porre esplicitamente prima di modificare un’applicazione in produzione, sia qui che presso qualsiasi altro fornitore.
Il secondo: non esiste un pulsante «torna alla versione precedente». Il rollback va pianificato, non improvvisato, ecco perché è utile esportare i propri dati prima di una modifica strutturale, operazione supportata dalla schermata Impostazioni in formato CSV e JSON.