Sapere con QMates
Prima rendiamo software e organizzazione coerenti, poi innoviamo con il mondo esterno e trasformiamo con AI e tecnologia.
Insights, strategie e best practices su architettura software, organizational design e scaling per team di sviluppo.
Tutti gli articoli
Come si accumula il debito tecnico senza che nessuno se ne accorga
Il debito tecnico non nasce da decisioni sbagliate: nasce da decisioni razionali prese in sequenza, senza che nessuno osservi l'effetto cumulativo. Il problema non è la singola scorciatoia, ma il meccanismo che la rende invisibile finché è troppo tardi.
I segnali del debito tecnico: nel codice, nel team e nel business
Il debito tecnico manda segnali precisi prima di diventare un'emergenza. Molti vengono interpretati come problemi di persone o di processo. Questa guida li traduce in quello che sono: sintomi di una struttura software che non regge più il ritmo dell'organizzazione.
Come misurare il debito tecnico: dall'architettura al flusso di lavoro
Misurare il debito tecnico non significa installare SonarQube. Significa capire dove il sistema oppone resistenza ai cambiamenti che il business richiede. Una guida operativa alle metriche che contano — e a quelle che distraggono.
Come ridurre il debito tecnico: strategie che funzionano
Ridurre il debito tecnico non significa riscrivere tutto da zero né fermare la delivery per mesi. Significa intervenire nei punti giusti, nell'ordine giusto, mantenendo attiva la capacità di rilasciare valore durante tutto il processo.
Software legacy: quando convivere, quando evolvere, quando riscrivere
Non tutto il software legacy va riscritto. Non tutto può essere lasciato com'è. La decisione dipende da tre variabili che quasi nessuno misura prima di scegliere. Una guida per chi deve decidere cosa fare con un sistema che funziona ma frena.
CI/CD reale: perché la tua pipeline probabilmente non lo è
Avere Jenkins o GitHub Actions non significa fare continuous delivery. La differenza tra una pipeline che automatizza il teatro e una che rilascia davvero, in modo continuo e sicuro.
Refactoring strategico: quando intervenire e come giustificare l'investimento
Il refactoring non è un capriccio tecnico: è una decisione di business. Come quantificare il costo del non-fare, scegliere dove intervenire e ottenere il supporto della direzione.
Debito Tecnico: introduzione per C-level
Una serie progressiva per capire, misurare e ridurre il debito tecnico nelle organizzazioni software. Per CTO, VP Engineering e CEO che devono prendere decisioni senza perdersi nei dettagli tecnici.
Debito tecnico: cos'è e cosa non è
Il debito tecnico non è codice vecchio né tecnologia obsoleta. È un vincolo strutturale che rallenta la tua capacità di modificare il sistema. Una guida per riconoscerlo, misurarlo e distinguerlo da ciò che non lo è.
Team Topologies per chi guida un'azienda software
I principi di Team Topologies tradotti in decisioni concrete per CEO e CTO. Come la struttura dei team determina la velocità del software e cosa fare quando i gruppi si bloccano a vicenda.
Dal monolite ai microservizi: quando ha senso e come non sbagliare
La migrazione ai microservizi non è sempre la risposta giusta. Una roadmap pratica per capire quando estrarre, cosa isolare e come non paralizzare la delivery durante il percorso.
Architettura evolutiva: far evolvere il software senza riscrivere tutto
L'architettura software non si progetta una volta sola. Si fa evolvere insieme al business, in modo incrementale. La guida per chi vuole modernizzare senza fermare la delivery.
Formazione AI obbligatoria in azienda: obbligo o vantaggio competitivo?
Dal 2 febbraio 2025 ogni azienda che usa strumenti AI deve garantire una formazione adeguata. Per chi la tratta come un adempimento è un costo. Per chi la tratta come un investimento è il primo passo per adottare l'AI con risultati concreti.
AI in azienda: cosa funziona davvero e da dove partire
L'AI non è un tool da comprare. È un cambiamento da governare. Guida pratica per chi guida un'azienda: da dove partire, cosa evitare, quando funziona davvero.
Software roadmap delays: perché le roadmap diventano instabili
Quando un'organizzazione software cresce, le roadmap diventano progressivamente meno affidabili. Spesso il problema non è la stima ma la complessità del sistema che produce la delivery.
Perché il tuo team tech sembra lento (anche se hai assunto senior)
Molte scale-up assumono sviluppatori senior per accelerare la delivery, ma la velocità non migliora. Il problema non è il talento, ma il sistema in cui il team opera.
Il vero significato di autonomia dei team (e perché spesso è un'illusione)
Molte aziende dichiarano di avere team autonomi, ma nella pratica dipendono continuamente da altri team. Questo disallineamento è una delle principali cause di rallentamento nelle scale-up software.
Cost of change nel software development: perché cresce
Quando il software cresce, modificare il prodotto diventa sempre più difficile. Il cost of change è uno dei segnali più chiari che architettura, organizzazione e delivery non stanno evolvendo insieme.
Startup delivery slowdown: perché la velocità cala crescendo
Molte startup scoprono che la crescita del team non aumenta la velocità di delivery. Il rallentamento è spesso il risultato di architettura, organizzazione e dipendenze che non evolvono insieme.
Team dependencies nel software development: il vero collo di bottiglia
Nelle scale-up software il rallentamento della delivery raramente dipende dal talento dei team. Spesso il vero collo di bottiglia sono le dipendenze tra team che aumentano con la crescita dell'organizzazione.
Technical Debt nelle Startup: perché rallenta la crescita
Molte startup attribuiscono il rallentamento del prodotto al debito tecnico. In realtà il problema è più profondo: riguarda il modo in cui software, organizzazione e strategia crescono insieme.
Il momento in cui una startup inizia a rallentare (e nessuno capisce perché)
Molte startup rallentano quando crescono. Non è un problema di persone, ma di sistema. Ecco perché succede e come evitarlo.
Raccontaci dove sei bloccato
Prototipo fragile, legacy pesante o delivery imprevedibile – partiamo da lì