TIA (This Is Acceptable)

TIA — This Is Acceptable — è la decisione, spesso non formalizzata, di accettare un difetto, un workaround o un comportamento anomalo come parte del normale funzionamento di un sistema. Non è una soluzione: è una soglia di tolleranza che il team, consapevolmente o meno, ha smesso di mettere in discussione.

Come funziona nella pratica #

Un TIA nasce quando un problema viene segnalato, analizzato parzialmente e poi archiviato con la nota “per ora va bene così”. Il riavvio che risolve il problema ogni lunedì mattina, la query lenta che “tanto gira di notte”, il log di errori che “non impatta gli utenti”: sono tutti TIA non dichiarati. Il rischio è che col tempo diventino invisibili — parte dell’infrastruttura di fatto, non di progetto.

Quando diventa un problema #

Un TIA non documentato è debito tecnico mascherato. Quando il contesto cambia — nuovo volume di dati, cambio di personale, aggiornamento di versione — il comportamento accettato smette di essere accettabile, ma nessuno ricorda perché era stato tollerato. La mancanza di tracciabilità trasforma una decisione ragionevole in un punto cieco operativo. Documentare esplicitamente un TIA (con data, contesto e condizioni di revisione) è la differenza tra una scelta consapevole e una bomba a orologeria.

Note operative #

Se un TIA deve esistere, deve essere scritto: ticket aperto, decisione registrata, owner assegnato, scadenza di revisione. Un TIA senza owner non è una decisione: è un problema dimenticato.