Gestire un Progetto di 2 Settimane (Con Jenna Trunzo di Globant)

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Chiediamo scusa per eventuali errori di battitura, dato che il bot non è sempre preciso al 100%.

Ben Aston:

Benvenuti al podcast DPM, dove andiamo oltre la teoria per offrire consigli esperti di project management digitale. Grazie per esservi sintonizzati. Sono Ben Aston, fondatore di The Digital Project Manager. Nel selvaggio West digitale che chiamiamo casa, non è sorprendente se ci troviamo a dover gestire un progetto con un budget minuscolo, un ambito poco chiaro e una tempistica strettissima. Ma cosa fai se quella tempistica è di sole due settimane? Nel podcast di oggi parleremo di come pianificare ed eseguire efficacemente un progetto quando, a dire il vero, non c'è abbastanza tempo per farlo a regola d’arte. Continua ad ascoltare se vuoi scoprire cosa puoi eliminare e quali scorciatoie potrebbero affossare il tuo progetto.

Ben Aston:

Oggi sono in compagnia di Jenna Trunzo. Jenna è una Certified ScrumMaster, anche Certified Product Owner, e project manager presso Globant—almeno credo si pronunci così. È un’azienda a Raleigh, North Carolina. Parleremo un po' del suo percorso per diventare project manager, che descrive come un felice incidente. Scopriremo qual è stato questo incidente. Adesso usa le sue competenze per guidare i team in questa agenzia che parla molto di Agile. Voglio parlare anche di questo, ma ciao Jenna. Felice di averti qui oggi.

Jenna Trunzo:

Ciao Ben, grazie mille per l’invito. E hai pronunciato correttamente, si dice Globant.

Ben Aston:

Globant. Sai cosa significa Globant? È solo un nome, suona come “globale”?

Jenna Trunzo:

Mi piacerebbe inventare una storia intrigante, ma sinceramente non lo so.

Ben Aston:

Ho lavorato per un’agenzia chiamata FCV e tutti volevano sapere cosa significasse FCV.

Jenna Trunzo:

Già.

Ben Aston:

In realtà non significava nulla; era l’acronimo di False Creek Ventures, ma non suonava bene e non sembrava il nome di un’agenzia.

Jenna Trunzo:

Hai inventato storie quindi?

Ben Aston:

Così è stato. Peccato che pronunciato al telefono suonava come altro, perfino come MST.

Jenna Trunzo:

Già, non il massimo.

Ben Aston:

Bisogna stare attenti.

Jenna Trunzo:

Certo.

Ben Aston:

Basta con i nomi, raccontaci cosa fai a Globant.

Jenna Trunzo:

Certo. Sono project manager qui a Globant. Ci occupiamo di tutto: dalla migrazione dati all’intelligenza artificiale. È tutto basato su progetti, dipende dal tipo di lavoro. Ho gestito piccoli progetti fino a quello su cui lavoro ora, che è abbastanza grande. C’è molta varietà. Siamo circa 8.000 persone in azienda, qui a Raleigh siamo in 150.

Ben Aston:

Interessante. Raccontaci qual è stato il tuo percorso; lo definisci un felice incidente. Cos’è successo? Eri una graphic designer diventata marketing manager, poi project manager. Qual è il felice incidente? Raccontacelo.

Jenna Trunzo:

Sì, certo. Sono sicura che è capitato anche ad altri nei settori creativi. Quando lavoravo lì, molti incarichi venivano dati in outsourcing e le opportunità lavorative scarseggiavano. Sono originaria di Pittsburgh, Pennsylvania, e lì lavoravo in quel settore, ma le opportunità erano poche. Quando mi sono trasferita in North Carolina, sono stata assunta come marketing manager in un team immobiliare e ho fatto questo lavoro per quasi dieci anni. Mi è piaciuto molto, ma in sostanza svolgevo già compiti di project management, anche se non lo chiamavamo così.

Ben Aston:

Certo.

Jenna Trunzo:

Conoscevo alcune persone che lavoravano qui e avevo confidato loro che non ero soddisfatta dove mi trovavo. Mi dissero: "Dovresti davvero valutare questa azienda. Stiamo assumendo project manager, sembra molto quello che fai tu." Io però dicevo: "Non ho esperienza tech, non credo di essere adatta." Ho tentennato per un po', poi alla fine mi sono convinta e mi sono candidata. È stata una delle decisioni migliori che abbia mai preso: un felice incidente.

Ben Aston:

Fantastico. Quindi già facevi project management, ma in Globant cosa hai scoperto subito che ha richiesto un cambiamento nel tuo modo di lavorare?

Jenna Trunzo:

Beh, anzitutto lavoravo da casa. Lavoravo da remoto, ora lavoro in ufficio—anche questo è stato positivo—ma ci sono stati molti processi da apprendere e nuove tipologie di clienti e richieste. Spostarsi dall’immobiliare alla tecnologia è stato un grande cambiamento; alcune similitudini ci sono, ma anche molta nuova terminologia, nuovi processi, nuovi modi di lavorare. È stato un importante passaggio, ma molto positivo.

Ben Aston:

Ho notato che Globant parla molto di “pod” Agile. Molti cercano di implementare l’Agile in vari modi. Ci spieghi come funzionano questi pod, in quale lavori e come viene gestito?

Jenna Trunzo:

Certo. In Globant ci sono vari tipi di pod: ad esempio un pod di sviluppo, o di strategia—credo ce ne siano cinque. Io faccio parte di un pod ibrido, cioè si selezionano le persone più idonee ai ruoli richiesti dal progetto e si crea così il pod. È un team di progetto, ma la differenza è che valutiamo continuamente i nostri obiettivi e la nostra responsabilità. Da queste valutazioni elaboriamo metodi e metriche su come raggiungerli. Con la maturazione del pod, i membri più forti poi creano nuovi pod per progetti successivi come leader.

Ben Aston:

Quante persone sono nel pod?

Jenna Trunzo:

Dipende, possono essere da 3 a 20. In quello su cui lavoro ora siamo in otto.

Ben Aston:

Come vengono assegnate le risorse al pod? Quando arriva un nuovo progetto parte il pod già formato o viene creato?

Jenna Trunzo:

È il progetto che determina tempistiche e consegne. Il pod si crea per quel progetto, a meno che il pod funzioni così bene da essere mantenuto anche per altri progetti. Non succede sempre, ma idealmente sì. Resti nel tuo pod finché non si scinde o cambia progetto.

Ben Aston:

Quindi i pod cambiano spesso.

Jenna Trunzo:

Sì, esatto.

Ben Aston:

Sei quindi in un pod ibrido, ma di solito nell’Agile o nello Scrum puro non esiste il ruolo di project manager.

Jenna Trunzo:

Esatto.

Ben Aston:

Qual è il tuo ruolo quindi nel pod?

Jenna Trunzo:

Faccio molto project management tradizionale, anche se Agile spesso è inteso in senso lato. Mi occupo di budget, ambito, consegne ecc., ma riferito al pod è più la salute del team e del progetto, la responsabilità di mantenere il pod maturo e valutato.

Ben Aston:

Parlaci di valutazioni e maturità del team. Ci sono test specifici?

Jenna Trunzo:

Non veri e propri test, è più una discussione collettiva: "Abbiamo raggiunto gli obiettivi fissati?" Redigiamo una costituzione di gruppo; ogni 3-6 mesi circa ci auto-valutiamo: "Stiamo rispettando i criteri? Dobbiamo cambiare qualcosa?" Preciso che per noi è ancora un concetto nuovo: siamo stati acquisiti da Globant non molto tempo fa e ci stiamo adattando ai loro processi.

Ben Aston:

Tempi interessanti quindi!

Jenna Trunzo:

Proprio così.

Ben Aston:

Chiedo sempre che strumenti vengono usati, perché i PM sono curiosi di scoprire tool e pratiche. Che strumenti usi nel tuo kit del PM preferito?

Jenna Trunzo:

Sicuramente Advil! Scherzo. Lavoro in un ambiente molto collaborativo, i colleghi sono la mia risorsa più grande. Ci consultiamo spesso sul project work per avere pareri diversi: "Questo ti ha funzionato? Quello l’hai già testato?" A livello di strumenti veri e propri usiamo molto Jira, Confluence e Google Drive come hub principale, poi vari tool per i designer se necessario, ma questi tre sono i nostri punti di riferimento.

Ben Aston:

Classici intramontabili.

Jenna Trunzo:

Sì, proprio loro.

Ben Aston:

Parliamo allora del tuo caso di studio. Per chi non lo avesse ancora letto, come ho detto prima si tratta di un progetto di due settimane che ti è stato affidato. Raccontaci come ti è arrivato addosso. Per la maggior parte delle persone, sentirsi dire: "Ehi, devi consegnare questo progetto in due settimane" li metterebbe in crisi. Com’è andata?

Jenna Trunzo:

Così è stato.

Ben Aston:

Hai avuto una scelta o te l’hanno affidato senza alternativa?

Jenna Trunzo:

Un po’ e un po’. Avevo disponibilità, uno dei miei progetti si era appena concluso. In azienda comunque se non vuoi proprio lavorare a un progetto, puoi rifiutare. Ma a me piacciono le sfide creative, quindi ho accettato. Mi sono detta: in due settimane, cosa potrà mai andare storto?

Ben Aston:

Cosa potrebbe andare storto?

Jenna Trunzo:

Esatto, cosa può andare storto in due settimane!

Ben Aston:

Perché la scadenza era proprio due settimane? Nel tuo articolo parli di test già calendarizzati; era una data arbitraria o davvero improrogabile?

Jenna Trunzo:

Era fondamentale che fossero due settimane. L’azienda aveva organizzato test con utenti contando di essere pronta in tempo; erano vincolati a quei test e non riuscivano a completare in autonomia, quindi servivano prototipi cliccabili realizzati in due settimane, pronti per i test utente programmati.

Ben Aston:

Quindi avevi due settimane per creare prototipi funzionali da testare con gli utenti, senza margine. Puoi raccontarci meglio cosa dovevi prototipare? Per un prototipo valido servono funzioni complete, no?

Jenna Trunzo:

Sì, certo. L'azienda voleva testare l’interfaccia utente di un elettrodomestico. Dovevamo riprodurre l’attuale interfaccia su un elettrodomestico specifico, simulando l’esperienza d’uso di un consumatore. Ogni prototipo simulava un intero flusso utente: ogni pulsante portava avanti la sequenza. Dovevamo assicurarci che tutto corrispondesse.

Ben Aston:

Parliamo di un elettrodomestico vero, tipo un forno?

Jenna Trunzo:

Sì, esatto, tipo un forno a convezione.

Ben Aston:

Ottimo. E i vostri prototipi? Erano solo immagini della schermata del forno?

Jenna Trunzo:

Più o meno. Includevano tutti i pulsanti e le schermate che si attivavano premendoli. Se volevo automatizzare la cottura di un certo cibo, ad esempio, premevi il tasto X e la schermata mostrava A, B, C, D e E; se premevi Y la schermata cambiava in base alle esigenze dell’utente.

Ben Aston:

Interessante, usabilità nei forni!

Jenna Trunzo:

Sì, proprio così.

Ben Aston:

Il prototipo finale: erano wireframe cliccabili o cos’altro?

Jenna Trunzo:

Erano wireframe cliccabili con qualche dettaglio grafico in più come richiesto dal cliente—font, spaziature, parametri del design effettivo—ma fondamentalmente wireframe cliccabili.

Ben Aston:

Avete usato Envision per questo?

Jenna Trunzo:

Credo di sì, era Envision.

Ben Aston:

In due settimane siete partiti dalla base esistente, giusto?

Jenna Trunzo:

Sì, esatto.

Ben Aston:

Quindi lavoravate sulle diverse esperienze d’uso in modo da testare la comprensione da parte dell’utente?

Jenna Trunzo:

Esatto. Una delle difficoltà è stata che la design team del cliente ci ha dato specifiche sbagliate all’inizio—un bel problema con una deadline di due settimane, se fai la cosa sbagliata. Ci ha rallentato non poco.

Ben Aston:

Quando vi siete accorti dell’errore?

Jenna Trunzo:

Nell’articolo parlo dell’importanza delle stand up e delle demo quotidiane: con progetti così brevi, questo permette di correggere subito la rotta se qualcosa non va. Infatti c’erano check-in e demo giornalieri col cliente. Così ci siamo accorti subito delle specifiche sbagliate riuscendo a rimediare senza perdere troppo tempo.

Ben Aston:

Timeline e budget fissi, ma che margine avevate sullo scope? C’erano flussi obbligatori o potevate limare qualcosa?

Jenna Trunzo:

Non c’era molto margine: dovevamo produrre sei flussi completi e relativi prototipi. Se non li facevamo tutti il test utente sarebbe stato incompleto perché ogni flusso era connesso agli altri. Cambiare lo scope significava cambiare tutta l'esperienza.

Ben Aston:

Quindi scope e tempistica fissi.

Jenna Trunzo:

Esatto…

Ben Aston:

Come hai pianificato? Dopo il primo giorno vi siete accorti dell’errore, ma dovevate preparare 6 flussi in 10 giorni. Come avete strutturato il lavoro?

Jenna Trunzo:

Per quanto sia possibile pianificare cose del genere, abbiamo lavorato molto insieme all’inizio. Questo tipo di progetto ti spinge ad adattarti: devi abbandonare il process standard e trovare modi per essere efficienti per necessità. Abbiamo analizzato cosa ci serviva dal cliente e cosa avremmo consegnato, poi abbiamo visto che mediamente riuscivamo a fare un flusso ogni due giorni, sapendo che alcuni erano più brevi, altri più lunghi.

Ben Aston:

Capisco.

Jenna Trunzo:

Bisognava semplicemente riuscirci, non c’erano molte variazioni possibili.

Ben Aston:

Quindi, in pratica, per stare nei tempi avete timeboxato lo sviluppo di ciascun flusso, anche se magari ne servivano 12 giorni invece che 10?

Jenna Trunzo:

Sì, sapevamo che una volta sistemate le basi, il resto sarebbe andato più veloce. Dopo una buona demo, il feedback era chiaro e si poteva correggere la rotta. Conoscevamo la velocità del team e le ore disponibili. Era rischioso, ma questo è tipico dei progetti così brevi.

Ben Aston:

Oltre ai wireframe, c’era anche sviluppo vero e proprio?

Jenna Trunzo:

I developer li rendevano completamente cliccabili, ma non c'era un vero sviluppo software completo.

Ben Aston:

Dopo aver capito subito delle specifiche sbagliate, avete dovuto cambiare i piani. Come avete reagito?

Jenna Trunzo:

Abbiamo avuto un po’ di flessibilità di budget e inserito un developer extra per qualche giorno. Così siamo riusciti a rientrare nei tempi senza aumentare troppo i costi e a consegnare tutto.

Ben Aston:

Alla fine la pianificazione ha funzionato?

Jenna Trunzo:

Sì.

Ben Aston:

Era sufficiente come piano?

Jenna Trunzo:

Sì, credo che fosse abbastanza, visto il poco margine. È andata bene, e il rapporto col cliente era ottimo. Forse avrei potuto approfondire meglio con il tech lead quali flussi richiedevano più tempo, per aiutarli a organizzare i lavori nei giorni giusti, ma alla fine mi sono fidata delle sue decisioni: la fiducia nel team è importante.

Ben Aston:

C’è stata qualche parte del piano che non ha funzionato?

Jenna Trunzo:

Sono soddisfatta di quante cose avrebbero potuto andare male e invece non è successo. Forse sarei stata più ferma col cliente all’inizio, assicurandomi di avere tutto quello che serviva ancor prima di iniziare. Sembrava che fosse così, ma è meglio fargli ricontrollare due o tre volte: ci avrebbe evitato di perdere una giornata.

Ben Aston:

Lezioni apprese? Cosa faresti diverso la prossima volta?

Jenna Trunzo:

Abbiamo fatto molte scelte intelligenti, ma in progetti così sacrifici e compromessi sono inevitabili. Sto pensando cosa cambierei davvero...

Ben Aston:

Ci sono stati angoli che hai provato a tagliare ma hai dovuto coprire comunque, come un brief non fatto oppure daily scrum escluse poi fatte lo stesso?

Jenna Trunzo:

Non abbiamo fatto un kickoff formale: niente riunione di chiarezza dei ruoli. Non so se fosse davvero indispensabile, ma un minimo di struttura in più avrebbe aiutato invece di procedere con chi arrivava prima al risultato.

Ben Aston:

Chiaro.

Jenna Trunzo:

Più che kickoff, sarebbe servita una breve sessione di chiarezza sui ruoli. È stato un taglio che in qualche modo abbiamo pagato.

Ben Aston:

Sì, perché in progetti così stretti ogni minuto conta.

Jenna Trunzo:

Giusto.

Ben Aston:

La mattina del primo giorno hai poche ore per dare chiarezza e non puoi entrare in troppi dettagli, ma serve comunque definire chi fa cosa e cosa occorre per il successo finale.

Jenna Trunzo:

E chi lo fa.

Ben Aston:

Sì, chi lo fa.

Jenna Trunzo:

Esatto.

Ben Aston:

Fare questa chiarezza fa una grossa differenza sull’efficacia, ma spesso si sottovaluta perché pensiamo: “Se lo capisco io lo capiranno tutti, tanto non è complicato.”

Jenna Trunzo:

Vero, bisogna stare attenti anche con il cliente: non sempre ha le nostre conoscenze e magari pensa di capire, poi davanti al lavoro finito si accorge che non è così. Ecco perché ogni tanto conveniva spendere un’ora in più per definire bene tutto.

Ben Aston:

Bene Jenna, grazie mille per essere stata con noi. È stato un piacere.

Jenna Trunzo:

Grazie a te, davvero un piacere.

Ben Aston:

E voi? Avete mai gestito un progetto con una deadline folle? Com’è andata? Raccontateci come l’avete gestita, i compromessi fatti e quelli che avreste voluto fare (ma non ci siete riusciti). Visitate TheDigitalProjectManager.com e entrate nel nostro gruppo Slack. Troverete tante discussioni interessanti sul project management digitale. Se vi è piaciuta la puntata di oggi, iscrivetevi e lasciateci una recensione. Le leggiamo tutte e ci aiutano a migliorare il podcast. Grazie ancora e alla prossima!