Progetti software: l’insuccesso non andrebbe contemplato

F.L. -

Eppure solamente uno su tre arriva a compimento. Ci si sfianca in pagine di requisiti, si perde tempo, denaro e non ci si allinea con la realtà. Ne parla Valentino Magri di Micro Focus.

Dice Valentino Magri, Regional Solutions Consulting Team Manager – Ig&Me di Micro Focus di aver sentito recentemente il Ceo di una delle più importanti istituzioni finanziarie al mondo dichiarare di essere “un’azienda di software, travestita da banca“.

Bella sintesi che serve a dire che tutto il business ormai si fonda sul software. «Oggigiorno se non creiamo esattamente quello di cui gli utenti necessitano, rischiamo di essere inefficaci – dice Magri -. In qualità di professionisti It, dobbiamo saper gestire i nostri esperti di tecnologia imprenditori e fornitori e assicurarci di soddisfare appieno le richieste dei nostri utenti».

Uno su tre ce la fa
Ma le statistiche sono implacabili: solamente il 32% dei progetti software ha successo. Il dato è tanto preoccupante quanto vero.

Un recente studio illustra la storia dei progetti software di successo: in alcune aree demografiche, l’amministrazione pubblica ha leggermente ridotto il tasso di insuccesso, mentre le organizzazioni bancarie hanno registrato un numero maggiore di insuccessi. La sanità è l’unico settore ad aver ottenuto un autentico miglioramento, tutti gli altri sono peggiorati.
L’andamento è precipitato in molti settori, mentre il settore pubblico e manifatturiero sono i soli ad essere migliorati, ma con un margine molto esiguo.

Negli scorsi 18 mesi, dice Magri «abbiamo monitorato i processi di sviluppo del software in oltre 150 aziende di tutto il mondo. Le tendenze emerse dai nostri dati indicano che definire e gestire le richieste software, e la capacità di rispondere rapidamente ai cambiamenti, sono ancora le principali e antiche problematiche che tormentano il settore It di pubbliche amministrazioni, aziende private e realtà commerciali».

La gabbia delle specifiche
Per ottenere risposte dal business, rivela il manager, molte organizzazioni dipendono ancora da metodologie antiquate: scrivono 200 pagine di specifiche di requisiti software che nessuno poi legge, passano tali descrizioni agli sviluppatori che non le comprendono, quindi gli sviluppatori cominciano a progettare ciò che i project manager presumono sia in linea con il business.
Per tali progetti, che possono essere considerati un successo, gli utenti vi diranno che solo il 67% di quanto richiesto è contenuto nella release. Si continua a tollerare questo trend, probabilmente perché corrisponde a precedenti standard offerti in ambito di sviluppo del software e perché ormai ci si è abituati ad accettare la mediocrità come un dato di fatto.

«In qualità di professionista – si chiede Magri – ha senso che per un terzo del nostro tempo non siamo in grado di fornire ciò che i clienti ci richiedono?».
Nel biennio 2008-2010, i team responsabili del software hanno registrato un tasso di miglioramento dei progetti pari al 26%; le nuove statistiche relative al successo dei progetti mostrano che il 50% di questi fallisce, «il che è imperdonabile, e dunque perché continuiamo a tollerarlo? Devo ancora trovare un’organizzazione che non sia esposta alle sfide legate al successo dei progetti software. In quanto professionisti dell’It, una delle nostre missioni dovrebbe essere quella di risolvere definitivamente il problema del successo dei progetti software, visto che siamo responsabili della loro gestione. Successo significa sviluppo di tutto ciò che è richiesto dall’utente, non solo il 67%. Ho riscontrato davvero troppa mediocrità nei progetti tecnologici, ad esempio il ritenere che il lavoro svolto sia sufficiente per ora; e che l’importante sia realizzare il progetto. Dobbiamo invece considerare quel sufficiente alla stregua di un fallimento».

Meglio la Pa
Per Magri bisogna ammettere che almeno le amministrazioni pubbliche hanno raggiunto alcuni risultati significativi, in numero maggiore rispetto alle loro controparti commerciali. Ma c’è ancora molta strada da fare.
E ci sono problemi specifici per i responsabili It dell’amministrazione pubblica: spesso vengono supervisionati partner che svolgeranno il lavoro di sviluppo, pertanto comunicare in modo efficace potrebbe essere un requisito significativo.
Come favorire il successo
Le cause più evidenti dei fallimenti risiedono nella mancanza di collaborazione e nell’assenza di rilevanza per il business.

La chimera della qualità del software
Come può un’organizzazione migliorare la collaborazione e perseguire gli interessi aziendali?
Già da molto tempo il mercato parla di Software Quality; ma cos’è cambiato?
«Nei nostri profili aziendali – rivela Magri – abbiamo ottenuto risultati tangibili in termini di riduzione dei costi, time-to-market e soddisfazione dell’utente nel momento in cui l’organizzazione ha implementato nuove tecniche di simulazione interattiva dei requisiti software, consentendo agli utenti aziendali di visualizzare e convalidare, subito e frequentemente. Sono un forte sostenitore del metodo Agile, e capisco profondamente che un’iterazione non è necessariamente l’applicazione completa. Il punto è che le aspettative dell’utente sono gestite dinamicamente e allineate attraverso il processo Agile: vediamo pertanto risultati di gran lunga migliori nella soddisfazione in queste richieste, laddove l’organizzazione ha implementato tecniche Agile. Se si stanno utilizzando correttamente i principi Agile, il business è parte di questo processo ed è in grado di comprendere e adattarsi o meno alle sfide poste dallo sviluppo del software».

Per Magri le amministrazioni pubbliche devono andare oltre la convinzione tale per cui le tecniche Agile non fanno per loro: questa è un’interpretazione obsoleta.
Nei fatti, il Software Engineering Institute, un centro di ricerca e sviluppo con sede presso la Carnegie Mellon University, sta pubblicando una serie di informazioni riguardanti l’uso dell’Agile. Non bisogna soffermarsi ai luoghi comuni: sperimentare Agile potrebbe davvero aiutare a mantenere alcuni dei progetti fuori dalle hit list.

Gli analisti parlano di costruire a priori la qualità. «In realtà – conclude Magri – sono 25 anni che ne sentiamo parlare nell’ambito dello sviluppo del software; ora, finché non è ancora un procedimento troppo complesso o costoso da effettuare, si dovrebbe convincere i team preposti ad abbandonare processi superati, andare oltre il caos iniziale, inevitabile nella fase transitoria, e focalizzarsi sugli utili che potrebbero generarsi».

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome