Il product manager passa in media 6 ore a settimana lavorando a diretto contatto con il development team. La riuscita di questa collaborazione è fondamentale per il successo di entrambe le parti e del prodotto, ma molto spesso sorgono tensioni che rendono il lavoro più faticoso per tutti.
In questo articolo andiamo ad analizzare gli ostacoli più comuni e i pregiudizi che possono essere fonte di stress e di una collaborazione inefficace. Suggeriremo alcuni metodi per facilitare una buona collaborazione, come la creazione di aspettative condivise e di una routine efficace. Infine guarderemo a modi in cui il product manager può supportare il suo development team e incoraggiarlo a partecipare attivamente alla creazione del prodotto.
Perché è spesso difficile per il product manager collaborare con il development team?
Perché un team abbia successo, ciascuno dei suoi membri deve sentirsi sicuro che anche i suoi colleghi stiano lavorando allo stesso obiettivo. La collaborazione richiede fiducia, ma richiede anche iniziativa da entrambe le parti. Per questo è importante il coinvolgimento di tutti, in modo che ciascuno possa contribuire con le sue idee e capacità.
Allo stesso tempo però il product manager è il responsabile finale del prodotto. In altre parole, la posizione del product manager è decidere cosa fare. Se però il modo in cui prende decisioni non è trasparente, la relazione con il development team ne risente.
Deve essere chiaro in ogni momento che il product manager agisce in base all’interesse dell’utente, entro certi limiti dettati dagli interessi aziendali. Per questo è importante che le sue decisioni siano basate su evidenze quantitative (dati) o qualitative (interviste agli utenti, sondaggi, ipotesi). Se il product manager non prende decisioni basate sui fatti, ma in base a opinioni non verificabili, allora non sta facendo un buon lavoro.
Miti da sfatare e pregiudizi sui developer
Ci sono molti luoghi comuni sui developer. Di fatto la maggior parte delle volte sono uomini, benché questo non dovrebbe essere dato per scontato. Il pregiudizio che le donne siano “meno portate” a fare le developer si traduce purtroppo spesso in una svalutazione del loro contributo.
Un’altro mito da sfatare è quello del developer misantropo. Oltre a creare stress da prestazione in coloro che magari hanno solo un carattere introverso, questo pregiudizio può portare ad accettare comportamenti asociali che non dovrebbero essere tollerati in alcun ambiente lavorativo. Una cosa è la timidezza, un’altra la voluta mancanza di collaborazione.
È importante essere consapevoli di questi pregiudizi – spesso inconsci – e fare del proprio meglio per non lasciare che influenzino ciò che si fa. Seguire processi in cui tutti sono incoraggiati a contribuire e gli input sono resi anonimi, per esempio, aiuterà a mantenere le decisioni imparziali e assicurarsi che i contributi di tutti siano valutati nel modo più oggettivo possibile.
Aspettative chiare per una collaborazione di successo
Uno degli aspetti chiave per raggiungere un buon livello di collaborazione con il tuo development team è assicurarti che tutti condividano lo stesso punto di vista riguardo a obiettivi da raggiungere e priorità.
Per fare questo è necessario prima di tutto stabilire delle aspettative chiare sui temi di maggiore importanza. Questi in genere includono responsabilità, qualità del lavoro svolto e definizione di “fatto”.
Responsabilità
Chiarezza sulle responsabilità include innanzitutto definire chi fa cosa e perché. È inoltre utile stabilire quando è necessaria un’approvazione e quando invece il singolo può prendere decisioni autonomamente. Per quanto riguarda la documentazione e i processi, è opportuno definire quali siano, quando devono essere eseguiti e soprattutto per quale scopo sono stati creati.
Infine deve essere chiaro quali persone devono essere informate in relazione alle decisioni prese. Una RACI può essere utile per portare chiarezza su questo punto e organizzare le informazioni in modo strutturato e facile da condividere all’interno dell’organizzazione. Inoltre aiuta a visualizzare quali compiti al momento non hanno un responsabile e agire di conseguenza.
Qualità del lavoro svolto
La qualità del lavoro svolto è un tema spesso difficile da affrontare, a causa della sua natura, per l’appunto, qualitativa. Per la buona riuscita di un prodotto e una collaborazione efficiente con il development team è importante che ci sia intesa su cosa si intende con buona qualità.
Per rimuovere ogni dubbio, il product manager può portare degli esempi concreti e porre alcune domande su cui riflettere: se l’introduzione di una nuova funzionalità influisce sulle performance di un’altra parte del prodotto, chi dovrebbe segnalarlo? Se i ticket non contengono tutte le informazioni necessarie per lo sviluppo del prodotto, a chi spetta sollevare il problema? Sembrano domande la cui risposta è ovvia, ma spesso in contesti lavorativi il buonsenso scarseggia.
Le risposte a queste domande possono essere discusse fino al raggiungimento di una visione di qualità condivisa da tutto il team.
Definizione di “fatto”
La definizione di un lavoro completo è interpretata in maniera differente da diversi membri del team più spesso di quanto si possa immaginare. Per questo è utile esplicitare sempre questo punto direttamente nei ticket, utilizzando un esempio verificabile con i fatti: “Quando l’utente fa X allora succede Y”.
Esplicitare il risultato che si vuole ottenere con esempi concreti è sempre una buona pratica. Soprattutto agli inizi di una collaborazione è importante comunicare ogni aspetto nel dettaglio. Questo non significa che il product manager debba scrivere ticket lunghi quanto libri, ma cercare un confronto continuo con il development team e facilitare una comunicazione diretta e onesta con i singoli developer.
Creare una routine efficace
Una volta identificato come limitare l’impatto dei pregiudizi e aver chiarito delle aspettative condivise, è il momento di creare un piano per far sì che le nuove iniziative vengano implementate.
L’esecuzione è quello che fa la differenza tra un piano ben riuscito e un fallimento. Per far sì che gli elementi che hai identificato come necessari per migliorare la collaborazione con il development team vengano implementati e portino i risultati sperati, è importante introdurli con una routine chiara, realistica e facilmente eseguibile.
Per prima cosa, metti subito in calendario i meeting ricorrenti che sono stati concordati, aggiungendo sempre a ciascuno un’agenda. Se sono stati concordati dei nuovi processi, metteteli per iscritto includendo chi, quando e come devono essere utilizzati. Ricorda sempre che un processo deve essere funzionale allo scopo. Se il processo non funziona va rivisto e adattato!
Come il product manager può incoraggiare il development team a contribuire
Incoraggiare tutto il team a contribuire, inclusi i developer, è un ottimo modo per favorire la collaborazione. A volte però questa iniziativa non viene direttamente dal team e deve essere incoraggiata. In questo caso il product manager deve chiedere feedback spesso e in maniera diretta. Se la partecipazione è ancora scarsa, il feedback può essere fatto in maniera anonima, con post-it o biglietti in una scatola, o con la loro versione digitale.
In altri casi il development team è pieno di iniziativa, ma il feedback che fornisce è poco utile per l’avanzamento del prodotto, perché basato su opinioni personali piuttosto che fatti e dati. In questa situazione è utile coinvolgere i developer nelle interazioni con l’utente, ad esempio includendoli nelle interviste o riportandone i risultati. Nel caso in cui i developer non parlino la stessa lingua degli utenti, è utile tradurre i commenti o le interviste perché possano farne uso.
