03il metodo
Prima il design tecnico, poi il codice.
Ogni progetto parte da un'analisi vera. Dal caos degli strumenti restano solo quelli adatti, dentro un documento chiaro: è quello che l'AI deve implementare, non improvvisare.
Quattro passaggi, sempre gli stessi
Non è una metodologia con un nome e un logo. È l'ordine minimo che serve per non costruire la cosa sbagliata: capire, studiare, scegliere, disegnare. Poi si scrive il codice, e a quel punto scriverlo è la parte facile.
Capire il problema significa fare domande scomode
La richiesta iniziale quasi mai coincide con il problema. «Mi serve un gestionale» di solito vuol dire che tre persone si rimbalzano un file Excel e nessuno sa quale sia la versione buona. Il gestionale è una possibile risposta, non è la domanda.
Quindi chiedo cosa succede oggi, dove si perde tempo, cosa succederebbe se non facessimo nulla, e chi userà davvero la cosa. Sono domande che a volte fanno emergere che non serve costruire niente, e in quel caso te lo dico: è il risparmio più grande che posso farti fare.
Come scelgo gli strumenti
Nessuna preferenza a priori. Quattro criteri, applicati ogni volta, che valgono tanto per un framework quanto per un servizio AI.
cosa guardo
- Maturitàda quanto esiste e chi lo usa in produzione
- Costo di uscitaquanto costa andarsene se domani chiude
- Codice in manoresta tuo o vive solo dentro la piattaforma
- Dove finiscono i datiserver, giurisdizione, chi può leggerli
cosa non guardo
- L'hypequanto se ne parla non dice se funzionerà per te
- Le mie abitudinilo strumento che conosco meglio non è sempre quello giusto
- Le funzioni in democontano quelle che userai davvero
- Il prezzo di listinoconta il costo a regime, non quello del primo mese
Cosa consegno prima di iniziare
Un documento breve, leggibile anche da chi non scrive codice. Non serve a me: serve perché tu possa dire «qui hai capito male» quando correggere costa un'ora invece di due settimane.
contenuto
- Il problema, riscrittocome l'ho capito io, per verificare che coincida
- Modello dei datile entità e le relazioni, prima di crearle
- Architettura a blocchicosa parla con cosa, e attraverso quale confine
- Scelte e alternativecosa ho scelto e cosa ho scartato, con il perché
- Rischi notidove può rompersi e cosa faremo se succede
a cosa serve
- A teper verificare che il problema sia quello giusto
- All'AIper implementare invece di inventare
- A entrambiper accorgersi degli errori quando costano poco
L'architettura non è un disegno. È l'elenco delle decisioni che non vuoi rifare.
E solo a questo punto si scrive
Con il design tecnico in mano, l'AI diventa quello che dovrebbe essere: un esecutore molto veloce, dentro binari decisi da qualcuno. Ogni pezzo che produce ha un riferimento contro cui essere verificato, e la verifica resta il mio lavoro, riga per riga.
Il capitolo successivo racconta esattamente questo: cosa succede quando quei binari non ci sono, e dove l'AI lasciata sola sbaglia in modo costoso.
Partiamo dal design tecnico
Raccontami il problema: la prima cosa che ricevi è il documento, non un preventivo a scatola chiusa.