Hai costruito un processo che funziona, l’hai automatizzato, ci hai messo controlli di qualità. C’è però un limite che nessuno dei capitoli precedenti risolve da solo: se il processo vive solo nella tua testa, o in un prompt salvato che solo tu conosci, hai costruito qualcosa di fragile. Il giorno che sei in ferie, o cambi ruolo, il metodo sparisce con te.

Il pattern dell’eroe solitario

C’è una figura che compare in quasi ogni team che comincia a usare l’AI seriamente: la persona che è diventata bravissima, ha costruito i suoi processi, ottiene risultati che gli altri notano e invidiano un po’. È un pattern gratificante sul momento e fragile sul lungo periodo, per due motivi. Il primo: quella persona diventa un collo di bottiglia, perché ogni richiesta simile passa comunque da lei. Il secondo, più subdolo: quello che ha imparato non si trasferisce da solo, e il team resta con la sensazione che «l’AI funziona per quella persona lì», invece che con una capacità propria.

Il modo per uscirne non è chiedere all’eroe solitario di lavorare di meno. È rendere esplicito e condivisibile quello che finora è rimasto implicito nella sua testa.

Scrivi il processo perché un altro lo possa rifare

Un prompt salvato che ha senso solo per te, con abbreviazioni e riferimenti che solo tu capisci, non è ancora uno standard condiviso. Diventa condivisibile quando qualcuno che non ha seguito il tuo percorso può prenderlo, seguirlo, e ottenere un risultato simile al tuo. Questo richiede di rendere esplicito quello che per te è diventato automatico: perché quel passo viene prima di quell’altro, cosa controllare e perché proprio quello, cosa fare se il risultato non torna.

Non serve un documento lungo. Serve che il collega che lo legge per la prima volta sappia rispondere a tre domande senza doverti chiedere niente: da dove parte il materiale, quali sono i passi in ordine, e cosa deve controllare lui stesso prima di considerare finito il lavoro. Se una di queste tre risposte manca dal tuo processo scritto, per ora esiste solo nella tua testa.

Scegli il problema noioso, non il più impressionante

Quando porti il primo processo al team, la tentazione è mostrare quello più sofisticato, quello che automatizza di più o che ha richiesto più lavoro da parte tua. È l’errore opposto ma speculare a quello dell’eroe solitario: impressiona, ma non convince nessuno a cambiare le proprie abitudini, perché sembra un’eccezione che riguarda solo te. Il problema che convince è quello noioso che tutti riconoscono: la compilazione ripetitiva che nessuno ama fare, la normalizzazione di dati sporchi, il resoconto che si trascina ogni settimana. Lì il vantaggio è immediato e non richiede fiducia cieca in te o nello strumento, perché chi lo prova se ne accorge da solo al primo utilizzo.

Un esempio vero

Il resoconto settimanale automatizzato nei capitoli precedenti è ormai stabile da mesi, e sei l’unico a usarlo nel tuo team. Per portarlo agli altri, non parti mostrando lo schema completo del flusso automatico: prendi un collega, un caso reale suo, e lo attraversi insieme dall’inizio alla fine una volta sola, con il processo scritto sotto mano invece che a memoria tua. Il collega vede da dove parte il materiale (i suoi aggiornamenti via email), i passi in ordine, e cosa deve controllare lui (la parte «bloccato», esattamente come facevi tu). Alla fine di quel singolo giro completo, il collega ha un caso reale che ha funzionato per lui, non solo una spiegazione teorica di come funziona per te. È quel caso vissuto in prima persona, non la qualità dello schema, che lo convince a riusarlo la settimana dopo.

Una cosa da fare, adesso

Scegli il processo più noioso e più stabile che hai costruito finora in questo percorso. Scrivilo in modo che risponda alle tre domande sopra (da dove parte, i passi in ordine, cosa controllare), e attraversalo insieme a un collega una volta, con un suo caso reale, invece di limitarti a spiegarglielo.

Un prompt da cui partire

Sto scrivendo questo processo perché un collega possa rifarlo senza di me: [nome del processo].
Ecco i passi come li eseguo io: [elenco].
Aiutami a controllare: da dove parte chiaramente il materiale? I passi sono nell'ordine giusto e spiegati senza riferimenti che solo io capirei? È chiaro cosa deve controllare chi lo esegue prima di considerarlo finito?

Fallo davvero

Il documento che risponde alle tre domande ha un formato collaudato, e il corso te lo dà già pronto: il template di handoff, un passaggio di consegne scritto per qualcuno che non ha visto niente del lavoro fatto prima. Nasce per le catene di agenti nel percorso builder, ma tra colleghi funziona identico, e contiene le due sezioni che quasi tutti i processi scritti dimenticano: cosa NON va fatto, e cosa vuol dire fatto. Compilalo per il tuo processo più noioso e usalo come copione quando lo attraversi col collega.

Poi c’è il posto dove il processo abita, e la regola è la stessa della libreria di prompt: dove il team guarda già ogni giorno. Se il tuo team usa Claude o ChatGPT con un piano di squadra, entrambi permettono spazi di lavoro condivisi (i Projects in Claude, i GPT condivisi in ChatGPT): l’istruzione del processo vive lì dentro scritta una volta, e il collega la usa senza nemmeno doverla copiare. Altrimenti va benissimo il posto dove tenete già le procedure, un documento condiviso con gli altri.

La misura del successo resta quella del template: il collega completa il suo primo giro da solo, e le domande che ti fa durante il giro le annoti tutte. Ogni domanda è un buco del documento, non un difetto del collega. Aggiorna il documento dopo il primo giro e il secondo collega partirà già più liscio.

Dove andare adesso

Il capitolo conclusivo del percorso, Capstone: sta funzionando? Misurare tempo e qualità, chiude il cerchio con la domanda che finora hai risposto solo per sensazione: quanto tempo hai davvero risparmiato, e la qualità è davvero migliorata, con numeri tuoi invece che con un’impressione generale.