→ Metodo
Si entra dalla formazione, non dal capitolato.
Non sai cosa chiedere finché non vedi cosa è possibile. Per questo il primo passo non è un preventivo: è formazione, un workshop in cui le tue persone mettono le mani sugli strumenti. Il bisogno lo trovano loro. Da lì costruiamo.
Dalla prima ora
fino al bivio.
L'ordine non è negoziabile, e nemmeno il punto di partenza. Ogni fase produce qualcosa di suo: puoi fermarti alla fine di ognuna e aver comunque portato a casa un risultato. Alla fine della quarta la strada si biforca, e la scelta è tua.
Una o più giornate con le persone che il lavoro lo fanno davvero, non con chi firma: si guarda quali pezzi del loro lunedì mattina un modello può prendersi. Non è una vendita mascherata da corso, è formazione vera, e si lavora sui loro casi con i loro dati. È il momento in cui si capisce dove l'AI aiuta e dove no, che è l'informazione più preziosa dell'intero percorso.
Nelle settimane dopo la formazione le tue persone si costruiscono i propri gadget: piccoli, personali, tarati sul processo che conoscono a memoria. Noi restiamo raggiungibili per le domande ma non agiamo direttamente — su quel processo il contesto ce l'hanno loro, non noi. Il guadagno immediato è qualche ora a settimana che torna indietro; quello che conta di più arriva dopo, quando l'azienda smette di parlare di AI per sentito dire.
Prima o poi un gadget non basta più: serve che lo usi anche il reparto accanto, che i dati restino, che ci sia un controllo su chi vede cosa. Il bisogno è emerso da solo, e ha un contorno preciso perché qualcuno l'ha toccato con mano per settimane. Qui si scrive il perimetro, ed è una conversazione molto più corta del solito: non stiamo immaginando un'esigenza, la stiamo descrivendo.
Sviluppo software classico, fatto bene: scoperta per fissare architettura e priorità, poi sprint settimanali con una dimostrazione alla fine di ognuno — non una relazione sullo stato di avanzamento, una cosa che gira. L'AI accelera scrittura e prototipazione, ma le decisioni di architettura restano di un artigiano: è la ragione per cui fra due anni quel codice si potrà ancora leggere.
Consegnato il prodotto la strada si divide, e nessuna delle due è quella giusta per definizione: o il rapporto continua — manutenzione, evoluzioni, presidio — o si chiude e la manutenzione passa a te. Il codice è scritto dal primo giorno perché la seconda strada resti sempre percorribile. Restare dev'essere una scelta: un fornitore che si rende indispensabile ha smesso di lavorare per te.
Una o più giornate con le persone che il lavoro lo fanno davvero, non con chi firma: si guarda quali pezzi del loro lunedì mattina un modello può prendersi. Non è una vendita mascherata da corso, è formazione vera, e si lavora sui loro casi con i loro dati. È il momento in cui si capisce dove l'AI aiuta e dove no, che è l'informazione più preziosa dell'intero percorso.
Nelle settimane dopo la formazione le tue persone si costruiscono i propri gadget: piccoli, personali, tarati sul processo che conoscono a memoria. Noi restiamo raggiungibili per le domande ma non agiamo direttamente — su quel processo il contesto ce l'hanno loro, non noi. Il guadagno immediato è qualche ora a settimana che torna indietro; quello che conta di più arriva dopo, quando l'azienda smette di parlare di AI per sentito dire.
Prima o poi un gadget non basta più: serve che lo usi anche il reparto accanto, che i dati restino, che ci sia un controllo su chi vede cosa. Il bisogno è emerso da solo, e ha un contorno preciso perché qualcuno l'ha toccato con mano per settimane. Qui si scrive il perimetro, ed è una conversazione molto più corta del solito: non stiamo immaginando un'esigenza, la stiamo descrivendo.
Sviluppo software classico, fatto bene: scoperta per fissare architettura e priorità, poi sprint settimanali con una dimostrazione alla fine di ognuno — non una relazione sullo stato di avanzamento, una cosa che gira. L'AI accelera scrittura e prototipazione, ma le decisioni di architettura restano di un artigiano: è la ragione per cui fra due anni quel codice si potrà ancora leggere.
Consegnato il prodotto la strada si divide, e nessuna delle due è quella giusta per definizione: o il rapporto continua — manutenzione, evoluzioni, presidio — o si chiude e la manutenzione passa a te. Il codice è scritto dal primo giorno perché la seconda strada resti sempre percorribile. Restare dev'essere una scelta: un fornitore che si rende indispensabile ha smesso di lavorare per te.
Esagonale, su uno spettro.
Sviluppata negli anni e formalizzata in modelli pronti all'uso. È uno spettro: si sceglie il grado di modularità giusto per il momento che il prodotto sta vivendo. Il debito tecnico lo governiamo invece di subirlo.
Codice diretto, accoppiato.
Gadget ≠ Applicazione.
Una distinzione che ti protegge. Il gadget te lo fai tu: piccolo, tuo, risolve il tuo problema di oggi. Le applicazioni le facciamo noi, per onestà tecnica: sicurezza, scalabilità e manutenibilità non si improvvisano in un fine settimana.
Lo fai tu.
Interno, non distribuito. Piccolo per natura, e va bene così: risolve un compito dentro un processo, poi finisce lì. Ti diamo di che costruirtelo, perché su quel processo hai contesto e competenza che noi non abbiamo.
La fa Efesto.
Distribuita, sicura, scalabile. Sopra la nostra architettura. Non si improvvisa: servono il metodo, il framework e l'esperienza per reggere utenti, dati, casi limite e prestazioni. Il DNA tecnico è nostro, la proprietà resta tua.
Resta una domanda. Un gadget lo fai in mezz'ora ma dove vive, dopo?
Un sistema operativo
per il tuo lavoro.
I gadget da qualche parte devono vivere. Non dentro l'ennesima chat, non sparsi in venti profili diversi: in un posto solo, dove le tue persone e i modelli stanno alla stessa scrivania, e dove chiunque entri ha un nome e un permesso. È un pezzo di tecnologia che fino a pochi mesi fa non esisteva.
Quello che ci si costruisce sopra.
Non un listino: spunti. Quali abbiano senso lo decide come lavora la tua azienda, non noi.
Un manuale che parla a due pubblici
Le procedure scritte una volta sola: le leggono le tue persone e le leggono i tuoi modelli. Chi entra nuovo smette di chiedere in giro.
Un bacino di contesto
Mail, chat e riunioni trascritte, tutto in un posto consultabile. Non è un archivio da sfogliare: è il contesto che serve a un modello per dirti come sta andando il lavoro questa settimana.
Connettori verso i tuoi sistemi
Gestionale, anagrafiche, documenti condivisi, segnalazioni. Ognuno con le sue regole su cosa si legge, cosa si scrive, e cosa va approvato a mano prima di partire.
Guardrail
Intercettano dati personali in uscita, contenuti fuori dalle regole interne, tentativi di far dire a un modello quello che non deve dire.
Sui guardrail siamo onesti. Oggi lo stato dell'arte non è accurato al cento per cento, e chi ti dice il contrario ti sta vendendo una garanzia che non può darti. Sono guardrail con dei compromessi, non muri. Ma un guardrail è meglio di niente, e questa è una delle poche aree dove si può dire con ragionevole certezza che fra sei mesi funzionerà meglio di oggi.
Cominciamo dalla formazione.
Un workshop di una giornata con le tue persone, sui tuoi casi. Se alla fine il bisogno non emerge, non c'è niente da vendere e ce lo diciamo.
Scrivici