NOTE / METODO E PROGETTI
Software su misura: dal problema al prototipo
Un progetto digitale può iniziare con una frase semplice: vorrei ritrovare un documento, seguire un ordine o rendere più chiaro un passaggio. Prima di scegliere una tecnologia, quella frase deve diventare osservabile. Il metodo Hands Studio procede dall’esigenza al percorso, dal prototipo allo sviluppo e alle verifiche. Questa nota spiega che cosa serve in ciascun passaggio e perché una schermata convincente non basta, da sola, a dichiarare pronto un prodotto.
Descrivere il momento del problema
Chiediamo che cosa sta succedendo quando nasce la difficoltà. Chi sta lavorando, quale informazione cerca e quale decisione deve prendere? Un esempio concreto è più utile di una lista di funzioni scollegata dal contesto. Nel caso di un ordine, il problema può riguardare l’inserimento, il controllo o il passaggio verso la produzione. Sono momenti diversi, con persone e conseguenze diverse. Individuarli permette di capire quale primo percorso osservare e quali domande restano aperte prima di progettare una soluzione.
Separare obiettivo e funzione
“Avere una dashboard” descrive una possibile interfaccia, non il bisogno. L’obiettivo potrebbe essere capire quali ordini richiedono attenzione. In quel caso servono regole per riconoscere gli ordini e informazioni sufficienti a scegliere un’azione. Potrebbe essere utile una dashboard, oppure una vista molto più semplice. Tenere distinto il risultato dalla funzione evita di trasformare ogni idea iniziale in un vincolo. Il primo perimetro dovrebbe contenere ciò che serve a provare il percorso, non tutte le possibilità immaginabili.
Rendere esplicite le informazioni
Un’interfaccia organizza dati, quindi occorre sapere quali siano disponibili e quali manchino. Definiamo il significato dei campi e come riconoscere un record. Due informazioni con lo stesso nome possono avere usi diversi in reparti diversi. Gli esempi aiutano a scoprire queste differenze prima che diventino regole nel software. Per la discussione iniziale si possono usare dati dimostrativi: devono conservare la struttura del problema senza essere confusi con un archivio operativo o con il risultato di una migrazione già eseguita.
Disegnare anche gli stati scomodi
Il percorso non finisce quando tutto va bene. Una ricerca può non trovare risultati, un campo può essere incompleto e un servizio esterno può non rispondere. Nel prototipo occorre rendere comprensibili anche questi stati. La persona deve capire se un’azione è stata completata, se deve correggere qualcosa o se può riprovare. Questo non richiede aggiungere messaggi ovunque. Richiede scegliere le informazioni necessarie nel momento giusto e mantenere coerenti il testo del pulsante, il comportamento e l’esito mostrato.
Usare il prototipo per fare domande
Una prova visiva permette di discutere ordine, gerarchia e termini. Si può osservare se il percorso sembra comprensibile e se manca un’informazione. Va però dichiarato ciò che è simulato. Un pulsante disegnato non dimostra un invio riuscito, e un elenco di esempio non prova la connessione con un database. Distinguere questi livelli rende il confronto più utile: ogni osservazione può tradursi in una scelta o in una verifica successiva, invece di creare aspettative su funzioni che non esistono ancora.
Scegliere la tecnologia sul caso
I progetti Hands Studio mostrano scelte diverse: PHP e MySQL nel gestionale VOLPE1943, Node.js e SQLite in MyNABI, strumenti Apple nei giochi. Il catalogo serve a spiegare il rapporto fra esigenza e implementazione, non a proporre una tecnologia per tutto. Le dipendenze e i servizi esterni introducono anche vincoli di manutenzione, accesso e configurazione. Queste condizioni devono essere comprese prima di considerare una scelta definitiva. La disponibilità di uno strumento non è, da sola, una ragione per aggiungerlo al progetto.
Scrivere prove che corrispondano al lavoro
Per una funzione definiamo un ingresso, un’azione e un risultato atteso. La verifica può riguardare dati salvati, un documento generato o un passaggio da tastiera. Alcuni controlli sono automatici, altri richiedono una prova nel browser o sul dispositivo reale. Non sono equivalenti. Un test locale riuscito non dimostra che il dominio pubblico abbia la stessa configurazione. Il rapporto finale deve indicare quale ambiente è stato controllato e quali limiti restano, così chi decide può leggere il risultato senza ricostruire tutta la conversazione.
Preparare il passo successivo
Una prima versione utile ha confini comprensibili. Permette di distinguere il lavoro completato dalle ipotesi e dalle funzioni successive. Prima del rilascio devono essere chiari contenuti, accessi, responsabilità e verifiche ancora necessarie. Il prototipo è quindi un passaggio di apprendimento, non una scorciatoia per saltare la revisione. Se vuoi discutere un software, puoi partire da un’attività reale e da un esempio senza dati riservati. Nella pagina del metodo e nei servizi trovi i riferimenti per trasformare quell’esigenza in un primo perimetro.