Gestire le Derive del Progetto (con Suze Haworth)

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast tramite un programma software. Perdonate eventuali errori di battitura, il bot non è sempre accurato al 100%.

Ben Aston:

Benvenuti al podcast DPM dove andiamo oltre la teoria per dare consigli esperti su come guidare meglio i progetti digitali. Grazie per averci ascoltato. Sono Ben Aston, fondatore di The Digital Project Manager. Ora, se c'è una cosa che manda quasi sempre fuori strada ogni progetto, è la deriva dell'ambito. Sappiamo tutti che è un problema. Sappiamo tutti che vogliamo evitarlo. Ma come puoi riconoscerlo sotto tutte le sue forme? Cosa lo causa? Di chi è la colpa? E, cosa più importante, come affrontarlo concretamente? Tutto questo verrà svelato nel podcast di oggi, dove parleremo di come gestire le derive dell’ambito di progetto.

Questo podcast è offerto da Clarizen, leader nel software di gestione dei progetti aziendali.

Scopri di più su clarizen.com

Oggi sono con Suze Hayworth. Suze è una delle nostre esperte residenti di DPM in The Digital Project Manager e lavora come freelance Senior Digital Project Manager a Londra, UK. Ha più di 10 anni di esperienza nelle agenzie e ha affrontato molti casi di scope creep, quindi è la persona ideale con cui parlare oggi. Benvenuta Suze.

Suze Hayworth:

Ciao Ben.

Ben Aston:

Suze, stavamo chiacchierando prima di iniziare a registrare. Puoi raccontarci che tipo di progetti stai seguendo al momento e quali sono alcune delle sfide che stai affrontando?

Suze Hayworth:

Sì, al momento sto lavorando in un'agenzia a Londra come freelance, quindi divido il mio tempo tra il ruolo di senior project manager e project director su due clienti. Su uno sto lavorando per IKEA, quindi una grande azienda retail eCommerce. Stiamo realizzando per loro un sistema di design, una sorta di prototipo di sistema di design. Poi sto lavorando anche per un altro retailer eCommerce nel Regno Unito. Quindi attualmente seguo molti progetti retail. Sì, e le sfide… credo sia sempre complicato parlare delle difficoltà, soprattutto mentre sono in corso. Sì, penso che-

Ben Aston:

Un cliente difficile?

Suze Hayworth:

In realtà no. Devo ammetterlo comunque.

Ben Aston:

Devi dirlo.

Suze Hayworth:

È vero. Sono ottimi clienti quelli con cui lavoro in questo periodo. Penso che, sia nel bene che nel male, il bello dei progetti e dell’essere project manager sia lavorare con le persone. Mi piace lavorare con persone diverse, caratteri e peculiarità varie. Ma a volte si arriva a un punto in cui diventa frustrante dover lottare per ottenere risultati da chi non vuole collaborare. Mi è successo recentemente, credo.

Ben Aston:

Divertente. Raccontaci del progetto per costruire un sistema di design, perché è un incarico interessante e credo che sia sempre più comune. Prima forse si trattavano tutti i progetti come casi a sé stanti, e i creativi volevano sempre distinguersi. Puoi spiegarci cosa è un sistema di design e su cosa stai lavorando realmente? Come lo state sviluppando?

Suze Hayworth:

Sì, in effetti è un incarico emozionante perché come hai detto i sistemi di design sono sempre più diffusi nel digitale. Di base sono una sorta di libreria di stile per la progettazione digitale di aziende e marchi. Fondamentalmente stabiliscono una base di componenti di design, moduli, template che qualunque designer o sviluppatore che lavori col brand può utilizzare per creare nuovi design o codice. Fornisce uno standard che promuove efficienza—codice e design riutilizzabili, ma anche coerenza interna all'azienda.

Per un colosso come IKEA, dove lavorano tanti enti, agenzie e persone, un sistema di design può stabilire uno standard che designer e sviluppatori possono seguire. In questo modo, per esempio, il pulsante di una pagina, una call to action, sarà coerente su tutte le piattaforme, dispositivi e app. Insomma, qualunque sia la proprietà su cui lavorano.

Ben Aston:

Raccontami il processo di gestione del progetto, perché sembra una di quelle attività interminabili. Come siete partiti? Su cosa iterate? E dove finisce il prodotto?

Suze Hayworth:

Per IKEA, molti brand realizzano interamente questi sistemi internamente. IKEA invece ha cercato supporto esterno, e credo sia stata una mossa intelligente perché questo ci ha permesso di portare una visione nuova, non legata alla cultura interna. Siamo partiti valutando i principi, i valori digitali di base, i principi di design. È stata una fase strategica per impostare l'esperienza complessiva e i principi di design. Poi ci siamo concentrati sulla creazione di un design base partendo dagli elementi fondamentali già esistenti come colori, tipografia, griglie, approfondendoli ulteriormente.

Successivamente abbiamo svolto test utente su queste soluzioni su diverse piattaforme scelte tra le proprietà di IKEA, e poi abbiamo iniziato a progettare e sviluppare componenti specifici, ospitandoli su un sito dedicato al sistema di design (per ora solo interno). L’obiettivo attuale è realizzare un prototipo versatile da sviluppare in una soluzione completa più avanti, al termine di questa fase.

Ben Aston:

Quindi la soluzione completa è una sorta di guida di stile dinamica, con snippet e template riutilizzabili? È questa la visione?

Suze Hayworth:

Sì, ogni sistema di design deve essere un entità in evoluzione e non avere una fine predefinita. Non è un prodotto che “finisce e basta”: va sviluppato costantemente. Noi abbiamo appena iniziato, analizzato principi, fondamenti e componenti iniziali. Da qui, raggrupperemo i componenti, svilupperemo moduli, template e strategie per portare le persone a usarlo, formarle e coinvolgerle. È un grande progetto, soprattutto perché coinvolge tante parti in azienda. Siamo solo agli inizi anche se ci lavoriamo da quasi un anno.

Ben Aston:

Sembra davvero interessante. Sono curioso: c’è qualche strumento che hai trovato utile o qualcosa che ti ha reso la vita più semplice ultimamente?

Suze Hayworth:

In realtà non sto usando nuovi strumenti ultimamente, resto fedele a quelli che conosco. Ma è ironico considerando che sono in un podcast, perché ultimamente ascolto più podcast del solito. Di solito ascoltavo musica durante l’ora di tragitto per andare a lavoro, ma ora utilizzo quel tempo per ascoltare vari podcast. È un altro modo per imparare e sfruttare meglio il tempo, visto che spesso sto in piedi in treno perché non trovo mai posto a sedere!

Ben Aston:

C’è qualche podcast particolarmente utile o interessante che hai scoperto?

Suze Hayworth:

Sicuramente il podcast di The Digital Project Manager, ovvio! Ne ho anche registrato uno recentemente dopo la mia sessione al DPM Summit, dove ho parlato di cosa trattava la mia sessione. Poi The Bureau of Digitalists, collegato al DPM Summit, offre molti contenuti validi, e Brett, che organizza il summit, ha lanciato un podcast chiamato Sprints and Milestones basato sul suo libro sulla gestione di progetti digitali—una risorsa molto utile.

Ben Aston:

Ottimo. Un'altra cosa che ho trovato interessante (non so se lo conosci) è Blinkist. Devo essere onesto: ascolto pochi podcast ad eccezione del mio stesso dove sono io a parlare, ma mi rendo sempre conto che ci sono libri che dovrei leggere, li compro e poi non li leggo mai. Blinkist invece offre riassunti condensati dei libri. È come un-

Suze Hayworth:

Penso di averne sentito parlare, sì.

Ben Aston:

In pratica, sono riassunti che si leggono in circa 15 minuti, oppure puoi ascoltarli mentre qualcuno li legge, con i punti principali. È come un podcast, e puoi addirittura ascoltarlo a velocità doppia. Quindi ti bastano sette minuti e mezzo per “ascoltare” un libro.

Suze Hayworth:

Fantastico, devo provarlo, anche io sto cercando di leggere di più ultimamente. Sarebbe utile per leggere più libri.

Ben Aston:

Ecco il mio trucco per i libri: Blinkist. Ma torniamo al tema di oggi: la deriva dell'ambito. Parliamone! Per chi non ha mai sentito parlare di scope creep, cos’è e perché dovremmo preoccuparcene?

Suze Hayworth:

In sostanza, quando il tuo ambito—le cose che hai concordato di consegnare, le funzionalità di un progetto—si amplia rispetto a quanto stabilito senza una pianificazione aggiuntiva. Può presentarsi in varie forme, ma la sostanza è che elementi extra cominciano a inserirsi nel progetto, allungando tempi e attività previste.

Ben Aston:

Quindi, sì, è lavoro aggiuntivo non preventivato che impatterà su budget, scadenze e quantità di lavoro. Sono molte le cause, giusto? Non analizziamo tutto ora, anche se tu ne parli nel tuo articolo, però ci sono davvero molte ragioni.

Suze Hayworth:

Sì, moltissime.

Ben Aston:

Per te, quali sono le tipiche? Parliamo delle comuni, e poi magari di quelle più insidiose?

Suze Hayworth:

Le più diffuse che ho notato sono, innanzitutto, la poca chiarezza iniziale sull’ambito. Se scrivi un documento dei requisiti troppo vago o poco preciso, i clienti (oppure il team) possono interpretarlo in modo diverso e, di conseguenza, si generano aspettative differenti che fanno crescere il progetto. Quindi fondamentale essere chiari fin dall’inizio su cosa si consegna effettivamente.

Di conseguenza, bisogna assicurarsi che chi approva il documento sia davvero consapevole di quello che riceverà. Il documento di progetto è utilissimo per elencare tutto, ma spesso è lungo e articolato. Devi assicurarti che i punti chiave—cosa riceverà il cliente, tempistiche e costi—siano ben evidenziati e spiegati. Se pensi che abbiano letto tutto, ma poi vedi feedback molto specifici, potrebbe significare che qualcosa non era chiaro, oppure che c’è una diversa interpretazione.

Insomma, spesso nascono problemi perché un documento viene approvato, ma più avanti qualcuno pensa che certe cose dovessero essere incluse, anche se magari non erano nemmeno state citate esplicitamente inizialmente.

Ben Aston:

Sì, ad esempio potremmo promettere una pagina modello, ma senza definire cosa dovrebbe includere. Oppure—è una questione di comunicazione, giusto? Il cliente magari interpreta la parola “template” diversamente da noi.

Suze Hayworth:

Esattamente. Ci sono questi due aspetti: definire con chiarezza le consegne e assicurarsi che chi firma il documento capisca perfettamente. Anche se sei stato chiaro, possono restare fraintendimenti.

Ben Aston:

Quindi hai evidenziato due cause tipiche: poca chiarezza iniziale e mancata comprensione da parte del cliente. Quelle sono le più comuni.

Ma voglio sapere delle derive più subdole, quelle che avvengono senza accorgersene. Raccontaci qualche esempio dalle tue esperienze?

Suze Hayworth:

Tipicamente si pensa che la deriva venga dai clienti perché chiedono sempre qualcosa in più. In realtà può nascere anche dentro ai team interni. Se i membri del team non sono allineati su cosa devono produrre, possono facilmente aggiungere dettagli o funzioni non previste, allungando tempi e codice senza rendersene conto. Un designer, ad esempio, può sviluppare qualcosa senza averne valutato l'impatto sull'implementazione.

Succede anche che alcuni stakeholder interni abbiano obiettivi autonomi e tendano ad ampliare l’ambito per motivi di relazione interna o perché accolgono richieste extra. Capita spesso! Quindi è una deriva più subdola perché all’interno si pensa di essere sulla stessa lunghezza d’onda, ma non sempre è così.

Ben Aston:

Concordo! Una delle cause principali delle derive insidiose è proprio l’interno: “over-delivering”, cioè aggiungere valore che nessuno ha chiesto. Succede spesso in area strategica, UX, design, ma anche nello sviluppo. Magari qualcuno vuole fare un lavoro straordinario oppure creare qualcosa da mostrare a un premio, ma nessuno si è chiesto chi pagherà tutto ciò.

Suze Hayworth:

Esatto.

Ben Aston:

O chi se ne assume la responsabilità! Quindi andare “fuori pista” è proprio…

Suze Hayworth:

Bella espressione.

Ben Aston:

Già, quando le persone danno interpretazioni soggettive alle richieste. Un altro esempio che citi nel tuo articolo è la QA. Se in fase di test non definiamo bene a monte i criteri di accettazione, il team potrebbe testare su browser superati come IU9 invece che solo dove serve, sprecando così tempo e risorse. Ti è mai capitato?

Suze Hayworth:

Assolutamente sì! QA è una delle aree dove la stima è difficilissima. A inizio progetto possiamo stimare tempi di sviluppo, ma per QA è davvero difficile sapere quanti cicli di test o correzioni serviranno. Se non definisci parametri chiari (bug prioritari, browser/dispositivi da testare, ecc.), rischi di prolungare esponenzialmente la fase di QA. Serve quindi chiarire tutto all’inizio: criteri di accettazione, matrici browser/dispositivi, priorità dei problemi rilevati. Alcuni bug minori possono essere lasciati per release successive o non sistemati affatto se non impattano davvero il rilascio.

Quindi di nuovo: definire il perimetro quanto più possibile e comunicare costantemente. Se scopri che stai spendendo molto tempo su un dispositivo o browser, parlane subito col cliente e valuta se ha senso proseguire o procedere con alternative. La comunicazione tempestiva e la proposta di soluzioni è fondamentale per gestire le derive della QA.

Ben Aston:

Mi piace molto questo approccio. Abbiamo quindi parlato di diverse cause della deriva, tra cui chiarezza, “over-delivery”, QA… ma di chi è la responsabilità? È utile capirlo per sapere come intervenire. Dicevi che coinvolge anche il project manager e non solo cliente o team: quanto pesa la nostra responsabilità?

Suze Hayworth:

Non è questione di attribuire colpe, ma di individuare i rischi. Vale la pena analizzare chi potrebbe innescare derive e come anticipare questi scenari. Spesso guardiamo agli altri—il team, il cliente—ma anche noi PM abbiamo responsabilità, ad esempio nel non segnalare subito i problemi. Anch’io, lo ammetto, a volte ho preferito risolvere silenziosamente senza parlarne subito per non sembrare negativa o lamentosa, ma rischia di peggiorare la situazione!

In realtà, meglio essere trasparenti e coinvolgere subito il cliente quando c'è un problema, proponendo anche delle soluzioni concrete. Così la conversazione è più costruttiva e si evita di accumulare questioni non affrontate che poi diventano ingestibili. Non bisogna “prendere in carico” tutto da soli solo per piacere al cliente, ma mostrargli l’impatto delle nuove richieste e proporre eventuali soluzioni o alternative.

Ben Aston:

Esatto: essere trasparenti, proattivi, e proporre alternative è fondamentale. Spesso, per paura di compromettere il rapporto col cliente, tendiamo a minimizzare i problemi invece di affrontarli subito, e alla fine ci troviamo in situazioni complicate—meglio parlarne subito!

Un altro punto, che citi nel tuo articolo, è che la deriva dell'ambito è associata soprattutto ai progetti waterfall, caratterizzati da molta pianificazione iniziale. Ma è un problema anche per i progetti agili? E se sì, in che forma?

Suze Hayworth:

Sì e volevo proprio sottolineare questo nell’articolo: spesso vediamo la deriva dell’ambito come qualcosa di negativo da evitare, ma uno dei principi dell’agile è invece proprio l’accoglienza del cambiamento come opportunità di migliorare prodotto o servizio finale. Quindi la sfida non è il cambiamento in sé, ma come lo gestiamo.

Nei progetti scrum, ad esempio, si pianifica ogni sprint ma può capitare che il product owner voglia inserire altre richieste “in corsa”. Va bene, ma bisogna valutare di volta in volta se bilanciare i carichi riducendo o riprioritizzando altro, e non solo aggiungere.

La fortuna della metodologia agile è che, grazie a iterazioni brevi, è più semplice adattarsi alle modifiche e mantenere sotto controllo l’ambito, a patto di avere delle regole e una comunicazione chiara con tutti i partecipanti.

Ben Aston:

È bello cambiare il punto di vista sulla questione: invece di vedere la deriva come un male, considerarla come uno spunto positivo e mantenere un dialogo aperto sulle priorità (budget, funzionalità realmente utili, ecc.). Così si evitano i “traumi” dell’ultimo minuto e si lavora insieme a soluzioni migliori per utente e progetto.

Suze Hayworth:

Vero! Bisogna coinvolgere costantemente il cliente, verificare se la nuova richiesta ha veramente senso per l’utente finale o se è solo “rumore”. Se è davvero utile, si può ridefinire cosa prioritizzare e cosa invece scartare o rimandare—con logica e trasparenza.

Ben Aston:

Ottimo consiglio: dialogo costante, attenzione all’utente. Cambiamo la prospettiva da “deriva = problema” a “deriva = opportunità”. Può essere un bene sia per cliente che per team! Basta non ignorarla e affrontare tutto proattivamente.

Infine, per chi dice: “il mio problema è che tutti i progetti vanno fuori budget e oltre le scadenze, la deriva ci travolge sempre”, quale sarebbe il tuo suggerimento numero uno per chi vuole ritrovare il controllo?

Suze Hayworth:

Se inizi su un nuovo progetto, la cosa più importante è lavorare bene sulle stime e sul documento di ambito. Non fare tutto da solo: confrontati col team e assicurati che le stime siano condivise e il più accurate possibile (restano stime, ma devono essere realistiche). Così riduci il rischio di vedere tempi e costi sfuggire di mano.

Se invece entri in un progetto già avviato che sta andando fuori controllo, il consiglio è: valuta la situazione, verifica quanto manca al traguardo, comunica apertamente con il cliente su eventuali problemi e discuti insieme eventuali aggiustamenti.

Ben Aston:

Perfetto. Grazie Suze per essere stata con noi! È stato un piacere, e ricordiamo che Suze, come esperta DPM, sarà anche nella nostra prossima edizione del corso “Mastering Digital Project Management” che parte a febbraio. Se non sai di cosa parlo ma vuoi formazione sul project management, visita DPMschool.com e iscriviti prima che il corso sia al completo. Vuoi interagire sulla deriva dell’ambito? Commenta il post e vai nella sezione risorse di TheDigitalProjectManager.com per unirti al nostro team Slack pieno di discussioni interessanti. Alla prossima, grazie per averci ascoltato.