20 motivi per cui i progetti software falliscono
Ogni progetto software inizia con grandi sogni e grandi visioni. Da qualche parte in un universo alternativo, c’è un progetto che soddisfa ogni sogno, ma troppo spesso i progetti software nel nostro universo inciampano verso il traguardo e talvolta lo attraversano.
Naturalmente, per definizione, il fallimento del progetto software non è una cosa binaria. Puoi finire con un codice che funziona bene ma nessuno usa. Oppure puoi finire con un codice che non verrà nemmeno compilato. A volte puoi salvare qualcosa di utile dal relitto fiammeggiante e talvolta è meglio scappare prima che esploda.
Quando il pasticcio fumante si raffredda, le autopsie iniziano, come la gente vuole sapere cosa è andato storto. Ecco i colpevoli più comuni.
Troppo pochi membri del team
Cercare di fare troppo con troppo pochi programmatori è un problema comune. Gli sviluppatori possono solo macinare così tanto codice prima di bruciare. Una volta ho lavorato in una squadra in cui il manager pensava che il modo giusto per spremere più lavoro dai team agili fosse pianificare ogni “sprint” in modo che iniziasse immediatamente dopo quello precedente. Nessuna pausa riflessiva per capire cosa funzionava e cosa no. Sprint 42 si è concluso mercoledì alle 1: 59pm e Sprint 43 è iniziato mercoledì alle 2: 00pm. Gli incontri di analisi retrospettiva sono stati programmati dopo che il prossimo sprint è già iniziato. Qualche ragazzo intelligente ha suggerito di essere rinominati “maratone” e presto trovato un altro lavoro.
Certo, è difficile sapere quanti programmatori sono sufficienti. A volte blocchi stradali e problemi si mettono in mezzo. Potrebbe non essere colpa del manager che il lavoro raddoppia di dimensioni, ma se non hai abbastanza persone sul posto di lavoro, il tuo progetto è probabilmente condannato.
Troppi membri del team
Se troppo pochi programmatori possono essere cattivi, troppi potrebbero potenzialmente essere peggiori, poiché gli effetti di rete possono rovinare un progetto software. Più persone significa più coordinamento e questo significa più incontri, prendendo tempo lontano dalla scrittura del codice. Ma se non tieni abbastanza riunioni, scoprirai presto che l’API del Team A non interfaccia i microservizi del Team B.
Sarebbe bello se potessimo semplicemente buttare soldi a un problema esagerando un progetto, ma non puoi.
Troppa comunicazione
Scrivere software è un’arte solitaria. Gli esseri umani possono lavorare insieme, ma solo in periodi limitati. Molti sviluppatori odiano le riunioni perché hanno bisogno di spostare i loro ingranaggi mentali dal profondo pensiero logico immersivo alla modalità più aperta e sociale. Ci vuole tempo. Alcuni team leader cercano di combattere il fallimento tenendo più riunioni per mantenere tutti sincronizzati. È uno sforzo nobile ma puoi sentire gli ingranaggi macinare. Il team ha bisogno di condividere informazioni sufficienti per rimanere sincronizzati, ma più semplicemente spreca i cicli cerebrali.
Modifiche di funzionalità fondamentali
In teoria, gli sviluppatori amano considerarsi agili. Ecco perché abbracciano la parola. Ma a volte l’agilità può gettare tutti fuori equilibrio. Tutto dipende se il cambiamento richiede modifiche fondamentali al quadro sottostante. È facile essere agili quando si sposta un pulsante o si cambia un colore. Ma quando si tratta di rielaborare lo schema del database o pasticciare con sharding e replica, non esiste un modo semplice per ruotare con grazia.
Scegliere la tecnologia sbagliata per il lavoro
Anche se si pianifica attentamente e si redige l’elenco corretto delle funzionalità, le cose potrebbero non riuscire se si utilizza la tecnologia sbagliata. I database, ad esempio, sono progettati per essere generali e flessibili, ma presentano limitazioni architettoniche. Spingili a consegnare qualcosa che non sono progettati per fare, e rallenteranno fino a un arresto virtuale quando gli verrà chiesto di scalare. Oppure puoi iniziare con un database NoSQL perché sembrano interessanti solo per scoprire in seguito che hai davvero bisogno di transazioni ACID-grade per mantenere le cose coerenti e il database non le offre. Ops.
Scarsa priorità
I buoni pianificatori redigono un elenco di funzionalità e le danno priorità. Ma a volte le priorità non si allineano con la realtà della loro attuazione. Nel peggiore dei casi, le caratteristiche più importanti sono le più difficili da creare.
Cosa devono fare i tuoi sviluppatori? Se si concentrano sulla funzionalità più importante, non faranno alcun progresso e potrebbero finire per non fornire alcuna funzionalità. Ma se iniziano a buttare giù quelli facili, potrebbero finire con qualcosa che è inutile.
Una buona pianificazione richiede più di una lista di controllo. La visione architettonica deve tenere conto delle esigenze e dei costi di consegna.
La finestra di mercato si chiude
A volte non è colpa del programmatore. Uno dei miei progetti è stato quello di trasformare un libro di riferimento best-seller in un app. Il libro venduto come hotcakes negli anni prima di internet. Il piano era quello di attingere a tale richiesta e creare una versione interattiva che consentisse alle persone di ordinare e cercare tra i dati. Il team di programmazione ha fornito software che includeva tutto nel libro, ma era più veloce, più bello e molto più leggero del libro stesso. Ma nessuno lo voleva più. C’erano abbastanza altre fonti e nessuno aveva bisogno di un’altra app che facesse più o meno la stessa cosa dei siti di notizie ovunque.
A volte un’idea sembra grande, ma il mercato è andato avanti.
Cattive decisioni architettoniche
Su un progetto, mi è stato dato il compito di cambiare un numero in una riga nel database. Quando l’utente ha terminato la registrazione, dovevo aggiungere il numero ID dell’utente all’ultimo ordine. Sembra semplice, giusto? Ma il sistema è stato costruito su un’architettura di microservizi e non ho potuto risolvere questo problema scrivendo una riga di codice che avrebbe detto al database di AGGIORNARE quella colonna. No. Il piano architettonico era quello di aggiungere una nuova chiamata microservice allo stack esistente e anche questo era difficile perché la mia prima chiamata microservice aveva bisogno di attivare un’altra chiamata microservice e così via.
Alla fine, il mago dell’architettura che ha creato questa rete di microservizi mi ha detto che era tutto molto semplice e delineato un percorso serpentino attraverso cinque strati dell’architettura. Il mio compito era aggiungere cinque nuove chiamate API a cinque diversi microservizi, il che significava anche aggiungere cinque serie di test automatici per ogni livello. E ogni API è stata sviluppata da un team diverso nel corso degli anni, richiedendomi di comprendere ed emulare cinque diversi stili di codifica. Tutto per cambiare un numero.
Le decisioni architettoniche possono durare una vita, specialmente se il tuo ego è completamente investito in esse e non puoi cambiarle. I project manager devono essere pronti a notare quando il piano architettonico principale non funziona così grandi decisioni possono essere fatte.
Conflitti politici
Incolpare fattori politici per un guasto tecnico può sembrare sciocco, ma è sempre più vero. Come progetti crescono più grandi e si estendono più organizzazioni, non dovrebbe essere una sorpresa che appaiono fazioni e gruppi fantino per il controllo, le risorse e, infine, il potere.
Le fazioni politiche sono diverse dalle reali differenze tecniche. Ci sono spesso standard tecnici o basi di codice che fanno più o meno la stessa cosa in modi diversi. Prendi XML e JSON. Ora che l’ho digitato, posso sentire i fan di entrambi correre a spiegare perché non sono gli stessi e la loro scelta preferita è quella giusta. Ma quando una parte di una squadra ama una scelta e un’altra tiene la fazione concorrente nella massima considerazione, beh, l’attrito li farà a pezzi.
Questo è diventato ancora più comune in quanto gli architetti suddividono le applicazioni in più servizi e API più piccoli. Diversi gruppi finiranno per controllarli e non andranno sempre d’accordo. Se il gruppo A ama JSON e il Gruppo B si aggrappa a XML, beh, il tuo team dovrà implementarli entrambi o farli cambiare. Tutti e tre sono un dolore per qualsiasi squadra che deve lavorare sia con il Gruppo A che con il Gruppo B.
Scommettere su una tecnologia che non è pronta per la produzione
I programmatori amano gli strumenti e i framework più recenti. Vogliono credere che il nuovo approccio spazzerà via tutto il cruft che impantana la generazione precedente.
Ma spesso la generazione successiva non è pronta per l’uso in produzione. Le nuove funzionalità possono sembrare perfette, ma spesso ci sono lacune che non sono immediatamente evidenti. A volte il codice supporta solo alcuni tipi di file o interfacce con solo pochi database. Gli altri arriveranno presto, ti assicurano, ma il tuo progetto deve essere spedito questo mese e “presto” potrebbe significare sei o più mesi prima che le funzionalità di cui hai bisogno siano complete.
Scommettere su una tecnologia che presto sarà obsoleta
Nella mia esperienza, le vecchie cose sono di solito più affidabili e testate in battaglia, ma ciò non significa che la vecchia tecnologia sia perfetta. Caratteristiche possono mancare che sono vitali per il vostro progetto software una volta che va in diretta. Peggio ancora, scommettere sulla vecchia tecnologia può farti perdere opportunità future basate su cambiamenti lungo la linea. Nuove idee, protocolli e formati di file appaiono e possono non essere implementati. E se qualcuno di una squadra in competizione insiste sul fatto che supporti un nuovo protocollo, la vecchia tecnologia farà male.
Scadenze irrealistiche
Le scadenze sono difficili. Molti progetti hanno bisogno di renderlo al mercato da una particolare stagione o evento. Tuttavia, quando le scadenze vengono scritte per la prima volta, i tuoi sviluppatori non hanno iniziato a scoprire i blocchi stradali e gli ostacoli sulla loro strada. Quindi, se il progetto scivola e l’evento passa senza che il software venga avviato, l’intero progetto viene visto come un errore anche se il codice sta per funzionare senza intoppi. Le scadenze aiutano tutti a concentrarsi e mettere insieme, ma creano anche aspettative che possono essere irrealistiche.
Concorrenza imprevista
Un buon product manager esamina la concorrenza prima di immergersi, ma nessuno può prevedere quale concorrenza possa apparire dal nulla. Se i nuovi concorrenti introducono nuove funzionalità che è necessario duplicare, bene, vedere le sezioni sulle modifiche alle funzionalità e disallineamenti di priorità, sopra.
Accelerare il processo
Molti progetti software iniziano come la visione di una persona o di un team che vuole risolvere qualcosa. Escono con una frase come “Snapchat per Y” o “Uber per Y” e poi si aspettano che il team di prodotto sia reattivo come Snapchat o Uber. Il problema è che capire lo scopo del progetto, disegnare i flussi di dati e immaginare l’interfaccia utente sono spesso dieci volte più lavoro della scrittura del codice. Ma gli imagineers vogliono passare dall’idea al codice subito.
I wireframe, lo schema del database e le storie degli utenti non sono solo ondeggianti, ma una parte essenziale del lavoro. Ma la maggior parte delle persone vogliono credere che un progetto software è solo la scrittura di codice per implementare un’idea.
False credenze nel potere del software
I sognatori hanno spesso credenze irrealistiche nel potere del software di cambiare il mondo. Molti immaginavano che i social media ci avrebbero uniti, ma in qualche modo sono solo linee di faglia esposte che erano sempre ovvie. I progetti software spesso iniziano con piattaforme di diapositive che promettono di rivoluzionare qualche angolo del mondo. Quando spingere i bit in un database non trasforma nessuno, beh, le persone si arrabbiano, si annoiano, si confondono o peggio. Dicono che il software è rotto perché non riesce a fornire la trasformazione magica che tutti si aspettavano.
Molti progetti software possono compilare, passare il QA, spedire e persino ottenere recensioni decenti, ma alla fine non riescono a raggiungere nessuna delle promesse sul ponte scorrevole perché, beh, quelle promesse di cambiamento del mondo sono impossibili.
Subappaltatori malvagi
Amiamo i fornitori che producono le librerie e gli strumenti che ci permettono di creare magia con poche righe di codice. Occasionalmente, ottengono il vento del loro potere e lo usano per distruggere un progetto. Il bilancio per la versione 1.0 era così buono che la direzione non ha esitato ad approvare la versione 2.0. Quindi il venditore decide di spremerci triplicando o quintuplicando il prezzo.
Questo effetto può essere sentito anche quando i venditori non lo fanno apposta. I livelli gratuiti possono rendere un progetto molto economico. Poi, quando la domanda sale e la seconda versione espande la domanda, i prezzi reali calci in.
Cambiamento epocale
In un anno con pandemie e proteste, nulla è cambiato più velocemente dello zeitgeist. Il progetto ha reso una forte protezione della privacy una caratteristica centrale? Ops. La pandemia ha reso tutti interessati a rintracciare i contatti. Qualcuno voleva concentrarsi sui viaggi d’affari? Ops. L’industria alberghiera è crollata. Progetti software più grandi che possono richiedere un anno o più rischiano di essere rovesciati da eventi cataclismici. Quella che sembrava una meravigliosa idea all’inizio può sembrare irrimediabilmente persa e disconnessa quando è il momento di andare in diretta.
Turni tecnici
Non sono solo cambiamenti nel mondo in generale. I cambiamenti di marea nella comunità tecnologica possono avere lo stesso effetto. NoSQL era una volta un’idea geniale che ci avrebbe liberato dallo schema relazionale. Poi qualcuno si è reso conto che i file si gonfiano perché ogni record portava uno schema locale. Un buon team di sviluppo agile può cambiare quando i cambiamenti tecnologici del mare spostano gli atteggiamenti della leadership e dei clienti. Ma anche le squadre più agili non possono affrontare grandi cambiamenti che succhiano tutta l’aria dai loro piani architettonici. Il sistema è stato costruito supponendo che X fosse una grande idea e improvvisamente X è sporco. A volte è meglio farlo saltare in aria e recitare di nuovo.
Troppe aggiunte
Alcuni progetti software iniziano bene e persino spediscono con successo. Poi qualcuno aggiunge una funzione extra o tre, innestando nuovo codice alla versione esistente in un modo che il codice continua a zoppicare lungo. Gli sviluppatori eroici possono tirare fuori questo più volte, soprattutto se l’architetto iniziale pianificato bene. Ma ad un certo punto, la fondazione si sbriciola. Forse il database non può gestire il carico. Forse ci sono troppi join necessari per soddisfare le varie query. Un buon software può diventare troppo grasso, a volte grazie a piccoli miglioramenti che lo hanno spinto oltre il limite.
Moving goal posts
I piani iniziali richiedevano un database per tenere traccia della spesa dei clienti per aiutare con i piani di marketing. Poi qualche genio ha aggiunto una funzione che utilizza l’intelligenza artificiale per correlare la spesa con le previsioni del tempo. O qualcun altro voleva che il software offrisse automaticamente annunci sui motori di ricerca. La modifica della destinazione può capovolgere un progetto.
È raro che le modifiche rovinino le cose da sole. Ma nuovi obiettivi possono rivelare punti deboli e innescare modalità di fallimento. Forse la squadra è ora troppo piccola per completare il progetto con successo. Forse le basi tecniche sono selvaggiamente inefficienti per il nuovo approccio. È difficile per tutti anticipare la combinatoria fastidiosa quando viene presa la decisione di cambiare gli obiettivi.