Fare le cose nel modo giusto (con Michael Luchen di Crema)

Leggi la trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Perdona eventuali refusi poiché il bot non è corretto al 100% delle volte.

Ben Aston:

È frustrante quando le cose non funzionano e quando passiamo settimane o mesi a costruire un progetto, solo per essere traditi da un bug subdolo all’UAT finale. Ma perché sembra che succeda quasi sempre e cosa possiamo fare a riguardo? Bene, se sei tormentato dai bug, continua ad ascoltare perché nel podcast di oggi parleremo di come possiamo fare le cose nel modo giusto con un prodotto e un processo migliorati e la magia di un piano di gestione della qualità.

Grazie per essere all’ascolto. Sono Ben Aston, fondatore dei project manager. Benvenuto al podcast DPM. Siamo in missione per aiutare i project manager ad avere successo, per aiutare chi gestisce progetti a ottenere risultati migliori. Siamo qui per aiutarti a portare il tuo lavoro di project management al livello successivo. Visita thedigitalprojectmanager.com per scoprire i nostri corsi di formazione e le risorse che offriamo con l’abbonamento. Questo podcast è sponsorizzato da Clarizen, leader del software di gestione di progetti e portafogli aziendali. Visita clarizen.com per saperne di più.

Oggi sono insieme a Michael Luchen, uno dei nostri esperti DPM residenti. È un coach di prodotto presso Crema, un’agenzia di prodotti digitali che crea web e app mobile per aziende innovative e leader del settore. Lavora solitamente da remoto da D.C. e aiuta a migliorare la collaborazione del team per analizzare e risolvere problemi complessi. Ha lavorato con Adidas, Callaway Golf tra gli altri, ed è coach presso Crema. Oggi parleremo con lui della creazione di un piano di gestione della qualità. Benvenuto Michael e benvenuto nello show.

Michael Luchen:

Ciao Ben, come va?

Ben Aston:

Bene, grazie. Sono curioso, dato che parliamo e registriamo podcast da anni, il tuo ruolo si è evoluto e mi interessa il ruolo di coach che hai ora, che è una novità penso. Puoi raccontarci un po’ cosa fa un coach di prodotto e cosa significa da Crema?

Michael Luchen:

Certo. Come hai detto, si tratta di circa sette anni di esperienza pratica nella gestione di progetti e prodotti. Francamente, il ruolo è in fase di definizione proprio ora. Stiamo cercando di capire cosa significa essere coach da Crema. Al momento lo vediamo come leader servente che aiuta i clienti a comprendere le pratiche Agile per diventare versioni migliori di sé stessi. Tipicamente posso fare da facilitatore, stratega di prodotto e design thinker per aiutare a ridefinire i problemi e trovare approcci innovativi. In questo momento quello che è interessante di questo nuovo ruolo e della nuova avventura per Crema è provare a lasciare il segno in un settore molto affollato da una prospettiva non prescrittiva. Esistono tanti processi di coaching prescrittivi, ma noi vogliamo essere diversi.

Ben Aston:

Quindi nel tuo ruolo vai con un piccolo team e lavori direttamente con il cliente. È più un ruolo strategico, ad esempio quando definisci la roadmap di progetto o di prodotto?

Michael Luchen:

Sì, è—

Ben Aston:

Oppure è più incentrato sulla delivery?

Michael Luchen:

… È simile a ciò che hai detto. Un po’ più ampio e più focalizzato sulle persone. Una delle cose che amo della gestione dei progetti è poter coltivare un ambiente sano per i team così che possano dare il meglio. Quindi si tratta di aiutare i clienti a fornire strumenti e mentalità per creare una cultura produttiva e un ambiente di lavoro sani nei loro team, per generare grandi risultati.

Ben Aston:

E quali sono le principali sfide che affronti aiutando i clienti a cambiare la mentalità della delivery?

Michael Luchen:

Le sfide possono essere molte, ma credo sia importante capire che i risultati non saranno sempre immediati. Non posso entrare e dire: fate questo e tutto migliorerà. Lì fuori ci sono tanti framework, tipo: impara il framework X e il tuo team avrà successo. Penso sia invece importante conoscere bene la cultura dell’organizzazione e capire che, quando dai potere ai leader con cui lavori, ci vorrà tempo per sperimentare e assimilare le lezioni.

Ben Aston:

Sì, è vero. Non esiste un processo unico che vada bene per ogni organizzazione o agenzia. Non basta seguire dei passaggi per ottenere risultati magici. Non esiste una bacchetta magica in grado di risolvere tutto. E a volte si pensa che, “Beh, Agile è la soluzione magica”, ma bisogna definirlo. Quindi è un ruolo interessante il tuo. E lavori principalmente da remoto o anche sul posto dal cliente?

Michael Luchen:

Decisamente una combinazione. Adesso, mentre registriamo, sicuramente 100% da remoto. Ma penso che le relazioni si costruiscano anche di persona, quindi se possibile è sempre bene iniziare coaching in presenza. Ho visto però che è possibile avere conversazioni produttive e significative su Zoom o usando Loom Screen Shares o facendo collaborazione su Mural. Si può fare sia in presenza che da remoto.

Ben Aston:

Già. Parlando di lavoro da remoto—siamo in piena quarantena da Coronavirus—e hai anche fatto un workshop per noi sul lavoro a distanza. Ma per chi se lo fosse perso, o per chi ora riflette sul lavorare da remoto: qual è il trucco o la tecnica più impattante per non impazzire lavorando da soli a distanza? Come affronti quel senso di isolamento?

Michael Luchen:

Bella domanda e molto attuale. Mentalmente cerco di ricordare che sto collaborando con altre persone: tante videocall Zoom quanto possibile sono preziosissime. Può sembrare banale, ma vedere le interazioni non verbali è utilissimo, soprattutto per un project manager. Faccio anche in modo di avere un monitor dedicato per vedere i volti dei colleghi durante la condivisione dello schermo.

Ben Aston:

Sì. Zoom è ottimo. Ma è facile, con Slack, finire a chattare solo via testo e dimenticare il valore delle relazioni e della comunicazione visiva. Una Zoom call fa davvero la differenza—quindi, vestitevi e fate una videochiamata!

Quindi, fai coaching sia da remoto che in presenza. Puoi raccontarci qualcuno dei progetti su cui stai lavorando attualmente?

Michael Luchen:

Ora sto facendo il passaggio completo dal product management al ruolo di coach. Sto concludendo un grande progetto enterprise pluriennale e posso affrontarlo con una mentalità da coach. C’è molta sovrapposizione quando il coaching si combina con la pratica. Ora sto facendo il punto sui servizi di coaching e sulla differenziazione di Crema, per servire i clienti con umiltà e competenza.

Ben Aston:

E quali difficoltà di delivery stai identificando come opportunità di miglioramento?

Michael Luchen:

Un’idea interessante alla quale stiamo pensando è vedere il coaching come curriculum universitario: sperimentazione e apprendimento autonomo sono fondamentali. Io faccio da facilitatore, guida e mentore con esperienza pratica.

Questo significa avere check-in regolari, retrospettive, osservazioni e note condivise: tipo, “Prova questa cosa alla prossima riunione”. Alla fine di alcune settimane o mesi, possiamo guardare indietro e vedere progressi significativi.

Ben Aston:

Come aiuti le grandi organizzazioni a individuare le aree più adatte per diventare più Agile?

Michael Luchen:

Si parte da un sondaggio: conversazioni aperte, non solo con un referente ma anche con project manager, sviluppatori e altri soggetti coinvolti. Si chiede cosa percepiscono più importante risolvere. Poi il mio team ed io analizziamo le risposte e le incrociamo con ciò che abbiamo colto dalle conversazioni, per identificare le 2-3 aree chiave su cui puntare per ottenere rapidamente buoni risultati.

Ben Aston:

In bocca al lupo!

Michael Luchen:

Grazie.

Ben Aston:

Vorrei tornare al post sull’argomento: gestione della qualità. Se non l’hai ancora letto, trovi tutto su thedigitalprojectmanager.com: si chiama come sviluppare un piano di gestione della qualità. Michael spiega passo passo il processo per creare il piano della qualità. E se sei iscritto puoi scaricare template utilissimi come il quality management plan, la lista dei dispositivi target e la checklist dei requisiti di qualità.

Qui non approfondiremo troppo il processo (lo trovi nel post), ma in sintesi Michael spiega come puoi realizzare un piano qualità per il tuo progetto o prodotto. Partiamo dal concetto di qualità: perché è difficile afferrarlo?

Michael Luchen:

Per cominciare, qualità per me significa due cose: qualità del prodotto e qualità del processo. La qualità del prodotto si riferisce al prodotto reale, digitale o fisico, e comprende tutto ciò che riguarda il lavoro del team di design e sviluppo. La qualità di processo, che come PM curiamo maggiormente, riguarda ciò che costruiamo come metodo e che incide sui risultati del team. Un esempio? La velocity, che misura la qualità dei processi.

Comprendere insieme la qualità è difficile per molti team, per la grande soggettività ed emotività in gioco. Ci sono molti stakeholder interni ed esterni, sviluppatori e designer, ognuno con la sua visione. Un cliente può puntare a una qualità “adeguata”, mentre uno sviluppatore potrebbe voler scrivere il codice perfetto. Va trovato l’equilibrio.

Ben Aston:

Parliamo di questo equilibrio. Agile prevede criteri di accettazione per ogni user story, ma spesso la qualità sembra in contrasto con la velocità della delivery iterativa. Cos’è più importante: rispettare tutti i criteri o consegnare valore?

Michael Luchen:

Domanda interessante. Credo che la qualità non sia in contrasto con Agile, ma sia un acceleratore e abilitante per il team Agile. Se, all’inizio del progetto, si definisce cosa significa qualità e cosa no, il team può lavorare meglio. I criteri di accettazione sono uno strumento per supportare Agile, non un ostacolo. Se cambia qualcosa durante una sprint, si modifica il criterio e si va avanti, serve a mantenere la qualità.

Ben Aston:

Quindi la qualità è componente del valore, non un ostacolo alla velocità. Se non rispettiamo i criteri, magari il valore che consegniamo non è quello che dovrebbe essere.

Michael Luchen:

Esatto.

Ben Aston:

Dividere le responsabilità della qualità: molte aziende hanno team QA dedicati, ma a volte tocca al PM o agli sviluppatori. Perché il test engineer è così importante?

Michael Luchen:

Da ex PM che ha fatto anche QA, posso dire che avere test engineer è una svolta. Hanno occhio critico verso la qualità, curano sia i dettagli tecnici che l’impatto finale per gli utenti. Coinvolgendoli diventano elementi chiave che moltiplicano il valore di tutti gli altri ruoli.

Ben Aston:

Il mindset di un QA o test engineer è molto diverso da quello di un PM, che spesso ragiona sul percorso ideale, mentre il QA cerca i percorsi che portano ai bug e rafforza la qualità finale. C’è sempre qualche bug che salta fuori.

Detto ciò, parlare di dispositivi target è complicato: come gestisci le aspettative dei clienti che vorrebbero funzionasse ovunque, anche su dispositivi o browser obsoleti?

Michael Luchen:

Determinare i dispositivi target è uno dei miei esercizi preferiti. Aiuta non solo sulla qualità ma anche a mettere a fuoco gli obiettivi chiave per l’utente finale. Se il cliente chiede di supportare ogni device e sistema, si inizia a discutere sui veri bisogni degli utenti. La conversazione sui dispositivi permette di focalizzare le priorità e ottimizzare tempi e risultati.

Ben Aston:

Attenzione anche, nello scrivere una dichiarazione di lavoro o criteri di accettazione, a non indicare troppo genericamente “supporta tutti i dispositivi ora e per sempre”, perché i browser cambiano e le cose si rompono, spesso non per colpa di nessuno. Bisogna essere precisi.

Veniamo alle strategie di test: test-driven development, test “al volo”, piani dettagliati… come vi regolate?

Michael Luchen:

Da Crema, la regola è che la qualità è responsabilità di tutti. Gli sviluppatori praticano il test driven development, integrando i test nel codice dove ha senso. Così il test engineer può concentrarsi su test manuali dal punto di vista dell’utente, scrivere test automatici ed esplorare casi limite.

Ben Aston:

Dire che la qualità è responsabilità di tutti rischia che non sia responsabilità di nessuno. Come fate in concreto?

Michael Luchen:

Molto parte dall’educazione e dalla discussione, anche su Slack. Ma soprattutto sono importanti processi e check di qualità durante le fasi di sviluppo. Per esempio, con JIRA creiamo flussi di lavoro che prevedono revisione del codice, passaggio su staging, e controllo QA prima del rilascio.

Ben Aston:

Quindi la qualità è integrata nel processo, non solo “prodotto finito, adesso QA”. E per i test automatici, come decidete quando conviene usarli?

Michael Luchen:

Il testing manuale è molto prezioso, soprattutto su esperienze utente complesse, come il drag and drop. Invece i test automated sono ottimi per azioni ripetitive o moduli complessi.

Ben Aston:

Sembra che il vostro piano di gestione della qualità sia molto integrato e organico: adattate le pratiche di test al progetto e ai componenti. Come sei sicuro di avere l’approccio giusto pur restando flessibili?

Michael Luchen:

Sono un grande fan dei processi organici. All’inizio si fa la prima stesura, seguendo framework già sperimentati. Poi si corregge man mano nelle prime settimane, in base all’esperienza del team. Raramente deviamo troppo, ma magari scopriamo che un device target non è utilizzato e possiamo adeguare la lista, dedicando più risorse altrove. E la volta dopo, ripartiamo dalle esperienze precedenti adattandoci al nuovo team.

Ben Aston:

Il buon senso conta tantissimo nella gestione della qualità: attenzione a non burocratizzare tutto in nome della qualità. Serve equilibrio fra pianificazione e adattamento, anche in chiave Agile. La documentazione serve se ha un senso, non solo per riempire scartoffie. Esplorate, adattatevi, incrementate il valore man mano.

Michael Luchen:

Esattamente.

Ben Aston:

Abbiamo lanciato da poco un podcast sul nostro sito gemello, QA Lead. Se vi interessa il QA, dite al vostro test engineer o QA di dare un’occhiata a qalead.com e, da PM, leggete il post: è dettagliatissimo e offre modelli e template tramite l’iscrizione.

Usa un piano di gestione della qualità: se non lo hai mai usato prima, prova! Ti aiuterà a ragionare sul processo, sui tuoi progetti/prodotti e su come offrire più valore aumentando la qualità finale.

Questi consigli sono utilissimi: soprattutto l’idea di coltivare la qualità a tutti i livelli dell’organizzazione. Anche senza ruoli dedicati, la qualità non è solo “è rotto o no?”, ma il riflesso del nostro processo. Pensiamoci spesso e teniamo una mentalità iterativa. Grazie Michael per gli spunti!

Michael Luchen:

Grazie a voi.

Ben Aston:

E voi che ne pensate? Quali sono le vostre soluzioni o errori nella delivery di progetti/prodotti di qualità? Raccontatecelo nei commenti.

E se volete imparare di più e crescere nel lavoro, unitevi alla nostra community di DPM: vai su thedigitalprojectmanager.com/membership per accedere a Slack, template, workshop, orari d’ufficio, ebook e tanto altro. Se vi è piaciuto l’episodio, iscrivetevi e restate in contatto su thedigitalprojectmanager.com. Alla prossima, grazie mille per l’ascolto.