Blog

Aug 15, 2023

Creazione e acquisto di ottimi software per la produzione di metalli

scanrail/iStock/Getty Images Plus Il software sta diventando sempre più rilevante e fondamentale per il moderno fab shop. Che tu stia sviluppando codice internamente o acquistando uno strumento di terze parti, lo è

scanrail/iStock/Getty Images Plus

Il software sta diventando sempre più rilevante e fondamentale per il moderno fab shop. Che tu stia sviluppando codice internamente o acquistando uno strumento di terze parti, è importante capire cosa stai cercando. Ciò può essere difficile senza una conoscenza approfondita di come viene realizzato il software.

Healthcare.gov rappresenta un caso di studio facilmente accessibile sui rischi della progettazione del software. È stato lanciato 10 anni fa ed è immediatamente atterrato con un tonfo. È stato così lento e problematico che solo l'1% delle persone interessate è riuscito a iscriversi nella prima settimana. Il web design non è riuscito a fornire i principi fondamentali assoluti, con flussi di lavoro scadenti e interfacce utente difettose. Per finire, il sito ha fornito ai fornitori di assicurazione sanitaria informazioni inesatte, rendendo difficile o addirittura impossibile gestire correttamente le iscrizioni.

Gli stress test che avrebbero dovuto esplorare il volume di utenti previsto erano del tutto inadeguati. Un giorno prima del lancio, si è riscontrato che il sito era diventato troppo lento con solo 1.100 utenti simultanei. Il numero di utenti previsto era compreso tra 50.000 e 60.000. Come se ciò non bastasse, il numero effettivo di utenti simultanei è salito a 250.000 nella prima settimana, oltre 200 volte il numero di utenti che gli stress test pre-rilascio indicavano che il sito poteva gestire. In retrospettiva, ci si chiede perché siano stati eseguiti gli stress test. Il loro evidente fallimento non ha fatto nulla per cambiare la tempistica del rilascio.

Il progetto non è inciampato per mancanza di budget. Inizialmente si stimava che il costo fosse di 93,7 milioni di dollari, una somma sbalorditiva anche se il progetto non avesse superato il budget. Ma le stime erano assolutamente errate. Prima del completamento, il costo totale raggiunse la sbalorditiva e strabiliante cifra di 1,7 miliardi di dollari, quasi 20 volte superiore a quanto stimato.

Healthcare.gov funziona alla grande nel 2023, ma al momento del lancio è stato forse il fiasco software più spettacolare, costoso e pubblico della storia. Sebbene gran parte della complessità legata al lancio di Healthcare.gov fosse inevitabile, possiamo sfruttare il suo lancio pasticciato per esplorare ciò che fa sì che i progetti software abbiano successo o falliscano. I suoi fallimenti potrebbero fornire informazioni su come creare il proprio team software interno. Potrebbe anche fornire informazioni su cosa cercare quando si acquista software di terze parti.

In un articolo precedente, ho scritto di come la Southwest Airlines sia andata in pezzi durante le vacanze del 2022. In poche parole, la società si affidava a un software vecchio di decenni che rendeva estremamente difficile gestire le interruzioni della programmazione. I lavoratori capivano il problema, ma i dirigenti aziendali, isolati dal dolore operativo quotidiano, non sono riusciti per decenni a investire in nuove infrastrutture. Quel fallimento, combinato con una tempesta invernale e un’elevata domanda stagionale, ha causato il blocco dell’intera azienda, bloccando decine di migliaia di persone nella settimana di Natale. La stessa Southwest stima che il disastro alla fine costerà all’azienda quasi 1 miliardo di dollari. Quella spesa straordinaria avrebbe potuto essere evitata se i decisori fossero stati abbastanza vicini ai problemi operativi da comprenderne l’urgenza.

La lezione è che un buon software è sviluppato da team vicini. Una buona vicinanza implica due cose: in primo luogo, che il team del software abbia una profonda familiarità con il problema che sta cercando di risolvere; in secondo luogo, gli sviluppatori sono vicini ai risultati prodotti dal loro software. In altre parole, un team con una buona prossimità comprende il dolore e quindi utilizza il proprio strumento software per alleviarlo. Se il software non raggiunge l'obiettivo o è difettoso o difficile da usare, gli sviluppatori dovrebbero essere i primi a scoprirlo.

Questa è un’area in cui il progetto Healthcare.gov ha sicuramente fallito. Gli sviluppatori potrebbero aver compreso i problemi per cui il loro sito Web era stato progettato per risolvere, ma l'appaltatore principale operava dal Canada, non dagli Stati Uniti, il paese servito da Healthcare.gov. Diversi componenti dell'intero sistema furono inoltre ceduti a molti subappaltatori, nessuno dei quali avrebbe posseduto l'intera applicazione. Anche se gli sviluppatori avessero compreso il problema che il software avrebbe dovuto risolvere, l'esperienza dell'utente end-to-end sarebbe stata fermamente al di fuori del controllo di ogni singolo sviluppatore di software.