Esercizio: trasformare tre idee vaghe in problemi definiti

Lezione completamente pratica. Applichi quanto imparato (problem statement, persona, vincoli, criteri di successo) su tre idee diverse per dimensione e dominio. L’obiettivo non è la perfezione ma il movimento mentale: da frase ispirazionale a brief tecnico.

Perché questa lezione conta

Sapere la teoria del problem framing non basta: devi farlo abbastanza volte da renderlo automatico. Tre idee diverse forzano a non ripetere lo stesso schema. Una è personale (basso rischio, scope ristretto), una è interna (utenti reali, vincoli pratici), una è pubblica (sicurezza, scala, complessità maggiore). Ognuna mette in luce errori diversi.

Obiettivo operativo

Alla fine della lezione devi avere:

1. tre brief completi (1 pagina ciascuno) per tre idee distinte;
2. esperienza pratica nello scoprire ambiguità nascoste durante la conversione;
3. consapevolezza dei punti dove tendi a saltare (persona vaga, vincoli mancanti, criteri assenti, ecc).

Nucleo della lezione

1. Le tre idee da scegliere

Una per categoria:

A. App personale: solo per te. Es: tracking allenamento, lettore RSS minimale, gestione abbonamenti. Bassa criticità, scope piccolo, libertà tecnica.

B. Strumento interno: per un piccolo gruppo (2-10 persone) con cui hai contatto. Es: gestione clienti per studio professionale, tracking ore per piccolo team, archivio fatture per microimpresa. Utenti reali, vincoli pratici (orari, dispositivi, manutenzione).

C. Servizio pubblico o commerciale: per utenti esterni che non conosci. Es: landing page con lead magnet, calcolatore con risultato condiviso, newsletter con pagamento ricorrente. Scala, sicurezza, supporto richiesti.

Non scegliere tre idee dello stesso tipo. Le difficoltà sono diverse.

2. Le ambiguità tipiche

Parole-segnale che indicano ambiguità ancora da risolvere:

• Semplice: per chi? in che senso? niente click? niente configurazione?
• Moderno: stile visivo? stack tecnico? UX pattern?
• Automatico: cosa scatena, cosa accade, chi controlla?
• Intuitivo: rispetto a chi? riconoscibile da chi non l’ha mai usato? misurabile come?
• Veloce: caricamento? ricerca? tempo di completamento di un task? quanti millisecondi?
• Sicuro: contro quali minacce? con quale modello di attaccante?
• Scalabile: a quanti utenti? quanti record? quanto traffico?
• Bello: secondo il giudizio di chi? riconducibile a quale benchmark visivo?

Ogni occorrenza di queste parole nel tuo brief = un punto da raffinare. Sostituire con specifico, misurabile, contestuale.

3. Riscrittura progressiva

Tre passaggi per ogni idea:

Passaggio 1 (idea grezza): una frase, come ti è venuta. Non censurare. Es: “voglio un’app per leggere le notizie senza distrazioni”.

Passaggio 2 (problem statement): applica le cinque domande della lezione 12. Una persona, una situazione, un ostacolo, un risultato osservabile, un vincolo rigido. 5-8 righe.

Passaggio 3 (brief tecnico di una pagina): aggiungi i pezzi delle lezioni successive:

• persona minima (5 attributi);
• caso normale + caso difficile;
• vincoli (rigidi, negoziabili, sconosciuti) per le 5 categorie;
• criteri di successo (3-5 funzionali, 2-3 non funzionali, DoD operativa);
• prima ipotesi di stack tecnico (NON definitiva, va validata);
• domande aperte (cose che non sai ancora e devi scoprire prima di sviluppare).

Il passaggio 3 è il deliverable. Una pagina compatta, riusabile come input al prompt iniziale.

Procedura pratica

Sequenza di 75 minuti:

1. Scelta (5 min): scegli A, B, C concrete, non astratte.
2. Idea grezza (5 min): scrivi le tre idee in una frase ciascuna.
3. Problem statement (15 min): applica le cinque domande a tutte e tre.
4. Brief tecnico A — personale (15 min): scope ristretto, dovrebbe essere il più rapido.
5. Brief tecnico B — interno (20 min): scope medio, vincoli reali emergono qui.
6. Brief tecnico C — pubblico (15 min): scope largo, accetta che alcune parti restino “domande aperte”.

Se finisci prima: ripassa i tre brief e segna ambiguità rimaste (parole-segnale).

Laboratorio guidato

Esempio di risultato per idea A (personale):

Idea grezza: “voglio un’app per leggere le notizie senza distrazioni”

Problem statement: “Io stesso, sviluppatore 35 anni, ogni mattina apro 5 siti di tecnologia ma finisco a guardare social. Vorrei un singolo lettore con i feed che mi interessano, senza commenti, senza pubblicità, senza notifiche. Vincolo rigido: nessun account, dati locali, niente tracking.”

Brief tecnico:

• Persona: io, intermedio-avanzato con tool digitali, uso quotidiano 15 min, frustrazione: distrazione su siti delle testate.
• Caso normale: apro app, vedo lista articoli per fonte, clicco titolo, leggo testo formattato, segno “letto”.
• Caso difficile: feed RSS rotto / aggiornato male, articolo solo riassunto, immagine pesante. Cosa vedo?
• Vincoli:
  • Tecnici: web (PWA, funziona offline) [R]; stack libero [N].
  • Pratici: tempo 2 weekend [R]; budget hosting €0 [R]; lo manterrò io [R].
  • Dati: nessun dato personale, solo URL feed e cache articoli locali [R]; export OPML [R].
  • Regolamentari: niente raccolta dati, niente cookie tracking [R].
• Criteri:
  • Funzionali: aggiunta feed via URL OPML; lista cronologica; lettura offline ultimi 50 articoli; segna come letto; export OPML.
  • Non funzionali: TTI < 1s su 3G; accessibile da tastiera; nessuna chiamata a terze parti.
  • DoD: testato su 3 feed reali; PWA installabile; build deployabile su Vercel free.
• Stack ipotesi: Astro + IndexedDB + Tailwind (validare).
• Domande aperte: come gestire feed che richiedono auth? CORS sui feed self-hosted? aggiornamento background?

Modello da seguire (con tuoi contenuti, non copiare). Replica per B e C.

Output atteso

Tre brief tecnici di una pagina ciascuno, salvati in cartella docs/idee/ o equivalente. Ogni brief è autonomo: un’altra persona dovrebbe leggerlo e capire abbastanza per iniziare lavoro.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: allenare la conversione da intuizione creativa a brief tecnico riutilizzabile. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Scomposizione dell’idea in utenti, bisogni, flussi, dati, vincoli e metriche di riuscita.
• Individuazione delle ambiguità: parole come semplice, moderno, automatico, intuitivo, veloce.
• Riscrittura progressiva: da frase ispirazionale a specifica breve ma operativa.

3. Applicazione: svolgi il laboratorio: lavorare su tre idee: una app personale, uno strumento interno e un servizio pubblico o commerciale. L’output da ottenere è: tre brief completi di una pagina, ciascuno pronto per generare un piano tecnico iniziale.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho tre brief, non uno o due;
• le tre idee sono di categorie diverse (personale / interno / pubblico);
• in ogni brief ho identificato almeno una “domanda aperta”;
• ho usato parole-segnale (semplice/moderno/veloce) zero o pochissimo, e dove le ho usate ho aggiunto definizione concreta.

Errori comuni

Brief troppo lunghi. 5 pagine per idea = stai progettando, non definendo. Una pagina, max due.

Idea grande dichiarata “personale”. “Mi servirebbe un Notion mio” non è personale, è un servizio cloud complesso. Distingui scope reale.

Vincoli copiati fra le tre idee. Vincoli devono cambiare con la categoria. Se sono uguali, non hai capito le differenze.

Stack deciso prima dei criteri. “Userò Next + Postgres + …” prima di sapere cosa serve. Stack è ipotesi, non punto di partenza.

Domande aperte zero. Significa stai scrivendo certezze finte. Onestà: se non sai, scrivilo.

Prompt di lavoro

Sto convertendo tre idee vaghe in brief tecnici. Ti ho dato:

Idea A (personale): [una frase]
Idea B (interno): [una frase]
Idea C (pubblico): [una frase]

Per OGNUNA delle tre, fammi un'intervista in tre fasi:

Fase 1 (problem statement, 5 min):
- per chi
- in quale situazione
- quale ostacolo
- quale risultato osservabile
- quale vincolo rigido

Fase 2 (persona + casi, 7 min):
- 5 attributi persona minima
- caso normale (6 elementi)
- caso difficile (6 elementi, un solo problema realistico)

Fase 3 (vincoli + criteri, 8 min):
- 5 categorie di vincoli (R/N/S)
- 3-5 criteri funzionali
- 2-3 non funzionali
- DoD operativa
- ipotesi stack
- domande aperte

Per ogni risposta: chiedimi una cosa alla volta. Non riempire tu i vuoti.
Al termine di ogni idea, sintesi in brief di una pagina.

Procediamo idea per idea, non in parallelo.

Esercizio finale

Mostra i tre brief a una persona di fiducia (collega, amico tecnico, anche un altro modello AI in chat separata). Chiedi: di queste tre idee, quale potresti iniziare a sviluppare domani senza chiedermi altro? Quella è il brief più maturo. Le altre due hanno ambiguità che nemmeno tu vedi più dopo averle scritte. Aggiungile alle “domande aperte” e poi scegli da quale partire.