Perché il capitolato classico fallisce
Il capitolato tradizionale ha un difetto strutturale: descrive lo strumento immaginato invece dell'attività reale. Vi si elencano schermate, pulsanti e requisiti («il sistema dovrà consentire di…») prima di aver definito l'unica cosa che conta: quali dati esistono, come si collegano, chi li tiene in vita.
Un risultato che tutti i progetti informatici conoscono: lo strumento consegnato è conforme al documento ma inadatto al lavoro reale, perché il documento stesso era una finzione. E la sua stesura è costata settimane che non hanno prodotto alcun software.
La struttura in una pagina: quattro blocchi
Un'applicazione gestionale si descrive interamente con quattro blocchi. È la struttura che usano i progettisti esperti, ed è esattamente ciò che Blueprint Maker estrae dalla tua descrizione per costruire il piano dell'applicazione.
- LE COSE (entità): ciò che segui: clienti, cantieri, articoli, interventi. Un elenco di 3-8 nomi, ciascuno con le sue informazioni chiave (campi).
- I LEGAMI (relazioni): come le cose si collegano: «un cantiere appartiene a un cliente», «un intervento riguarda un'attrezzatura». Una frase per legame.
- GLI STATI (stati): il ciclo di vita dei tuoi oggetti: «preventivo, firmato, in corso, terminato, fatturato». Le tue parole, nell'ordine reale.
- I NUMERI (indicatori): ciò che vuoi vedere ogni mattina: importi da fatturare, pratiche in ritardo, scorte sotto soglia. Da tre a sei indicatori.
Esempio completo: una pagina che basta
«Azienda di posa recinzioni, 4 persone. COSE: clienti (nome, indirizzo, telefono), cantieri (indirizzo, tipo di recinzione, metratura, importo preventivo, data prevista), interventi (data, ore svolte, squadra), materiali (riferimento, scorta). LEGAMI: un cantiere appartiene a un cliente; un intervento si svolge su un cantiere; i materiali si consumano per cantiere. STATI di un cantiere: preventivo inviato, firmato, pianificato, in corso, terminato, fatturato, saldato. NUMERI: cantieri in corso, metratura posata del mese, importo da fatturare, materiali sotto soglia.»
Questa pagina contiene tutto il necessario per costruire l'applicazione, da uno sviluppatore come da un generatore. Ciò che non contiene è altrettanto significativo: nessuna descrizione di schermata, nessuna scelta tecnica, nessun requisito numerato. Le schermate DERIVANO dalla struttura.
Le tre trappole di scrittura
Trappola 1, descrivere lo strumento attuale: «voglio le colonne dalla A alla R del mio foglio di calcolo». Il foglio di calcolo è una fonte di informazioni, non un obiettivo: estraine le cose e i legami, non la disposizione.
Trappola 2: l'ambito troppo ampio: voler coprire la fatturazione a norma, le paghe, la contabilità. Questi ambiti regolamentati hanno i loro strumenti; la tua applicazione si ferma dove essi iniziano ed eccelle nel tuo monitoraggio operativo.
Trappola 3, i casi particolari per primi: «e quando un cliente è anche fornitore?». Descrivi prima il flusso normale che copre il 90 % delle giornate; i casi particolari si aggiungono dopo, su una struttura sana.
Dalla pagina all'applicazione: due percorsi
Percorso classico: la pagina fa da brief a uno sviluppatore o a un'agenzia, riduce drasticamente il rischio di fraintendimenti e il tempo di analisi fatturato.
Percorso diretto: la pagina È il prompt. Sottoposta a Blueprint Maker, diventa un piano applicativo strutturato: entità, relazioni, stati, indicatori, che validi prima della generazione. L'applicazione arriva già distribuita, con dati dimostrativi: il tuo capitolato si verifica su schermate reali, non in riunioni di collaudo. E se in seguito interviene uno sviluppatore, parte dal codice generato (export ZIP, push GitHub) invece che da una pagina bianca.
Il modello da copiare
Riprendi queste quattro righe e riempile con le tue parole: «La mia attività: … COSE seguite (con le loro informazioni chiave): … LEGAMI tra loro: … STATI attraversati: … NUMERI da vedere ogni mattina: …» Dieci righe bastano; il piano Scoperta (0 €) permette di testare subito l'applicazione che la tua pagina produce.