Perché molti progetti digitali falliscono prima ancora di essere sviluppati

Ogni anno vengono spesi miliardi di euro per costruire prodotti digitali che, di fatto, non avrebbero dovuto essere costruiti. Non perché siano fatti male: spesso il codice è pulito, l'infrastruttura solida, l'interfaccia presentabile. Il problema è più a monte. Il prodotto risolve il problema sbagliato. O lo risolve nel modo sbagliato. O risolve il problema giusto per le persone sbagliate.

È un fallimento difficile da raccontare, perché non lascia macerie visibili. Non c'è un crash, non c'è una violazione di sicurezza, non c'è un articolo sui giornali. C'è solo un prodotto che esiste, viene lanciato, e non succede quello che doveva succedere: gli utenti non lo adottano, le metriche non si muovono, il fatturato atteso non arriva.

E quando si va a cercare la causa, quasi sempre la si trova nello stesso punto: nelle settimane prima della prima riga di codice.

C'è una convinzione tenace nel mondo aziendale: che la parte costosa di un progetto digitale sia lo sviluppo. È una convinzione comprensibile — gli sviluppatori sono visibili, le ore-uomo sono fatturabili, i preventivi parlano la lingua del codice. Ma è anche una convinzione che porta sistematicamente a sottovalutare la fase più importante: quella in cui si decide cosa costruire.

Il dato più citato, e ancora oggi più vero, viene da uno studio storico di Barry Boehm degli anni '80: il costo di correggere un errore aumenta di un ordine di grandezza ogni volta che si avanza di una fase. Un errore individuato in fase di requisiti costa 1. Lo stesso errore in design costa 5. In sviluppo, 10. In QA, 20. Quando arriva in produzione, può costare fino a 100 volte tanto.

I numeri esatti variano a seconda dei contesti — su progetti piccoli e ben gestiti la curva è molto più piatta — ma il principio resta intatto e oggi più rilevante che mai: più tardi scopri che hai sbagliato, più cara paghi la correzione. E le correzioni più costose, in assoluto, non riguardano singole feature: riguardano l'aver costruito l'intero prodotto attorno a un'ipotesi sbagliata.

Per questo la domanda strategica non è "quanto ci costerà sviluppare?", ma "quanto ci costerà scoprire troppo tardi che abbiamo sviluppato la cosa sbagliata?". È una domanda meno comoda, perché non si presta a un preventivo, ma è quella su cui si gioca davvero il ROI di un progetto digitale.

Il punto di partenza tipico, in un progetto digitale aziendale, è un documento di requirements. Una lista di funzionalità, spesso lunga, scritta da chi commissiona il progetto — talvolta con il supporto di consulenti, talvolta no — e consegnata al team di sviluppo come specifica da realizzare. È una pratica così diffusa da sembrare ovvia, ed è una delle prime cause di fallimento dei progetti digitali.

Il problema non è che il documento sia mal scritto. È che, nella stragrande maggioranza dei casi, il documento contiene la lista delle soluzioni che lo stakeholder ha già immaginato, non la lista dei problemi che il prodotto dovrebbe risolvere. È un salto logico apparentemente innocuo, ma rovinoso: chi scrive i requirements ha già fatto, da solo, il lavoro di product design. Solo che lo ha fatto senza dati, senza utenti, e spesso senza esperienza specifica.

Il CHAOS Report dello Standish Group, che da quasi tre decenni studia gli esiti dei progetti software, ha sempre identificato tra le tre cause principali di fallimento la mancanza di un coinvolgimento reale degli utenti e la scarsa qualità dei requirements. Nell'edizione più recente, basata sull'analisi di circa 50.000 progetti, solo il 31% dei progetti viene considerato pienamente riuscito.

La conseguenza è prevedibile: il team di sviluppo riceve specifiche dettagliate per costruire qualcosa che non risolve un problema verificato. Le costruisce bene. Le consegna in tempo. E poi nessuno le usa. Il progetto figura come "completato con successo" sui report interni, mentre il prodotto, in produzione, non muove nessuna delle metriche per cui è stato finanziato.

La discovery è la fase in cui un team prova a rispondere a tre domande prima di mettere mano al codice: chi ha questo problema, quanto spesso lo ha, e cosa sta facendo oggi per risolverlo? È il lavoro che separa un'ipotesi da una decisione informata. Eppure, in moltissimi progetti, viene saltata o ridotta a una formalità.

Le ragioni sono quasi sempre politiche, raramente tecniche. La discovery è invisibile a chi guarda da fuori: non produce schermate, non produce codice, non produce qualcosa che assomigli a un avanzamento. Produce decisioni — il tipo di output più difficile da difendere in una riunione di status, perché non si può fotografare. Eppure è il momento in cui si determina se il progetto, alla fine, avrà senso o no.

Saltare la discovery è una scelta che si paga sempre, prima o poi. Si paga in tre modi: build-time sprecato (mesi di sviluppo su feature che andranno riscritte o cestinate), opportunità mancate (il problema vero, quello che gli utenti avevano davvero, è rimasto irrisolto), e credibilità interna (la prossima volta che si proporrà un progetto digitale, qualcuno ricorderà l'ultimo).

C'è una metrica, citata spesso da Marty Cagan nel suo lavoro sui prodotti digitali, che vale la pena interiorizzare: in media, più della metà delle idee che un team prova a sviluppare non funziona. Non perché il team sia incompetente, ma perché la maggior parte delle ipotesi — anche quelle plausibili, anche quelle scritte da persone esperte — non sopravvive al contatto con la realtà degli utenti. Un processo serio di discovery non elimina questo problema: lo intercetta presto, quando ancora costa poco.

Una delle distorsioni più radicate nei progetti digitali è il framing per feature. La conversazione iniziale, in molte aziende, suona così: "vogliamo un sito con un configuratore prodotto, una dashboard utente, una sezione blog, un sistema di prenotazione integrato e una chatbot". Sono richieste plausibili. Sembrano concrete. Eppure, prese così, sono già un sintomo del problema.

Una feature è una soluzione. E ogni soluzione presuppone un problema sottostante che qualcuno, da qualche parte, ha già diagnosticato. Quando una feature arriva in cima al brief senza il problema che la giustifica, sta succedendo una di tre cose: il problema esiste, ma non è stato esplicitato (e quindi non si potrà verificare se la feature lo risolve davvero); il problema è stato dato per scontato (e quindi non è stato testato); oppure il problema non c'è, e la feature è stata richiesta per imitazione di un competitor o per pressione interna di qualche dipartimento.

Il framing per problemi, invece, parte da un'altra domanda: "qual è la cosa specifica che gli utenti oggi non riescono a fare, o fanno male, e che ci impedisce di vendere/fidelizzare/ridurre il costo del supporto?". La risposta a quella domanda non è quasi mai una feature. È un comportamento, un percorso, un punto di attrito. E solo dopo averlo capito si può decidere — con più di un'ipotesi sul tavolo — qual è la soluzione di design che lo affronta meglio.

La differenza è enorme dal punto di vista del rischio. Costruire una feature presuppone che la soluzione sia già stata trovata. Costruire intorno a un problema lascia aperta la possibilità che la soluzione vera sia più semplice, più piccola, o completamente diversa da quella inizialmente immaginata. E quasi sempre, a posteriori, lo è.

Lo strumento che, da solo, riduce di più il rischio di un progetto digitale non è una nuova metodologia, né un framework, né uno stack tecnologico. È il prototipo. Inteso non come schermata graficamente curata, ma come simulazione interattiva sufficiente a far provare un'esperienza a una persona vera prima che il codice esista.

Il prototipo serve a una cosa precisa: trasformare opinioni in dati. Dentro un'azienda, di fronte a uno schermo, sei persone con ruoli diversi possono passare ore a discutere di "come dovrebbe funzionare il flusso di onboarding". Tutti hanno opinioni legittime, tutti hanno argomenti. Quella discussione non porta mai a una decisione robusta, perché non ha un arbitro esterno. Mettere il prototipo davanti a cinque utenti reali e guardarli usarlo per quindici minuti chiude la conversazione in modo definitivo.

Il dato di Nielsen è uno dei più citati e dei meno applicati nel settore. Bastano cinque sessioni per intercettare la grande maggioranza dei problemi di un'interfaccia. Cinque sessioni costano, in tempo e denaro, una frazione minima di una sprint di sviluppo. Eppure moltissimi progetti arrivano in produzione senza che il prodotto sia mai stato messo davanti a un utente che non lavorasse per l'azienda che lo ha commissionato.

C'è un'altra cosa che il prototipo fa, e che è meno discussa ma altrettanto importante: allinea gli stakeholder interni. Quando una decisione viene presa guardando insieme un utente che si blocca su un certo passaggio, smette di essere una decisione di gusto e diventa una decisione di evidenza. La conversazione cambia di natura. Le riunioni diventano più corte. Il "secondo me" lascia spazio al "abbiamo visto che".

I progetti digitali che funzionano hanno un tratto in comune che si nota subito: il lavoro di design e prodotto comincia prima dello sviluppo, non in parallelo o dopo. Non è una questione di gerarchia interna, è una questione di sequenza delle decisioni. Le scelte di design sono scelte di prodotto. Le scelte di prodotto sono scelte di business. Farle bene significa farle nell'ordine giusto.

Concretamente, questo si traduce in alcune abitudini riconoscibili. Si parte dai problemi degli utenti, non dalle feature: il documento iniziale del progetto descrive cosa non funziona oggi, prima di descrivere cosa si vuole costruire. Si fanno interviste prima del kickoff: anche solo cinque o sei conversazioni con utenti tipo cambiano radicalmente le priorità del progetto rispetto a come erano state immaginate al primo brief.

Si prototipa prima di stimare: la stima di sviluppo arriva su un flusso testato, non su un brief. Questo riduce drasticamente le sorprese in corso d'opera e i ticket di "chiarimento" che si accumulano nelle prime sprint. Si dà al design un budget esplicito di iterazione: non viene trattato come una mano di vernice da applicare alla fine, ma come la fase in cui si scartano le ipotesi sbagliate quando ancora costano poco scartarle.

Le aziende che lavorano così non sembrano più lente: spesso lo sembrano, all'inizio del progetto, perché il primo pixel arriva qualche settimana dopo. Ma poi non rifanno il prodotto sei mesi dopo il lancio. Non lo cancellano dopo un anno. Non lo riprogettano daccapo perché "non ha funzionato come ci aspettavamo". Il tempo che sembrano perdere all'inizio è esattamente il tempo che gli altri perdono dopo.

Ogni progetto digitale fallito è, in fondo, lo stesso progetto: qualcuno ha deciso troppo presto cosa costruire. Lo ha deciso senza dati, senza utenti, senza alternative sul tavolo. Lo ha scritto in un documento di requirements e lo ha passato a chi doveva costruirlo. E quando il prodotto è arrivato in produzione, si è scoperto che la decisione presa al mese zero — la più importante di tutte — era stata anche quella presa con meno informazioni in assoluto.

Non è un problema di sviluppatori, di metodologia, di stack tecnologico, di budget. È un problema di sequenza delle decisioni. Discovery prima dei requirements. Problemi prima delle feature. Prototipi prima dello sviluppo. Utenti prima degli stakeholder.

Chi inverte questa sequenza non sta scegliendo di andare più veloce. Sta scegliendo, ogni volta, di pagare il conto più tardi e a un prezzo molto più alto. E quasi sempre, a quel punto, il conto non si paga in soldi: si paga in prodotti che esistono ma non servono a nessuno.