1. Partire dal processo, non dallo strumento
Scelgo un’attività che conosco bene e che ripeto. Gli input devono essere abbastanza stabili, le regole spiegabili e il risultato controllabile. Non parto dal processo più complesso: parto da quello che posso confrontare con un working paper o un output storico già affidabile.
- Ricorre con frequenza mensile, trimestrale o annuale.
- I dati hanno una struttura riconoscibile o possono essere normalizzati.
- Le regole ordinarie e le principali eccezioni possono essere scritte.
- Esistono quadrature o risultati storici con cui verificare l’output.
2. Assegnare un ruolo a ogni ambiente
Non serve conoscere tutti i modelli. Serve separare progettazione, sviluppo, memoria e controllo. Un ambiente può aiutare a strutturare il processo e il brief; un altro può scrivere il codice; una base documentale conserva fonti, mapping, decisioni e test; una chat nuova esegue l’audit.
3. Insegnare il processo prima di chiedere il codice
La prima richiesta non dovrebbe essere “scrivi il programma”. Prima descrivo l’obiettivo, carico input reali, spiego colonne, segni e righe da ignorare, scrivo regole ed eccezioni e definisco output e controlli. Poi chiedo al modello di restituire un brief completo e di indicare ciò che non è chiaro.
- Se manca un dato essenziale, il tool deve fermarsi e segnalarlo.
- Le decisioni professionali non devono restare implicite nel prompt.
- Il brief viene approvato prima di iniziare lo sviluppo.
4. Definire i test prima del prototipo
Un applicativo non è corretto perché produce un numero. Prima dello sviluppo preparo casi e risultati attesi. Dopo lo sviluppo provo deliberatamente a farlo fallire. I criteri PASS o FAIL vengono definiti prima, così non vengono adattati al risultato ottenuto.
- Caso ordinario con risultato verificato a mano.
- Caso limite con segni invertiti, conti nuovi o saldi zero.
- Input errato: colonne mancanti, formato sbagliato o dati incoerenti.
- Confronto con il risultato atteso predisposto prima del prototipo.
5. Sviluppare per versioni piccole
La prima versione deve fare poche cose e renderle verificabili. Una funzione alla volta, dati reali e changelog. La complessità viene aggiunta soltanto quando la versione precedente è stabile e i test di regressione continuano a passare.
6. Separare chi produce da chi controlla
La stessa chat che ha costruito il tool non dovrebbe certificarlo. Apro una nuova conversazione, fornisco codice, brief e matrice di test, ma non la storia dello sviluppo. Chiedo di cercare errori, assunzioni non supportate e casi non gestiti, restituendo per ogni controllo PASS o FAIL, motivazione, evidenza e correzione.
7. Rilasciare con limiti, manuale e memoria
Il rilascio non coincide con la fine del codice. Servono un manuale d’uso, un changelog, la descrizione degli input accettati, i controlli eseguiti, le assunzioni aperte e i limiti del tool. Il professionista deve poter capire non solo come usarlo, ma anche quando non usarlo.