Capstone — scelta del problema e definizione delle specifiche

Capstone è il progetto integrato finale del corso. Non è esercizio: è il primo progetto vibe coding completo applicato a un problema reale tuo. Lo scopo è dimostrare di saper integrare tutto: dal problem framing alla pubblicazione responsabile. Comincia bene chi sceglie un problema giusto.

Perché questa lezione conta

Il problema sbagliato condanna il capstone. Troppo grande → non lo finisci, frustrazione. Troppo piccolo → niente da imparare. Già esistente → ripeti pattern noti senza scelte difficili. Inventato → manca tensione di un utente vero. La scelta giusta è un problema reale tuo, di scope finibile, con almeno una scelta tecnica non banale.

Obiettivo operativo

Alla fine devi avere:

1. problema scelto, abbastanza definito da partire;
2. brief tecnico di una pagina (problem statement + persona + casi + vincoli + criteri + ipotesi stack);
3. piano di scope: cosa entra in MVP, cosa resta fuori, cosa è “manuale per ora”.

Nucleo della lezione

1. Criteri di scelta

Il problema giusto soddisfa cinque criteri:

Reale: lo vivi tu o qualcuno che conosci. Non inventato per esercizio. Esempio buono: “tracking abitudini per me”, “gestione clienti per studio professionale di mio cugino”. Esempio cattivo: “to-do list generica per dimostrare React”.

Piccolo abbastanza per finire: implementabile in 2-4 settimane part-time. Se richiede mesi, dividi.

Insegna qualcosa di nuovo: include almeno una scelta tecnica non banale. Se sai fare già tutto a mano, non c’è apprendimento. Almeno un’area dove vibe coding ti mette alla prova.

Realistico nei vincoli: vincoli rigidi riconducibili (privacy, costo, dispositivi, manutenzione). Senza vincoli, il design diventa generico.

Verificabile: criteri di “fatto” osservabili. Senza, non sai quando hai finito.

Categorie tipiche di buoni capstone:

• Utilità personale: tool che useresti ogni giorno (es. tracker spese, lettore RSS, gestione abbonamenti).
• Workflow professionale: piccola app per il tuo lavoro o di un cliente conosciuto.
• Strumento didattico: app per imparare/insegnare qualcosa (es. flashcard, quiz).
• Dashboard: visualizzare dati che ti interessano (es. statistiche personali, monitor di server).
• Micro-servizio: integrazione/automazione fra strumenti che già usi.

2. Brief tecnico

Documento di una pagina, 6 sezioni:

Problem statement (5 righe): chi, situazione, ostacolo, risultato osservabile, vincolo rigido (lezione 12).

Persona (5 attributi): ruolo, competenza, obiettivo, frequenza, frustrazione (lezione 13).

Casi d’uso:

• caso normale (6 elementi: trigger, azione, dato, decisione, risultato, errore);
• caso difficile (un solo problema realistico); (lezione 13 estesa)

Vincoli (lezione 14):

• tecnici (rigidi/negoziabili)
• pratici
• dati (incl. privacy)
• regolamentari
• umani

Criteri di successo (lezione 15):

• 3-5 funzionali
• 2-3 non funzionali
• DoD operativa

Ipotesi tecniche:

• stack iniziale (NON definitivo)
• domande aperte tecniche

3. Scope control

Tre liste, sempre:

Dentro MVP: cosa è essenziale per primo deploy. Massimo 5-7 feature primarie.

Fuori MVP: cose desiderabili ma non per la prima versione. Lista con motivo.

Finto/manuale per ora: cose che potrebbero essere automatizzate ma per MVP fai a mano. Esempio: invio email = manuale via Gmail per primi utenti, automatizzazione poi.

Esempio per “tracker abitudini personali”:

• Dentro: aggiungere abitudine, segnare oggi (sì/no), vista calendario ultimo mese, persistenza locale.
• Fuori: streak, notifiche, multi-device sync, social sharing, statistiche avanzate.
• Manuale per ora: niente backup automatico (export manuale).

Scope control evita che capstone diventi prodotto enterprise impossibile.

Procedura pratica

90 minuti per definire bene:

1. Brainstorm 3-5 idee (10 min): scrivi senza censura, anche idee brutte.
2. Filtra con i 5 criteri (10 min): quale supera tutti? Se più di una, scegli quella che ti emoziona di più.
3. Brief tecnico (40 min): compila le 6 sezioni. Una alla volta, breve.
4. Scope control (15 min): liste dentro/fuori/manuale.
5. Validation (10 min): mostra brief a persona di fiducia. Capisce? Vede il problema? Suggerisce buchi?
6. Salva in docs/capstone-brief.md.

Brief vivo, non finale. Aggiornerai man mano.

Laboratorio guidato

Esempio brief: “Tracker delle iniziative di mio cugino, idraulico, che fa anche piccoli interventi non fatturati a parenti”.

Problem statement:

“Mio cugino, idraulico, fa anche piccoli interventi non fatturati a parenti e amici. A fine anno non ricorda quanti, quanto valgono, e si dimentica di chiedere indietro favori. Vorrebbe registrare ogni intervento (1 minuto, da telefono, anche zona senza connessione) e a fine anno avere lista. Vincolo rigido: privato, dati restano sul suo telefono.”

Persona:

• Ruolo: idraulico, 50 anni.
• Competenza: base con smartphone (WhatsApp, foto), niente app complesse.
• Obiettivo: tenere traccia interventi non fatturati.
• Frequenza: 5-10 voci al mese, sporadiche.
• Frustrazione: a Natale realizza di aver fatto 50 piccoli favori, perde traccia di quali.

Casi:

• Normale: dopo intervento da zia Maria, apre app, “Aggiungi”, scrive “Riparato lavandino, zia Maria, tempo 1h, valore 50€”, salva. App ricorda nome cliente.
• Difficile: in cantina senza segnale. App deve funzionare offline e sincronizzare quando torna online (anche se per MVP, single-device, sync non necessario).

Vincoli:

• Tecnici: PWA mobile-first, offline-first [R]; iPhone (target principale) [R].
• Pratici: budget €0/mese [R]; tempo 3 weekend [R]; lo manterrà cugino niente, io occasionalmente [R].
• Dati: privato, no cloud [R]; export CSV richiesto [R].
• Regolamentari: dati personali (nomi clienti) ma uso strettamente personale, no GDPR commerciale.
• Umani: utente unico, non condivide [R].

Criteri:

• Funzionali: aggiungere intervento (cliente, descrizione, durata, valore stimato); lista cronologica; filtro per cliente; export CSV; modificare intervento; cancellare intervento.
• Non funzionali: TTI < 1s su 4G; offline funzionante; UX da telefono in piedi.
• DoD: testato 1 settimana di uso reale dal cugino; PWA installabile da Safari iOS; export funzionante.

Ipotesi stack: Astro + IndexedDB + Tailwind. PWA con manifest + service worker.

Domande aperte: nomi clienti come tag predefinito o testo libero? Foto allegate? Rendere pronto per multi-device dopo MVP?

Scope:

• Dentro: aggiungere/modificare/cancellare intervento, lista, filtro cliente, export CSV.
• Fuori: foto, sync multi-device, statistiche, notifiche, vista calendario.
• Manuale: backup (cugino farà export ogni 2 settimane).

Brief in una pagina. Pronto per architettura.

Output atteso

File docs/capstone-brief.md per il tuo capstone. Una pagina, 6 sezioni, scope control. Salvato in repo, condiviso con persona di fiducia per validation.

Studio passo passo

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

1. Prima lettura: chiarisci l’obiettivo: avviare un progetto integrato scegliendo un problema abbastanza piccolo da finire e abbastanza reale da insegnare. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Scelta del dominio: utilità personale, workflow professionale, strumento didattico, dashboard o micro-servizio.
• Specifiche: utente, problema, flussi principali, dati, vincoli, criteri di successo e rischi.
• Scope control: cosa entra nella prima versione, cosa resta fuori, cosa può essere finto o manuale.

3. Applicazione: svolgi il laboratorio: scrivere il brief completo del capstone e sottoporlo all’AI per far emergere ambiguità e domande. L’output da ottenere è: una specifica capstone approvata, con MVP, esclusioni esplicite e criteri di accettazione.

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

• problema scelto è reale, mio o di chi conosco;
• brief in 6 sezioni completo;
• scope control con tre liste;
• almeno una persona di fiducia ha letto il brief e l’ha capito;
• so cosa farò domani come primo passo.

Errori comuni

Idea generica. “App per la produttività”. Senza utente specifico, non progettabile.

Scope troppo grande. “Voglio fare un Notion mio”. Mesi di lavoro, abbandono.

Niente vincoli rigidi. “Lo facciamo bene e basta”. Senza vincoli, ogni soluzione vale e nessuna è giusta.

Brief troppo lungo. 5 pagine = stai progettando, non definendo. Una pagina max.

Saltare validation. Solo tu lo leggi. Persone esterne notano ambiguità che a te sembrano ovvie.

Ipotesi stack senza domande aperte. Pretendi di sapere tutto già. Non è così; rendilo esplicito.

Prompt di lavoro

Aiutami a costruire brief capstone.

Idea iniziale: [una frase]

Per favore conducimi attraverso 6 fasi, una alla volta (rispondi una, aspetta mio OK, vai alla successiva):

1. Problem statement: cinque domande della lezione 12.
2. Persona minima: 5 attributi.
3. Casi d'uso: caso normale + caso difficile (6 elementi ciascuno).
4. Vincoli: 5 categorie con classificazione R/N/S.
5. Criteri di successo: funzionali, non funzionali, DoD.
6. Ipotesi stack + domande aperte.

Per ogni fase: chiedimi una cosa alla volta, NON riempire tu i vuoti.
Ferma se vedi contraddizioni o ambiguità.
Al termine: brief riassunto in formato markdown da copiare.

Concludi con scope control: dentro MVP / fuori / manuale.

Esercizio finale

Mostra brief a 2 persone diverse. Una tecnica (può vedere assunzioni problematiche), una non tecnica (capisce davvero il problema?). Annota domande/dubbi che fanno. Quasi sempre 2-3 ambiguità emergono. Sistemale prima di passare a architettura. Brief solido = primo passo del capstone.