Tutti i progetti software iniziano con grandi sogni e grandi visioni. Da qualche parte in un universo alternativo, c’è un progetto che soddisfa ogni vostro sogno, ma troppo spesso i progetti software nel nostro universo inciampano nel loro percorso verso il traguardo finale o, nel peggiore dei casi, non vengono nemmeno portati a termine. Ecco le principali cause che portano al loro fallimento.

Troppi pochi membri del team

Cercare di fare troppo con pochi programmatori è un problema comune, anche perché gli sviluppatori prima o poi si “esauriscono”. Una volta ho lavorato in un team di sviluppo in cui il manager pensava che il modo giusto per spremere più lavoro fosse programmare ogni “sprint” in modo che iniziasse immediatamente dopo quello precedente. Nessuna pausa ponderata per capire cosa funzionasse e cosa no. Lo Sprint 42 si era concluso mercoledì alle 13:59 e lo Sprint 43 era cominciato mercoledì alle 14:00.

Non mi sono stupito più di tanto quando alcuni membri del team hanno preferito cambiare aria. Certo, è difficile sapere quanti programmatori siano sufficienti e potrebbe non essere colpa del manager il fatto che il lavoro raddoppi per dimensioni, ma se non avete fin dal principio abbastanza sviluppatori nel vostro team, è probabile che il vostro progetto sia già condannato in partenza.

Troppi membri del team

Se troppi pochi programmatori possono essere dannosi, averne troppi potrebbe essere potenzialmente peggio. Più persone significano infatti più coordinamento e questo significa più incontri, che rubano tempo prezioso alla scrittura del codice. Ma se non organizzate abbastanza riunioni, potreste presto scoprire che l’API del team A non si interfaccia con i microservizi del team B. Sarebbe bello se potessimo semplicemente risolvere un problema aumentando il numero di sviluppatori (e quindi spendere di più), ma non si può.

Troppa comunicazione

Scrivere software è un’arte solitaria. Gli 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 in una modalità sociale più aperta. Questo richiede tempo. Alcuni team leader cercano di combattere l’ipotesi del fallimento del progetto tenendo più riunioni per mantenere tutti sincronizzati. È uno sforzo nobile, ma il team ha bisogno di condividere solo le informazioni sufficienti per rimanere sincronizzato e non di essere sovrastato da incontri e riunioni.

Modifiche fondamentali alle funzionalità

In teoria, agli sviluppatori piace considerarsi agili, ma a volte l’agilità può far perdere l’equilibrio. È facile essere agili quando si sposta un pulsante o si cambia un colore. Ma quando si tratta di rielaborare lo schema di un database o di mettere mano a intere feature, non esiste un modo semplice per farlo senza causare altri problemi.

Scegliere la tecnologia sbagliata per il lavoro

Anche se pianificate attentamente ed elaborate un elenco corretto di funzionalità, le cose potrebbero andare male se usate la tecnologia sbagliata. I database, ad esempio, sono progettati per essere flessibili, ma presentano limiti architetturali. Spingeteli a fornire qualcosa per cui non sono stati progettati e quando gli verrà chiesto di scalare andranno in crisi. Oppure potreste iniziare con un database NoSQL perché sembra interessante, solo per scoprire in seguito che avete bisogno di transazioni ACID per mantenere le cose coerenti e il database non le offre.

Priorità sbagliate

I bravi pianificatori redigono un elenco di funzioni e danno ad esse una certa priorità. Ma a volte le priorità non si allineano alla realtà della loro attuazione. Nel peggiore dei casi, le funzionalità più importanti sono le più difficili da creare. Cosa devono fare allora i vostri sviluppatori? Se si concentrano sulla caratteristica più importante, non faranno progressi e potrebbero non offrire alcuna funzionalità. Ma se iniziano a sbarazzarsi di quelli facili, potrebbero finire con qualcosa di inutile. Una buona pianificazione richiede più di una checklist. La visione architettonica deve tener conto delle esigenze e dei costi di consegna.

La finestra del mercato si chiude

A volte non è colpa del team manager. Uno dei miei progetti è stato quello di trasformare un libro di grande successo dell’era pre-Internet in un’app. Il piano era di creare una versione interattiva che consentisse alle persone di cercare tra i dati del libro. Il team di programmazione ha realizzato un’app che includeva l’intero libro e che permetteva una sua consultazione in modo più veloce, piacevole e leggero. Peccato solo che il libro stesso non interessasse più a nessuno. C’erano infatti altre fonti a cui attingere e nessuno aveva bisogno di un’altra app che facesse quasi la stessa cosa di decine di siti. A volte un’idea sembra grandiosa, ma se in quella finestra temporale il mercato non è più recettivo sono guai.

Cattive decisioni architettoniche

In un progetto mi è stato assegnato il compito di modificare 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, vero? Ma il sistema è stato costruito su un’architettura di microservizi e non sono riuscito a risolverlo scrivendo una riga di codice per dire al database di AGGIORNARE quella colonna. No. Il piano architettonico era quello di aggiungere una nuova chiamata di microservizio allo stack esistente e anche questo era difficile perché la mia prima chiamata di microservizio doveva innescare un’altra chiamata di microservizio e così via.

Alla fine chi ha creato questa rete di microservizi mi ha detto che era tutto molto semplice e ha delineato un percorso tortuoso attraverso cinque strati dell’architettura. Il mio compito era quello di aggiungere cinque nuove chiamate API a cinque diversi microservizi, il che significava anche aggiungere cinque serie di test automatizzati 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. I project manager devono essere pronti a notare quando il piano architettonico principale non funziona.

Scommesse su una tecnologia che non è pronta per la produzione

I programmatori adorano i più recenti strumenti e framework e vogliono credere che il nuovo approccio spazzerà via tutta la generazione precedente. Ma spesso la nuova generazione 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 infatti il codice supporta solo pochi tipi di file o interfacce con pochi database. Il vostro progetto deve essere consegnato questo mese e potrebbero volerci sei o più mesi prima che le funzionalità di cui avete bisogno siano complete.

Scommesse su una tecnologia che sarà presto superata

Nella mia esperienza le vecchie cose sono di solito più affidabili, ma ciò non significa che la vecchia tecnologia sia perfetta. Possono mancare funzionalità che sono vitali per il vostro progetto software una volta attivo. Peggio ancora, scommettere su una vecchia tecnologia può farvi perdere opportunità future tra nuove idee, protocolli e formati di file che non possono essere implementati.

Scadenze non realistiche

Le scadenze sono difficili da rispettare. Molti progetti devono arrivare sul mercato per una particolare stagione o evento. Tuttavia, quando le scadenze vengono decise per la prima volta, i vostri sviluppatori non hanno ancora scoperto i problemi e gli ostacoli sulla loro strada. Le scadenze aiutano tutti a concentrarsi e a lavorare con il necessario impegno, ma creano anche aspettative che possono essere non realistiche.

Concorrenza imprevista

Un buon product manager controlla sempre la concorrenza prima di impegnarsi in un nuovo progetto, ma nessuno può prevedere un competitor che sbuca improvvisamente dal nulla. Se i concorrenti introducono nuove e interessanti funzionalità che volete portare nella vostra applicazione, bisogna essere pronti e agili per implementarle, con però tutto quello che ne consegue a livello di deadline e di nuove feature impreviste da aggiungere.

Accelerare il processo

Molti progetti software iniziano come la visione di una persona o di un team che vuole sistemare qualcosa. Il problema è che capire l’ambito del progetto, disegnare i flussi di dati e immaginare l’interfaccia utente richiede spesso dieci volte più lavoro che scrivere il codice. Ma i “visionari” vogliono passare subito dall’idea al codice perché credono (erroneamente) che i progetti software riguardino semplicemente scrivere codice per implementare un’idea.

Troppe aggiunte

Alcuni progetti software iniziano bene e arrivano anche ad avere successo. Quindi qualcuno aggiunge una o due funzionalità extra e certi sviluppatori possono farlo più volte, specialmente se l’architetto iniziale del progetto ha pianificato le cose per bene. Ma a un certo punto qualcosa può iniziare a crollare. Forse il database non è in grado di gestire il carico, o forse ci sono troppi JOIN necessari per soddisfare le varie query.

Allontanarsi dall’obiettivo primario

I piani iniziali di un software richiedevano un database per tracciare la spesa dei clienti per aiutare con i piani di marketing. Quindi alcuni “geni” hanno aggiunto una funzionalità che utilizza l’intelligenza artificiale per correlare la spesa con le previsioni del tempo. Oppure qualcun altro vuole che il software faccia automaticamente offerte per gli annunci sui motori di ricerca. La modifica dell’obiettivo originario di un software può rovinare completamente un progetto, con le nuove aggiunte che possono rivelare punti deboli e portare a seri problemi. Il team infatti potrebbe essere troppo piccolo per completare con successo il progetto o forse le basi tecniche si rivelano del tutto inefficienti per il nuovo approccio.