Navigare l’era dell’oro dell’AI: Svelare i costi nascosti del debito tecnico nelle imprese

Nel corso dell’ultimo anno, l’intelligenza artificiale ha catturato l’attenzione dei leader aziendali, spingendoli ad accelerare gli investimenti in aziende di AI o a velocizzare l’introduzione dei propri prodotti per stare al passo. Tuttavia, nella fretta di unirsi a questa nuova era di progresso tecnologico, le organizzazioni che sono nuove all’AI potrebbero non considerare un fattore importante che dovrebbe essere al centro dell’attenzione quando si investe o si creano nuovi prodotti AI: il debito tecnico.

Sebbene l’idea di debito tecnico non sia nuova, la tecnologia AI comporta un tipo diverso di debito tecnico rispetto ai servizi software regolari. E poiché l’AI continua a migliorare rapidamente, sta causando la crescita di questo importante problema.

Cosa è il debito tecnico?

Il debito tecnico, nella definizione più semplice, è l’accumulo di codice di bassa qualità durante la creazione di un pezzo di software. Ciò deriva generalmente da una timeline di go-to-market accelerata per soddisfare le esigenze aziendali o per ottenere qualcosa sul mercato più velocemente per ottenere un feedback più rapido dai clienti. Quando si considera il debito tecnico, è importante concentrarsi sull’aspetto deliberato, poiché i responsi delle decisioni sono spesso consapevoli dei rischi con il software e degli impatti di prendere scorciatoie per la velocità. L’emergere dell’AI ha portato a una sfida diversa e unica quando si tratta di debito tecnico, e con essa rischi e conseguenze significativi che potrebbero derivarne.

Man mano che i sistemi AI iniziano a invecchiare e i loro dati di training diventano inaccurati e superati, il costo di investire in AI adesso supera il tempo e l’investimento necessari per mantenere dati di training di alta qualità, altrimenti noti come igiene dei dati.

Esaminiamo come il debito tecnico si accumula, l’impatto che ha sul fondo e come le organizzazioni possono porvi rimedio.

Come le organizzazioni acquisiscono il debito tecnico?

  Ci sono due modi in cui il software può accumulare il debito tecnico. Uno è attraverso il semplice codice scadente. Le organizzazioni possono acquistare prodotti o ereditarli attraverso l’attività di fusioni e acquisizioni, solo per scoprire in seguito problemi di qualità oltre a tassi di modifica e innovazione lenti. L’altro è quando i leader scelgono deliberatamente di assumere il debito tecnico.

Quando si tratta di AI, più del 72% dei leader vuole adottare l’AI per migliorare la produttività dei dipendenti, ma la principale preoccupazione sull’implementazione dell’AI è la qualità e il controllo dei dati. Sembra controproducente per un’organizzazione utilizzare un prodotto promosso per aumentare la produttività, mentre allo stesso tempo distrae il tempo dalle attività vitali per affrontare tutti i problemi di qualità causati dal debito tecnico che potrebbero compromettere la produttività. Ma la promessa del payoff finale per una maggiore produttività supera questi ostacoli nel prossimo futuro, che alla fine tornerà a perseguitare il software nel lungo termine.

Deriva del modello: un nuovo tipo di debito tecnico

Con l’emergere di maggiori investimenti in AI, le organizzazioni hanno accelerato le strategie di go-to-market per sfruttare la miniera d’oro dell’AI generativa. Sebbene ciò possa funzionare come un driver di entrate a breve termine, le organizzazioni stanno trascurando ciò che potrebbe accumulare una grande quantità di debito tecnico in futuro, noto come deriva del modello.

La deriva del modello si verifica quando le prestazioni di un sistema AI iniziano a diminuire e le uscite diventano meno accurate man mano che i dati di training invecchiano. Guardando il ciclo di vita dell’AI, è ovvio che i dati di training dovranno essere continuamente mantenuti e aggiornati per garantire che le risposte fornite dalla macchina siano il più accurate possibili: è qui che inizia il problema. Quando si affrettano a ottenere soluzioni, i responsi delle decisioni spesso depotenziano questioni come l’ottenimento di ulteriori dati di training, la manutenzione dell’igiene dei dati del sistema e la garanzia che ci sia una forza lavoro sufficiente per supportare queste attività.

Man mano che i dati di training continuano a invecchiare e le lacune tra realtà e uscite si allargano, le organizzazioni saranno lasciate con costi e tempo aumentati per affrontare queste lacune che avrebbero potuto essere evitate con una pianificazione e procedure adeguate.

L’impatto del debito tecnico sul fondo

Il debito tecnico può anche impattare profondamente sull’efficienza organizzativa — ad esempio, consideriamo i team di vendita. Quando il debito tecnico inizia a crescere e il tasso di modifica rallenta, diventa sempre più difficile per i rappresentanti di vendita attirare i clienti, il che rallenta i tassi di chiusura e inevitabilmente i flussi di entrate come risultato.

Oltre alle vendite, il debito tecnico impatta anche notevolmente sui team di sviluppo. Non solo richiederà più tempo dedicato all’aggiornamento del codice, ma l’attenzione deviata effettivamente mette in secondo piano l’innovazione. Spostando l’attenzione e il tempo sulla manutenzione, la roadmap del prodotto diventa ritardata o abbandonata, creando un effetto a catena che potrebbe alla fine risultare in una mancanza di fiducia tra il lato tecnico e commerciale dell’azienda. Senza una roadmap del prodotto da seguire, i team di vendita sono lasciati con promesse rotte o nulla da mostrare ai potenziali clienti, nuovamente impattando notevolmente sulle entrate.

Come affrontare il debito tecnico

Man mano che la prevedibilità della consegna diminuisce, le organizzazioni inizieranno a vedere il crollo dell’efficienza organizzativa, portando a conversazioni su come affrontare le sfide in atto. Ci sono due modi in cui i responsi delle decisioni possono utilizzare per combattere il debito tecnico. Il primo è gettare via la piattaforma e il codice interamente e ripiattaformare, o incorporare piccoli cambiamenti incrementali, simili a pulire lentamente una stanza uno per uno, per eventualmente portare i sistemi alla velocità.

Il primo metodo, la ripiattaformazione, richiede un completo ribaltamento dei sistemi e rappresenta un enorme e costoso rischio da correre. Simile a un processo di costruzione su larga scala, eventuali ritardi nella pianificazione possono far deragliare le tempistiche del prodotto e potrebbero far fallire l’intero sforzo. Questo metodo può funzionare a volte, però. Prendiamo ad esempio LinkedIn – dopo il suo IPO nel 2011, l’azienda ha ripiattaformato il sito e adesso è un grande giocatore nel mercato.

La scommessa più sicura, fare piccoli cambiamenti che alla fine si sommano a miglioramenti significativi, è un altro caso d’uso per argomentare. Con gli sviluppatori che già interagiscono con i dati quotidianamente, entrare per apportare piccole modifiche può mettere in forma i sistemi per liberarli dal debito tecnico. Ciò beneficia anche le competenze degli sviluppatori, poiché richiede loro di rimanere aggiornati con gli ultimi standard di codice e tecnologia, il che a sua volta prepara un’organizzazione per il successo tecnico poiché ci sono meno lacune nelle competenze. Implementare un’iniziativa guidata dagli ingegneri, in cui vengono allocati il 20% del loro tempo per pianificare gli aggiornamenti del prodotto, è un ottimo modo per iniziare. Sebbene questo processo sia molto più lento della ripiattaformazione, è meno rischioso e comunque produce valore per il modello di business.

Lasciare il debito tecnico alle spalle nell’era dell’AI

Man mano che lo spazio AI continua a svilupparsi rapidamente, continueremo a vedere più soluzioni emergere che vantano guadagni di produttività e efficienza organizzativa. Sebbene ciò sia vero, i responsi delle decisioni devono dare priorità all’integrazione di tecniche come la manutenzione continua dei dati e pensare alla grande quando si tratta del ciclo di vita della soluzione. Investire in AI non deve essere costoso e schiacciante, e con alcuni piccoli cambiamenti nella pianificazione e nella strategia di go-to-market, è possibile evitare la prossima montagna di debito tecnico.