Perché i progetti non vanno mai come previsto?

Ascolta su Apple Podcasts, su Spotify oppure su Google Podcasts

Sergio Panagia: Benvenuti nel podcast di Moze, uno spazio di discussione e approfondimento tecnico sullo sviluppo di nuovi prodotti digitali. Io sono Sergio, partner dello studio, e con me oggi c’è Luca, fondatore di Refactoring, precedentemente manager in Translated e CTO in Wanderio. Ciao Luca.

Luca Rossi: Ciao Sergio, grazie di avermi invitato qui, sono molto contento.

Sergio: Refactoring è una newsletter settimanale sullo sviluppo software che parla di collaborazione tra persone, di processi e di crescita personale. Luca ha una vasta esperienza nell’organizzazione dei gruppi di lavoro per lo sviluppo di progetti digitali, e oggi parliamo proprio di questo: come gestire le persone, che siano interne o esterne all’azienda, rendendole soddisfatte, contente ed efficaci; e come gestire i tempi, che di solito non tornano mai, e i costi di progetto. Luca, comincio con una domanda scottante: perché i progetti non vanno mai come pianificato inizialmente?

Luca: Questa è la domanda delle domande, Sergio. Ci sono tanti motivi, secondo me: uno dei principali è che, rispetto ad altre discipline, anche ingegneristiche, nell’informatica e nello sviluppo software approcciamo la pianificazione in modo diverso. Se bisogna costruire un ponte, solitamente viene stilato un progetto a monte, perché vanno comprati i materiali e, se poi si fa un errore in corso d’opera, i rischi sono maggiori. Con il software è molto più facile fare e disfare, apprendere mentre si fa e adattarsi al feedback, che venga dai clienti o dai manager. Quindi la pianificazione che si fa, almeno nella mia esperienza, è più snella: quando scriviamo i requisiti accettiamo che ci siano delle zone di incertezza, che poi verranno dipanate nel corso del progetto. Questo, da una parte, è funzionale a come avviene lo sviluppo software, che infatti si è orientato verso un tema di agilità, iterazioni brevi e così via. Dall’altra, però, quegli stessi requisiti più snelli rendono impossibile fare delle stime precise e quindi vincolanti su quando il progetto verrà consegnato e quando sarà tutto pronto e in produzione.

Sergio: Hai detto che i requisiti cambiano ed è per questo, spesso, che è complicato fare delle stime. Però dal momento che dobbiamo farle tutti (perché all’inizio dobbiamo valutare l’ingombro, quanto impiegheremo per completare le attività e così via) nella tua esperienza qual è il modo migliore di approcciare la stima di un progetto?

Luca: Ci sono diversi modi di stimare i progetti. C’è un lavoro molto importante che viene prima, che è quello di organizzare bene il lavoro e dividerlo in iterazioni e batch piccoli: piccole funzionalità, piccole attività indipendenti le une dalle altre, in modo che, prese singolarmente, siano a rischio più basso e più veloci da realizzare. Questo perché c’è molto meno rischio e maggiore affidabilità nello stimare cinquanta piccole funzionalità che nello stimarne dieci grandissime. È quanto ho notato di persona, perché nelle iniziative grandi si nascondono più insidie, più difficoltà e si diverge più facilmente. Quindi, questa attività di dividere il lavoro in software che poi può essere lanciato indipendentemente ogni uno, due giorni, o anche più volte al giorno, abbatte moltissimo l’incertezza e il rischio, a prescindere dalla tecnica di stima che si adotta. Detto questo, ci sono diverse tecniche: la più diffusa è quella di stimare il tempo che lo sviluppatore impiega per scrivere il software. Secondo me è anche la meno efficace, perché la scrittura del software è quello che si dice “knowledge work” o “creative work”, il che significa che la stima temporale dipende molto da chi poi, effettivamente, fa la stima.

Sergio: La mia stima potrebbe essere diversa da quella del mio collega che fa lo stesso lavoro.

Luca: Completamente. Prima di tutto, nel migliore dei casi si tratta di una stima che vale soltanto se sarò io a fare l’attività. Poi vale anche il motivo di cui abbiamo parlato prima, cioè che disporre di un requisito un po’ incompleto rende la stima temporale, che peraltro sa subito di impegno per realizzarlo in quel tempo, poco affidabile. Quello che, secondo me, funziona meglio è passare per un livello intermedio, in cui fornire una stima, anche arbitraria, della complessità dell’attività. Quindi, se dobbiamo percorrere un tratto di strada, non diremo subito: “Ci metto mezz’ora a farlo”, senza sapere quanto è lungo. Prima dovremo provare a dire: “È lungo x”. Poi, se uno è più bravo a correre ci mette meno, se è meno bravo ci mette di più. Nell’industria, come sappiamo, questa stima della complessità spesso si esprime in story points, che sono dei numeri (anche arbitrari) assegnati dai team software, che poi possono essere usati per calcolare la velocità del team, misurata come quantità di punti eseguiti in un arco di tempo. Questa misura, da una parte, è più affidabile nel tempo, soprattutto se si può contare su di un team con una storia di performance; dall’altra, in maniera un po’ più sottile, è più sicura psicologicamente, perché è un numero che rimane sotto il controllo di chi sviluppa e non diventa subito: “Ah, mi hai detto che ci vogliono due giorni, allora dopodomani è fatta”, come spesso succede, finendo per creare tensioni e problemi.

Sergio: Però questa è una cosa che va a chiaro vantaggio dello sviluppatore. Io, che sono un tecnico, sono assolutamente dalla parte del developer, ma ad un manager che vantaggio può derivare da un approccio di questo tipo?

Luca: Il manager può capirne il vantaggio considerando la velocity del team nel tempo. Questa stima è più affidabile rispetto alla mera statistica del numero delle ore che servono per completare un task; e non dipende dalla singola persona, perché tipicamente la stima la si fa tutti insieme. Per esempio, il team può decidere che una funzionalità vale quattro story point, pur sapendo bene che consumerà n story point a settimana, perché ci sarà chi va più velocemente e chi meno. Quindi è più controllabile, come previsione.

Sergio: Quindi, piuttosto che illudersi che ci vorranno quattro giornate, sapendo che non sarà così, parliamo di story point sapendo che esiste il concetto di velocity, che si ricalcola sulla media del consumo effettivo durante il lavoro, in maniera tale da definire un approccio “patti chiari e amicizia lunga”. Questo è un po’ il principio.

Luca: Sì, poi riuscendo a impostare una relazione di lavoro, un workflow per cui si rilasciano funzionalità velocemente, quasi tutti i giorni, allora anche il manager riesce poi a vedere il valore apportato in modo incrementale tutte le settimane. Questo poi riduce molto il focus e l’attenzione sulle stime e le deadline, portando a creare un rapporto più sano, semplicemente basato su: “Definiamo a inizio settimana, ogni due settimane cosa vogliamo fare, che valore possiamo riuscire ad apportare, e concentriamoci su quello”. Chiaramente questo è possibile farlo soltanto se il lavoro è organizzato in batch piccoli, perché con un mega-progettone da tre mesi dove l’aspettativa è: “Ci vediamo all’inizio e ci vediamo alla fine del lavoro”, allora è ovvio che c’è molta più pressione sulla deadline, su quando bisogna finire tutto.

Sergio: Parli di un sacrosanto principio dell’Agile, che è quello dei batch di lavoro piccoli, delle iterazioni piccole e frequenti, con anche rilasci frequenti. Ho visto che anche in Italia viene applicato, non è solo un’illusione! Però nella realtà di Moze, e anche in tante altre realtà simili, esistono spesso dei casi in cui il manager dice: “Io queste cose devo comunque farle, sono dei blocchi importanti”, e diventa necessario pianificare bene in anticipo. Come possiamo approcciarci a un progetto grande e importante in maniera intelligente, in piccoli batch e, soprattutto, siccome i requisiti cambiano, come possiamo prepararci a reagire al cambiamento?

Luca: Ovviamente dipende molto da progetto a progetto. Ci sono effettivamente progetti dove non si riesce a mostrare il valore all’utente finale prima di aver accumulato tutta una serie di funzionalità che vanno rilasciate tutte insieme; ce ne sono altri dove invece è più semplice dividere in iterazioni che diminuiscono il rischio. In generale, pianificare è giusto: non è mai un’attività che è sbagliata di per sé, perché aiuta con la comprensione e a creare delle aspettative. Bisogna però pianificare il giusto, il minimo indispensabile per quello che è la nostra necessità di prendere decisioni. I piani servono a noi a tal fine, in un senso o nell’altro. Poi ho notato che a volte le persone si affezionano più al piano che al valore vero e proprio che stanno apportando, per cui la definizione di successo del progetto diventa: “Io consegno il piano”. Così finiscono per perdere l’opportunità di deviare leggermente qualora dovessero accorgersi che c’è un modo più semplice o di maggior valore di fare la stessa cosa per l’utente, perché durante l’attività si apprende sempre qualcosa su quello che si sta facendo. Quindi, personalmente formulerei comunque un piano, ma cercherei di organizzare l’attività in iterazioni, in modo tale che anche quando non è possibile ricevere feedback dagli utenti finali o dagli stakeholder mostrando loro demo o anteprime (e quindi simulando quello che sarebbe il risultato finale), sia comunque possibile deviare dal piano per generare maggior valore; e sia possibile farlo in corso d’opera, piuttosto che dopo, quando non dico che è tardi, ma è molto più costoso.

Sergio: Giustissimo. Prima hai anche parlato delle persone, dell’Agile costruito attorno alle persone, e ora torni a citare di nuovo l’importanza di far partecipare gli utenti, di raccogliere feedback e di prendere decisioni, in particolare considerando che qualcuno deve prenderle, che debba esserci un responsabile che si faccia carico di una scelta. Questo mi porta a parlare di team, quindi della squadra di lavoro, nel contesto dei progetti. In Refactoring hai parlato di generalisti e di specialisti e delle differenze tra questi ruoli. Puoi parlarcene un po’ meglio?

Luca: Certo. Quello che ho raccontato in Refactoring parte dalla mia esperienza di founder e CTO di una startup, che è l’esperienza generalista per definizione, in cui è necessario fare tutto e avere mille cappelli. Quando poi un’esperienza del genere termina ti porta a chiederti: “Ok, ma cos’è che so fare veramente? Che cosa dovrei fare?”. Quindi, la distinzione tra generalisti e specialisti non è netta, è più un continuum. E benché gli specialisti siano persone che tendono a seguire un chiaro percorso professionalizzante e ad approfondire una determinata skill, questo non significa che tralasciano soft skill e altri aspetti della gestione del lavoro, ma solo che tendono a specializzarsi più marcatamente lungo un asse verticale. I generalisti, invece, sono persone che accumulano più esperienze che non hanno un collegamento netto immediato a cui sia possibile attribuire valore; come nel caso di un founder, che si ritrova a fare un po’ di design, di sviluppo, di back-end e di supporto ai clienti. Diciamo che, al di là delle skill, i generalisti e gli specialisti crescono in modo diverso e si trovano ad avere delle caratteristiche personali diverse: gli specialisti tendono a fare un grande investimento sul loro verticale e a pensare che la propria carriera, il proprio percorso dipenda da quello. Esagerando, potremmo dire che corrono un rischio, perché volendo applicare quello che sanno fare potrebbero trovarsi in situazioni che si possono riassumere in: “Hai solo un martello e tutto sembra un chiodo”. Il generalista, invece, è una persona più aperta a imparare cose diverse, perché non percepisce il proprio valore come legato alla skill, ma più all’apertura in sé. Ovviamente una soluzione non è migliore dell’altra: dipende dalla fase di vita dell’azienda, dal tipo di attività che si fa. Nel team di una startup che è in via di formazione o è stata appena lanciata, i generalisti portano tipicamente molto valore, perché possono essere pragmatici e trovare il modo migliore di fare una cosa senza essere affezionati a “un modo” in cui sanno di poterla fare.

Sergio: E quando l’azienda cresce, qual è il giusto mix? Perché mi è capitato di trovare dei team dove i generalisti erano fin troppi, e altri in cui erano quasi tutti specialisti, quindi si faceva fatica a fare sufficiente astrazione. Qual è, secondo te, un buon mix, parlando di team e divisione di ruoli e responsabilità?

Luca: Innanzitutto, va da sé che più il team cresce e le responsabilità si strutturano e si delineano, più si crea lo spazio per gli specialisti, che possono poi, grazie alla loro verticalità, permettere di fare il salto di qualità su di una determinata competenza. In team e in aziende più grandi, i generalisti tendono a diventare dei buoni manager o comunque delle persone capaci di mantenere una visione d’insieme, perché è quello che li contraddistingue. Diventano quindi figure con responsabilità gestionali, benché al netto delle sensibilità personali, anche se spesso beneficiano dall’avere esperienze variegate, come nel caso di un product manager con un background tecnico o un ingegnere front-end con una sensibilità per il design del prodotto. Quindi, sono persone che riescono a ritagliarsi uno spazio nella gestione o nel collegamento e nella comunicazione tra reparti, in cui si riscontrano invece difficoltà se si può fare affidamento solo su persone che parlano strettamente soltanto una lingua.

Sergio: Ottimo, mi sembra un ottimo orientamento per capire come creare il giusto team di progetto. Hai parlato di comunicazione e di dialogo tra le persone, e questo mi porta al tema successivo: viviamo in tempi in cui gli strumenti di comunicazione e di collaborazione digitali sono diventati pervasivi; siamo ormai abituati a lavorare destreggiandoci tra notifiche di Slack, SMS, Messenger, persino WhatsApp. Eppure si sa: il lavoro necessario a sviluppare un prodotto digitale o, più in generale, a risolvere dei problemi complessi, richiede un impegno significativo, con il giusto focus e senza interruzioni, per quanto possibile. Secondo te, come è possibile invertire la rotta e organizzare un team di lavoro in maniera efficace, massimizzando la produttività e garantendo, allo stesso tempo, la giusta collaborazione e i giusti livello di comunicazione tra le persone?

Luca: È un tema importantissimo perché, e sarà una banalità, la comunicazione all’interno di un team è un elemento fondamentale. In questi anni stiamo imparando molto, stiamo facendo molta sperimentazione. Prima non c’erano neanche le chat e adesso abbiamo Slack, i canali solo audio, molte più conference call. Senza contare che ora lavoriamo tutti da remoto: questo come cambia le cose? Com’è lavorare in fusi orari diversi? C’è molta confusione, anche perché continuiamo a dover affrontare situazioni che poi, in definitiva, ci aiutano a capire meglio che cosa vuol dire comunicare, quali sono i vari metodi di comunicazione a nostra disposizione e quali sono i loro pro e i loro contro, dal punto di vista umano. Se si vuole tagliare il tema un po’ con l’accetta, potremmo dividerlo in due grandi mondi: la comunicazione sincrona, estemporanea, come può essere la chat su Slack o WhatsApp, ma anche la conference call, quindi volatile e in tempo reale; e poi tutto il mondo della comunicazione asincrona, scritta, ragionata, che magari passa dalla documentazione o da conversazioni più organizzate. Sono utili entrambe, però bisogna sapere quando usarle e perché. La comunicazione volatile, estemporanea, ovvero quando ci si sente in conference call o in altri modi, come su Slack o per messaggio, è potente perché richiede che tutte le persone si sedano allo stesso tavolo nello stesso momento e consente quindi di farle convergere velocemente. È forse l’arma più potente che abbiamo ma, proprio perché è potente, va usata con parsimonia, perché è anche molto dispendiosa in termini di energia e di focus delle persone. Alla fine richiede di trovarsi tutti d’accordo, di interrompere quello che si sta facendo e di trovarsi tutti concentrati nello stesso momento. Quindi è una strategia che va tenuta per le materie più urgenti, più complesse o più personali, come quando hai la necessità di avere un one-to-one con qualcuno, benché niente possa sostituire il faccia a faccia. Però i benefici della comunicazione asincrona, quella scritta, sono tali e tanti che la maggior parte delle nostre interazioni dovrebbero ricorrere a questo sistema. Un documento scritto è più strutturato e ragionato di quello che si potrebbe ottenere in chat; è permanente, quindi poi le persone possono cercarlo e utilizzarlo; contribuisce alla base di conoscenza del team; senza contare che, per loro natura, la maggior parte delle decisioni importanti e, in senso assoluto, delle interazioni, si prestano meglio a essere comunicate in questo formato. Inoltre, anche dal punto di vista di organizzazione dei tempi, il fatto che la comunicazione avvenga in maniera asincrona, per cui una persona scrive un documento e lo manda un’altra, che lo commenta e poi se ne discute in un secondo momento, è un aspetto molto vantaggioso anche per chi lavora da remoto, in fusi orari diversi. Permette di ottimizzare il lavoro. Quindi vale un po’ la regola dell’80/20.

Sergio: Da quanto mi sembra di capire, questi strumenti, che si tratti di Slack, e-mail o qualsiasi altra cosa, sono tanto pervasivi quanto utili, ed è meglio utilizzarli in maniera asincrona. Quando qualcuno sta lavorando a qualcosa può fare domande a un’altra persona, purché la lasci prima finire di fare quello che sta facendo, senza aspettarsi una risposta istantanea. Altrimenti si tratta di comunicazione sincrona: nel caso di Slack o delle e-mail, se si ha l’aspettativa di una risposta immediata, si finisce a comunicare tanto e a lavorare poco.

Luca: Assolutamente sì. Questo è tanto più importante ora che, nella maggior parte delle aziende, non siamo più tutti seduti uno vicino all’altro con davanti il contesto di quello che uno sta facendo in un dato momento, oltre a godere della serenità di potergli scrivere sapendo di non interromperlo. Siamo tutti in posti diversi, in alcuni casi in fusi orari diversi, quindi ci vuole più flessibilità, nonché la scelta di strumenti che facilitino tali qualità. Perché tante volte pensare che una chat sia asincrona è un po’ come remare controcorrente. Non sto parlando di Slack in particolare, ma la chat in generale è pensata per consegnare notifiche il prima possibile, per far interagire il prima possibile; quindi anche lo spirito dello strumento incoraggia un certo tipo di comportamento.

Sergio: Oggi, assieme a Luca, abbiamo parlato di progetti, di processi, di come lavorare alle stime e di come organizzare al meglio un team di lavoro e la relativa collaborazione. Se volete condividere la vostra esperienza, scriveteci su mozestudio.com. Luca, ti ringrazio.

Luca: Grazie a te, Sergio, di avermi invitato. Molto contento della chiacchierata.