Le deadline sono spesso considerate strumenti indispensabili per garantire risultati e prevedibilità nello sviluppo prodotto.
Ma la realtà spesso racconta una storia diversa.
Le scadenze rigide non solo falliscono nel garantire la prevedibilità tanto desiderata, ma rischiano di innescare un circolo vizioso di aspettative irrealistiche, compromessi tecnici, e frustrazione collettiva. Anziché accelerare lo sviluppo, finiscono per rallentarlo, sacrificando qualità del lavoro e morale del team sull’altare dell’urgenza.
Indice:
- Il tradizionale ruolo delle deadline nello sviluppo prodotto
- La genesi di una deadline
- La natura imprevedibile dello sviluppo software
- Le conseguenze negative delle deadline
- Possibili alternative
- Conclusioni
Il tradizionale ruolo delle deadline nello sviluppo prodotto
Nel mondo dello sviluppo prodotto, le deadline sono spesso usate per trasmettere quel senso di “urgenza” che sembra essere l’ingrediente fondamentale per ottenere grandi risultati.
A volte, le deadline ci sono imposte dall’esterno, come quando a richiederle è un cliente importante. Altre volte, invece, sono “create” internamente (spesso da manager ed executive).
Tradizionalmente chi imposta una scadenza sul lavoro del team lo fa per uno di questi motivi:
- Prevedibilità esterna: Gli stakeholder (clienti, partner o investitori) vogliono sapere quando il lavoro su cui contano o la funzionalità che vogliono (o pensano di volere) verranno completati.
- Senso di controllo: Le deadline aiutano manager ed executive a sentirsi in controllo del lavoro del/dei team che gestiscono.
- Senso di urgenza: Le deadline sono considerate un ottimo metodo per spingere il team a raggiungere obiettivi ambiziosi ed evitare di cadere nell’eccessivo perfezionismo.
Questi motivi possono essere validi e non sto suggerendo che non abbia mai senso fissare delle deadline ma, in questo articolo, vorrei farvi vedere anche l’altro lato della medaglia e tutti i motivi per cui spesso sarebbe meglio invece non imporsi una data di scadenza.
La genesi di una deadline
Il rischio di questa metodologia è di creare un circolo vizioso in cui la deadline:
- Nasce: Il team di prodotto decide su che cosa lavorare nel prossimo mese/trimestre/sprint e fa una stima del tempo necessario per il completamento dei lavori. I manager/executive fissano una deadline per motivare ed efficientare il team di prodotto. Il team vendite promette ai clienti la deadline pattuita. I clienti sono felici.
- Inciampa: Il piano si scontra con la realtà. La funzionalità è più complessa del previsto; quella parte del software è risucchiata nell’oscuro abisso del debito tecnico; bug o problemi imprevisti si mangiano parte del tempo degli ingegneri dedicati al progetto; salta fuori una nuova idea di funzionalità di cui “non possiamo fare a meno” e acquisisce maggiore priorità. I motivi sono tanti. Fatto sta che gli sviluppatori si rendono conto che la deadline non è più fattibile.
- Si arena: È impossibile nascondere che la deadline non verrà raggiunta. Si cercano i colpevoli. Si finisce per definire una nuova deadline che “questa volta non possiamo mancare”. Al team vendite tocca l’ingrato compito di ammettere il ritardo ai clienti. I clienti non sono più tanto felici.
- Si accontenta: Con un ultimo slancio frettoloso la funzionalità viene lanciata entro la nuova deadline, probabilmente non tutto quello che era stato promesso, probabilmente con diversi compromessi tecnici e “soluzioni temporanee” (che, spoiler, temporanee non saranno). I clienti non sono soddisfatti. La soluzione mitiga solo il loro problema.
- Ci riprova: Si fa una retrospettiva, si cerca di capire cos’è andato storto. Si dà la colpa ai processi e se ne crea di nuovi.
La natura imprevedibile dello sviluppo software
Il circolo vizioso descritto è sicuramente una semplificazione della realtà, ma per chi lavora in ambito sviluppo software non sarà particolarmente difficile immedesimarsi in uno scenario simile. Per chi, invece, è meno familiare con questo mondo, possiamo immaginare lo sviluppo di un prodotto software come il processo di costruzione o ristrutturazione di una casa.
Chiunque abbia mai anche solo ristrutturato la cucina di casa sa che qualsiasi stima di costi e tempistiche è quasi sempre una sottostima. Si parte sempre con le migliori intenzioni e un piano ben definito ma poi, per motivi spesso imprevedibili, tutto si complica e i tempi slittano. Il fornitore è in ritardo, “nel frattempo” l’impresa ha spostato i muratori su un altro progetto, l’impianto elettrico non è a norma, quella perdita proprio non capiamo da dove arrivi.
Sono mille i motivi che rendono le tempistiche di una ristrutturazione così come dello sviluppo software così difficili da prevedere. Se poi parliamo di sviluppo di prodotti nuovi o che usano tecnologie nuove, l’incertezza cresce esponenzialmente.
È molto semplice credere nell’illusione della prevedibilità che le deadline portano con sé. Ma la dura verità è che, nell’ambito dello sviluppo software, è irrealistico pensare di poter prevedere con certezza quanto lavoro sarà completato entro una certa data. Imponendo una deadline, manager ed executive possono ottenere dai team di prodotto una promessa. Una promessa che assomiglia molto di più a una speranza che non ha una stima basata su dati empirici. Di conseguenza la prevedibilità che la deadline ci sta regalando non è altro che una speranza travestita da data.
Le conseguenze negative delle deadline
L’invito qui non è per forza ad abbandonare del tutto l’utilizzo delle deadline. (Alcune aziende per la verità hanno iniziato a farlo e a ispirare questo articolo è proprio una di loro: PostHog che parla di questo argomento in “The deadline doom loop”). A volte, ad esempio, una deadline ci può essere imposta da un obbligo contrattuale. L’invito è a limitarne l’utilizzo solo allo stretto necessario e considerare gli aspetti negativi. Le conseguenze di quanto scritto sopra infatti possono avere un forte impatto sul team e sull’azienda in generale.
Le deadline perdono di significato
Se diventa normale non raggiungere le deadline, queste perdono completamente di significato. Un fenomeno che sperimentiamo anche nella produttività personale. Le deadline possono essere efficaci nel tenerci concentrati e produttivi fintanto che queste hanno un significato. Nel momento in cui invece diventa chiaro che la deadline è irrealistica, non necessaria ed è normale superarla tanto “è sempre così”, anche quel poco di effetto positivo che potevano avere svanisce del tutto.
Il morale e la collaborazione del team ne risente
Nella maggior parte dei casi (come illustrato nel circolo vizioso descritto sopra) non è “colpa” del team se la deadline non è stata raggiunta. Ma l’aver “fallito” nel consegnare il lavoro in tempo impatterà sul morale del team. Il team vendite sarà costretto a comunicare al cliente del ritardo e questo intaccherà la collaborazione tra team diversi in futuro. I team di prodotto vedranno il continuo controllo dei loro manager tramite deadline come una mancanza di fiducia e autonomia.
Perdita di fiducia dei clienti e “commercial debt”
Clienti e prospect a cui era stato promesso qualcosa che poi è stato fatto male, per metà o in ritardo non saranno contenti. Il team vendite sarà costretto a fare altre promesse e compromessi.
Tech debt
Come sempre, quando si ottimizza per obiettivi a breve termine e risultati immediati, si rischia di creare problemi a lungo termine. Problemi che si accumulano e rendono il processo più lungo e lento ad ogni passaggio.
Se gli sviluppatori si trovano costretti a generare consapevolmente tech debt per rispettare una deadline, significa che il sistema è ormai compromesso e che le deadline stanno danneggiando la qualità del lavoro e la professionalità del team.
Processi eccessivamente complessi
Spesso si tende a incolpare i “processi” quando le cose non funzionano e a pensare che, migliorandoli, la volta successiva andrà meglio. Tuttavia, questo può portare a un’eccessiva complessità che finisce per rallentare ulteriormente le operazioni.
Deadline e sviluppo prodotto: possibili alternative
L’alternativa a quanto descritto sopra richiede un cambio di approccio e cultura su diversi fronti.
Team piccoli e autonomi
Dal punto di vista del team, mantenere i team di prodotto piccoli può essere un ottimo modo di avere team efficienti e risultati veloci. Al di là dell’organizzazione interna in team, l’attenzione qui si sposta necessariamente a monte sul processo di hiring. Per avere dei team davvero autonomi non possiamo accontentarci di persone che possano semplicemente fare bene quello che gli viene chiesto di fare. Devono essere abbastanza motivate e autonome da spingersi a vicenda verso un obiettivo comune.
Ad adottare un approccio simile sono ormai diverse aziende. PostHog ha documentato nel loro articolo “The magic of small engineering teams” come team di 3-5 persone possano muoversi con agilità e autonomia. Spotify, con il suo modello a “Squad” e “Tribes”, promuove da tempo l’autonomia di team cross-funzionali a cui venga data la fiducia di completare il loro lavoro nel modo in cui scelgono di farlo.
Rilasci piccoli ma regolari
Le deadline non sono l’unico modo di ottenere la fiducia e il senso di prevedibilità che manager, clienti e stakeholder cercano. Sembra banale in un mondo pieno di “Agile” ma fare rilasci veloci e frequenti che permettano di raccogliere feedback costantemente può anche essere un ottimo modo per rendere felici gli stakeholder senza fare promesse con una scadenza.
L’articolo “Deadlines (in software development) do not give you any predictability” fa un’ottima metafora con il trasporto pubblico (metafora che io allungherò leggermente in termini temporali per rendere meglio l’idea). Se so che la metro che devo prendere per andare al lavoro passa ogni 15 minuti, mi importa molto sapere esattamente quando passerà per non dover aspettare e perché 15 minuti in più o in meno possono fare la differenza nell’organizzazione dello spostamento da casa al lavoro. Se invece so che la metro passa ogni 3 minuti, non mi pongo neanche il problema di guardare la programmazione dei treni.
Questo è il principio che guida il concetto di Continuous Delivery (ormai applicato universalmente in grandi e piccole aziende tech) rendendo obsoleto il concetto di “grande rilascio” legato a una deadline. Quando il flusso di valore è continuo, spesso scandito da Sprint o simili, la prevedibilità emerge naturalmente dalla regolarità, non dall’urgenza aumentando di conseguenza il senso di sicurezza dei manager e la fiducia dei clienti.
Si può dire di no
Noi Product Manager ci sentiamo ripetere in continuazione quanto sia importante imparare a dire di no. Ma tra dire e il fare … Ci piacerebbe dire di sì al cliente, renderlo felice con il nostro prodotto, figuriamoci quando si tratta della nostra startup e dalla felicità del cliente dipende anche la nostra sopravvivenza.
Più e più volte ho però constatato nella mia esperienza che, per quanto sia difficile sul momento, il rapporto di fiducia con clienti e prospect non beneficia di certo dal fare promesse mantenute a metà o affatto. È molto meglio spiegare al cliente perché non possiamo promettere una deadline e dimostrare il valore del nostro prodotto non con promesse ma con i fatti: risultati piccoli ma frequenti.
Deadline e sviluppo prodotto: conclusioni
E con questo la finisco con la mia invettiva ai danni della deadline. La mia speranza è che la prossima volta che sentirai l’urgenza di chiedere al tuo team di darti una deadline, ti venga in mente questo articolo e scelga di procedere con cautela. Il cattivo uso delle deadline può compromettere il morale del team, la qualità del prodotto e l’efficienza dell’azienda nel medio/lungo termine.
E se ancora senti forte l’impulso di mettere mano al calendario, guarda quello degli eventi di Product Heroes e dammi una chance di farti cambiare idea davanti a un Cocktail dell’Eroe ;)
Fonti
- https://newsletter.posthog.com/p/the-deadline-doom-loop
- https://posthog.com/newsletter/small-teams
- https://medium.com/agility-path/deadlines-do-not-give-you-any-predictability-3cbe6308fff5
