Debito Tecnico #3: Impariamo a gestirlo

by Andrea Maioli on 29 gennaio 2013

Nei post precedenti abbiamo visto che sviluppare software genera Debito Tecnico e che il suo importo è proporzionale alla complessità dello stesso. Purtroppo abbiamo anche visto che con le tecniche di sviluppo tradizionali, accumulare debito è inevitabile.

È proprio per questa ragione che imparare a gestire il Debito Tecnico diventa un’attività importante. Una ricerca Gartner afferma che entro il 2015 il Debito Tecnico delle maggiori imprese americane potrebbe assumere un valore equivalente a 1000 miliardi di dollari.

Come evitare allora di farsi schiacciare dall’entità di questo debito? È qui che la scelta di assegnare a questo concetto il nome di Debito Tecnico trova la sua massima efficacia. Innanzitutto occorre avere la consapevolezza della sua esistenza. La situazione peggiore in cui ci si può trovare dopo aver contratto un debito, infatti, è proprio quella di dimenticarsene.

È pertanto estremamente importante effettuare immediatamente una stima della quantità di lavoro necessaria per coprire sia il debito che gli interessi e allocare al più presto le risorse per ripagarlo prima possibile.

Anche il Debito Tecnico infatti, come ogni altro tipo di debito, genera interessi. Più si posticipa il pagamento, più alta diventa la quantità di lavoro necessaria per ripagarlo, a causa dell’entropia che il lavoro mancante sta generando. Ecco perché è importante non rimandare troppo a lungo i pagamenti.

Se si continua a rimandare, può succedere che allocare tutto il pagamento del debito non sia più possibile ed è a questo punto che il progetto software entra in uno stato di rischio strategico da cui non è facile uscire.

Purtroppo non esistono scorciatoie. Occorre un nuovo approccio che permetta di ridurre, o meglio, di eliminare il debito tecnico all’origine. E qui entra in gioco la Programmazione Relazionale di Instant Developer. Ma di questo parleremo nella prossima puntata.

Nel frattempo provate a rispondere a questa domanda: quando raggiungerò la soglia oltre la quale potrei avere difficoltà a rientrare dal mio Debito Tecnico?

In questa serie:

{ 5 comments… read them below or add one }

1 Giuseppe Cassanelli 29 gennaio 2013 alle 14:53

“La situazione peggiore in cui ci si può trovare dopo aver contratto un debito, infatti, è proprio quella di dimenticarsene.”
NON SONO D’ACCORDO.
E a riprova questo post avrà molti meno commenti del precedente :-)

2 Mauro Marini 29 gennaio 2013 alle 19:01

Anche io sono stato colpito dalla frase di Andrea, ma la riformulerei: “la situazione peggiore in cui ci si può trovare dopo aver contratto un debito è che se lo ricordi il creditore!”. Da qui lo spunto per una soluzione alternativa a In.De: far dimenticare il debito al creditore.
Quante volte il compito del commerciale è proprio quello di “imbornire” il cliente dicendogli “ma ora c’è una nuova tecnologia..Dai facciamo tutto con X che si fa in fretta e viene molto meglio della soluzione vecchia …ti faccio un buon prezzo…”.
Il creditore, pur non avendo la quantifazione esatta del suo credito tecnico, ne percepisce lo spaventoso ammontare con il sesto senso…e finisce per accettare, azzerando di fatto il debito tecnico.
Ho idea che succederà lo stesso anche in altri settori. Nessuno salderà il “debito polito” degli ultimi 40 anni, e neppure quello mostruoso economico degli molti stati occidentali. Ci sarà un bravo “commerciale” che ci convincerà che è meglio fare trovare un accordo.
Questo non cambia il fatto che non vorrei avere un debito tecnico con un boss dei casalesi. Dubito infatti che un bravo commerciale potrebbe convincerlo a non esigere il pagamento del debito.
In questo caso, InDe potrebbe salvarmi dall’essere sciolto nell’acido.
Per questo ben venga la prossima puntata! :)

3 Andrea Maioli 30 gennaio 2013 alle 10:42

Ho l’impressione che ci siano alcuni debiti che possono essere “rimessi”, mentre quello tecnico se c’è bisogna proprio pagarlo con gli interessi!

4 Giuseppe Cassanelli 1 febbraio 2013 alle 18:47

Uno dei primi principi che ho imparato in ambiente informatico è il GIGO (Garbage In, Garbage Out) che normalmente si riferisce ai dati in ingresso e uscita in un’applicazione.

Ma il concetto si estende ovviamente anche all’impegno profuso in fase di analisi e realizzazione: una procedura “nata male” e realizzata peggio non può che produrre problemi e saranno le prime “tangenti” che si dovranno pagare, come ad un usuraio, fino a quando il debito di qualità sull’analisi, sviluppo e test non sarà stato pagato.

E sappiamo tutti molto bene che rattoppare costa sempre di più che fare bene subito, quindi altri “interessi” che si aggiungono.

Questa è la teoria che conosciamo bene e nessuno strumento può stroncare le nostre malefatte ;-)

Però lavorare con “attrezzi” che ci aiutano ci semplifica la vita e, in ultima analisi, consente di limitare o eliminare, se siamo bravi, le cause, con buona pace degli “strozzini” che rimarranno a bocca asciutta :-)

5 Andrea Maioli 1 febbraio 2013 alle 19:05

@giuseppe: in riferimento al primo commento, lo sapevo che non saresti riuscito a resistere! :)

Leave a Comment

Previous post:

Next post: