I 10 peggiori errori nel software che devi assolutamente evitare

Qual è la classifica dei 10 peggiori errori nel software che potrebbero far saltare il tuo progetto o la tua azienda?

Ho commesso errori nella mia vita professionale, tanti, anche se fortunatamente non troppi: è la strada inevitabile degli innovatori, dei curiosi, di chi adotta tecnologie promettenti o al contrario è obbligato a utilizzare quelle vecchie per vincoli aziendali imposti. Ancora più spesso, mi sono trovato a gestire i problemi degli altri! Guai a ripetizione per scelte magari fatte da chi c’era prima di me, o gerarchicamente sopra di me, o che metteva i soldi ma non si rendeva conto di quello che erano le conseguenze di certe scelte.

Ma oltre agli effetti negativi, per i quali ho quasi sempre dovuto trovare personalmente delle soluzioni o comunque dei rimedi, ho passato anche tantissimo tempo a pensare a come evitare di farli in futuro e come evitare che li facessero i miei clienti e i miei collaboratori.

Così come ci sono tanti colleghi, clienti, partner strategici con cui mi confronto quotidianamente, che da sempre vista la mia passione e dedizione alla tecnologia, mi hanno riferito le loro “disgrazie” sulle quali siamo finiti a ragionare insieme, al lavoro ma spesso anche in orari improponibili a cena se non dopocena, passati a parlare di lavoro ed elaborare insieme una soluzione, un rimedio ma soprattutto il modo per scongiurare il loro ripetersi.

Da queste cattive esperienze e dall’enorme fatica fatta per comprenderle in profondità, ho imparato tanto: mi permetto di suggerirti quali sono i 10 peggiori errori, in modo che tu possa evitare le stesse conseguenze disastrose in futuro, e le migliori strategie per evitarli.

Cercare nuovi clienti invece che gestire bene quelli attuali: tante aziende, purtroppo non solo quelle piccole ma anche quelle di medie e grandi dimensioni, non hanno sotto controllo i numeri, le metriche, i margini dei vari progetti e dei vari clienti. Numeri sia tecnologici, di performance, di rendimento ed efficienza, sia economici e finanziari. E non si rendono conto quali sono le ferite aperte dei problemi causati dal software, ad esempio gli altri 9 di questo decalogo, che sanguinano e drenano risorse preziose, sia umane che economiche. E si buttano a capofitto su qualunque nuovo cliente senza discriminazioni, senza capire se si hanno le competenze tecnologiche, il tempo, la convenienza e il margine a seguirli. Pensando che tutto fa brodo, qualunque commessa e qualunque tipo di attività, senza rendersi conto che qualunque nuova distrazione, mancanza di focus, di specializzazione non può portare ad altro che a gestire peggio i clienti attuali, senza ricavare veramente ossigeno da quelli nuovi.
Adottare processi diversi per team diversi: i processi sono come le mode. A qualcuno piace AGILE, chi si trova bene con il ciclo a “V”, c’è chi di fatto continua ad adottare il vecchio modello Waterfall magari perché crede che sia l’unico modo di poter raggiungere una certificazione Safety-Critical. Ma il problema è quando… ognuno fa di testa sua. Ogni team adotta un metodo diverso, ognuno è innamorato della propria filosofia, tutti i “geek” hanno una loro missione di “evangelizzazione” preferita ed è così che si moltiplicano i corsi, i tool, gli approcci, le strategie e ognuno va per la sua strada, ovviamente divergente. Senza economie di scala, senza utilizzo pieno delle licenze, senza formazione continua tra progetti, senza instaurare un circolo virtuoso di cultura aziendale unificata.
Acquisire tool senza formazione e affiancamento: come si dice in inglese, “a fool with a tool, is a more powerful fool”. Uno strumento software, un compilatore, un debugger, un tool di modellazione o di test anche ottimo, il migliore sul mercato possono realmente fare la differenza, migliorare le attività, rinforzare i processi, automatizzare compiti ripetititi. Purtroppo, anche dopo verifiche accurate dei vari tool disponibili, loro confronto evalutazione ecc. il rischio è che, dopo aver speso un sacco di soldi, tutto questo rimanga solo sulla carta relegato alle buone intenzioni. Infatti, senza un’adeguata strategia di addestramento, di formazione, di introduzione, di affiancamento, di verifiche successive sul suo inserimento ed effettivo utilizzo e la sua efficacia rischiano solamente di amplificare i problemi esistenti. Salvo perdere qualche mese (o anno) e dare la colpa al tool, e ricominciare da capo con la novità tecnologica del momento.
Non misurare la qualità: le sensazioni, gli entusiasmi, le impressioni o i fogli Excel compilati a caso non aiutano per niente a percepire la vera qualità di un progetto software. Così come non servono i diagrammi di GANTT che vanno al 90% in poche settimane e rimangono così per mesi, magari perché compilati per adattarsi alle previsioni per far fare bella figura ai manager. Se il tuo progetto sta drenando risorse preziose, se il tool ha velocizzato o rallentato le attività, se ci sono colli di bottiglia evidenti, se la qualità di un sotto-processo è scadente, a volte il “sanguinamento” di risorse importanti è visibile ma più spesso ancora le emorragie sono interne per cui quando te ne accorgi è troppo tardi, sono già in corso da troppo tempo. La qualità è tale solo se misurabile: conosci i tuoi numeri? I tuoi indicatori chiave, i KPI? Che metriche adotti? E come le visualizzi? Chi le analizza? Ogni quanto?
Testare alla fine dello sviluppo: non esiste quasi nulla di peggio del continuare a buttare la “polvere” (i bug) sotto al tappeto, non facendo nulla per scoprirli, salvo poi trovarsi con una montagna di guai e pretendere di partire con un’attività di test che dovrebbe, in una frazione del tempo di sviluppo del codice, scoprire tutti i bug. Impresa disperata: anche pensando alla migliore efficienza di individuazione e correzione degli errori, non si può pensare di poter fare tutto in pochissimo tempo. Cosa fai allora? Hai due scelte, una peggiore dell’altra: far slittare la data del rilascio in modo da avere il tempo di testare… oppure ridurre il tempo e le risorse dedicate all’attività di test. Le conseguenze non te le dico neanche, penso che le conosci benissimo, no?
Modificare all’ultimo minuto: hai un software perfetto, un sistema che funziona come un orologio, un’applicazione pronta per essere rilasciata. Tutto è pronto per il rilascio e stai trattenendo il fiato. Ma poi… scopri un ultimo bug, un cliente ti chiede l’ennesima modifica fondamentale, il team di sviluppo introduce una ottimizzazione e non riesci o non hai il potere di dire di no. E il castello di carte crolla. Non funziona più niente. L’equilibrio miracolosamente raggiunto viene compromesso, a volte per sempre. All’inizio ci metti ore, notti insonni a cercare di sistemare tutto all’ultimo ma spesso ti infili in una spirale senza senso. E funzionava tutto perfettamente poco prima!
Inchinarsi a qualunque richiesta del cliente: certo, il cliente ha sempre ragione, è lui che paga, è un cliente esigente, difficile, ti dà tanto fatturato, ecc… peccato che spesso sia il primo a non rendersi conto che le conseguenze della variabilità, dell’instabilità, della vulnerabilità delle sue continue richieste, dei suoi requisiti ballerini, dei suoi cambiamenti all’ultimo minuto gli si ritorceranno contro con gli interessi. Ti modifica tutto quello che è possibile modificare ogni mese, se non ogni settimana o più volte al giorno. Magari a progetto già ultimato e pronto per partire. Ma dopo aver bruciato le tue risorse, il tuo tempo e i tuoi margini per dover reinventare ogni giorno la ruota che gira come dice lui, forse non si rende conto che gli fornirai qualcosa che sarà in ritardo, instabile, più costoso e meno corrispondente alle specifiche. Vuoi fare leggere questo decalogo anche a lui? 😉
Non formarsi e non aggiornarsi: lavori già 10 ore al giorno, se non di più. Certe volte anche nei weekend. Hai la famiglia, gli amici, altri interessi oltre al lavoro. Come fai pure a formarti, a studiare? Dove trovi il tempo di leggere riviste di settore se già vai a letto tardi tutte le notti? Come fai a seguire quell’interessante webinar proprio quando c’è una riunione? Senza parlare poi di quel fantastico corso, però proprio nei giorni in cui il cliente o il team da un’altra sede vengono a trovarti in azienda e non hai proprio il tempo di allontanarti. O risulta impossibile valutare un nuovo tool, perché il team di sviluppo è impegnato in attività urgenti scadute ieri. Intanto la tecnologia va avanti, i tool progrediscono, le tecniche migliorano e tu rimani indietro… che fare? Come aggiornarsi per non perdere il treno?
Ragionare sui costi di R&D e non sul TCO: magari tu lavori dentro o sei responsabile del gruppo di sviluppo, mica di altro. Non sei il manager del supporto sul campo, non curi i problemi dei clienti, non gestisci la manutenzione e non ti viene chiesto di farlo. O magari sei il responsabile di tutto il progetto, ma adesso i tuoi capi ti chiedono i costi della sola fase di ricerca e sviluppo, dell’R&D. Mica dell’intero ciclo di vita, del cosidetto Total Cost of Ownership (TCO). Per cui non sono immediatamente visibili i costi successivi, che di solito sono molto più alti: un bug sul campo, quando ci sono magari centinaia o migliaia di dispositivi sul campo, ha dei costi enormi di individuazione, gestione e correzione, per non parlare dei costi sostenuti dal tuo cliente. Ma se ai tuoi manager, alla proprietà interessano solo i costi a breve termine prima di arrivare sul mercato e non quelli successivi… ti stai perdendo una grossa fetta della torta dei problemi futuri. E non sempre è una vera e propria torta gourmet…
Trascurare i progetti non certificati: come dico sempre ai miei clienti, quando uno ha la pistola della Certifcazione Safety-Critical puntata alla tempia, è troppo facile essere i primi della classe. Non puoi vendere, non puoi volare, non puoi trasportare persone se il tuo software direttamente o indirettamente gestisce potenziali vite umane. Per questo motivo dedichi tutte le tue migliori risorse ed energie nei progetti DO-178, ISO-26262, IEC-61508: sei obbligato a farlo, ad adottare i migliori processi, acquistare i tool più avanzati, fare gap-analysis per trovare la strada più rapida e formare te e i tuoi collaboratori. Ma tutto questo che senso ha, se la tua azienda lo adotta solo per un progetto mentre gli altri languono nel disordine, nel caos, nell’anarchia? Perché c’è ancora qualcuno che pensa che certi metodi, processi, tool siano troppo costosi e burocratici per essere adottati anche negli altri prodotti che la tua azienda fa? Così spendi un sacco di soldi per introdurre tecnologie avanzatissime in un solo progetto o in una minoranza, senza poter pensare al modo di diffondere questi automatismi, questa ricerca della qualità anche ad altri ambiti che ne guadagnerebbero in metriche, indicatori e anche in termini di margini economici.

Cosa dici, ci ho azzeccato? Riconosci qualcuno di questi problemi perché ti è capitato personalmente o lo hai visto accadere nelle realtà in cui hai lavorato? O ti sei trovato nello sgradevole compito di doverne gestire le conseguenze, risolvere tutto e ripulire pure le tracce, senza averlo deciso né provocato tu? Ma subendone tutti gli effetti? Non so perché, ma ci scommetto di sì…

Come vedi, questi errori non sono problemi tecnologici ma spesso sono metodologici: sono approcci sbagliati alla base, in partenza e molte volte non sono neanche sotto il tuo controllo. Sono scelte fatte prima che tu arrivassi, da altre persone. O le hanno fatte manager che non avevano gli strumenti per comprenderne a fondo gli effetti. Se non addirittura sono scelte che hai fatto tu, ma con vincoli di tempo, di budget e di sovraccarico che ti hanno impedito di poter fare la scelta migliore.

Come fare a risolvere questi problemi?

O meglio ancora a evitare proprio che capitino del tutto?

Visto che ho dedicato buona parte della mia vita professionale esattamente a questo, all’individuare le migliori pratiche, i processi più efficienti, le metodologie più rapide per ottenere risultati migliori ho deciso con i miei grandissimi collaboratori, “guru” e anche amici Vance Hilderman e Niroshan Rajadurai, di creare un vero e proprio metodo che risolve tutti e 10 questi problemi alla radice: il Metodo per lo Sviluppo Efficiente del Software (M.E.D.S.).

Quali sono in breve le caratteristiche di questo metodo? E perché è adatto anche se non fai software certificato?

è scalabile a varie dimensioni di progetto e azienda
è progressivo, non costringe a rivoluzioni dal giorno alla notte
è scientifico, promuove un approccio rigoroso seppur flessibile
è misurabile, non sono parole e concetti vani ma metriche che hai sotto controllo
è ripetibile, puoi clonarlo con facilità da un progetto all’altro
è efficiente, tremendamente efficiente, riducendo costi e tempi in maniera impensabile
è garantito, è l’unico metodo che se applicato garantisce risultati misurabili

Cosa puoi fare per saperne di più?

Prima di tutto, potresti chiedere una delle 100 copie gratuite del libro “Software Sicuro” da me scritto insieme a Vance e Niroshan, mandando una mail a: info@softwaresicuro.it

Ma occhio, prima che vadano esaurite e sta succedendo velocemente!

In ogni caso, puoi rimanere informato su tutte le soluzioni a questi 10 problemi e loro conseguenze e sui migliori rimedi e strategie per il tuo software, lasciando qui la tua email:

e ricevendo periodicamente articoli come questo nonché informazioni su webinar e corsi sul M.E.D.S.