Tredici anni di audit di progetti software portano a una conclusione chiara: i progetti non falliscono per sfortuna, falliscono a causa di tredici errori che sono
Si ripetono. Quattro sono legate alla pianificazione (ambito aperto, team sbagliato, scadenza impossibile, budget basato sulla fiducia). Quattro sono legate all'esecuzione.
(Nessun test, nessuna documentazione, debito tecnico fin dal primo giorno, decisioni prese per consenso). Cinque sono problemi di governance (nessun responsabile chiaro, comitati).
(Nessun processo decisionale, metriche vaghe, nessun criterio di accettazione, cambiamenti costanti senza priorità). Individuare questi problemi nelle prime due settimane previene il 90% (un codice fiscale spagnolo).
del costo.
La letteratura sulla gestione dei progetti software è ricca di best practice. Ciò che manca è l'onestà riguardo agli errori. Dopo tredici anni di analisi di progetti bloccati o falliti, abbiamo identificato tredici errori che si ripetono in quasi tutti i casi. Conoscerli per nome ci permette di individuarli nelle prime due settimane, quando possono ancora essere corretti a un costo ragionevole. Individuarli al sesto mese costa dalle 5 alle 20 volte di più.
Li raggruppiamo in tre categorie: errori di pianificazione, errori di esecuzione ed errori di governance.
Errore 1 · Ambito aperto firmato come chiuso. Il contratto parla di "implementazione CRM", ma non specifica quali moduli, integrazioni o livello di personalizzazione siano inclusi. Ciascuna parte ritiene di aver firmato un accordo diverso. La discussione su cosa sia incluso e cosa no inizia al terzo mese e non finisce mai. Soluzione: definire l'ambito del progetto modulo per modulo, con risultati espliciti.
Errore 2 · Attrezzatura errata per il tipo di progetto. Assumi Big
Quattro per un MVP veloce è inefficiente. Assumere un freelance per un
Un sistema critico regolamentato è rischioso. Assumere una boutique senior per un
I piccoli lavori sono costosi. La scelta del fornitore determina il risultato.
rispetto a qualsiasi altra metodologia.
Errore 3 · Scadenza impossibile da rispettare a causa di pressioni commerciali. Il cliente ha bisogno
“"Per giugno" perché ha un annuncio confermato. Il fornitore
Firma pur sapendo che è impossibile perché ha bisogno del contratto. Il progetto
L'uscita era prevista per settembre, ma l'annuncio non va a buon fine e tutti si incolpano a vicenda.
Soluzione: stimare onestamente ed escludere l'impossibile.
Errore 4 · Budgeting basato sulla fede. Stime di “più o meno”
Questo senza una suddivisione in tappe, senza piani di emergenza e senza criteri per le modifiche.
Quando il progetto devia di 30% nel secondo mese, non c'è modo di
Per determinare se è ragionevole o catastrofico. Soluzione: stima dettagliata da
modulo con buffer firmato.
Errore 9 · Nessun responsabile del progetto chiaramente identificato presso il cliente. Eventi
dove “il progetto riguarda la tecnologia ma anche le operazioni, anche
"di marketing e anche di vendite". Quando tutti sono proprietari,
Nessuno lo è. Le decisioni vengono rimandate, le consegne subiscono ritardi.
Rimangono non convalidati e il progetto rallenta. Soluzione: un singolo
Responsabile con reale autorità fin dal primo giorno.
Errore 10 · Comitati senza potere decisionale. Riunioni bisettimanali
con quindici persone dove nessuno ha il potere di prendere decisioni che
Sono importanti. Servono per informare, non per decidere. Soluzione: riunioni di
Decisioni separate dagli incontri informativi, con procura firmata.
Errore 11 · Metriche vaghe o assenti. “Che funzioni bene e che gli utenti siano contenti” non è una metrica. Senza metriche oggettive, la decisione di
“"È finito" dipende dall'umore di chi lo legge. Soluzione: metriche dichiarate prima del primo commit, misurate settimanalmente.
Errore 12 · Nessun criterio di accettazione firmato. Il progetto entra nella fase di test senza una definizione concordata di "accettato".
Infinite discussioni sul fatto che il bug X sia bloccante o meno. Soluzione: criteri di accettazione firmati all'inizio del modulo, prima di avviarlo.
Errore 13 · Cambiamento costante senza priorità. Ogni settimana il cliente aggiunge nuovi requisiti senza rimuoverne alcuno dal backlog. Il progetto cresce senza
Né i tempi né il budget dovrebbero aumentare. Altrimenti la situazione precipiterà. Soluzione: una politica di modifiche concordata, in cui è possibile aggiungere qualcosa, ma ciò implica la rimozione di qualcos'altro.
oppure estendere la scadenza e il budget.
Le prime due settimane di un progetto sono le più importanti. Se durante questo periodo vengono rilevati tre o più dei tredici errori previsti, il progetto è a rischio.
a rischio, e dobbiamo fermarci prima di andare avanti. Cinque domande che puoi porre in una riunione di 60 minuti:
Se la risposta a tre o più domande è "no" o "per niente", devi fermarti e
risolvere prima di andare avanti.
No, ma i costi si riducono significativamente quando i problemi vengono identificati tempestivamente. Il progetto perfetto non esiste. Un progetto ben gestito è quello che individua gli errori in settimane, non in mesi.
Nella nostra esperienza, l'errore 1 (oscilloscopio aperto) e l'errore 9 (nessun proprietario chiaro) sono i più costosi perché amplificano tutti gli altri.
Non da sole. Un'implementazione agile scadente può trasformarsi in "Scrum senza disciplina" e riprodurre tutti gli stessi errori sotto un nome diverso. La disciplina conta più della metodologia.
Esistono strumenti (SonarQube, CodeClimate) che forniscono metriche oggettive. L'importante è misurarlo fin dal primo giorno, non scoprirlo al sesto mese.
Quando il costo stimato per il completamento supera il valore atteso dei risultati, si tratta di una decisione difficile ma a volte necessaria. L'abbiamo consigliata ai clienti che ci hanno incaricato di svolgere attività di revisione contabile.
Sì, è proprio questa la sua funzione. Un audit di 10 giorni con TCG analizza i tredici errori individuati e fornisce un breve report che evidenzia quelli più critici per il progetto specifico.
Una diagnosi onesta: cosa si può salvare, cosa va riscritto, cosa va fermato. A volte, andare avanti con uno sforzo maggiore costa più che rifare solo una parte.
La decisione dipende dal caso specifico e dovrebbe essere presa con una prospettiva esterna.
I progetti software non falliscono a causa della tecnologia scelta o della sfortuna. Falliscono a causa di una combinazione prevedibile di errori.
Pianificazione, esecuzione e governance. Conoscere i tredici errori per nome permette di individuarli in tempo e correggerli mentre sono ancora presenti.
È possibile. Se il vostro progetto individua tre o più problematiche, è consigliabile un audit esterno prima di investire ulteriori risorse.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
