L’ANALISI

Budget IT limitati? Come e dove virare al meglio le risorse

I suggerimenti di Idc per migliorare notevolmente il ciclo di vita dello sviluppo software con una spesa contenuta. “Piccoli investimenti possono creare una leva sufficiente per realizzare cambiamenti reali”

Pubblicato il 13 Gen 2023

software

Investimenti “piccoli”. Ma in grado di creare una leva sufficiente a dare una svolta all’azienda. Si concentra sui fronti strategici per l’innovazione il focus di Idc che punta a migliorare il ciclo di vita dello sviluppo del software anche in presenza di un limitato budget IT.

Predictability e creazione di nuovo valore aziendale

Secondo il dossier, la premessa è che un’organizzazione sana – anche con budget IT limitati – deve concentrarsi sulla creazione di nuovo valore aziendale. Analizzando i tipi di attività su cui i team dedicano il proprio tempo, sarà possibile identificare le aree di miglioramento. Miglioramenti che creeranno ulteriore capacità e/o margine di budget per sviluppare e implementare più modifiche che apportano valore all’organizzazione.

Sul fronte del cambiamento del ciclo di vita dello sviluppo del software, la predictability è fondamentale. Il confronto con altri team presenti sul mercato chiarirà gli aspetti da migliorare e quelli già ben posizionati. Queste informazioni aumenteranno la prevedibilità delle iniziative di sviluppo del software e faranno un uso migliore delle risorse. Emblematico il caso Ncoi, uno dei principali fornitori di formazione permanente in Europa, che con l’aiuto di Idc Metri ha analizzato la produttività del team nearshore che si occupava della manutenzione del sistema amministrativo centrale. Entro sette mesi il team ha potuto raggiungere gli stessi risultati con un terzo del numero di persone e ha permesso all’azienda di reindirizzare circa 250mila euro al mese dalla manutenzione allo sviluppo di nuovo valore di business.

Migliorare la prioritization of value

Serve poi introdurre una migliore definizione delle prioritization of value fornendo ai proprietari dei prodotti una visione più dettagliata delle funzionalità che apportano valore all’organizzazione, sia a lungo che a breve termine. Nella maggior parte delle organizzazioni di sviluppo di applicazioni agile, i proprietari dei prodotti sono (implicitamente) responsabili della creazione di software value senza una solida base su cui lavorare. Aiutarli in questo senso farà sì che l’azienda ottenga le funzionalità di cui si necessita per servire meglio i clienti, e il portafoglio IT rimarrà comunque “future proof”.

Approccio Software Value Map

Inoltre è possibile “addestrare” i proprietari del prodotto a lavorare con l’approccio Software Value Map. Le organizzazioni che hanno collaborato con Idc Metri hanno affrontato ogni requisito da 2-4 diverse prospettive di valore. In questo modo, tutte le prospettive di valore vengono bilanciate in modo che non solo vengano rilasciate nuove funzionalità di business, ma ci sia anche sufficiente attenzione alla prevenzione/riduzione del debito tecnico, all’utilizzo delle risorse infra (cloud) e all’innovazione di prodotto. Ciò porta a proprietari di prodotti e team soddisfatti delle funzionalità che offrono e della architectural runaway con cui potranno lavorare.

Evitare le sovrapposizioni

Ancora, serve creare una visione migliore del proprio portafoglio in modo da evitare dependecies, rielaborazioni e sovrapposizioni non necessari alle priorità. Ciò fornirà informazioni dettagliate sulle dependencies e sui possibili rischi per i vantaggi aziendali. Questa strada aiuterà l’azienda a prendere decisioni mirate nell’assegnazione delle risorse e si tradurrà in un punto di partenza basato sui fatti per migliorare la solidità del portafoglio.

Fondamentale anche passare dal reinventare al ripetere, facilitando i team in modo che possano trarre vantaggio dal lavoro degli altri. Una volta che si ha a disposizione una visione approfondita del portfolio, è infatti possibile identificare gli elementi costitutivi comuni nel portfolio che possono avvantaggiare più team. Dopo aver identificato questi tipi di elementi costitutivi, è perfino possibile dedicare un team alla parte comune dell’architettura. Quando il responsabile IT e il team inizieranno a esaminare quali elementi costitutivi o microservizi contiene l’architettura aziendale, la mentalità dei team passerà dal re-inventare soluzioni per un problema comune all’uso ripetuto di una soluzione comune già creata. Questo modo di pensare non solo aumenterà la produttività, ma creerà anche un patrimonio comunque a cui tutti i team potranno attingere.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!


Aziende


Argomenti


Canali

Articoli correlati

Articolo 1 di 5