Blog / Tecnologia

Perché il gestionale invecchia: il debito tecnico spiegato semplice

Lettura: 5 minuti

Il primo anno il software va benissimo. Il terzo anno ogni modifica richiede settimane. Il quinto qualcuno propone di “rifarlo da zero”. Succede quasi sempre, e ha un nome preciso: debito tecnico.

Cos’è il debito tecnico

Il debito tecnico è il costo futuro delle scorciatoie prese oggi nello sviluppo. Una soluzione rapida invece di una ben progettata, una libreria non aggiornata, una funzione aggiunta “in fretta per la fiera”: ognuna funziona subito, ma lascia un debito che si paga dopo, con gli interessi.

Come un debito finanziario, non è sempre un male: a volte conviene indebitarsi per andare più veloci. Il problema nasce quando nessuno lo ripaga.

I sintomi

• Ogni piccola modifica richiede molto più tempo di quanto sembri ragionevole.
• Correggere un problema ne fa comparire un altro altrove.
• Il software gira su versioni vecchie di linguaggi e librerie, che nessuno osa aggiornare.
• Solo una persona sa davvero come funziona, e se cambia lavoro il progetto si ferma.

Perché colpisce soprattutto il software su misura

Un prodotto usato da migliaia di clienti viene mantenuto per forza: il produttore aggiorna, corregge, rifattorizza. Un software su misura tradizionale, invece, è un progetto unico. Dopo la consegna il budget finisce, la manutenzione si riduce agli interventi urgenti, e il debito cresce anno dopo anno. Non per incompetenza, ma perché nessuno ha l’incentivo economico a ripagarlo.

Come si evita

Separare ciò che è comune da ciò che è unico

Gran parte di un gestionale è uguale per tutti: utenti, permessi, anagrafiche, agenda, documenti, notifiche, API. Se questa parte vive in una piattaforma comune, mantenuta per tutti i clienti, il debito tecnico si ripaga una volta sola e il beneficio arriva a ognuno.

Aggiornare in modo continuo, non a strappi

Piccoli rilasci frequenti, con test automatici, costano molto meno di una grande migrazione ogni cinque anni.

Tenere separate le personalizzazioni

Le funzioni specifiche di un cliente devono vivere in moduli distinti, che parlano con la piattaforma tramite interfacce stabili. Così la piattaforma può evolvere senza rompere ciò che è su misura.

Il nostro approccio

È esattamente il motivo per cui abbiamo costruito GoCRM sul CORE: una piattaforma comune, scritta in Go, che manteniamo e aggiorniamo per tutti i clienti insieme. I moduli su misura restano tuoi; tutto il resto segue il ciclo di rilascio del core. Il risultato è un software su misura che non invecchia.