Perché il settore IT non è in grado di fornire rapidamente progetti grandi e senza errori come in altri settori?

498

Dopo aver visto le serie MegaStructures di National Geographic, sono rimasto sorpreso dalla rapidità con cui sono stati completati i progetti di grandi dimensioni. Una volta che il lavoro preliminare (design, specifiche, ecc.) Viene fatto su carta, la realizzazione stessa di progetti enormi richiede solo pochi anni o qualche mese .

Ad esempio, Airbus A380 " lanciato ufficialmente il 19 dicembre 2000 "e" all'inizio di marzo 2005 ", l'aereo era già stato testato. Lo stesso vale per enormi petroliere, grattacieli, ecc.

Confrontando questo con i ritardi nell'industria del software, non posso fare a meno di chiedermi perché la maggior parte dei progetti IT sono così lenti o, più precisamente, perché non possono essere altrettanto veloci e impeccabili, alla stessa scala, dato abbastanza persone? p>

Progetti come l'Airbus A380 presentano entrambi:

  • Principali rischi imprevisti: mentre questo non è il primo aeromobile costruito, spinge ancora i limiti della tecnologia e le cose che hanno funzionato bene per aerei di linea più piccoli potrebbero non funzionare per quello più grande a causa di vincoli fisici; allo stesso modo, vengono usate nuove tecnologie che non erano ancora state utilizzate, perché ad esempio non erano disponibili nel 1969 con Boeing 747.

  • Rischi connessi alle risorse umane e alla gestione in generale: persone che smettono nel bel mezzo del progetto, incapacità di raggiungere una persona perché è in vacanza, errori umani ordinari, ecc.

Con tali rischi, le persone continuano a realizzare progetti come quelli di grandi aerei di linea in un periodo di tempo molto breve e nonostante i ritardi di consegna, questi progetti hanno ancora un enorme successo e una qualità elevata.

Quando si parla di sviluppo del software, i progetti non sono tanto grandi e complicati come un aereo di linea (sia dal punto di vista tecnico che in termini di gestione), e presentano rischi meno imprevisti dal mondo reale.

Tuttavia, la maggior parte dei progetti IT sono lenti e tardivi e l'aggiunta di altri sviluppatori al progetto non è una soluzione (a partire da un team di dieci sviluppatori fino a duemila a volte consente di consegnare il progetto più velocemente a volte no, a volte danneggia solo il progetto e aumenta il rischio di non completarlo affatto.

Quelli che vengono ancora consegnati spesso contengono molti bug, che richiedono service pack consecutivi e aggiornamenti regolari (immagina di "installare aggiornamenti" su ogni Airbus A380 due volte a settimana per correggere i bug nell'originale prodotto e impedire che l'aeromobile si schianti).

Come possono essere spiegate tali differenze? È dovuto esclusivamente al fatto che l'industria dello sviluppo software è troppo giovane per poter gestire migliaia di persone su un singolo progetto al fine di fornire prodotti su larga scala e quasi impeccabili molto velocemente?

    
posta Arseni Mourzenko 07.10.2017 - 16:49
fonte

31 risposta

-2

C'è una spinta attiva e resistenza da parte degli sviluppatori di software per migliorare il processo di sviluppo del software. La raccolta dei requisiti viene respinta in quanto non realistica e comporta sempre un cambiamento, il che significa che la documentazione è sempre scaduta.

D'altra parte, anche i metodi agili sono resistiti. Si presume che le uscite giornaliere e il refactoring costante siano consentiti solo per le squadre che hanno più tempo e budget.

Non c'è garanzia di una cultura del professionista. La cultura e i processi degli ingegneri del software variano da azienda a società e questo è uno dei problemi. Non puoi fare affidamento su uno standard minimo accettato diverso da "puoi codificare qualcosa nella lingua X usando le librerie A, B, C e farlo finire entro martedì?"

Questa mancanza di professionalità e resistenza attiva al professionismo è ciò che causa i bug. Difficilmente possiamo convincere la gente a fare revisioni periodiche del codice anche se ci sono numerosi studi che dimostrano quanto siano efficaci nel ridurre il numero di bug in un prodotto. Difficilmente riusciremo a documentare il loro codice che può portare a nuovi bug e portare a giorni sprecati lungo la strada quando tutti hanno dimenticato esattamente cosa il codice dovrebbe fare e perché è stato costruito in quel modo.

    
risposta data 05.07.2013 - 18:37
fonte