Indice
Uno dei principali problemi dei progetti di riscrittura completa del software e dei prodotti digitali è che tendono a fallire molto spesso, o comunque quasi sempre diventano più costosi e più lunghi del previsto.
Per quali motivi i progetti di riscrittura di solito costano addirittura più che non creare un nuovo prodotto?
Lo spiego in questa puntata del The CTO Podcast, dove indico come dovrebbe essere strutturato un progetto di questo tipo.
Puoi scaricare il report sul debito tecnico di cui si parla nella puntata all’indirizzo www.debitotecnico.com.
Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.
Trascrizione
Ciao da Alex Pagnoni e benvenuto nel CTO Podcast, il podcast dedicato ai CTO e ai responsabili dei team di sviluppo, a chi vorrebbe diventarlo e a Founder e imprenditori digitali.
Nell’ultima puntata ho accennato al fatto che avrei parlato nei prossimi episodi di alcuni argomenti relativi alle stime nello sviluppo software, tuttavia in una delle precedenti puntate del podcast, la numero 11 di preciso, ho parlato delle situazioni in cui si deve decidere se effettuare il refactoring di un prodotto digitale o se riscriverlo da capo.
Nella puntata è emerso che la maggior parte delle volte bisognerebbe cercare di effettuare il refactoring per via di una serie di motivi che ho spiegato e che i casi in cui vale la pena riscrivere da zero sono pochi.
Però dei casi in cui è utile procedere con una riscrittura completa effettivamente ci sono e alcune persone mi hanno scritto se potevo approfondire questo argomento, perciò ho deciso di dedicare questa puntata del podcast a questo tema.
Uno dei principali problemi dei progetti di riscrittura, infatti, è che tendono a fallire molto spesso, o comunque quasi sempre diventano più costosi e più lunghi del previsto.
Anche in Axelerant negli ultimi anni ci è stato chiesto più e più volte dai clienti di rimpiazzare del codice custom ormai vecchio, dove spesso si trattava di software scritti con linguaggi, framework o paradigmi obsoleti o sconosciuti che pochi degli sviluppatori di oggi conoscono o su cui vogliono metterci mano.
Inoltre, in molti casi si tratta di basi di codice molto al di sotto degli standard attuali di come del software moderno dovrebbe apparire e comportarsi; diciamo che si tratta di codice “vintage”.
Purtroppo è diventato chiaro come rimpiazzare un vecchio sistema è spesso molto più costoso di sviluppare un nuovo prodotto digitale partendo da nuove specifiche.
Ma questo perché succede? Per quali motivi i progetti di riscrittura di solito costano più che non creare un nuovo prodotto?
In breve, questo accade perché, anche sembra paradossale, le aziende e gli utenti non sanno esattamente cosa faccia realmente il loro software.
Per fare capire cosa intendo, questo è un esempio di come procede un tipico progetto di riscrittura di un software già esistente:
- Innanzitutto l’azienda elenca tutte le funzionalità visibili e ufficiali del loro sistema custom.
- Successivamente, il team di sviluppo stima quanto ci potrebbe volere per creare un rimpiazzo del tipo 1:1, duplicando queste funzionalità.
- Poi, il team inizia a sviluppare, ma ben presto scopre che il vecchio sistema faceva molto di più per gli utenti di quello che loro stessi e l’azienda pensavano, ad esempio interagendo con altri software, sistemi, API e integrazioni esterne in modi di cui non erano neanche a conoscenza.
- A questo punto l’azienda decide di aggiungere nuove funzionalità e integrazioni, man mano il budget e i tempi aumentano inesorabilmente, facendo fallire in alcuni casi l’intero progetto.
Quindi, come accade praticamente senza eccezioni, i vecchi sistemi sono molto più complessi di quanto pensano le persone e supportano gli utenti in modi che neanche ci si immaginava.
Questo accade anche perché quando il codice custom aiuta a far funzionare il core business di un’azienda, il modo in cui le persone lo usano tende a crescere organicamente nel tempo e di conseguenza anche le relative funzionalità che vengono implementate man mano.
A quel punto nessuno conosce tutti gli aspetti e i modi in cui gli altri utenti usano quel sistema e come le funzionalità interagiscono tra di loro e con l’esterno.
Perciò i progetti di riscrittura non fanno altro che svelare man mano queste complessità, dopodiché rimangano impantanati in estensioni su estensioni per far sì che tutti gli utenti ottengano ciò di cui hanno bisogno.
Quindi questi progetti tendono a diventare molto incerti e rischiosi.
La soluzione per evitare di rimanere impantanati, a questo punto, è quella di cercare di non pensare in termini di elenchi di funzionalità, ma di approcciare l’intero progetto da un punto di vista orientato agli obiettivi degli utenti.
Quindi, invece di chiederci come possiamo duplicare un software già esistente con un nuovo software scritto con linguaggi e tecnologie moderne, bisogna chiedersi come questo software aiuta gli utenti a raggiungere i loro obiettivi.
Anche se la differenza può sembrare molto sottile, in realtà è estremamente importante ed è peraltro uno degli stessi motivi per i quali nei progetti organizzati in modo moderno e agile si tende a formalizzare gli obiettivi di un nuovo prodotto software tramite il concetto delle user stories, e non dei classici documenti di specifiche con i requisiti funzionali.
Ad esempio, l’obiettivo di un reparto marketing digitale, che è quello di attrarre nuovi clienti tramite Internet, cambia poco nel tempo.
Ma le attività che compiono ogni giorno sono influenzate dalle tecnologie e dagli strumenti che sono a disposizione in quel momento, sia che si tratti di una landing page, di un sito web, di una live chat che prima magari era sul sito e ora è anche tramite WhatsApp o su Messenger, e così via.
Chiaramente chi si occupa del marketing non è interessato a come funziona una landing page, ma è interessato al fatto di portare nuovi lead all’azienda.
Questo si può realizzare con un White paper scaricabile, una landing page o altri strumenti.
Quindi lo strumento può essere uno qualsiasi che fornisce sufficiente valore al business.
Questa separazione che c’è tra gli obiettivi degli utenti e il modo in cui si possono eseguire le attività necessarie per ottenerli in termini di funzionalità offre l’opportunità di ridefinire le funzionalità richieste in un progetto di riscrittura, garantendo di portarsi a casa il vero obiettivo.
Pertanto, la strada migliore è quella di evitare di realizzare una riscrittura pari pari, 1:1.
Invece, la riscrittura di un’applicazione è un ottimo momento per riflettere con spirito critico su ciò di cui l’azienda ha realmente bisogno.
E questo come si può fare?
Innanzitutto, catalogando il più possibile le funzioni del software attuale.
Poi bisogna valutare queste funzioni e astrarne le sottostanti esigenze di business, legando le attività al valore offerto al business.
Bisogna poi dialogare con gli utenti coinvolti per comprendere a fondo quali sono gli obiettivi di alto livello che il vecchio prodotto li aiutava a raggiungere.
Basandoci poi su ciò che abbiamo appreso, bisogna farsi alcune domande. Innanzitutto se abbiamo realmente bisogno di ciò che pensiamo di avere bisogno. Oppure se c’è un modo per ristrutturare il business per essere più efficienti e consentirci di scrivere e usare meno software, ad esempio migliorando un processo aziendale.
Se si parte con gli obiettivi degli utenti, quello che si può scoprire e che in molti casi varie funzionalità del software esistente possono essere combinate, riviste o addirittura eliminate completamente.
Bisogna poi pensare a come il nuovo software possa sostituire quello vecchio con rilasci a fasi, pezzo dopo pezzo, ad esempio lavorando a iterazioni incrementali in cui si consegna continuamente del software funzionante.
Questo è l’approccio che consente di convalidare progressivamente il valore del nuovo sistema ed eventualmente correggerlo prima che sia troppo tardi.
L’alternativa è di aspettare mesi o anni prima di vedere un ritorno dall’investimento, e questo è troppo rischioso per la maggior parte delle imprese.
Mettendo invece gli utenti nelle fasi iniziali dello sviluppo del nuovo software, aumentano considerevolmente le probabilità di avere successo e allo stesso tempo ci si libera dalla gabbia di dover replicare in modo esatto tutte le vecchie funzionalità.
Allo stesso tempo si può così fornire un approccio che può servire in modo efficace le aziende e i loro utenti e che può essere gestito per molte versioni e cicli o iterazioni di lavoro.
Nel report strategico che ho scritto sul debito tecnico, che puoi scaricare gratuitamente dal sito www.debitotecnico.com, tratto più in profondità questi argomenti, che peraltro aiutano a ridurre la necessità di dover riscrivere da capo un software seguendo una serie di criteri e metodi.
Grazie per aver ascoltato questa puntata del podcast dedicata a come evitare i tipici fallimenti a cui si va incontro quando si riscrive del software da zero.
Se vuoi approfondire questo argomento o vuoi riportare la tua esperienza, oppure se vuoi suggerire un argomento per le prossime puntate, puoi scrivere nel gruppo Facebook del podcast cercando CTO Mastermind su Facebook, oltre a scaricare il report gratuito su www.debitotecnico.com.
Se invece hai bisogno di supporto per valutare un progetto di riscrittura, puoi scrivermi tramite il modulo di contatto.
Come promesso, nei prossimi episodi parlerò dei temi relativi alle stime nello sviluppo di nuove funzionalità, e visto quanto è vasto e importante questo argomento probabilmente dedicherò nel tempo varie puntata.
Grazie di nuovo e al prossimo episodio, ciao da Alex.
