Quando si prende in mano un progetto con cui un team precedente ha fallito, la prima intenzione può essere quella “gettiamo tutto alle ortiche e rifacciamo tutto daccapo.”

Il rischio è quello di commettere gli stessi errori, facendo lo stesso percorso, senza approfittare dell’esperienza precedente.

Occorre quindi dialogare con il cliente e possibilmente con qualcuno del team precedente e capire quali sono state le cause del fallimento.

Vi diranno di tutto: rimostranze e cose dettate dal dispiacere. Ma se state attenti probabilmente vi riveleranno quali problemi hanno davvero fatto andare male tutto.

Altri indizi possono essere raccolti usando il software “fallito”: badando ai problemi di UI/UX, alle macchinosità, evitando di concentrarsi sui malfunzionamenti.

Quest’ultima analisi vi farà venire dozzine di idee per far meglio: valutatele giudicandovi duramente e paragonandole a quelle che avete avuto “col foglio bianco”. Serviranno di entrambi gli approcci.

Del maiale non si butta via nulla: se i dati sono stati ben strutturati o meno, se ci sono dati di prova e di produzione, probabilmente sono organizzati meglio dei dati precedenti e possono accelerare il lavoro.

Avere discusso col team precedente vi avrà comunicato anche i comportamenti delle persone che hanno condotto al fallimento: se tra questi ci sono atteggiamenti del cliente inaccettabili, mettete la questione avanti prima di cominciare.

Siate aperti ed eviterete il fallimento, sfruttando le cose buone che sono sempre presenti in qualsiasi progetto: non mettere il cappello d’asino a chi è stato prima di voi a risolvere un problema vi farà soltanto del bene.