Un product manager voleva trattare il 'genie' come una fotocopiatrice

«Dimmi quando hai finito le 300 copie, purché non ci metta un tempo ridicolo». Kent Beck riporta così la richiesta di un product manager, ex collega, su come usare il “genie”¹.

Beck ammette la stessa tentazione. Vorrebbe dire: «Scrivi una virtual machine Smalltalk ad alte prestazioni, con molta memoria, e semantica di database», e attendere che torni finita¹. Poi chiarisce il punto: il “genie” non lavora come una fotocopiatrice. Non prende un ordine, non sparisce, non riconsegna un pacco perfetto. Chiede contesto. Chiede criteri di successo. Chiede scelte. Serve un dialogo, anche serrato¹.

Il problema non è la potenza dello strumento. È la forma del lavoro. Il “genie” produce bozze, ipotesi, variazioni. Occorre dire che cosa conti, che cosa evitare, quali vincoli rispettare. Occorre spezzare il compito. Occorre guardare l’output, segnare cosa funziona e cosa no, e chiedere un nuovo tentativo. È un ciclo di prova e correzione, non un invio a fondo cieco¹.

Beck sposta l’attenzione dall’ordine chiuso al risultato negoziato. Suggerisce di specificare l’obiettivo con esempi. Di rendere misurabili i vincoli importanti. Di dichiarare le priorità quando i vincoli entrano in conflitto. Se serve precisione, spiegare cosa sia un errore accettabile. Se serve originalità, chiedere più alternative e poi selezionare. Il “genie” risponde meglio a istruzioni chiare e a feedback puntuali che a richieste generiche¹.

Emergono tre mosse pratiche. La prima: ridurre l’ampiezza del problema. Un compito enorme, tipo la virtual machine citata, va diviso in parti verificabili. La seconda: rendere visibile la qualità attesa. Esempi positivi e negativi aiutano il modello a orientarsi. La terza: iterare rapidamente. Ogni risposta è materiale per la successiva. Il ritmo conta quanto l’accuratezza della singola richiesta¹.

C’è anche un effetto sul ruolo di chi chiede. Trattare il “genie” come una fotocopiatrice deresponsabilizza. Trattarlo come un collaboratore riassegna il lavoro: più progettazione, più valutazione, meno esecuzione ripetitiva. La fatica si sposta dall’implementazione alla definizione del problema. Il risultato dipende dalla qualità di quella definizione e dalla cura nella revisione interattiva¹.

Il metodo cambia le aspettative di tempo. Non si promette una consegna unica dopo ore di silenzio. Si organizza una serie di scambi brevi, ognuno con un avanzamento misurabile. L’errore non è un fallimento, diventa segnale per correggere rotta. Anche la “velocità” assume senso solo insieme ai criteri di qualità condivisi all’inizio della sessione¹.

Beck non promette magie. Indica un modo operativo per ottenere valore. Trattare il “genie” come un interlocutore competente, ma non onnisciente. Dargli struttura, esempi, limiti. Chiedere verifiche, non solo soluzioni. Fermarsi quando il risultato soddisfa gli standard scelti all’inizio. L’efficienza arriva così: poco spreco di richieste vaghe, molta chiarezza di scopo, iterazioni corte e verificabili¹.

La lezione tocca il management del prodotto. Se il “genie” non è una fotocopiatrice, i team che lo usano bene guadagnano non dalla delega totale, ma dalla qualità delle domande e dei cicli di feedback. È una competenza da praticare, come qualunque altra del mestiere¹.