L'idea non è ancora un progetto

Dal campo

Un imprenditore del settore edile arriva con un’idea che si porta dietro da tre anni: una piattaforma dove i clienti caricano le foto del cantiere, ricevono un preventivo automatico, prenotano il sopralluogo e seguono i lavori in tempo reale. Aveva chiesto due preventivi. Il primo, quarantamila euro; il secondo, sessantacinque. Si era fermato lì.

La domanda che ha sbloccato tutto non era tecnica: quale di queste cose, se domani funzionasse da sola, ti farebbe risparmiare più tempo? La risposta è arrivata in un secondo: il caos delle foto che arrivano su WhatsApp e nessuno sa più a quale cantiere appartengono.

Quella è una cosa sola. Si costruisce in un fine settimana. Non è la piattaforma, ma è l’unica parte che serviva davvero.

Sui casi di questo corso

I casi che aprono le lezioni sono composti: mettono insieme situazioni ricorrenti nel lavoro con le piccole imprese, non raccontano un cliente identificabile. Le cifre danno l’ordine di grandezza di quello che succede di solito, non un risultato promesso.

Le parole che incontrerai

Il laboratorio usa pochi termini tecnici, ognuno spiegato dove serve. Eccoli in anticipo.

• Specifica: il documento in cui scrivi cosa deve fare il programma, per chi e con quali regole. È il lavoro del primo modulo.
• Assistente che scrive codice: un’AI che lavora dentro la cartella del progetto, legge e modifica i file ed esegue i comandi (Claude Code, Codex e simili).
• Terminale: la finestra del computer in cui si scrivono i comandi invece di cliccare. L’assistente ci lavora dentro; a te serve saperlo aprire e leggere.
• GitHub: un servizio che tiene una copia del progetto e la storia di ogni modifica, per poter tornare indietro.
• Database: il posto dove il programma conserva i dati (utenti, prenotazioni, foto), come un archivio ordinato.
• Browser e console: il browser è il programma con cui apri i siti; la console è una sua finestra nascosta in cui compaiono gli errori.
• Chiave di accesso: il codice segreto con cui il programma usa un servizio esterno, come la posta o i pagamenti. Non si pubblica mai.
• Pubblicare: mettere il programma su un servizio online, così funziona anche a computer spento e lo usano gli altri.

Perché le idee non si costruiscono

Un’AI che scrive codice è brava a eseguire istruzioni precise e pessima a indovinare quello che hai in testa. Se le chiedi «costruiscimi una piattaforma per la gestione dei cantieri», riceverai qualcosa: una schermata plausibile, dei bottoni, forse un elenco finto di progetti. Sembrerà un buon inizio. Non lo è, perché ogni decisione che non hai preso l’ha presa lei. Le ha prese tutte al posto sbagliato.

Il lavoro che l’AI non può fare al posto tuo è decidere. Chi userà questa cosa, cosa deve poterci fare, cosa succede quando lo fa. Sono decisioni che richiedono di conoscere il mestiere, non il codice: sono esattamente quelle che tu puoi prendere meglio di chiunque altro.

Il paradosso di questo momento è che la parte tecnica è diventata la più economica mentre la parte di pensiero è rimasta cara come prima.

Le tre domande che riducono un’idea

Prima di scrivere una riga, servono tre risposte scritte. Non pensate: scritte.

Chi la usa. Non «i clienti», non «le aziende». Una persona concreta, con un nome se serve: il geometra che apre il telefono in cantiere con i guanti addosso. Ogni scelta successiva dipende da questa. Il geometra con i guanti non digita password lunghe.

Cosa deve poter fare. Un elenco di azioni, ciascuna con un verbo. Caricare una foto. Assegnarla a un cantiere. Vedere le foto di un cantiere in ordine di data. Tre verbi, non trenta.

Cosa succede dopo. Per ogni azione, dove finisce il risultato. La foto finisce in un archivio, ordinata per cantiere. Il titolare la vede dal suo computer. Se non sai dire dove finisce una cosa, quella cosa non è ancora pensata.

Se le tre risposte stanno in mezza pagina, hai un progetto. Se ne servono cinque, hai ancora un’idea.

Il taglio: la prima versione utile

Il criterio per decidere cosa entra nella prima versione non è «cosa serve», perché serve tutto. È un altro, più duro: cosa deve esserci perché una sola persona la usi una sola volta e ne tragga un vantaggio reale.

Tutto quello che non supera questo test esce. Non viene cancellato, viene rimandato: si scrive in un elenco a parte, che si chiama «dopo». Quell’elenco è la cosa più preziosa del progetto perché è dove va a morire l’ansia di fare tutto subito.

Nel caso del cantiere: caricare la foto, assegnarla, rivederla. Fuori restano il preventivo automatico, la prenotazione del sopralluogo, le notifiche, i ruoli utente, l’applicazione per il telefono. Ognuna di quelle cose, presa da sola, avrebbe raddoppiato il tempo di costruzione.

Chi costruisce per la prima volta sbaglia quasi sempre nella stessa direzione: mette dentro troppo, perché ogni pezzo sembra piccolo. Presi uno per uno lo sono. È la loro somma che affonda i progetti. Non si vede finché non ci sei dentro.

Il primo utente sei tu

C’è un vantaggio enorme e sottovalutato nel costruire qualcosa che userai tu, o che userà qualcuno a due metri da te: il ciclo di correzione dura minuti invece di settimane. Vedi la cosa, capisci cosa non va, la cambi.

Per questo il progetto giusto da cui partire non è quello con il mercato più grande. È quello di cui conosci il problema meglio di chiunque altro, perché ce l’hai tu. La prima versione di quasi tutto il software che oggi usiamo è nata così.

Se stai scegliendo fra un’idea ambiziosa in un settore che non conosci e una noiosa nel tuo, prendi la noiosa. È l’unica delle due che finirai.

Al lavoro con l’AI

L’intervista si fa prima di aprire qualunque strumento di sviluppo: serve a mettere per iscritto le decisioni, non a produrre codice.

«Ho un’idea per un software e voglio ridurla a una prima versione costruibile. Fammi una domanda alla volta e aspetta la mia risposta prima di procedere. Per ogni cosa che dico di voler fare, chiedimi dove finisce il risultato e chi lo guarda. Alla fine restituiscimi due elenchi: le azioni che entrano nella prima versione, non più di quattro; tutto il resto sotto il titolo «dopo». Se qualcosa che ho chiesto non supera il test «una persona la usa una volta e ne trae un vantaggio reale», mettilo nel secondo elenco e dimmi perché.»

Errori comuni

• Chiedere all’AI di costruire l’idea intera: riceverai una facciata plausibile in cui ogni decisione che non hai preso è stata presa male al posto tuo.
• Descrivere l’utente come una categoria: «i clienti» non ha mani, non ha fretta e non sta in piedi sotto la pioggia. Una persona concreta sì: le sue condizioni cambiano il progetto.
• Confondere «serve» con «serve adesso»: quasi tutto serve. Mettere tutto nella prima versione è il modo più comune di non finirla mai.
• Partire da un settore che non conosci perché sembra più promettente: senza il problema in mano non sai riconoscere quando la risposta dell’AI è sbagliata.
• Tenere le decisioni in testa invece che in un file: quello che non è scritto verrà reinventato da capo a ogni conversazione con l’assistente.

Checklist operativa

• Scrivi in mezza pagina chi userà la tua cosa, come persona concreta e non come categoria.
• Elenca le azioni che deve poter fare, ognuna con un verbo. Fermati a quattro.
• Per ogni azione scrivi dove finisce il risultato e chi lo guarda.
• Applica il test della prima versione utile e sposta nell’elenco «dopo» tutto ciò che non lo supera.
• Verifica di essere tu, o qualcuno che puoi interrogare oggi, il primo utente di quello che stai per costruire.