Dai requisiti
alle user story.
La call è finita. Il lavoro inizia adesso.
Registrazione salvata e note su un documento. Business e dev che aspettano. Due formati: Linear e GitHub.
La call. Così com'è.
Cliente: Ciao! Scusa se ti disturbo il lunedì mattina.
PM: Nessun problema, stavo fissando il vuoto. Dimmi tutto.
Cliente: Ho due cose. La prima è un casino: le email di notifica non partono quando aggiorniamo lo stato di un ordine. Ci è stato segnalato più volte questa settimana.
PM: Non partono proprio o arrivano in ritardo?
Cliente: Proprio non arrivano.
PM: Capito. I tuoi clienti le usano frequentemente?
Cliente: Sì, usano quelle notifiche per gestire i flussi. Se non arrivano, si bloccano.
PM: Ok, allora diamo la priorità al fix. L'altra?
Cliente: Filtri avanzati sui report, per data, categoria e utente. Adesso scaricano tutto e filtrano su Excel. Avevamo detto entro fine mese, regge ancora?
PM: Sì. Però ho bisogno di sapere una cosa: i filtri devono funzionare anche sull'export?
Cliente: (pausa) ...non me l'hanno ancora chiesto. Ti faccio sapere domani?
PM: Perfetto. Mandami quello e organizzo nel pomeriggio.
Cliente: Grazie!
PM: Buon lunedì.
Cliente: Già.
Claude legge. Claude classifica.
Dalla trascrizione caotica Claude estrae quattro categorie. Non inventa niente: riorganizza quello che c'è.
Le domande giuste. La destinazione giusta.
Claude: Ho analizzato la call con il Cliente. Due cose, ordini diversi. Partiamo dalla prima: le email di notifica. Quando non arrivano, i clienti perdono operazioni irreversibili o ricevono solo un aggiornamento in ritardo?
PM: Si bloccano completamente. Senza la notifica non sanno che lo stato è cambiato: non processano l'ordine.
Claude: Impatto operativo diretto su clienti paganti. Questo non aspetta il prossimo sprint. GitHub issue oggi, priorità urgente.
Claude: Seconda cosa: i filtri avanzati sui report. Devono applicarsi anche all'export CSV, o basta la visualizzazione in-app?
PM: Non lo so ancora. La referente del cliente non me l'ha ancora detto, le scrivo stasera prima del sync.
Claude: Allora fermati qui. Scope aperto: task su Linear prima, parlane internamente. Se l'export è incluso lo scope può raddoppiare: potrebbe servire un preventivo al cliente.
Per il PM. Per il dev. Mai più la stessa cosa.
Come parlargli. Tre regole.
Non serve saper programmare. Serve sapere cosa chiedere e come chiederlo.
Una Skill. Zero ripetizioni.
Spiegare a Claude le stesse cose ogni volta è tempo perso. Salvi le istruzioni una volta Claude le applica a ogni trascrizione, automaticamente.
Ruolo: Assistente PM. Il PM non è tecnico. I dev usano GitHub. Quando ricevi una trascrizione di una call cliente: · Estrai: bug, feature request, decisioni, ambiguità · Per ogni item: tipo · chi lo ha detto · urgenza dichiarata · impatto (blocca clienti / non critico) · Se lo scope non è chiaro → fai domande prima di generare task Routing: · Bug con impatto operativo su clienti paganti → GitHub issue oggi, urgente · Bug non bloccante + scope chiaro → GitHub issue, priorità normale · Bug non bloccante + scope non chiaro → chiedi prima · Feature con scope aperto → Linear prima, parla internamente · Ambiguità su impatto o scope → chiedi prima di assegnare Output · Task Linear (PM): · Titolo: linguaggio business, zero termini tecnici · Corpo: contesto decisionale, perché è prioritario, chi è coinvolto · Label: priorità · tipo · stato scope · Deadline solo se concordata esplicitamente in call Output · Issue GitHub (dev): · Titolo: [Bug] / [Feature] / [Chore] + descrizione tecnica · Acceptance criteria: testabili, uno per riga · Edge case: null, errori, duplicati, permessi Regole: · Campo mancante → chiedi, non inventare · Scope non confermato → non generare GitHub issue · Requisito cambia → aggiorna entrambi i documenti
.md nella cartella /skills/. Si carica in automatico.Come iniziare oggi.
+ MCP
Il flusso. Tre regole.
Danilo Spanò
Claude Torino #1
claudetorino.dev