Centrando i Requisiti (con Kelly Suter di BI Worldwide)

Leggi la Trascrizione:

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

Ben Aston:

Benvenuti al Podcast DPM, dove andiamo oltre la teoria per fornire consigli esperti di project management per gestire meglio progetti digitali. Grazie per essere qui, sono Ben Aston, fondatore del Digital Project Manager. Siate sinceri: vi è mai capitato che il cliente, a fine progetto, vi abbia detto: “Ehi, l’hai centrato davvero, è esattamente ciò che volevamo, proprio quello che avevi detto all’inizio del progetto, ed è incredibile come tu sia riuscito a riprendere tutto senza perdere nulla per strada.”

Bene, sospetto che non sia mai successo. Probabilmente perché i tuoi requisiti non erano stati definiti a dovere. Quindi, come si possono gestire i requisiti per non ritrovarsi nei pasticci durante il progetto e allo stesso tempo fornire al cliente e allo sviluppatore ciò di cui hanno bisogno per portare a termine il lavoro? Ecco di cosa parla l’episodio di oggi: dei requisiti di progetto.

Il modo in cui definiamo un progetto e le sue funzionalità per i nostri clienti così che tutti sappiano cosa verrà consegnato. Sostanzialmente, i requisiti, secondo me sono uno strumento di comunicazione, ma sono davvero difficili da impostare bene, perché se li definiamo in modo troppo blando, ci diamo più flessibilità ma rischiamo di non ottenere esattamente ciò che volevamo. Se invece li definiamo in modo troppo rigido, rischiamo di dimenticare tante cose. Quindi, come trovare il giusto equilibrio?

Oggi ne parlo con Kelly Suter. Kelly è project manager tecnico presso BI Worldwide, ed è una delle nostre esperte residenti in casa Digital Project Manager. Ciao Kelly.

Kelly Suter:

Ciao, grazie per l’invito Ben.

Ben Aston:

No, è davvero bello averti qui. Credo sia il nostro secondo podcast insieme, vero?

Kelly Suter:

Sì, lo è.

Ben Aston:

Abbiamo fatto un podcast molto tempo fa. Per chi si fosse dimenticato di chi sei, vuoi raccontarci un po’ come sei arrivata al project management? Hai avuto un percorso interessante, credo, come tanti project manager. Nessuno di noi da piccolo voleva fare il PM, quindi raccontaci un po’ il tuo percorso: come sei diventata una PM digitale?

Kelly Suter:

Sì, ho iniziato la mia carriera come giornalista sportiva, in realtà, perché ho studiato Comunicazione con indirizzo in relazioni pubbliche e media. Quando ho capito che i giornali stavano tramontando, ho deciso di affacciarmi al settore dell’ufficio stampa, facendo la PR per circa tre anni per un singolo brand, Sesame Street Live. Ho curato davvero a fondo il brand, per circa tre anni, e poi una persona che lavorava in una agenzia eCommerce personalizzata, agenzia digitale full service focalizzata sull’eCommerce, mi ha detto: "Qui non abbiamo un reparto project management, vuoi diventare PM?" E io: "Cos’è?" Mio padre aveva un’agenzia di grafica, quindi ero cresciuta già conoscendo un po’ l’ambiente agenzia, abbastanza da sapere che era tutto abbastanza frenetico. Ma ho accettato, ero incuriosita, ho letto il primo libro "People, Pixels, and Process" di Meghan McInerny (non so se ho detto nell’ordine giusto), e ho provato ad applicarne i principi…

Ben Aston:

Lo conosco, sì.

Kelly Suter:

Esatto. E ho cercato di applicarlo al meglio in agenzia: ai tempi eravamo in 12, lavoravamo su siti vetrina eCommerce personalizzati. In circa quattro anni ho fatto crescere il team fino a sette project manager, applicando e facendo evolvere un processo. Poi, volevo espandere le mie competenze tecniche e ho colto l’opportunità in BI Worldwide come PM tecnico, per stare di nuovo “dentro” ai progetti e affinare le mie competenze tecniche. Ed eccomi qui: è volato in un attimo, ma amo davvero questo lavoro.

Ben Aston:

Sono curioso, è il lavoro dei tuoi sogni adesso? Sembra un percorso interessante: reporter sportiva, Sesame Street, ora PM tecnologia. Ma tu cosa vorresti fare "da grande"?

Kelly Suter:

Bella domanda. Quello che amo di più è entrare dove il processo manca o sta iniziando a prendere forma, e aiutare il team a sentirsi sollevato sapendo di avere qualcosa su cui contare. Quindi, il mio lavoro da sogno sarebbe quello di “pompiere”, per mancanza di parola migliore, per startup o aziende in crescita: entrare, implementare il processo, vedere se funziona… amo le sfide stimolanti.

Ben Aston:

Bene. Quali sono le sfide che affronti adesso? Sistemare il processo e la documentazione è una cosa, ma quali problemi affronti ora, concretamente?

Kelly Suter:

Direi che la sfida principale oggi, tra tutte quelle che abbiamo, è ottenere il coinvolgimento del team sulla documentazione senza essere noiosa. È difficile, con clienti ed team entusiasti, ottenere il vero “buy-in” senza perdere slancio, pur documentando abbastanza da non perdere logiche e processi se qualcuno cambia ruolo. Ho visto team reinventare la ruota sia nel prodotto sia nella doc. Quindi sto lavorando a documenti che risalgono al 2014, che hanno funzionato per tutti, ma dobbiamo fare meglio. È importante, soprattutto quando in futuro si farà auditing, avere tutto in ordine.

Ben Aston:

Interessante. Che strumenti usi per questo, che ti aiutano nell’attività di documentazione?

Kelly Suter:

Per la documentazione non reinvento la ruota, uso Google Suite, se i clienti non hanno problemi di privacy; documenti condivisi, permessi per chi può vedere/commentare. Così non devo pensare al versioning, poi esporto in PDF per i formalismi. InVision è ottimo per feedback e annotazioni sui design/wireframe, con commenti dei clienti o stakeholder. Se non ho InVision (per budget), uso Sketch di Evernote, gratuito, per annotare semplicemente i design. Quindi quello che mi basta è importare i design, annotarli, inserirli nella doc e scrivere le parti testuali.

Ben Aston:

Parliamo invece della tua evoluzione come digital project manager. Ora sei PM tecnico ma porti diversi “cappelli”: project manager, business analyst, SCRUM master… In cosa si differenzia un PM tecnico da un DPM? E com’è indossare ruoli diversi?

Kelly Suter:

Domanda interessante. Nel mio ruolo qui è particolare: in BIW faccio sia PM tecnico che tradizionale, gestisco eventi dal vivo e anche contenuti didattici (un quarto del mio tempo). Gli altri tre quarti, project management tecnico. Cambiano definizioni ovunque: digital, tecnico, agile... Sei comunque un PM, ma rispetto a un DPM classico, nel ruolo attuale mi occorre una comprensione molto maggiore del lavoro digitale che si fa, quindi più “tecnica”. Da DPM avevo chiaro il content strategy, la sitemap, il wireframe e la creatività, nello sviluppo invece mi limitavo a “fatemi sapere quando avete finito”. Ora, come PM tecnico, sono più immersa nello sviluppo, anche durante la QA, fianco a fianco con il lead dev per confrontare i requisiti tecnici che scrivo col codice prodotto. Più sei vicino ai requisiti, più aumenta la responsabilità e più devi restare coinvolto se emergono questioni.

Quindi, come DPM gestivo e passavo i requisiti alle persone giuste, mentre ora li scrivo in prima persona. È un coinvolgimento molto più “sul campo”.

Ben Aston:

Esatto, quindi per chi non ha familiarità con “requisiti funzionali” o “requisiti di business”, tu ti occupi proprio di questo: definizione dei requisiti. Spesso c’è ambiguità tra PM, BA e sviluppatori su chi debba definirli. Come gestisci questo scenario, dove tocchi entrambi gli aspetti?

Kelly Suter:

All’inizio di un progetto, o quando entri in un team o una nuova azienda, è fondamentale capire ruoli e responsabilità: potrebbero evolversi o cambiare a seconda del cliente. Spesso, per esempio, lavorando a un’integrazione custom (esempio: inventario, database di prodotti), posso specificare cosa debba succedere ("serve l’aggiornamento quotidiano delle scorte, divise per taglia…"), ma lo sviluppatore può dover andare più a fondo su cose che io non conosco tecnicamente. Non ha senso fingere di sapere tutto, meglio essere trasparenti e dire “di qui in poi aiutami tu con i dettagli”, ponendo domande “perché serve questa funzione”, andando a fondo fino a dove riesco… E poi, quando occorre, passo la palla agli sviluppatori per completare i requisiti.

È un equilibrio. Bisogna stabilire cosa sei in grado di fare ed essere aperti sul fatto che certe cose spettano ad altri (BA, stratega, ecc). In questo modo si decide anche come allocare il budget e si resta efficienti. Serve comunicazione continua su tutto.

Ben Aston:

Certo. Per chi ascolta e pensa “ma che sono questi documenti di requisiti di business o funzionali? Noi facciamo design e poi passiamo tutto ai dev”: questa documentazione non contrasta con l’approccio agile?

Che cosa sono questi documenti? Perché sono così importanti?

Kelly Suter:

Parlando di documentazione requisiti di business (BRD) e requisiti funzionali (FRD): il BRD è come il corso base 101, con i punti di alto livello (ad esempio, serve la traduzione in spagnolo e mandarino, 10 corsi diversi, go-live ad aprile, supporto per 6.000 utenti/concorrenza…). Quindi è una checklist per capire se siamo tutti allineati. E ovviamente c’è una clausola che dice: “Definiremo meglio questi punti e se qualcosa esce dal perimetro o dal budget vi avvertiremo.”

L’FRD è un altro checkpoint dove si entra nel dettaglio dei punti generali del BRD: come faremo la traduzione? Sarà manuale, automatica, tramite fornitore esterno? L’FRD esplode ogni punto, documenta ciò che verrà fatto e cosa potrebbe essere rimandato a una futura Fase 2 se fuori budget. FRD è il vero e proprio progetto esecutivo del sistema.

Ben Aston:

Quindi il BRD si scrive all’inizio e definisce il successo dal punto di vista del business; l’FRD dettaglia come rendere quei requisiti realtà, ad esempio “localizzazione in mandarino”, ecc.

Ma cosa rispondi a chi pensa che questa documentazione vada contro l’agilità?

E come riesci a conciliare questi due approcci, tra iterazione/agilità e la necessità di avere requisiti ben definiti?

Kelly Suter:

Domanda molto attuale. Il modo migliore è concordare fin da subito (magari anche con un documento!) quale approccio seguire: dire “ok, adotteremo un metodo agile, ecco cosa significa, ecco cosa serve dal cliente e internamente.” Fare un kick-off solido, chiarire il prodotto da realizzare. Faccio un esempio: al momento stiamo creando un software che associa punti all’apprendimento (frequenza corsi, progressi, punti da spendere). Sappiamo l’obiettivo finale (go-live a gennaio), il cliente si fida, abbiamo poco tempo per documentare tutto. Allora ci focalizziamo sull’obiettivo e lavoriamo a iterazioni: ogni settimana ci incontriamo, ognuno lavora su una specifica (badge, certificati, leaderboard, shopping experience), presentiamo i risultati ogni due settimane al cliente, che sa che il prodotto è provvisorio, magari poco rifinito ma con la logica già impostata.

I meeting settimanali con il team e con il cliente sono essenziali. Come PM, documento queste riunioni: cosa mostriamo oggi, cosa si vedrà realizzato, quali domande restano aperte. Quando emergono dubbi del cliente, si registra tutto e si elabora il piano per la settimana successiva.

Così si mantiene la rotta, si prende atto di eventuali cambi o rinunce (ad esempio se i certificati non possono essere sviluppati ora), e tutto sta nella documentazione in itinere e nel rapporto di fiducia.

Ben Aston:

Certo, spesso se si aspetta di definire tutto dettagliatamente prima di partire, il progetto non parte mai. Il vantaggio dei requisiti funzionali e processuali è dare agli sviluppatori chiarezza su cosa costruire, ai clienti su cosa otterranno e alla QA su cosa verificare realmente. Bisogna trovare il giusto equilibrio tra documentazione e avanzamento del progetto.

Però documentare così tanto è impegnativo. Come lo concretizzi nella tua quotidianità lavorativa? Usi JIRA per le singole task?

Kelly Suter:

Sì, ottima domanda. Non lavoro in isolamento: mentre scrivo l’FRD chiedo feedback al team, domande sulle best practice o sui punti discussi anche se non sono annotati. Quando l’FRD è pronto, tutti lo revisionano, lo si sottopone al cliente che approva. A quel punto, con i dev, chiedo: preferite che costruisca io le task o volete farlo voi? Spesso, se hanno letto l’FRD, accettano che sia io a creare tutte le task in JIRA: una storia per ogni tipologia di pagina (registrazione, home, scheda prodotto), e sottotask per ogni riga di requisito. Poi i dev stimano il tempo che serve, preferibilmente chi sviluppa effettivamente quei task. Così allineiamo le stime alla documentazione esistente, minimizzando gli errori. Uso JIRA (suite Atlassian) e suddivido i task in sprint da 30-35 ore a settimana, se le risorse sono singole. E per ciascuna task di sviluppo, aggiungo una linea di QA su come testare se il risultato è stato raggiunto o meno.

Ben Aston:

Perfetto. Vorrei toccare il tema delle stime, che coi progetti tecnici diventa sempre più critico. All’inizio il cliente vuole subito un preventivo ma non conosciamo le funzioni in dettaglio… Come te la cavi? Fai stime sulla base dei requisiti di business?

Kelly Suter:

Domanda complessa. In qualità di PM, il più delle volte non mi viene chiesto davvero un parere sul preventivo, se non in modo informale (tipo: “Potremmo finirlo per marzo?”). Quando però posso intervenire, prima cerco progetti simili fatti dall’azienda su cui basarmi (in base alle dimensioni del cliente, utenti, tipo di piattaforma…), ad esempio uno sviluppatore senior ricorda che realizzare un e-commerce con Magento v1 standard voleva dire 6-8 settimane, due sviluppatori, no grosse personalizzazioni. Quindi mi baso sulle esperienze precedenti, ma è difficile stimare da zero. Alle vendite dico: “Se non ci sono integrazioni o personalizzazioni, questa è la soluzione e il tempo/costo presumibile.” Ma spesso serve qualcuno, tipo un tech lead, che possa dare una stima attendibile.

Quindi l’importante è avere pronto un foglio riassuntivo per i diversi tipi di progetto (eCommerce, LMS, ecc.). So che è una risposta aperta, ma la stima iniziale è davvero complicata.

Ben Aston:

Sì, si parla di stima analogica: all’inizio si confrontano progetti simili (basso, medio, alto) e ci si tiene volutamente larghi, chiarendo al cliente che il dettaglio verrà quando avremo raccolto i requisiti veri. La fase di analisi serve a chiarire ciò che davvero richiedono e da lì si farà una stima “vera”.

Kelly Suter:

Due esercizi utili: faccio sempre il "triangolo" con scope, tempi, budget e chiedo al cliente di metterli in ordine di priorità (dicono sempre "tutti!, ahah", ma poi scelgono). E questo spesso cambia in corso d’opera, quindi è essenziale parlarne fin dall’inizio.

L’altro esercizio è "buono, meglio, ottimo" (good, better, best): se hai un budget, si chiarisce subito che certe funzioni “premium” costeranno di più e decide il cliente dove “fermare” o spendere qualcosa in più per avere il meglio. Utile anche per evitare di tagliare a priori funzionalità importanti senza discuterne insieme.

Questi due strumenti li trovo utilissimi sia per rispettare tempi, scope e budget, sia per coinvolgere il cliente nelle scelte e responsabilizzarlo nella decisione finale.

Ben Aston:

Sì, coinvolgere il cliente nella collaborazione è fondamentale, soprattutto quando pretende un budget fisso su progetti tecnici e integrati, dove l’incertezza è alta. L’approccio che suggerisci aiuta a chiarire che ogni estensione delle funzioni comporta lavoro aggiuntivo, e che possiamo adattare stime e funzionalità in base alle loro priorità reali.

Per chi, tra chi ascolta, vuole iniziare a scrivere meglio i requisiti, non l’ha mai fatto, è sempre andato in sviluppo dalle wireframe e dai design, che consiglio daresti per muovere i primi passi ed essere più rigorosi nel definire lo sviluppo?

Kelly Suter:

Se sei al tuo primo incarico come digital PM, ricordati che essendo già “nativo digitale” sai più di quanto credi, perché hai già assorbito abitudini e logiche digitali quotidiane. Quindi, invece di cercare subito template online da riempire, Parti da quello che state facendo per il cliente: ad esempio una pagina di registrazione per un evento, con homepage e form web. Chiediti: “Cosa deve fare questa pagina? Su mobile e desktop?” Spiega ogni elemento come se dovessi descriverlo a tua nonna, che usa ancora il vecchio Nokia. Poi verifica con lo sviluppatore se quanto hai scritto è corretto: magari riderà, ma apprezzerà il tuo impegno nel chiarire tutto per permettere anche a lui di lavorare meglio.

Quindi, quando sei all’inizio, suddividi tutto in piccoli elementi, spiegali dettagliatamente senza darti fretta e correggi nel tempo: la prima doc sarà probabilmente troppo discorsiva o incoerente, ma va bene così. È un processo evolutivo, nessuno è perfetto all’inizio. Ricorda anche che spesso il cliente non è abituato a sviluppare progetti digitali e si affida a te in questo. Quindi percorri il processo con lui, spiegandolo in modo chiaro e accessibile.

Ben Aston:

Sì, penso sia davvero utile. I requisiti sono fatti di domande e risposte: non esistono domande “stupide” e nulla è ovvio. Inizia chiedendoti le cose che spiegheresti davvero a tua mamma o nonna. Ricorda che la documentazione dei requisiti è uno strumento di comunicazione per avere tutti sulla stessa pagina: così si riduce lo spreco di energie sul management dell’aspettativa, toglie ambiguità e fa risparmiare tempo sul lungo periodo, perché si evitano errori, rilavorazioni o delusioni da parte del cliente.

Grazie mille Kelly per essere stata con noi.

Kelly Suter:

Grazie a voi, è stato un piacere.

Ben Aston:

Kelly, come una delle nostre esperte DPM, sarà anche presente nel nostro corso Mastering Digital Project Management. Se non sai di cosa si tratta ma pensi di aver bisogno di formazione da PM, dai un’occhiata! È un corso intensivo di sette settimane, include videolezioni interattive, compiti, discussioni di gruppo, webinar. Vai su dpmschool.com per iscriverti; il corso parte a febbraio. E se vuoi partecipare alla conversazione sui requisiti e su come li gestiamo, visita la sezione risorse di thedigitalprojectmanager.com per unirti al nostro team Slack: troverai tante conversazioni interessanti. Oppure lasciaci un commento qui sotto! Alla prossima, grazie per l’ascolto.