Estate 2019
Servizi - Applicazioni
 

26/10/2015

Share    

Alla ricerca del miglioramento

Chi si occupa di sviluppo software oggi in Italia, negli staff IT delle aziende utenti o presso fornitori, ha ben presente quali sono i percorsi da fare per dare più efficienza alle proprie attività. Si sconta però ancora molta ‘artigianalità’ e una pesante sottovalutazione di alcuni aspetti critici.

Quali sono i problemi aperti nelle strutture che si dedicano allo sviluppo software? Questa la curiosità principale che ha guidato un'indagine condotta dalla redazione di Office Automation. Per fare questo ci siamo rivolti a un campione molto eterogeneo, ovvero fatto da: responsabili di ‘fabbriche del software’ attive presso aziende utenti; strutture di sviluppo di software house italiane di qualsiasi dimensione e che operano in mercati diversificati, quindi non solo il classico gestionale; piccoli o grandi system integrator che realizzano in outsourcing personalizzazioni e customizzazioni per clienti finali. Un panorama diversificato di aziende, che però oggi hanno tutte il problema di aumentare l’efficacia della loro risposta al business sia inteso come aziende cliente sia inteso come utenti interni. Dalla nostra indagine, a cui hanno risposto 174 rappresentanti delle diverse tipologie di aziende selezionate, emerge una realtà bivalente. Certamente c’è una forte consapevolezza, nella maggioranza delle aziende intervistate, di quali sono i passi necessari da implementare per migliorare le cose, dall’altra invece una parte consistente del campione, seppur minoritaria, sconta ancora un approccio molto artigianale al tema della gestione dello sviluppo e in alcuni casi non manca anche una certa sottovalutazione di alcune criticità. Vediamo comunque di seguito i risultati raccolti grazie alla nostra indagine.

Dati e considerazioni

La prima domanda rivolta al nostro campione è stata: “Qual è il numero di rilasci software effettuati dalla vostra organizzazione?”, grazie alle risposte raccolte possiamo iniziare a individuare la composizione dimensionale del nostro campione. Il 44,25% degli intervistati (77 risposte su 174) ha infatti dichiarato che la sua organizzazione focalizzata sulle attività di sviluppo software ha una media di 5 rilasci al mese. Questa secondo gli esperti, tenendo presente che il dato proiettato sull’anno totalizza oltre 50 rilasci, denota il fatto che tali strutture fanno riferimento ad organizzazioni di media e piccola dimensione, intese sia come strutture di sviluppo interne ad aziende più grandi, sia come società esterne che sviluppano in outsourcing per conto terzi. Il 22,41% del campione (39 intervistati) ha risposto invece ‘altro’, e andando a controllare quanto ognuno ha effettivamente specificato si può dire che prevalentemente questo campione è fatto da aziende/organizzazioni ancora più piccole (34 risposte), ovvero caratterizzate anche da uno o due rilasci al mese; mentre solo 5 intervistati hanno dichiarato un valore che va oltre il limite massimo proposto nelle risposte (300 rilasci al mese, ovvero oltre 3.000 sviluppi all’anno): in tre hanno dichiarato oltre 500 rilasci mese e in due oltre 1.000.
Per quanto riguarda invece le altre risposte: il 20,11% del campione ha dichiarato 10 rilasci al mese, un valore che gli esperti identificano come struttura interna/società esterna di medio livello; l’8,62% 50 rilasci/mese (organizzazioni che iniziano ad avere una certa consistenza); il 3,45% 100 rilasci/mese e l’1,15% 300 rilasci al mese.
La struttura del campione di questa indagine può quindi essere così suddivisa: un 35% circa del campione che fa riferimento a strutture di sviluppo interne/software house di medie e grandi dimensioni e il restante 65% del campione che fa riferimento a organizzazioni medio/piccole (analisi risultati domanda 1).

Una conferma di quanto estrapolato dalle risposte alla prima domanda arriva anche dalle risposte relative alle piattaforme utilizzate per lo sviluppo applicativo. Il 10,47% del campione lavora esclusivamente su piattaforma mainframe e il 25% invece sia con mainframe sia con ambienti distribuiti, mentre il restante 64,53% degli intervistati è focalizzato sullo sviluppo esclusivamente in ambienti distribuiti. Questo non significa che esiste una corrispondenza stretta tra ambienti distribuiti e società o strutture di sviluppo interne medio/piccole; non è così perché infatti anche molte grandi software house italiane protagoniste del gestionale, per esempio, lavorano esclusivamente con ambienti distribuiti, e così anche molte grandi aziende operative nel nostro Paese. Così come non è detto che coloro che intervengono su piattaforma mainframe siano sempre delle strutture o delle società di grandi dimensioni. Fatte salve queste considerazioni, queste risposte ci danno una conferma in generale sulla struttura del campione già emersa nella precedente domanda, ma ci confermano anche come la presenza dell’ambiente mainframe sia ancora significativa e importante nel panorama dell’IT italiano (analisi risultati domanda 2).


Qual è invece il tempo medio necessario per mettere in produzione un nuovo rilascio software? E’ questa la terza domanda rivolta al nostro campione che ha così risposto: il 29,19% del campione ha dichiarato che i tempi medi di rilascio dei propri sviluppi vanno da due ai tre giorni, e questi certamente identificano strutture interne o società di software di piccole dimensioni, ovvero che vanno difficilmente oltre le quattro persone. Il 45,96% parla invece di un tempo di rilascio medio dalle due alle tre settimane, e il 24,85% da due a tre mesi. Più aumenta la complessità degli ambienti sui quali bisogna intervenire e più è necessario un attento lavoro di pianificazione, e questo è anche valido quando si interviene su applicazioni mission critical o comunque rilevanti. In queste condizioni sono coloro che sicuramente hanno risposto un tempo medio di due o tre mesi, ma anche buona parte delle strutture che mettono in produzione i nuovi rilasci software con tempi che vanno dalle due alle tre settimane (analisi risultati domanda 3).


Dopo queste prime domande di inquadramento utili a tracciare un primo profilo del campione, l’indagine proposta da Office Automation ha iniziato ad approfondire delle problematiche caratteristiche di alcuni dei temi che caratterizzano la vita delle organizzazioni dedicate allo sviluppo software.
Il primo aspetto trattato non poteva quindi che essere una valutazione sulla criticità relativa alla ‘coda’ degli sviluppi. Ben il 41,29% del campione ha dichiarato che la coda degli sviluppi è nella norma, mentre il 33,55% dichiara che la coda è sicuramente migliorabile, ma la sua ‘lunghezza’ non rappresenta una criticità eccessiva. Solo il 18, 06% del campione ha dichiarato che la coda dei lavori in sviluppo da evadere è ‘decisamente migliorabile’, mentre il 7,1% degli intervistati lavora in una realtà nella quale tutti gli sviluppi vengono evasi in maniera tempestiva e quindi non vi è coda.
Se fosse vero che solo meno di un quinto del campione vede nella coda degli sviluppi una criticità da risolvere, allora non si spiegherebbero alcuni dei dati che emergono nelle risposte successive. Da questa risposta sembra emergere una situazione in cui se non del tutto risolta, la coda degli sviluppi rappresenta comunque una problematica facilmente gestibile (analisi risultati domanda 4).


Una situazione secondo noi, questa volta più realisticamente positiva è quella che si configura dalle risposte alla domanda 5, ma purtroppo dalle stesse si palesa anche una forte sottovalutazione della problematica affrontata. Alla nostra domanda “Oggi il vostro processo di rilascio software è automatizzato e tracciato?” il 53,95% del campione ha risposto positivamente, mentre la restante parte del campione che ha risposto ‘no’ si è così suddivisa: il 17,11% del campione ha riconosciuto che questa mancanza è un problema, mentre invece ben il 28,95% ha invece affermato che l’assenza di un processo automatizzato che tiene traccia dei rilasci software non è affatto un problema.
Ci permettiamo di dissentire fortemente con quella parte del campione che ha espresso questo ultimo parere. La tracciatura del perché, del come e da chi vengono implementate delle modifiche sulle applicazioni aziendali e/o dei clienti è un punto ritenuto fondamentale che assolutamente deve essere messo in campo, anche se si fanno pochi rilasci all’anno. Certamente non si può gestire in modo efficiente questa attività senza un minimo di automazione, e vista la difficoltà a mettere in atto mun processo di questo tipo, siamo convinti che in tutte e tre le categorie del campione che si sono delineate attraverso le tre risposte proposte ci sia ancora una forte componente di ‘artigianalità’. Ovvero le modifiche vengono tracciate manualmente con strumenti di base quali fogli elettronici o anche semplici messaggi mail.
Poiché a chi ha risposto no, in entrambi i casi, abbiamo chiesto di dare una spiegazione delle loro risposte ci permettiamo di dire che non sono ammissibili, nel caso di chi ritiene che la tracciatura e l’automazione del rilascio del software non è un problema, giustificazioni del tipo: “Trattandosi di uso interno non considero un problema la mancanza di automazione” oppure “Perché lo sviluppo software è un processo artigianale, non ripetibile e non sottoponibile a miglioramento continuo e il suo successo dipende interamente dalle persone fisiche che interpretano il processo”. La nostra obiezione più forte a queste affermazioni sta nel fatto che riteniamo che il processo di sviluppo per essere efficiente, coerente e consistente nel tempo debba comunque essere implementato con una logica industriale. E se è sicuramente vero che dipende molto dalla qualità delle persone, cosa succede all’attività di sviluppo di uno staff interno o di una software house quando i migliori programmatori si ammalano? Come la mettiamo con le consegne al business e/o ai clienti?... Queste sono considerazioni che pensiamo debbano essere sempre ritenute valide in tutte le tipologie e le dimensioni degli ambienti di sviluppo, soprattutto quelli più piccoli.
Positive le giustificazioni di chi invece dichiara come la mancanza di automazione e tracciabilità del processo di rilascio rappresenti invece un problema rilevante. Tra i tanti perché che contestualizzano questo giudizio segnaliamo: “La mancanza di tracciabilità e automazione provoca spreco di tempo e lavoro e penalizza l’autorevolezza e la credibilità di chi sviluppa, soprattutto nei confronti dei clienti”; “Si perde il controllo sugli aggiornamenti”; “Perché la manualità porta a errori e perdite di tempo”; “Scarsa qualità del rilascio finale, con effetti su costi, tempi e difettosità in produzione”; oppure semplicemente: “Come può non essere un problema?” e via andare altre decine di commenti su questo tono… Tali considerazioni fatte da singoli rappresentanti di aziende utenti dimostrano una piena consapevolezza delle problematiche che caratterizzano la gestione di ambienti di sviluppo che cercano di mantenersi sempre allineati con le richieste del business e/o delle aziende clienti (analisi risultati domanda 5).


Infine è stato chiesto quali sono le sfide che gli intervistati si trovano ad affrontare nella gestione dei processi di rilascio degli sviluppi software. Il fatto che al primo posto con un consistente 24,31% del campione, quasi un quarto degli intervistati, risulti la risposta “rispetto dei tempi di rilascio” è sinceramente ‘molto scioccante’. C’è dunque un problema di allineamento con le esigenze del business non di poco conto e alla luce di questo risultato le risposte date alla domanda 4 sembrano ora cadere fortemente in contraddizione. Delle due l’una: o le code degli sviluppi non sono un problema che incide sui tempi di consegna del codice, e questa sarebbe una novità; o in molti staff IT dedicati alle applicazioni si considera il ritardo una ‘normalità’ da gestire in maniera più o meno diplomatica con i propri committenti interni e/o esterni.
La seconda sfida più popolare, che ha raccolto il 20,14% del campione è “rendere automatizzato il processo di rilascio”, aspetto oggi trascurato e da molti non considerato. Si può interpretare il fatto che questa fetta del campione intenda fare un salto di qualità da strumento più artigianali come i fogli elettronici a soluzioni di management più o meno sofisticate che portano a una maggiore industrializzazione nel processo di sviluppo. Al terzo posto si posiziona la sfida del “rilascio da effettuare su ambienti target multipli”, con il 18,06%. A seguire poi: la “mancanza di visibilità sull’intero processo di sviluppo” (14,58%) e la “mancanza di consistenza e di ripetibilità dl processo” (11,81%). Più bassa la “gestione di eventuali rollback a fronte di fallimenti nel rilascio” (6,94%). Anche se le percentuali non sono alte la considerazione che si può fare guardando complessivamente ai numeri emersi dalle risposte a questa ultima domanda è che una fetta significativa delle aziende o delle organizzazioni che si occupano di sviluppo software oggi sono alla ricerca di un significativo ‘salto di qualità’ (analisi risultati domanda 6).

 

TORNA INDIETRO >>