Un prototipo può mostrare una schermata convincente e un percorso che funziona. È utile per discutere l’idea. Prima di affidargli un’attività reale, però, serve verificare come si comporta con dati incompleti, utenti diversi e passaggi interrotti.
Il pilota è una prova delimitata: riguarda un’attività, un gruppo di persone e criteri concordati. Serve a decidere cosa estendere e cosa correggere.
Definisci il confine della prova
Scrivi quali operazioni entrano nel pilota e quali restano gestite come prima. Per esempio, il sistema può preparare una richiesta senza inviarla, oppure proporre un aggiornamento che il referente deve confermare.
Questa distinzione rende leggibile il risultato: se cambia tutto insieme, diventa difficile capire quale intervento abbia aiutato e quale abbia creato lavoro aggiuntivo.
Prepara casi diversi, comprese le eccezioni
Non provare soltanto l’esempio migliore. Inserisci un’informazione mancante, una richiesta duplicata, un allegato poco leggibile e una correzione arrivata dopo l’avvio. Sono esempi di prova, da adattare all’attività.
Per ciascuno stabilisci l’esito atteso. Può essere una risposta corretta, una domanda di chiarimento o un passaggio a una persona. Fermarsi in modo comprensibile può essere il comportamento giusto.
Controlla accessi e possibilità di recupero
Verifica con profili diversi che ogni persona veda e modifichi soltanto ciò che le compete. Controlla anche come si riconosce un’attività incompleta e come si riprende senza duplicare l’operazione.
Prima di usare dati reali, chiarisci chi può autorizzare l’accesso e quali copie di ripristino servono. Il gruppo che prova il software deve sapere come segnalare un problema e come continuare il lavoro se il sistema non è disponibile.
Osserva l’intero compito
Misura il tempo fino a un risultato utilizzabile, includendo verifiche e correzioni. Una preparazione più rapida che richiede molte revisioni potrebbe non migliorare il lavoro complessivo.
Raccogli anche ciò che una misura non spiega: passaggi poco chiari, informazioni difficili da trovare, azioni che le persone evitano. Trasforma questi rilievi in correzioni riconoscibili.
Chiudi con una decisione
Alla fine della prova scegli se estendere, correggere e riprovare oppure fermare quel percorso. Registra perché, con i casi osservati e i limiti rimasti. Una decisione documentata è un risultato utile anche quando la prima idea cambia.
Una matrice di prova da portare al gruppo
Il rischio di una dimostrazione preparata è vedere sempre il percorso migliore. Crea invece una piccola raccolta di casi con risultato atteso. Le indicazioni OpenAI sulle valutazioni raccomandano di includere situazioni ordinarie, casi limite e tentativi di comportamento indesiderato. Qui traduciamo il principio in una prova operativa.
| Caso illustrativo | Esito da cercare | Segnale da correggere |
|---|---|---|
| Richiesta completa | Preparazione corretta e verificabile | Informazioni aggiunte senza fonte |
| Cliente ambiguo | Domanda di chiarimento | Scelta arbitraria di una scheda |
| Documento mancante | Stato incompleto comprensibile | Risultato presentato come completo |
| Invio ripetuto | Riconoscimento dell’operazione già trattata | Duplicazione del lavoro |
| Accesso non previsto | Arresto o passaggio al referente | Lettura di materiale fuori perimetro |
Come registrare una segnalazione utile
«Non funziona» esprime un problema reale, ma non permette ancora di riprodurlo. Raccogli il compito, il risultato atteso, ciò che è successo e il passaggio in cui è cambiato il comportamento. Usa dati di prova o riferimenti autorizzati invece di copiare archivi riservati nella segnalazione.
Distingui un errore dal desiderio di una nuova funzione. Entrambi possono meritare un intervento, ma hanno conseguenze diverse sul perimetro e sull’ordine del lavoro. Una raccolta unica con stato, referente e verifica evita che la stessa osservazione rientri a ogni incontro senza esito.
La decisione di uscita dal pilota
Prepara prima della prova le condizioni per estendere l’uso: compiti coperti, eccezioni riconosciute, persone formate e modalità di assistenza. Le soglie dipendono dal progetto e non vanno inventate dopo aver visto i risultati.
Se il percorso principale funziona ma resta fragile il recupero da un errore, può essere sensato prolungare la prova su quel punto. Se manca una fonte necessaria, la correzione può riguardare l’organizzazione dei dati. La decisione finale deve dire cosa si estende, a chi e con quali condizioni ancora aperte.