Quando serve un intervento mirato?

Quando una parte specifica del software blocca tutto il resto: un prototipo che non scala, un componente legacy fragile, o un nodo tecnico che rallenta la delivery dell'intero team.

Quanto dura un intervento mirato?

L'intervento è chirurgico e focalizzato. La durata dipende dalla complessità del problema, ma l'obiettivo è produrre un risultato concreto nel minor tempo possibile.

Lavorate anche sul codice legacy?

Sì. Interveniamo su legacy complesso con refactoring incrementale: stabiliziamo le parti critiche senza riscrivere tutto, riducendo il rischio e mantenendo la continuità del servizio.

Come capite dove intervenire?

Analizziamo architettura, flussi di delivery e dipendenze tra componenti per identificare il punto esatto dove il sistema si blocca. L'intervento è mirato sul collo di bottiglia reale.

C'è una parte del software che sta rallentando la crescita

Interveniamo su prototipi che non scalano, legacy fragile e nodi tecnici
che bloccano la delivery

Se ti riconosci in uno di questi segnali, non è un problema di persone

Ogni modifica genera regressioni

Le stime sono imprevedibili

Il team evita certe parti del codice

Le feature richiedono più tempo del previsto

La roadmap rallenta per problemi tecnici

È un nodo tecnico non risolto

Perché succede

Quando un prodotto cresce troppo in fretta, alcune parti del sistema si irrigidiscono

Non per incompetenza

Non per superficialità

Ma perché:

Decisioni tecniche prese in urgenza diventano permanenti

Architettura evoluta senza refactoring continuo accumula compromessi

Confini tra componenti diventano ambigui

Nuove feature si appoggiano su fondamenta già fragili

All'inizio funziona

Poi ogni modifica diventa più costosa della precedente

order_manager.js — 847 righe

function processOrderV2_FINAL_fixed(o, ctx, flag) {

// TODO: capire perché flag=2 rompe tutto — non toccare

if (o.type != 'B' && flag !== 2 && ctx.user.role !== 'admin') {

var res = db.query(`SELECT p.*, d.val, COALESCE(d2.override_val, p.base) as eff FROM pricing p LEFT JOIN disc d ON d.oid=${o.id} AND d.active=1 LEFT JOIN disc_override d2 ON d2.pid=p.id WHERE p.sku=${o.items[0].sku} AND p.region=${ctx.region || 'EU'}`)

if (res[0].eff * 1.22 > o.total && !o._skip_check) {

sendMail(ctx.user.email, 'ALERT', res)

updateLegacyERP(o.id, 3, ctx)

// non capisco cosa fa il flag 3 nell'ERP

} else if (o.total === 0 || o._legacy_import) {

db.query(`UPDATE orders SET status=99 WHERE id=${o.id}`)

// status 99 = ??? vedi slack #ops-2021

}

var tmp = calcDiscount_NEW(o, res, true)

if (tmp2 != null) notifyAll(tmp, ctx.user, o)

// tmp2 non è definita qui — ma non crashare mai in prod

refreshCache_v1()

refreshCache_v2(o)

// chiamare entrambe, ordine conta (non si sa perché)

}

⚠ ogni modifica qui richiede ore di analisi per capire cosa non rompere

Non è caos. È complessità non gestita

Intervento chirurgico. Perimetro chiaro

Non riscriviamo tutto

Non restiamo per sempre

Identifichiamo il punto critico e interveniamo lì

Audit tecnico mirato

Identificazione del collo di bottiglia

Refactoring opportunistico

Stabilizzazione

Trasferimento continuo di know-how al team

Sblocchiamo la parte che oggi rallenta tutto il resto

Cosa non facciamo

Non riscriviamo tutto da zero per principio

Non creiamo dipendenza dal nostro intervento

Non aggiungiamo complessità dove non serve

Non vendiamo un refactoring infinito

Interveniamo solo dove l'impatto è massimo

L'obiettivo non è cambiare tutto

È rimettere controllo dove oggi c'è fragilità

Come capiamo dove intervenire

Prima di toccare il codice, analizziamo il sistema

Osserviamo:

Punti di accoppiamento tra componenti

Dipendenze cicliche e aree ad alta volatilità

Parti con test coverage insufficiente

Flussi che generano regressioni frequenti

Zone dove le modifiche hanno impatto sproporzionato

Non interveniamo dove è più visibile

Interveniamo dove l'effetto è sistemico

// mappa dipendenze — modulo billing

module: billing

depends_on:

- pricing

- notifications

- reporting

volatility_score: high

test_coverage: 42%

// alto impatto sistemico

Per questo l'intervento è mirato

Dopo l'intervento

Il codice torna modificabile

Le stime diventano più affidabili

Meno firefighting

Delivery più stabile

Roadmap più prevedibile

order.service.ts

- function updateOrder(order) {

- recalculatePricing(order)

- notifyWarehouse(order)

- syncCRM(order)

- updateAnalytics(order)

- }

+ function updateOrder(order) {

+ pricingService.update(order)

+ eventBus.emit('order.updated')

+ }

// responsabilità isolate, effetti controllati

La crescita non si ferma più per un problema tecnico

È il momento giusto se:

Stai scalando e qualcosa si è irrigidito

Il prototipo iniziale non regge più

Hai ereditato un legacy complesso

Il team è bloccato su una parte critica

Non aspettare che diventi ingestibile

Approfondisci su Sapere

Articoli del nostro team che esplorano in dettaglio i temi legati a questa sfida

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.

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.

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.