Gestire progetti è un lavoro serio

Project Manager: “Quanto ci vuole per sviluppare questo nuovo sito?”

Dev Team: “Abbiamo fatto una stima di massima con le (poche) informazioni che abbiamo: circa 6 mesi”

Project Manager: “E’ troppo, non posso dire al clienti che ci vorrà così tanto tempo. Gli dirò 3 mesi, sono sicuro che siete stati larghi con le stime come sempre. E poi c’è Mario che ci può aiutare con gli sviluppi se abbiamo bisogno, quindi i tempi si riducono ancora.”

Dev Team: “Ma Mario ha mai lavorato con questo framework?”

Project Manager: “No, ma imparerà alla svelta.“

Project Manager: “Entro sera dovete preparare una timeline dettagliata dei tempi di sviluppo, il cliente vuole una data precisa di messa online.”

Inutile che vi stia a raccontare l’esito del progetto; potete immaginare come da una situazione del genere nessuno ne uscirà soddisfatto: né il cliente, nè il PM, ne i poveri sviluppatori che sono costretti a lavorare in questo modo.

Quello che avete letto sopra è uno scenario ahimé molto diffuso nel nostro ambiente, nonostante sia chiaro (o perlomeno dovrebbe esserlo) che un approccio di questo tipo alla gestione del progetto non può che avere un esito: un misero e doloroso fallimento su tutti i fronti.

E’ necessario davvero lavorare così? No

E’ possibile gestire un progetto meglio di così? Sì

Come si fa? Studiando, come per qualsiasi altro ruolo!

Gestire progetti è un lavoro serio. Possiamo avere nel nostro team i migliori sviluppatori sul pianeta, ma se non si sa gestire il progetto con efficacia l’esito non può che essere sempre lo stesso. Saper gestire progetti non è una dote innata, non piove dal cielo e non è detto che si acquisisca con la semplice esperienza: bisogna studiare!

Nelle ultime settimane mi sono letto “Rapid Development” di Steve McConnell, un must-read per ogni PM che si rispetti, e sono rimasto sbalordito: nonostante sia del 1996, il libro descrive precisamente uno ad uno tutti gli errori che vedo compiere attorno a me e ne spiega gli effetti dannosi sullo scheduling e gli effetti tossici per il team. 

La cosa che più mi ha colpito di tutta la lettura è il responso finale che ne emerge: ci sono diversi fattori su cui un PM può fare leva per fare in modo che un progetto vada in produzione senza intoppi e nei tempi previsti, ma di tutte le leve ce n’è una che da sola vale l’80% della torta: la gestione del team. Ebbene sì: volete un progetto che fili liscio come l’olio? Impegnatevi a mantenere il vostro team motivato e stimolato, dimostrate ai membri del team che vi fidate di loro, fateli sentire importanti, fateli sentire parte di qualcosa, non dei semplici scribacchini su cui riversare le colpe dei vostri (evitabilissimi) errori.

Un team motivato può avere una produttività enormemente maggiore rispetto ad un team dello stesso livello tecnico ma con il morale sotto ai piedi.

Lo sò, lo sò, non mi credete, sembrano cose da hippy. Vi rimando alla lettura del libro, ci sono decine e decine di casi concreti che convalidano questa tesi. Oppure provate a parlarne con il vostro team, sono sicuro che ne uscirete illuminati.

Prendiamo ora la conversazione con cui abbiamo aperto questo post e, riga per riga, andiamo a sottolineare gli errori di gestione commessi, gli effetti negativi di ogni errore e, soprattutto, come si sarebbe comportato un PM vero.

“E’ troppo, non posso dire al clienti che ci vorrà così tanto tempo. Gli dirò 3 mesi”

Cosa significa “è troppo”? Sulla base di quale valutazione? Se il cliente si aspetta dei tempi inferiori, dobbiamo spiegargli il perché le sue richieste sono irrealizzabili. Molto spesso il cliente viene vissuto come una entità avversa a cui non si può dire mai di no. Proviamo ad avere un approccio più inclusivo e collaborativo, rendiamolo partecipe del nostro flusso di lavoro, sono sicuro che davanti all’evidenza dei fatti, sarà ben contento di avere un prodotto funzionante in 6 mesi rispetto ad un abominio in 3.

Accorciare i tempi di sviluppo è l’errore più classico, ed è quello più devastante per la quantità di danni che può fare. In primo luogo, una convergenza prematura del progetto per la produzione fa perdere un sacco di tempo. Con convergenza si intendono tutte quelle attività che servono per portare il progetto dallo stato di “sviluppo” allo stato “produzione”. Se fatta nei tempi giusti, la convergenza è poca cosa, se fatta con eccessivo in anticipo richiede molte attività extra, per “sistemare” temporaneamente tutte le funzionalità non pronte per il rilascio. Ho visto convergenze richiedere settimane/uomo intere di lavoro buttato.

Accorciare i tempi di sviluppo ha un effetto ancora più devastante: quando ci si rende conto che i tempi sono troppo stretti e la deadline è alle porte, si butta al vento qualsiasi forma di pianificazione e si lavora rimbalzando tra una funzionalità e l’altra nel tentativo di fixare tutto il possibile prima del go-live. Il nostro è un lavoro di concentrazione, non è un mistero: uno sviluppatore costretto a lavorare così rende probabilmente il 5% rispetto a quanto potrebbe rendere con una pianificazione efficace. Volete uno sviluppatore produttivo? Lasciatelo lavorare in pace sullo stesso task per più di 5 minuti! 

Lo stesso discorso si applica anche dopo il go-live: con un sito in produzione (consegnato nella metà dei tempi auspicabili) il team dedicherà la totalità del tempo a fixare i problemi che sorgeranno quotidianamente, al posto che lavorare per terminare gli sviluppi pianificati (ma parlare di pianificazione a questo punto è quasi comico).

“Sono sicuro che siete stati larghi con le stime come sempre”

Lasciatemelo dire: cazzata. Noi sviluppatori anche quando vogliamo stare larghi in media sottostimiamo l’effort effettivo del 25%: un po’ perché siamo degli eterni ottimisti, un po’ perchè sopravvalutiamo alcuni strumenti che utilizziamo, un po’ perchè tendiamo a dimenticarci di includere nelle nostre stime alcune attività. Tornando poi al discorso “motivazione”, accusare il team di stime non corrette senza evidenze concrete serve solo a demotivare i membri e di certo non li sprona a dare il meglio di sé. Se le stime sono davvero incompatibili con le esigenze del progetto, contrattiamo: si possono togliere alcune funzionalità secondarie e pianificarle per un secondo rilascio, possiamo scegliere di implementare alcune funzionalità con un approccio più minimale per svilupparle poi in base al feedback degli utenti. Pretendere di dimezzare i tempi di sviluppo senza modificare qualcosa del progetto è pura follia.

“E poi c’è Mario che ci può aiutare con gli sviluppi se abbiamo bisogno, quindi i tempi si riducono ancora. Ma Mario ha mai lavorato con questo framework? No, ma imparerà alla svelta.”

Aggiungere persone ad un progetto avviato è una operazione molto pericolosa. Ogni persona extra aggiunge un layer di comunicazione nel team, e questo significa tempo extra di allineamento. Il nuovo membro inoltre prima di essere davvero operativo avrà sicuramente bisogno di essere affiancato da un membro “senior” del progetto, il quale avrebbe bisogno di tutto fuorché dover perdere del tempo a spiegare come funziona un determinato modulo. Il risultato quindi è che la nuova risorsa in realtà fa perdere tempo al team esistente e aggiunge un layer di comunicazione; se poi il nuovo membro non è fortemente, fortemente, fortemente skillato sullo stack utilizzato nel progetto…insomma ci siamo capiti.

“Entro sera dovete preparare una timeline dettagliata dei tempi di sviluppo, il cliente vuole una data precisa di messa online.”

Mi chiavano Nostradamus! Abbiamo appena fatto una stima di massima, la maggior parte delle funzionalità da implementare non è chiara, non abbiamo ancora scritto una riga di codice, e pretendiamo di avere una data di rilascio? La verità è che nello stato iniziale del progetto non è possibile avere una data di rilascio, ci sono troppe variabili e qualsiasi ipotesi è un puro azzardo. Si può arrivare certamente ad una data effettiva di rilascio, ma per step! All’inizio ha senso solo ragionare per range di date, per poi andare progressivamente a ridurre il delta e arrivare ad una data definitiva. Anche in questo caso però, sta a noi spiegare il perché non è possibile avere una data di rilascio precisa all’avvio del progetto, è ovvio che il cliente, dal canto suo, vorrebbe avere l’incertezza minore possibile, ma ahimè è utopia.

Considerate che dopo la prima analisi di massima di un progetto, la variabilità effettiva delle stime che andremo a fare è 25% – 400%! Questo significa che se stimiamo circa 100 giorni, l’effort effettivo potrà variare tra 25 giorni e 400! Vogliamo davvero continuare a fare finta che questo problema non esiste? Vogliamo davvero continuare a consegnare progetti con ritardi del 100% perché semplicemente si è preteso di avere delle stime precise in un momento in cui non è umanamente possibile averle?

Concludendo

Questo è un argomento che mi sta particolarmente a cuore: ho iniziato a lavorare come sviluppatore in un team, ed oggi in TangoDev sviluppo e gestisco i nostri progetti. Ho sempre visto tanti errori di gestione nei progetti a cui ho partecipato e a cui partecipo tutt’ora, ma oggi, a differenza dell’inizio della mia carriera, ho una nuova consapevolezza, dettata dalle esperienze che ho fatto e dagli studi che sto facendo sull’argomento: lavorare meglio si può ed è possibile, la gestione del progetto (e come abbiamo visto specialmente la gestione del team) è una attività davvero cruciale, e non si può affrontarla senza uno studio di base adeguato. In TangoDev sbagliamo e sbaglieremo ancora molto, ma perlomeno abbiamo capito che con un po’ di senso critico, e soprattutto studiando, possiamo migliorarci ogni giorno. Perché l’esperienza da sola non basta: hai davvero 10 anni di esperienza, o hai solo ripetuto per 10 volte il primo anno senza mai imparare nulla?