Stai costruendo un portale web? In questo episodio, Rebecca Germond (Direttrice dei Servizi ai Clienti presso FCV) approfondisce gli strumenti, i processi e le sfide quotidiane specifiche della gestione della realizzazione di un portale. Realizza un portale web di successo imparando dagli errori reali e dalle storie di successo del suo team.
Questo podcast è offerto da Clarizen, il leader nei progetti aziendali e nel software di project management.
Link correlati:
- Clarizen | Software di Project Management
- Perché e come documentare le lezioni apprese (con modello di lessons learned)
- Scrivi uno Statement Of Work in modo semplice (con un modello)
- Recensione esperta: 10 dei migliori strumenti di project management
- Come stimare i progetti: guida completa a budget e stime dei costi di progetto
- Come condurre una riunione di sprint planning come un professionista (+ ordine del giorno)
- Agile vs Waterfall. Cosa dovresti usare per il tuo progetto?
- Conduci una sprint retrospective che sorprenderà il tuo team (Ecco come!)
- Unisciti al nostro team Slack per project manager
Leggi la Trascrizione:
Stiamo provando a trascrivere i nostri podcast utilizzando un software. Ti chiediamo scusa per eventuali errori, il bot non è sempre preciso al 100%.
Ben Aston:
Benvenuti al podcast DPM dove andiamo oltre la teoria per offrire consigli esperti di PM per guidare meglio i progetti digitali. Grazie per essere all'ascolto. Sono Ben Aston, fondatore di The Digital Project Manager.
I bisogni dei clienti stanno maturando e anche il ruolo delle agenzie digitali sta cambiando ed evolvendo. Poiché il processo di progettazione e sviluppo dei siti web è diventato più standardizzato, cresce la necessità di agenzie che possano essere non solo partner per il sito web, ma anche partner strategici e tecnici per realizzare non soltanto siti, campagne e landing page. Nel podcast di oggi, parleremo nello specifico dei portali: cosa sono, come si realizzano e alcune lezioni apprese se stai per intraprendere uno di questi progetti. Continua ad ascoltare se vuoi conoscere l'evoluzione delle agenzie digitali e un approccio di sviluppo prodotto all'ingaggio con il cliente.
Oggi sono con Rebecca Germond. Rebecca è direttrice dei servizi ai clienti presso FCV. Ha una solida esperienza in project management e comunicazione nei media. Ho avuto l'occasione di assumere Rebecca qualche anno fa. Ricordo il tuo colloquio: ti ho portato nella stanza e ho pensato, sì, assumerò questa ragazza. Non ricordo esattamente cosa ti abbia chiesto, ma ero sicuro. Ti ricordi l’intervista?
Rebecca Germond:
Me la ricordo. Mi sentivo sotto torchio. No, scherzo! Ma ricordo molto bene la vista dall’ufficio ed è stata quella a convincermi, credo, su FCV, oltre ovviamente alla nostra conversazione.
Ben Aston:
Quindi non sono stato io, ma la vista.
Rebecca Germond:
Già.
Ben Aston:
Rebecca, per chi si chiede di cosa ti occupi ogni giorno: cosa significa essere direttrice dei servizi ai clienti? È project management? È gestione clienti? Cosa significa oggi per te questo ruolo?
Rebecca Germond:
Sì, è un po' entrambe le cose, oltre a gestire il team dei PM, che è interessante. È un nuovo ruolo per me nell'ultimo anno circa. Non mi sporco più tanto le mani sui progetti come una volta, ce ne sono alcuni a cui non rinuncio, ma ora lavoro direttamente con i PM per assicurarmi che possano consegnare al meglio e dargli il supporto necessario. Inoltre, gestisco la maggior parte dei nostri clienti, quindi ho un rapporto clienti abbastanza stretto. In realtà, ho iniziato proprio in account management prima di diventare produttore/PM, quindi è anche un po' un ritorno alle origini, il che mi piace.
Ben Aston:
Bello. Per chi è interessato a questo ruolo di gestione di un team di project manager: com’è la tua giornata tipo? Come li gestisci? Perché non puoi essere nei dettagli di tutti i loro progetti ogni momento. Quando fai un check-in con loro, cosa fai davvero?
Rebecca Germond:
Ottima domanda. Generalmente rivedo molto lavoro o deliverable che vogliono inviare. Ad esempio, gli do feedback su uno SoW o una timeline. Se c’è qualche escalation, mi coinvolgo oppure aiuto i PM a gestire la situazione. Li incontro uno ad uno ogni settimana, ma siamo anche in contatto costante su Slack per sentire che tutti abbiano supporto ogni giorno. A volte partecipo alle riunioni più importanti con i clienti. Insomma, un po' di tutto.
In più, sono molto coinvolta nel processo di sviluppo commerciale in FCV. Seguo anche la parte operativa tipo quanto dobbiamo fatturare ai clienti o come stiamo gestendo il processo di Change Management. Molte altre cose fanno parte della routine quotidiana con il team dei PM.
Ben Aston:
Parlaci un po' del tuo percorso. Arrivi dall'account management. So che hai iniziato al Ministero del Lavoro. Come sei arrivata dal Ministero del Lavoro a un’agenzia digitale e alla gestione progetti? Com’è andato per te?
Rebecca Germond:
Quando ero a scuola, mia zia aveva un’agenzia interinale. Mi trovava dei lavori mentre cercavo la strada giusta. Sapevo di volere lavorare in agenzia. Ho avuto una posizione al Ministero del Lavoro, era un lavoro amministrativo governativo, ma è stato interessante. Mi ha fatto imparare molte dinamiche della macchina pubblica, cosa che poi è tornata utile perché la maggior parte dei progetti della mia prima agenzia e anche molti su cui lavoro ora in FCV sono relativi al settore pubblico. Quindi è stata una buona base.
Un giorno mi hanno mandata in un’agenzia, Manifest Communications a Toronto, per due settimane di lavoro temporaneo alla reception mentre una persona era in ferie. Mi hanno poi chiesto di restare per uno stage, che desideravo molto. Ho fatto tre mesi di stage e mi hanno assunta. Ho lavorato lì quattro anni. Inizialmente ero Account Executive, gestivo clienti e solo in parte progetti digitali. Questa parte è aumentata con il tempo. Dopo un anno sono diventata producer: circa il 60% digital, ma anche radio, broadcast e stampa, il che era molto interessante.
Ben Aston:
Bene. Siamo ancora nel primo trimestre dell’anno. Dal punto di vista crescita personale o professionale, oggi parliamo di portali e di come le cose si evolvano; hai degli obiettivi che ti sei data per quest’anno?
Rebecca Germond:
In realtà, quest’anno non voglio pormi particolari obiettivi professionali, sembra strano. È l’ultimo anno dei miei vent’anni quindi voglio solo vivere come una Millennial. Ho obiettivi di viaggio, quelli sì. A livello lavorativo, mi è piaciuto tanto lavorare a questo progetto di portale. Lo abbiamo trasformato in un prodotto su cui costantemente facciamo rilasci e miglioramenti. È una bella esperienza. Vorrei fare più progetti simili.
Ben Aston:
Bene. Abbiamo parlato di cosa fai, e delle sfide che magari affronti adesso: qual è il grattacapo più grande che stai cercando di gestire giorno per giorno, o in particolare oggi con un progetto?
Rebecca Germond:
Nella routine di ogni giorno, sono abituata a fare la "baby sitter" in team di progetto, se capisci cosa intendo. Chi lavora nella gestione progetti sa che si deve gestire una varietà di ego o personalità. Ora, sulla scala attuale, sono meno i progetti ma sono tutti all’interno dell’organizzazione, con esigenze e priorità diverse. Cercare di gestire tutto senza però togliere supporto ai PM, che per me resta fondamentale, è complicato. In più, ti ritrovi dentro a cose che non ti sembravano così importanti, tipo attività amministrative. Insomma, anche tenere aggiornata la mia lista di cose da fare è una lotta quotidiana.
Ben Aston:
Come tieni traccia delle attività? La tua to-do list segue un sistema?
Rebecca Germond:
Uso in gran parte Evernote per le to-do, ma abbiamo integrato da poco in Slack Workast: con questa puoi mantenere la lista delle cose da fare direttamente in un canale Slack e assegnarle se serve. Puoi anche solo annotare una cosa a te stessa in Slack e ti ricorda la scadenza. Siamo all’inizio, ma sembra interessante.
Ben Aston:
Si chiama Workast?
Rebecca Germond:
Workast, W-O-R-K-A-S-T.
Ben Aston:
Workast, nome simpatico.
Rebecca Germond:
Decisamente. Per ora bene. Il problema è che riesci ad arrivare alla tua lista o prima delle 9 o dopo le 17, perché il 70% della giornata lo passi in riunione telefonica o a rispondere alle mail in Slack: oggi essere produttivi è difficile.
Ben Aston:
Cos’altro c’è nel tuo kit PM? Ad esempio la tua to-do, che ti aiuta a dare priorità a ciò che conta. Cos’altro usi per gestire i progetti?
Rebecca Germond:
Ho parecchi strumenti. Negli ultimi anni abbiamo cambiato anche, ora però sono soddisfatta. Uso Evernote. Usiamo Jira ormai in modo serio. Tutti, compresi UX, designer e clienti, sono su Jira: così tutto è rintracciabile e si tengono le "ticket" sotto controllo. Uso Slack in modo assiduo.
Teams di Microsoft, lo stiamo testando come alternativa a Skype for Business: lo usiamo per le conference call coi clienti ed è andata bene. Uso Merlin per la schedulazione dei progetti. Usavamo MS Project, ma ne sfruttavamo solo il 15%. Manteniamo qualche licenza MS Project nel caso serva ai clienti. Spotify è indispensabile. E poi Outlook, anche se odio l’email!
Ben Aston:
A parte Workast, altri strumenti che ti hanno rivoluzionato la gestione dei progetti?
Rebecca Germond:
Non molto altro, ma il modo in cui usiamo Jira ora è interessante: integriamo notifiche su Slack, così solo le informazioni chiave arrivano lì, tipo se un ticket cambia stato o un cliente commenta: molto utile, perché nessuno legge le email di Jira. MS Teams è stato apprezzato anche da clienti che prima non volevo usare il video e ora invece sì.
Ben Aston:
Bene. Parliamo del tuo articolo, il tuo primo case study pubblicato. Complimenti, Rebecca.
Rebecca Germond:
Grazie.
Ben Aston:
Cos’è un portale? È solo un sito? Se no, cosa lo rende diverso?
Rebecca Germond:
Per me i portali sono piuttosto complessi perché sono solitamente personalizzati per molti tipi di utenti differenti, ognuno con proprie azioni, funzionalità o percorsi. In questo caso specifico avevamo tre livelli di utenti da considerare, e analizzare le loro interazioni reciproche è stato sottovalutato. In generale i portali diventano complessi proprio per le tante dinamiche che non incontri in un sito normale dove atterri e basta sulla homepage.
Ben Aston:
Quindi parliamo di interattività più ricca lato funzionalità dipendenti dal ruolo impostate o meno in base a cosa fai nel portale.
Rebecca Germond:
Esatto. Nel nostro portale, senza login la homepage non offre nulla. Ci sono barriere e l’onboarding clienti nel portale non è proprio semplice. Ci sono tanti aspetti che in un sito tradizionale non esistono.
Ben Aston:
Non parliamo in astratto: brevemente, quali sono le funzionalità di questo portale?
Rebecca Germond:
Perfetto. Il nostro cliente è un retailer di elettronica che serve clienti B2B, ossia aziende che ordinano prodotti in grandi quantità. Prima del portale, la gestione ordini era manuale: telefonavano all’account manager. Tutto molto complicato sia per loro che per i clienti. Cercavano una soluzione dove potessero loggarsi, visualizzare un catalogo prodotti a loro riservato e acquistare solo quelli. Inoltre, esistono meccanismi di sconto complessi: senza portale gli sconti sarebbero spariti e i clienti avrebbero usato il sito consumer per acquistare. Siccome comprano in grandi quantità, ricevono sconti personalizzati in base al volume d’acquisto. Questo è un aspetto.
In più, c’è la funzione di checkout. Sul dashboard si vedono i prodotti più acquistati e gli ordini aperti o quelli fatti negli ultimi 30 giorni. Ci sono strumenti utili per avere visione completa dell’attività nel portale.
Ci sono diversi livelli di utenti: alcuni possono comprare direttamente, altri devono avere l’approvazione di un admin cliente prima che un ordine passi. Per esempio, se superano il budget, l’ordine viene bloccato. Ci sono molte sfumature quindi.
Ben Aston:
Quindi, in pratica, se sono Telus e voglio ordinare 2000 monitor, posso loggarmi, fare acquisti, avere un checkout con approvazione e monitorare lo stato dell’ordine?
Rebecca Germond:
Esatto.
Ben Aston:
Quindi si tratta di un eCommerce su larga scala.
Rebecca Germond:
Esatto!
Ben Aston:
Nel tuo post hai menzionato tecnologie interessanti. Puoi farci un riassunto tecnico sull’architettura, la soluzione e cosa la rende particolare?
Rebecca Germond:
Certo, i nostri sviluppatori potrebbero approfondire meglio, ma do una panoramica.
Ben Aston:
Versione "PM".
Rebecca Germond:
Sì. Utilizziamo .NET Core per alimentare i microservizi e React per la parte front-end che fornisce l’interfaccia a questi microservizi — che sono semplicemente endpoint riutilizzabili come vogliamo. Per esempio, monitoriamo il volume ordini e possiamo mostrare questi dati in dashboard o manipolarli come serve, in tanti modi. Ovviamente React è molto apprezzato dai nostri front-end developer. Usando React abbiamo creato una libreria di componenti riutilizzabili in varie aree del sito, evitando ripetizioni. Volevamo anche coerenza visiva e mantenere il sito in linea col brand e vicino al sito consumer.
Ben Aston:
Nessun CMS quindi. In .NET avete creato funzionalità per il retailer che può aggiungere o modificare prodotti? Esiste un CMS lato prodotti?
Rebecca Germond:
No, tutto arriva tramite API del cliente, che viene usata anche sul loro sito consumer. I dati prodotto sono sempre aggiornati, c’è uno script che ogni giorno si assicura di ricevere prezzi e informazioni aggiornate. Il processo per aggiungere prodotti è totalmente automatizzato: molto comodo.
Ben Aston:
Si tratta quindi di sviluppo prodotto: costruire un portale da zero. Come avete pianificato il progetto/prodotto? Qual è stato il vostro approccio?
Rebecca Germond:
Abbiamo seguito un approccio MVP (minimum viable product) che ha funzionato e non. Durante il progetto, il "minimo" del MVP si è allargato. All’inizio però ci ha aiutato molto per timeline e stime. Avevamo un backlog definito e siamo partiti subito con sprint di sviluppo, senza lunghe fasi di raccolta requisiti. Definivamo i requisiti nelle riunioni di sprint planning per le feature da completare nel prossimo sprint.
Ben Aston:
Per l’MVP avevate budget e deadline definiti? Come siete arrivati a stabilire cosa fosse "dentro" il budget e cosa escluso?
Rebecca Germond:
Sì, ed è complicato perché lavorando in agile in agenzia i clienti vogliono un prezzo certo per tutto. In vero agile i costi sono per sprint, ma alla fine di uno sprint non sempre hai una feature completa. Noi abbiamo dovuto quotare a funzionalità in modo da permettere al cliente di scegliere le priorità. Quando abbiamo identificato le funzionalità incluse nell’MVP, abbiamo determinato il costo per ogni dipendenza. Il pricing era "a la carte", ma dovevamo impacchettarlo per funzionare in sprint. Avevamo cinque mesi totali, un mese di UAT, due settimane di setup ambienti. In pratica sei o sette sprint in totale.
Ben Aston:
Nel case study dici che avete sottostimato alcune feature obbligatorie: qual è stato il motivo?
Rebecca Germond:
La più sottovalutata è stata la costruzione del catalogo e l’applicazione degli sconti. Sembrava solo aggiungere uno sconto, ma nella realtà – tra logiche API, diverse categorie e varianti – la complessità è esplosa. In più, volevano escludere alcuni brand (tipo Apple, dove il margine è basso, no sconto). Dovevamo far sì che con "escludi brand Apple" venissero mostrati solo i prodotti corretti e scontati. Davvero complicato!
Purtroppo, il progetto era a prezzo fisso: abbiamo recuperato con richieste di change e varianti sulle feature quotate inizialmente. Siamo stati attenti con il change management, ma è difficile tornare dal cliente e dire che abbiamo sottostimato.
Ben Aston:
C’entra anche il fatto che alcuni dettagli — per esempio la complessità degli sconti — non erano chiarissimi dall’inizio, vero?
Rebecca Germond:
Esattamente. I requisiti all’inizio sembravano richiedere uno sconto molto più semplice. Poi scavando nelle specifiche la complessità è cresciuta.
Ben Aston:
Questo capita spesso con progetti agili: proprio perché non è tutto in bianco e nero, servirebbe un modello di pricing flessibile. Anche qui era prezzo fisso ma requisiti poco chiari. Con l’esperienza, come imposteresti diversamente un progetto così?
Rebecca Germond:
Con quello che so ora, il rapporto cliente va molto meglio e abbiamo margini di manovra sul tempo. Ci piacerebbe vendere in modalità "costo per sprint", anche se non ci siamo ancora. Forse dare subito un range di costi all’inizio e poi, sprint per sprint, stimare quanto fatto/prevedere il team e il costo. In generale, non cambierei molto del modo in cui abbiamo lavorato: eravamo snelli, poco numerosi, la partecipazione dal lato cliente era ristretta ai giusti stakeholder. Molto utile.
Ben Aston:
Un team piccolo è stato un successo. Nel tuo post parli di approccio ibrido agile: chi era nel team e come avete gestito design e sviluppo?
Rebecca Germond:
In agenzia è difficile fare agile puro: spesso i clienti non vogliono pagare un team "a prescindere", ma una certa funzionalità. Se hai il prodotto tuo interno è diverso; se lavori su progetti multipli è complesso.
Il nostro team era composto da due back-end, due front-end, una UX a metà tempo, un designer saltuario e un QA al 50%. Nessun BA (Business Analyst), non ne sentivamo bisogno perché conoscevamo bene il prodotto da realizzare; non ci serviva neppure uno strategist perché la vision del cliente era netta. Io ero la PM.
Per l’approccio: partendo da zero, avevamo solo le linee guida del brand e le feature. Design e UX lavoravano "uno sprint avanti" rispetto allo sviluppo: in agile puro non sarebbe così, ma per il cliente era importante vedere prima look e feeling e approvare la direzione. Il primo sprint è servito al setup ambienti e pipeline. Dal lato cliente erano già abituati ad agile, quindi tutte le cerimonie: scrums, review, demo, retro, le abbiamo fatte e il cliente ha partecipato molto attivamente.
Ben Aston:
Il cliente era il product manager: niente stakeholder multipli, una sola persona, ottimo! Hai scritto che sognava nuove feature durante il lavoro, pur avendo un budget fisso ma approccio agile. Come hai gestito questo?
Rebecca Germond:
È stato difficile, ogni volta che proponeva una feature nuova sapeva che sarebbe stato gestito con una Change Request e che serviva una quotazione ad hoc. Il problema era fermare lo sprint per stimare la nuova funzionalità e aspettare l’approvazione. Però il cliente aveva piena autonomia e lo progettavano così da tempo: il nostro contributo è stato far venire fuori esigenze che non avevano considerato.
Ha portato feature "simpatiche" in corso d’opera, ma tutte importanti. Ad esempio, prima della build l’onboarding clienti era previsto via PDF e mail. Dopo il terzo sprint abbiamo creato una sorta di wizard: il cliente riceve una mail, fa login, può resettare la password e scaricare/reinviare i documenti. Ha reso tutto più facile anche se non era in origine preventivato.
Ben Aston:
Hai parlato di lezioni apprese. Una di queste: tieni coinvolti team e cliente. Qui il cliente era molto coinvolto. Quali consigli daresti sul coinvolgimento?
Rebecca Germond:
Il modello lavorativo era nuovo per FCV: avevamo clienti "legacy" o pubblici che ci seguivano da anni, ma erano statici nei loro processi. Con questo approccio il coinvolgimento ha pagato perché abbiamo visto che la partecipazione è apprezzata dai clienti. Era nel nostro interesse coinvolgerlo anche per portare avanti una fase due. Abbiamo visto che il portale non è un sito che si esaurisce, ma un sistema vivo e in evoluzione.
Il team era stimolato perché poteva scegliere stack tecnologico, strumenti, e aveva voce in capitolo col cliente (alcuni team non gradiscono parlarci, ma il nostro sì). Anche il cliente era su Slack con noi. Insomma, erano coinvolti perché stavano creando qualcosa di sentito.
Ben Aston:
Un’altra lezione è stata: elimina processi inutili ma tieni quelli essenziali. Puoi raccontare qualcosa che avete eliminato o migliorato e poi magari integrato altrove?
Rebecca Germond:
Sì, dopo il secondo sprint retrospective abbiamo deciso di smettere di farli: ormai conoscevamo pregi e problemi, quindi portavano via tempo prezioso allo sviluppo. Il cliente, essendo così coinvolto, ci dava feedback continui su cosa non funzionava.
Per noi era difficile fare scrums regolari perché metà team era a Toronto e metà a Vancouver, quindi meglio una call rapida da 15 minuti per sbloccare le cose che una discussione infinita su Slack.
Ben Aston:
Quindi scrums ad hoc invece che cerimonie fisse.
Rebecca Germond:
Esatto, abbiamo provato a farle alle 9:30 ma poi, presi il ritmo, sono diventate ad hoc o via Slack. Le abbiamo fatte ogni giorno per tre sprint, poi una volta ogni due o solo via Slack.
Ben Aston:
Hai mai provato a eliminare un processo che sembrava inutile e poi l’hai rimesso dopo esserti accorta che era una cattiva idea?
Rebecca Germond:
Non proprio, anche se avrei voluto coinvolgere subito il QA: avremmo dovuto integrarlo prima, non solo dal terzo sprint. Ricordo alcune demo fatte lavorando fino all’ultimo minuto, sperando che il codice tenesse. Alla fine abbiamo lavorato come "cowboy" ma ci siamo divertiti.
Ben Aston:
Grazie mille Rebecca per essere stata con noi. È stato un vero piacere.
Rebecca Germond:
Grazie a voi, quando volete.
Ben Aston:
Se ti interessano i portali, leggi il case study scritto da Rebecca: c’è una tonnellata di informazioni utili. Se vuoi parlarne, unisciti al nostro team Slack su digitalprojectmanager.com/slack, dove si sviluppano discussioni su tutto il mondo digital PM. Se ti è piaciuto il podcast, lascia una recensione su Apple Podcasts (ex iTunes): feedback e valutazioni ci aiutano molto! Alla prossima e grazie per l’ascolto.
