Articoli su tech, prodotto, team e appunti vari: quello che imparo, non solo dentro i team di prodotto delle startup, raccontato dal campo, con quello che funziona e quello che non va.
I founder mi chiedono spesso quali feature sviluppare dopo, e partire dalle feature è il modo più rapido per costruire una roadmap piena che non porta da nessuna parte. Racconto come la costruisco dagli obiettivi di business con Value Proposition Canvas, Impact Mapping e Opportunity Solution Tree, e perché a volte il workshop giusto è un livello più in alto. Le giustificazioni migliori non bastano: la domanda finale è cosa non faremo, e perché
Partire dal codice esistente per riscrivere o integrare un software significa copiarne gli errori. In due progetti opposti, viteSicure e PharmaLink, il punto di partenza è stato il dominio, fatto emergere con l'Event Storming. Da un dominio mai modellato sono usciti i bounded context del nuovo backend; da quattro sessioni su un processo già mappato, il mapping tra processi e software. Quando serve davvero, e quando invece è solo teatro.
In anni di consulenza ho imparato che i danni che lascia non nascono quasi mai dall'incompetenza, ma da obiettivi disallineati. Ho visto un design implementato senza domande diventare in due anni un'applicazione inutilizzabile. A un founder ho detto che il suo metodo non funzionava e sono stato allontanato, poi richiamato qualche settimana dopo a costruire una validazione. Cosa insegna quel ritorno, e come si riconosce una partnership vera.
In XPeppers ho imparato che la seniority non si misura in conoscenza: si giocava su quattro dimensioni, e la tecnica era quasi solo il prerequisito. Anni dopo, dall'altra parte della cattedra, ho cercato di insegnare allo stesso modo. Racconto il modello di senior che respiro ancora oggi, tra un DSL in Kotlin scritto in pair e un team costruito da zero con il mentoring dentro il lavoro quotidiano.
Per quasi dieci anni ho fatto il sistemista, poi sono tornato a scrivere codice. Nel 2019 ho portato sul palco un live-coding in cui scrivevo i test prima dei ruoli Ansible, con Molecule e Testinfra, per due volte davanti a un pubblico vero. Cosa mi è rimasto addosso: testare il sistema e non lo strumento, ambienti usa-e-getta e cicli di feedback corti. E perché gli errori che raccontavo allora li ritrovo ancora oggi, quasi intatti.
Dieci anni fa avevo pipeline, deploy automatici e log collector, e credevo di essere DevOps. Non lo ero: il racconto di due visioni sbagliate, della metafora dell'arciere che non reggeva e dei quattro errori che mi hanno portato a capire che gli strumenti sono il come, non il perché. La serie di quattro post scritta dopo il talk del 2019, raccolta in un testo unico: perché DevOps è cultura e collaborazione, non una questione di tool.
Due problemi opposti: smontare un legacy che fatturava un milione di euro all'anno senza fermare le vendite, e modellare da zero una piattaforma per milioni di giocatori. In entrambi i casi sono partito dal dominio con l'Event Storming e ho lasciato che i bounded context scegliessero la forma: un monolite modulare da una parte, microservizi che finiscono in lambda dall'altra. Ecco come i confini trovati col business sono diventati codice.