Cosa puoi smettere di fare nei tuoi progetti (con Patrice Embry)

Leggi la trascrizione:

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

Ben Aston:

Grazie per essere all'ascolto. Sono Ben Aston e questo è il podcast del Digital Project Manager.
Ci sentiamo sempre dire tutte le cose che dovremmo fare, e io stesso spesso lo dico agli altri. C'è questa pressione di migliorarci, di fare tutto per bene e, in realtà, la pressione di essere visti mentre facciamo la cosa giusta è piuttosto immensa, ma dobbiamo davvero fare tutte queste cose, sempre? Continua ad ascoltare questo episodio per scoprire come puoi risparmiarti un sacco di tempo eliminando o riducendo alcune delle attività dalla tua routine di PM che potresti non dover includere in ogni progetto.
Parleremo di come puoi riprenderti un po' della tua vita, passare meno tempo in ufficio o alla scrivania, eliminando sei attività da cui potresti risparmiare tempo. E questo podcast parla proprio di liberarsi dei vincoli dei "dovrei" e dei "devo", e diventare un po' più efficienti nel modo in cui facciamo le cose.
Oggi sono insieme a Patrice Embry che è — e devo proprio dirlo — probabilmente la partecipante più attiva nel nostro team su Slack, e se non ti sei ancora iscritto, potresti parlare ora con Patrice. Se vai nella sezione community di Digital Project Manager ti puoi registrare da lì. Patrice è quasi sempre presente e sempre pronta alla conversazione, quindi è una persona da conoscere.
Per introdurla brevemente, Patrice è una project manager digitale freelance; è anche certificata come scrum master, livello due. Lavora nel settore da molti anni, in ogni tipo di agenzia e azienda. Ascolta anche altri nostri podcast per capire meglio che tipo di lavoro ha fatto. Ha lavorato su tutto, quindi è davvero una persona da conoscere.
Benvenuta Patrice.

Patrice Embry:

Ciao. Grazie per l’invito.

Ben Aston:

Prego, è un piacere. Patrice, puoi raccontarci dall'ultima volta che ci siamo sentiti se ci sono dei progetti interessanti su cui stai lavorando in questo periodo?

Patrice Embry:

Ho appena concluso un’app su cui lavoravo, che aiuta persone in cerca di lavori a breve termine o da svolgere rapidamente. Una specie di Care.com, ma ancora più veloce, per chi ha urgente bisogno di lavori temporanei. Era un'app davvero interessante. Non è ancora stata lanciata del tutto, è in beta, quindi non è ancora disponibile al pubblico, ma è stato un progetto stimolante anche perché ho lavorato con persone da tutto il mondo.
Non avevo mai lavorato con nessuno dalla Nigeria prima d’ora, quindi questa è stata la prima volta che ho salutato in Igbo. Davvero divertente.

Ben Aston:

Sembra quasi una truffa, il classico progetto nigeriano! Il team di sviluppo era lì?

Patrice Embry:

Come scusa?

Ben Aston:

Il team di sviluppo era lì in Nigeria?

Patrice Embry:

Sì.

Ben Aston:

Davvero?

Patrice Embry:

Sì. Il front end designer era… il front end developer era in Nigeria. Il developer back end era in Messico e il nostro technical lead era in Svezia. Poi c’ero io fuori Philadelphia e il cliente, che stava a Boston. Eravamo davvero sparsi ovunque.

Ben Aston:

Deve essere stata tosta con tutti quei fusi orari diversi.

Patrice Embry:

Sì, davvero.

Ben Aston:

Non dev’essere stato semplice. Come avete fatto a far funzionare il tutto?

Patrice Embry:

Ho trovato un orario che andava bene più o meno per tutti, le 8:00 di mattina Eastern Time. Gli amici europei lavoravano tardi, era abbastanza tardi anche per il nostro amico nigeriano, e il collega messicano si doveva svegliare prima di quanto volesse – ma ce l’abbiamo fatta.

Ben Aston:

È per una start up questa app?

Patrice Embry:

Sì. Penso sia un servizio nato da una donna che ha iniziato aiutando alcune persone, e poi sempre più gente le ha chiesto supporto. Così ha deciso: "Non riesco più a coordinare tutto da sola, facciamo un'app." È davvero all’inizio, quindi non voglio svelare troppo, ma quando sarà lanciata vi informerò. Credo possa diventare un servizio molto utile.

Ben Aston:

Sembra un progetto interessante. Quali sono state le principali sfide che hai incontrato? È stato lineare o ci sono stati momenti difficili?

Patrice Embry:

Un po’ difficile perché il cliente non era molto esperto di computer o di app, aveva una conoscenza base. Come sai nel mondo tech di solito si ha una maggiore comprensione di come funzionano certe cose, e quindi ho dovuto spiegare spesso.
Era come spiegare a un amico che non usa il computer tutti i giorni come funzionano certi processi. In progetti come questo ci si rende conto di quante cose non vengono mai messe in conto. Il test – motivo per cui è ancora in beta – è stato molto intenso; scoprivamo percorsi mai considerati prima. È stato impegnativo ma divertente. Bello collaborare tutti insieme e l’idea è molto valida. Sono soddisfatta del risultato.

Ben Aston:

Che strumenti hai utilizzato per gestire tutti questi membri del team e i diversi fusi orari? Come hai raccolto i requisiti da un brief iniziale così poco definito e gestito l’evoluzione del progetto?

Patrice Embry:

Era davvero poco definito. Non c’erano molti soldi a disposizione, e questo si collega bene a ciò di cui parleremo oggi. Non avevo molte ore da dedicare a varie attività. Dovevo scegliere con attenzione cosa fare e cosa no, perché volevo risparmiare più ore possibile per lo sviluppo vero e proprio.
Abbiamo utilizzato Slack perché è gratuito. Trello perché è gratuito. E molti Google Docs, sempre gratis. Dovevamo capire come far funzionare tutto senza opzioni a pagamento, cercando di essere quanto più snelli possibile per questa donna e il suo progetto.

Ben Aston:

Come hai trovato questo progetto? È stato tramite passaparola?

Patrice Embry:

Sì. Come hai detto sono sempre su Slack, non solo il tuo! Essendo freelance, devo mantenere i canali di comunicazione sempre aperti con tutti per essere aggiornata e cogliere opportunità. Parlo con tante persone di tante cose.
Non ricordo nemmeno bene il percorso che mi ha portato a questo progetto, sicuramente tramite passaparola o reti di contatti. Faccio molto networking e spesso le opportunità arrivano in modi insoliti.

Ben Aston:

Hai assemblato tu il team di progetto?

Patrice Embry:

No.

Ben Aston:

Te ne sei occupata tu?

Patrice Embry:

No, sono stata inserita in un gruppo di persone e abbiamo semplicemente deciso chi faceva cosa. Non ho dovuto trovare io le risorse, ma sono contenta del team con cui ho lavorato. Spero lavoreremo ancora insieme; ho apprezzato molto il contributo di tutti.

Ben Aston:

Sì, interessante. In questi progetti spesso il cliente non è molto esperto ma questo apre anche a molta flessibilità, il che è positivo: un cliente che si fida, non sa davvero cosa sta facendo ma lascia fare a noi — è il momento migliore! Si può davvero fare bene.
Il lato negativo è quando bisogna dire: "Ok, prova a premere Control F5."

Patrice Embry:

C'è stato molto di questo! Però sai, è importante ricordare che se stai realizzando un’app per il grande pubblico, non tutti hanno lo stesso livello di conoscenza. È stato utile tornare alle basi, sia come team che come app: non si possono dare certe cose per scontate. Ad esempio, che usando il dito si possa scorrere un modulo — abbiamo dovuto spiegare esplicitamente che era necessario scorrere. È stato utile per il progetto.

Ben Aston:

Esatto. Passiamo a ciò che hai già accennato. Abbiamo parlato su Slack della realtà di come gestiamo davvero i progetti: c’è la teoria e poi la pratica quotidiana, con tutte le incombenze da sbrigare. Soprattutto se si hanno certificazioni come PMP, si conoscono i processi e tutti i registri e report di stato da aggiornare. È un incubo amministrativo.
La verità è che siamo sempre sovraccarichi, sempre con qualche documento o dettaglio da aggiornare. Mi è sembrato interessante parlare del vero motivo per cui facciamo alcune attività: sono davvero necessarie, o stiamo investendo troppo in quelle sbagliate? Hai menzionato poco fa l’idea di "inizia, smetti, continua": cosa dovremmo iniziare a fare, cosa smettere o ridurre, cosa portare avanti?
Vorrei sapere il tuo punto di vista sugli elementi imprescindibili. Quando inizi un progetto, quali sono per te le cose non negoziabili, senza le quali il progetto è destinato a fallire?

Patrice Embry:

Per me sempre la timeline e i requisiti. Poi viene il budget, che è importante ma in modo diverso a seconda dei progetti. Ma una timeline dettagliata è fondamentale. E non si può fare a meno dei requisiti, altrimenti non si sa cosa si sta facendo, né tu né il team. Questi sono imprescindibili per me.

Ben Aston:

Per chiarire: quando parli di requisiti non intendi uno statement of work, giusto? In che formato allora sono i requisiti?

Patrice Embry:

Ottima domanda: non devono necessariamente essere in un documento, ma bisogna sapere qual è lo scope e anche andarlo un po’ oltre. Se guardo uno statement of work, spesso molte cose sono date per scontate e c’è un ulteriore livello da definire: funzionalità, dettagli, cose da approfondire e realizzare perché lo scope si realizzi. È di questi requisiti che parlo.
Devono essere definiti, le persone devono sapere cosa sono. È la base del lavoro del team. Altrimenti nessuno sa cosa si sta costruendo. Questi sono i tipi di requisiti di cui parlo.

Ben Aston:

Verissimo. Anche per me: stime, timeline, statement of work sono i documenti da cercare subito all’inizio di un progetto, quello che ti permette di fare il punto della situazione. Se non sai i tempi e i requisiti, non puoi controllare o gestire il progetto.

Patrice Embry:

Come si fa a sapere se è finito? Come facciamo a sapere se non ci siamo fermati? Esatto.

Ben Aston:

Di solito quando erediti un progetto, spesso alcune cose sono già un po' outdated — in particolare sui requisiti o lo statement of work. Qual è la tua strategia per mantenere queste informazioni aggiornate durante il progetto?

Patrice Embry:

Ricordo sempre al team la timeline a ogni incontro, almeno una volta a settimana o ogni due. Ricordo a tutti dove siamo, qual è la prossima scadenza, e qual è la scadenza dopo ancora — così sappiamo verso cosa stiamo lavorando.
Ricordo la data finale, verso dove stiamo andando. Non sempre la data di lancio, spesso la fase QA o UAT. Se cambia, aggiorno sempre tutti e se rischiamo di sforare lo faccio sapere ancora più spesso.
Sui requisiti, cerco di tenerli il più aggiornati possibile. Se lavoriamo con un sistema tipo Trello o Jira si possono monitorare discussioni e aggiornamenti in tempo reale su ogni feature, tutto in un unico posto, ricercabile.
Se non usi questi tool, bisogna tenere aggiornato qualche tipo di documentazione: tutto ciò che decidi con il cliente, ciò che aggiungi o risparmi, le cose da includere. È un aggiornamento continuo della documentazione, qualunque essa sia.

Ben Aston:

Sì, anch'io spesso scrivo uno statement of work e poi faccio richieste di modifica o aggiornamenti ogni volta che il progetto devia, in modo da avere sempre una firma del cliente su ogni cambiamento.
Tutta questa tracciabilità diventa importante soprattutto quando ci sono tanti interlocutori o non è chiaro chi davvero gestisce il progetto. Avere sempre una traccia scritta può fare la differenza.

Patrice Embry:

Assolutamente.

Ben Aston:

Se questi sono i non negoziabili (statement of work, requisiti, timeline, stime), parliamo allora di alcune delle attività che forse non servono sempre o non vale la pena rendere troppo complicate.
Uno degli aspetti che citi nell’articolo è il budget dettagliato e la scomposizione del progetto. Ce ne parli?

Patrice Embry:

Sì. Ho iniziato in contesti con processi molto rigorosi, come un ingranaggio in un grande meccanismo, dove tutti i PM dovevano fare tutto nello stesso modo. Da freelance o in agenzie più piccole mi sono resa conto che non sempre si può fare tutto, altrimenti il budget non regge.
Quando lavoravo nella grande agenzia, dovevamo avere budget dettagliatissimi. Li preparo ancora in modo tradizionale, su un foglio di calcolo con tabelle pivot, formattazione condizionale, riferimenti tra celle; percentuale svolto/da svolgere rispetto al budget, aggiornamenti settimanali per ruolo.
È un sistema molto robusto, utile per rispondere ad ogni domanda in ogni momento, ma richiede molto tempo. Se mantenere tutta questa analiticità non interessa al cliente, o al committente, forse è meglio evitare.
La mia proposta a chi si chiede "Devo davvero fare tutto questo?" è: quanto serve realmente? Puoi fare meno? Peggiora il progetto se fai di meno? Fai solo ciò che serve davvero al progetto, non solo per senso del dovere.

Ben Aston:

Interessante. Gestisci il tempo di project management come percentuale delle ore totali, o per task?

Patrice Embry:

Una volta lo gestivo a percentuale, soprattutto nelle grandi agenzie. Ho molta esperienza in posti diversi, ho imparato tanto da tanti ambiti. Prima lo facevo come percentuale, utile se puoi assorbire imprevisti. Ora invece analizzo ogni task. Faccio breakdown per tutte le attività e, se uso la percentuale, la applico alle singole task, non al totale generale.
Penso vada bene continuare così se funziona per te; per me ultimamente non copriva le necessità.

Ben Aston:

Non bastavano le ore?

Patrice Embry:

Sì, non bastavano, oppure…

Ben Aston:

Che percentuale usavi?

Patrice Embry:

Spingevamo per il 20% per l’account management, più un ulteriore 20% per il project management — è tanto.

Ben Aston:

È il 40%!

Patrice Embry:

Esatto, ma la percentuale non risolve tutto: se il prezzo di base è sbagliato, la percentuale è comunque inutile. Se il progetto è sottostimato, non basta comunque. Di solito il problema stava nella base di partenza del budget, più che nella percentuale in sé.

Ben Aston:

Concordo. Anch’io penso che, a seconda del cliente, dobbiamo adattare il dettaglio del budget e delle proiezioni. Oltre questo, c’è il tema della disponibilità del cliente a pagare per questo dettaglio. Se il cliente vuole essere molto dettagliato sui costi per risorsa, bisogna spiegargli che farlo costa.
So che esistono tool di gestione che integrano tutto; nella realtà spesso è un processo manuale: ore trascritte a mano, calcoli su fogli di calcolo. È un grande investimento di tempo.
Se scegliamo la via più leggera e rinunciamo ai budget dettagliati, come monitori l’andamento? Come lo fai in modo snello?

Patrice Embry:

In passato facevo proiezioni delle ore, breakdown per ruolo, poi inserivo i consuntivi e aggiornavo le proiezioni per il resto del progetto. Se prendevo più ore in una settimana, le recuperavo nelle successive modificando le proiezioni totali.
Questa sarebbe la prima cosa che eliminerei se non avessi abbastanza tempo o budget: niente più aggiornamenti dettagliati ogni settimana. Ti permette di individuare subito i problemi, ma costa tanto tempo.
Ci sono altri modi per individuare red flag: per esempio, eliminerei tutte le analisi super dettagliate e mi concentrerei su alcune metriche base — siamo in linea col budget? Abbiamo abbastanza ore? La percentuale di progresso è simile a quella delle ore già consumate? Se sì, avanti così, senza complicarsi troppo la vita.

Ben Aston:

Giustissimo. Va anche detto: in progetti grandi il burn rate è molto superiore. Serve più attenzione, più controlli; in piccoli team, ci si può permettere di lasciare correre un po’ di più senza problemi.

Patrice Embry:

Sì, io comunque controllo tutto ogni settimana, ma analizzo meno dettagli. A volte ho avuto clienti o subappaltatori che dichiaravano "non importa se andiamo fuori budget, basta che tu stia nel tuo". Sembrano situazioni ideali ma in realtà generano ansia — senza parametri tutto rischia di deragliare. Anche se mi dicono che il budget non è un problema, io il controllo lo faccio comunque; non sarebbe professionale il contrario.

Ben Aston:

Quando ti dicono che il budget non conta, è quasi sempre fuorviante: c’è molta differenza tra sforare di 10mila o di 100mila!

Patrice Embry:

Sì. Dopo un po’ ti ci abitui e può andare tutto fuori controllo. Mi è capitato e non è per niente piacevole.

Ben Aston:

Quando il team dice: "Ah, il budget lo abbiamo sforato mesi fa…"

Patrice Embry:

E chi se ne importa.

Ben Aston:

E poi la situazione peggiora. Quando il budget residuo scende a zero, cosa facciamo, mettiamo numeri negativi?
Qualcuno deve tenere traccia. Abbiamo accennato ai report di stato: quanto devono essere dettagliati? Io in genere aggiorno cliente su stato budget, ore spese, stato attuale, piano per la settimana successiva, rischi, problemi. Possiamo inserire qualsiasi cosa in un report di stato! Tu come lo adatti?

Patrice Embry:

A volte penso che i report di stato siano lo specchio del valore che pensiamo di portare. Se il tuo report non sembra solido, sei un bravo PM?
Non voglio sentirmi dire "Cosa fai con tutte queste ore?" Quindi spesso riempiamo i report per mostrare il valore nostro o dell'agenzia. Ma tutto va aggiornato e non sempre serve.
Per esempio la cliente dell’app non era molto tecnica. Le interessavano tre cose: se tutto procedeva bene, se avremmo rispettato le scadenze e se qualcosa era in attesa di una sua risposta. Spesso non partecipava nemmeno alle call di stato! Solo queste tre cose le interessavano.
Sprecare tempo in report ricchi di dettagli per clienti a cui non interessa è inutile.
Naturalmente ogni cliente è unico! La chiave è pensare a cosa serve davvero al cliente e non riempire di extra solo "per giustificare il proprio lavoro". Puoi tagliare molto dai report di stato se ti concentri solo su ciò che serve.

Ben Aston:

Verissimo. Spesso iniziamo un progetto riciclando modelli di report pensati per altri clienti, aggiungendo sempre più dettagli inutili. A volte il cliente non li legge nemmeno.
Meglio partire dal minimo e aggiungere su richiesta. Se serve più dettaglio, si può sempre aggiungere dopo. Se ti ci vogliono ore per compilare un report, è un campanello d’allarme.

Patrice Embry:

Ho avuto clienti che mi hanno chiesto più dettagli o prospettive diverse sui numeri. Ho spiegato che tempo e budget sono legati: ogni aggiunta richiede più ore di preparazione all’inizio può sembrare poco, ma su tante settimane fa la differenza. Di solito così li convinco a mantenere le cose semplici.

Ben Aston:

Esatto: basta spiegare che una piccola richiesta può costare migliaia di euro su tutto il progetto e il cliente spesso cambia idea.

Patrice Embry:

Proprio così.

Ben Aston:

Certo, se il progetto è rischioso o il cliente difficile, conviene monitorare i rischi e tenerli sempre esplicitati — non vogliamo rimanere scoperti senza prove di averlo fatto.

Patrice Embry:

Assolutamente.

Ben Aston:

Giusto, bisogna trovare il giusto equilibrio.

Patrice Embry:

La regola d’oro è: devi essere davvero sicuro per eliminare qualcosa. Se sei abbastanza esperto, puoi alleggerire; altrimenti meglio non tagliare. Il livello di fiducia lo si acquisisce con l’esperienza, il tipo di cliente o progetto, gli anni di lavoro come PM. Ognuno ha il suo livello di comfort, da cui farsi guidare.

Ben Aston:

Ben detto. Un punto che hai sollevato, e credo sia interessante, sono tutte le cerimonie Scrum. Se fai Scrum, sono centrali, lo insegnano nel training: planning, review, retrospettive… ma nella pratica, se le incastri tutte in sprint di una o due settimane, puoi passare giorni interi solo in riunioni.
La tua proposta è che a volte si possono unire più meeting o alleggerire il processo.

Patrice Embry:

Conosco persone molto legate a Scrum che non tollerano deviazioni! Ma penso che anche i veri Scrum Master concordino che bisogna fare solo ciò che serve davvero al progetto.
Se fai backlog grooming, planning e review tutti separati, può diventare eccessivo, soprattutto se il budget è limitato.
Molto ruota intorno a tempo e budget. Se li hai, fai pure tutto. Altrimenti, magari accorpa le riunioni. A volte è utile fondere grooming e planning subito dopo aver rivisto il backlog, così sfrutti la memoria fresca delle discussioni. Sta alle singole situazioni… ma se puoi chiudere tutto in 90 minuti invece che in tre ore, tanto meglio!

Ben Aston:

Ottima indicazione. Lo stesso vale per le retrospettive: lo scopo è il miglioramento continuo, ma spesso spendiamo ore a raccogliere feedback e statistiche che poi nessuno usa davvero. Se lo sprint è andato bene, basta una sintesi veloce e si va avanti.

Patrice Embry:

Va tutto bene, pollice su!

Ben Aston:

Non è necessario ingegnerizzare report inutili. Se va tutto bene, basta andare avanti senza perdere altro tempo. Ma spesso restiamo bloccati sul "così si deve fare", invece di essere pragmatici.

Patrice Embry:

Sì.

Ben Aston:

Meglio essere pratici, e concentrarsi su concludere bene il progetto.

Patrice Embry:

Sì. E a volte i report di stato servono solo a dimostrare il nostro valore ai clienti, mentre le retrospettive a farlo vedere agli stakeholder interni. Il punto resta: chiediamoci sempre quanto tempo vale davvero ogni attività — 5 ore, 2 ore, 30 minuti? Regoliamoci di conseguenza, e tagliamo dove possibile.

Ben Aston:

Giusto. E infine, parliamo delle riunioni di kick off. Nell’articolo suggerisci di valutare se siano addirittura necessarie, a volte può bastare una semplice email. Come fai a farla funzionare così?
Inizi un nuovo progetto, raduni il team, ognuno sa già cosa deve fare e mandi un’email con le istruzioni?

Patrice Embry:

Sì.

Ben Aston:

Ci vediamo tra una settimana?

Patrice Embry:

Esatto! Può sembrare strano ma mi è capitato in agenzie pharma dove si seguivano progetti molto simili per vari clienti. Non era tutto uguale, ma le differenze erano minime e il team quasi sempre composto dalle stesse persone, già assegnate.
Uno degli scopi delle kick off è chiarire i ruoli, ma se tutti sanno già cosa devono fare, magari si conoscono anche il cliente e il progetto è uguale a quelli precedenti, allora basta evidenziare le poche differenze, la timeline, i primi task.
In quei casi, era più utile ricevere un’email dettagliata, invece di sprecare 30 minuti in una riunione per sentire sempre le stesse cose. È stato molto apprezzato dal team. Se gestisci progetti ripetitivi con lo stesso gruppo, puoi evitare la riunione e mandare una mail di kick off. Ha funzionato benissimo.

Ben Aston:

Sì, ha senso quando si lavora su attività ricorrenti. Invece quando c’è qualcuno di nuovo o qualcosa di nuovo da introdurre, bisogna adattare. Più in generale, molti briefing includono informazioni ridondanti solo per completare un template, ma spesso basta focalizzarsi su ciò che serve davvero a partire.
Far perdere tempo col copia/incolla di parti inutili non è efficiente.

Patrice Embry:

Giusto.

Ben Aston:

Meglio puntare al concreto. "Ecco l’obiettivo, questi i task, è tutto chiaro a tutti?" Ogni progetto è un caso a parte; solo perché una volta hai fatto un lavoro eccezionale con tanto di documentazione dettagliata, non significa che serva lo stesso sforzo su ogni progetto. La chiave è adattare il metodo di lavoro a ogni situazione.

Patrice Embry:

Assolutamente.

Ben Aston:

Grazie Patrice per essere stata con noi! Se vuoi contribuire alla discussione, commenta il post di Patricia o vai nella sezione community su thedigitalprojectmanager.com e partecipa alla conversazione. Alla prossima, grazie per l’ascolto.