Tag Archive for stakeholder

Incontrare chi investe in noi

Con il termine stakeholder si intende uno sponsor del progetto che il Product Owner sta seguendo, un super cliente interno all’azienda o comunque uno di quelli che, sul vostro progetto, ci mette il soldo.

Già da questa definizione si capisce che uno sbadiglio del vostro stakeholder è peggio di una critica del vostro capo: non avete interessato il vostro investitore, non lo avete eccitato con quello che avete rilasciato.
Male.

Da lì in poi la situazione è tutta in salita, ma recuperabile.
Ci sono fior di capitoli dedicati al coinvolgimento dell’investitore, dai piccoli dettagli dei pasticcini offerti in review agli incontri one to one di preparazione e di retrospettiva di ogni review: ho scoperto quanto gli investitori siano timidi e quante cose emergano da incontri personali (“volevo dirlo in review, ma non me la sentivo in inglese”, “non volevo che il mio commento portasse alla bocciatura della user story”, “mi scocciava fare una critica in pubblico”).
Io spendo decine di ore in incontri con i miei stakeholders e non sembrano mai bastare; se l’investitore tiene davvero ai propri soldi non sarà mai sazio di incontri e presentazioni personalizzate e revisioni del planning e dei rilasci.
Non si tratta di una mera attività diplomatica: è uno scambio nelle due direzioni, un processo per rendere permeabile quella membrana di diffidenza o timidezza che altrimenti sarebbe impermeabile.

Un’altra tecnica scaccia-timidezza si basa sui feedback anonimi.

Le nostre review attualmente si chiudono sempre con un survey inviato alla lista degli stakeholder. Il survey è anonimo e brevissimo (4 domande, con risposte multiple, e campi di testo solo per chi vuole aggiungere qualcosa).
Allo stakeholder è richiesto un breve giudizio sulla qualità della review, in termini sia di comunicazione che di contenuti espressi, quindi viene chiesto l’argomento preferito, e infine si entra nel dettaglio del rilascio più importante, chiedendo il grado di apprezzamento del prodotto ed eventuali commenti.

Favorire la partecipazione alla review

Il prodotto che io e il mio team gestiamo interessa parecchie persone all’interno della nostra azienda.
Queste persone sono sparse in 8 uffici diversi distribuiti in 6 paesi europei.
Le nostre sprint review sono perciò necessariamente in inglese e gestite in remoto con uno strumento che consente di organizzare una multiconference con condivisione di schermo e chat.
Ciò nonostante, è tutt’altro che scontato che queste persone mantengano un interesse e una partecipazione attiva alle review, visto che noi siamo solo uno degli otto team di prodotto (ciascuno con la sua review) e sopratutto visto che molti di loro ci stanno seguendo da 48 sprint review.
Immaginate quindi la soddisfazione nel riscontrare la presenza di 25 partecipanti all’ultima sprint review, praticamente tutti i responsabili helpdesk, marketing e vendite e tutti gli esperti del prodotto in esame in ognuno dei paesi in cui siamo presenti.
Alla fine della review ho fatto i complimenti al mio team: aver mantenuto l’attenzione e l’interesse di queste persone per così lungo tempo è un successo conquistato con un lungo lavoro fatto di vittorie, errori, sconfitte, dietrofront e ripartenze. Bravi!
Cosa è che rende interessante e partecipata una review ad alto rischio di incomunicabilità come la nostra?
Nel tempo ci siamo resi conto che dovevamo trovare un modo di compensare un livello medio di conoscenza dell’inglese non proprio eccelso e una certa reticenza alla comunicazione in pubblico. Ecco come abbiamo lavorato.
La review si compone di sessioni di presentazione; in ciascuna sessione ogni team member mostra un lavoro, una feature, un risultato, uno sviluppo, il prodotto di una attività concluso nello sprint appena terminato.
Why & What
Ogni sessione viene introdotta da una slide che illustra il tipo di sviluppo e dunque il perché quello sviluppo è stato fatto (cioè le motivazioni e le esigenze che sono alla base di quella scelta) e il cosa è stato in pratica fatto. Se necessario, e per lo più lo è, alcuni link rimandano alle aree di preproduzione dalle quali i risultati del lavoro saranno mostrati.
Esempio:
Gestionale delle iscrizioni – interfaccia di verifica e validazione delle iscrizioni
Perché: l’attività viene fatta ad oggi manualmente con notevole dispendio di lavoro
Cosa: nell’area di backend abbiamo inserito una lista delle iscrizioni che possono essere validate o rifiutate
Link: area di gestione
Il tutto, ovviamente, in inglese.
Uso della chat
La review, come detto, è in inglese, ma i partecipanti parlano le lingue più svariate e non sempre si sentono a loro agio nel gestire una conversazione in inglese. Scrivere è immensamente più facile per tutti.
Dunque, usiamo lo strumento di chat per interagire con i partecipanti, chi vuole può scrivere una domanda o un commento e uno dei team member più senior è incaricato di rispondere alle domande oppure, se necessario, avvertire il resto del team e il Product Owner che c’è una domanda di interesse generale che vale la pena di essere risposta a voce. Raramente c’è la necessità di aprire l’audio del richiedente e interagire direttamente, ma se desiderato ovviamente si fa.
What’s next

La sprint review si chiude sempre con una slide finale sugli sviluppi previsti per lo sprint successivo: ovviamente questa viene presentata dal Product Owner, che anche in questo caso risponde alle domande in proposito.
Ricordo le prime review dove la maggior parte dei partecipanti veniva nella nostra stanza e per creare una atmosfera accogliente e rilassata facevamo trovare qualche dolcetto. Quando l’interesse crebbe nelle sedi estere mi chiesi con cosa avremmo sostituito quello “sweet welcome”; credo che a distanza di alcuni mesi abbiamo trovato una formula altrettanto confortevole e che, oltretutto, non favorisce la carie.