Camminavo per la città con le mani in tasca perso nei miei pensieri.
Poi avvertì un sordo rombo in lontananza.
Alzai gli occhi al cielo e vidi sagome nere minacciose volare lente.
Seguì con lo sguardo la flotta dei neri bombardieri passare indisturbata sopra la città; nessuna contraerea.
Tutti sapevano che sarebbero arrivati, i civili erano stati evacuati per tempo.
Gli aerei oltrepassarono i grattacieli e li persi di vista.
Chiusi gli occhi e nella mente immaginai le bombe che venivano sganciate.
Non sapevo esattamente dove sarebbero cadute e quali danni avrebbero fatto.
Sapevo solo, che una volta terminato l’attacco, io e la mia squadra avremmo dovuto ripristinare ciò che era stato danneggiato per rendere la città nuovamente funzionate e vivibile.
Almeno fino al prossimo bombardamento.
Adeguamento normativo
Il software è un manufatto realizzato per risolvere problemi di business.
In un mercato caratterizzato da cambiamenti frequenti ed improvvisi il software è soggetto a continui adeguamenti.
L’adeguamento può scaturire da esigenze funzionali espresse dal cliente oppure da variazioni normative decise dal legislatore.
Nel primo caso il requisito può essere oggetto di un negoziato nel secondo caso no.
In Italia la normativa è una fonte inesauribile di adeguamenti, spesso complessi e complicati.
Il problema è che gli adeguamenti normativi sono requisiti con complessità incomprimibile e non negoziabile, pertanto rappresentano una seria minaccia rispetto alla quale andrebbero adottare opportune contromisure.
La triade
Il software per sua natura è plastico, ma qualunque adeguamento ha un costo e può avere degli effetti collaterali sul suo funzionamento.
Più l’adeguamento è ampio e profondo maggiore sarà l’impatto e maggiore sarà il costo.
Più elementi del software debbono essere modificati, più complicato e lungo sarà l’intervento di adeguamento.
Più il software è progettato male e scritto in modo incomprensibile, maggiori saranno i neuroni bruciati da chi deve modificarlo. Un momento, questo aspetto non e’ considerato tra i costi aziendali, quindi non frega a nessuno (sigh!).
Il lato oscuro dell’adeguamento normativo e’ che esprime anche una scadenza, pertanto definisce a priori il tempo che si ha disposizione per lo sviluppo per i test e per la delivery sui clienti.
Perciò nel caso di un adeguamento normativo, se prendiamo la triade: Time, Scope e Cost, abbiamo i primi due assi fissi e possiamo modulare solo il Cost: forse.
Si ma, di che effort stiamo parlando ? Facciamo una stima dell’impatto.
Stallo
Non è infrequente che la stima per l’adeguamento ecceda il tempo utile a disposizione e qui casca l’asino.
In questi casi la via aurea del manager illuminato (male) è spingere sul budget: cioè aumentare le persone che lavoreranno al progetto.
Il problema è che questa strada seppur costosa non sempre è praticabile: dipende da come è stato progettato il software.
Se il software non è modulare, lavorarci in parallelo potrebbe risultare talmente caotico da indurre l’effetto contrario.
E’ come pensare di aumentare la produttività di una minuscola cucina mettendoci a lavorare in contemporanea tre cuochi della stazza di Giorgione: una ben triste un’utopia.
Quando il parallelismo non è attuabile siamo in presenza di uno stallo in cui l’apporto del management è pari a zero.
In questi casi la realtà inconfessabile è che l’adeguamento nei tempi previsti semplicemente: non è umanamente possibile.
Nessun manager ama udire queste parole e Caterina lo sa bene:
La verità ti fa male, lo so
Caterina Caselli “Nessuno mi può giudicare”
Un eroe al tavolo 5
Come si esce dallo stallo ? Serve un eroe.
“Accendiamo il Bat-segnale.” disse il Capitano Gordon.
Si cerca qualcuno sprezzante del pericolo, con alto senso del dovere pronto ad immolarsi per il bene dell’azienda.
Qualcuno pronto al sacrificio che, esercitando il super-poter dell’extra-effort (non retribuito) curvi abilmente lo spazio-tempo e lavorando 12 ore al giorno prenda in mano quel groviglio infernale di codice e ne dipani la matassa.
E il miracolo si compie ogni volta, come la liquefazione del sangue di San Gennaro.
Ma possiamo veramente definirlo un miracolo ?
Non è piuttosto una perversa roulette russa ?
Magia nera alimentata dal sacrificio umano ?
E se ha funzionato una volta, forse e’ ripetibile, quindi perche’ prendere provvedimenti?
Manager certificati, ma privi di buonsenso, empatia e competenza non funzionano.
Sono individui che, non avendo adottato in tempo utile opportune contromisure, trovandosi spalle al muro, attribuiscono agli Dei le colpe della propria inettitudine per poi invocarne subito dopo l’intercessione e l’invio dell’eroe salvatore…
Non abbiamo veramente bisogno di figure del genere in azienda. Saremmo in grado di fare gli stessi danni anche da soli. Per fare meglio servono manager competenti e proattivi.
Quel debito ? Non e mio!
Queste situazioni di stallo non possono essere gestite in nessun modo ortodosso, ma possono essere evitate facendo prevenzione.
In un’azienda IT il debito tecnico è un problema di tutti, ma sembra non interessi a nessuno, tranne gli sviluppatori che ci combattono quotidianamente.
Il debito tecnico deve essere mantenuto basso perché è un costo aziendale e prima o poi i debiti vanno saldati.
Se il software è soggetto ad adeguamento normativo frequente, il debito tecnico ne amplifica gli effetti negativi, pertanto non può essere sottovalutato.
In uno scenario del genere convivere con codice legacy senza investire per reingegnerizzarlo è una mancanza grave che denota miopia e scarso rispetto per le persone.
Predisponiamo la contraerea ed adottiamo dei criteri costruttivi diversi per ridurre e mitigare gli effetti devastanti dei bombardieri normativi e magari così non avremo più bisogno degli eroi.