Il modo più veloce per sprecare tre settimane è automatizzare un processo che nessuno ha mai scritto per intero. La procedura «vera» sta in tre teste diverse, in un foglio di calcolo e in una consuetudine che nessuno chiama procedura. Claude serve proprio qui, prima della soluzione: per tirare fuori i requisiti e per capire se il caso d’uso regge.

Prima domanda: è un compito o è una domanda?

La distinzione che risolve metà dei dubbi è la più semplice. Se ti serve una risposta o una spiegazione, e la cosa si esaurisce in poche battute, quella è una conversazione. Se ti serve un risultato consegnabile, un file che qualcuno aprirà, una presentazione che qualcuno mostrerà, un foglio da riordinare, allora stai chiedendo un lavoro, e va scritto come un lavoro.

C’è poi un terzo caso. Quando non esiste nessuna condizione osservabile che dica «adesso è finito», non è un compito: le linee guida di Anthropic dicono di riformularlo come una domanda invece che come un incarico. Un incarico senza fine verificabile produce un rapporto aperto e una discussione che nessuno può dichiarare chiusa.

I cinque ingredienti di un caso d’uso adatto

La guida per iniziare con Claude Cowork elenca cinque caratteristiche di un compito delegabile. Non servono tutte, ma più ne conti, più il caso è solido:

  1. Più input: più file, una cartella intera, oppure file più applicazioni collegate.
  2. Un output in forma di file: un documento, una presentazione, un foglio di calcolo, un CSV.
  3. Ricorrenza: le attività una tantum vanno bene, ma quelle che si ripetono sono il terreno migliore.
  4. Criteri di successo noti: ne conosci già la forma, quindi in quindici secondi capisci se il risultato è giusto.
  5. Un centro automatizzabile: il pensiero sta all’inizio (decidere cosa vuoi) e alla fine (decidere se è giusto); tutto quello che sta in mezzo è ciò che deleghi.

Il quarto punto è il filtro più severo. Se non sai riconoscere in quindici secondi se l’output è corretto, il problema non è ancora abbastanza definito per essere delegato: né a Claude, né a un collega appena assunto.

Fatti intervistare, invece di scrivere il requisito da solo

L’abitudine indicata come la più utile in assoluto è controintuitiva: chiedere a Claude di farti domande prima di iniziare. Non è cortesia, è analisi dei requisiti; serve a far emergere le assunzioni che non hai scritto perché per te sono ovvie: che cosa significa «buono» in questo caso, quali eccezioni conosci tu e Claude no.

Prima di cominciare, ripeti la mia richiesta con parole tue, così verifico
che ci siamo capiti. Poi fammi tutte le domande di chiarimento che ti servono,
e non iniziare finché non ti dico di procedere.

Lo stesso approccio funziona un passo prima, quando non sai nemmeno quali attività esaminare. Con la memoria e la ricerca nelle chat attive, puoi chiedere a Claude di guardare come lavori:

Guarda le mie conversazioni degli ultimi due mesi. Quali attività ripeto
più spesso? Per ognuna dimmi: quali input richiede, quale output produce,
e se il successo è verificabile in pochi secondi.

Un’osservazione della stessa guida: la differenza fra un risultato mediocre e uno ottimo quasi mai sta nel prompt, sta nel contesto che gli hai dato.

Scrivere il requisito: esito, vincoli, definizione di fatto

Un requisito scritto bene ha quattro parti. La prima, nella versione compatta della documentazione: dai a Claude la destinazione, non il percorso, cioè metti l’esito verificabile nella prima frase, non l’attività. «Guarda questa cosa» non ha una fine; «pubblica lo stato del progetto e avvisami quando è online» ce l’ha.

Poi i vincoli, scritti come regole: che cosa il lavoro deve rispettare, che cosa conta come verifica, che cosa non deve toccare. Poi la definizione di fatto, che decide anche chi chiude: se la prova è un controllo oggettivo, chiude Claude; se è un’approvazione o una scelta fra alternative, chiudi tu. Infine le decisioni che devono tornare da te prima che qualcuno agisca.

Obiettivo: una checklist di onboarding per i nuovi assunti dell'amministrazione,
pronta da consegnare al responsabile venerdì.
Vincoli: massimo due pagine, un passo per riga, nessun riferimento
ai sistemi dismessi.
Fatto significa: copre i primi cinque giorni e ogni passo ha un responsabile.
Torna da me prima di aggiungere passi che coinvolgono le buste paga.

La verifica finale la suggerisce la guida ufficiale e costa trenta secondi: mostra la tua richiesta a un collega che non conosce il progetto e chiedigli di eseguirla. Se resta confuso, lo sarà anche Claude.

Dal requisito al primo test

Un requisito si valida provandolo, e conviene farlo sul lavoro che conosci meglio, dove sai già che aspetto ha un risultato buono. Se il primo tentativo delude, la documentazione indica quattro mosse: semplifica la formulazione, aggiungi contesto come se parlassi a chi non sa nulla del tema, spezza la richiesta in sottopassi, e correggi con istruzioni di follow-up invece di ricominciare.

Un compito con un obiettivo solo e un perimetro stretto produce risultati migliori di un prompt che ne insegue tre insieme. Se il caso d’uso è grosso, la scelta corretta non è scrivere un requisito più lungo: è dividerlo in passaggi in sequenza, dove l’output di ciascuno diventa l’input del successivo. È lo stesso principio dell’analisi dei processi, applicato alla conversazione.