“Perché ci stiamo mettendo così tanto per questo sviluppo?”

“Possibile che questa lavorazione così semplice la stimiate così tanto?”

“Ma questo sviluppo non è quello che avevo chiesto!”

Queste sono solo alcune delle più frequenti conversazioni che ho sentito tra Product Manager e Software Engineer nel corso della mia carriera. Chiaramente, non voglio fare di tutta l’erba un fascio: sto parlando di una collaborazione ancora lontana dall’essere perfetta e con ampi margini di miglioramento. Purtroppo, però, non è raro che collaborazioni che faticano a essere ottimali tra Product Manager e Software Engineer siano più comuni di quanto vorremmo ammettere.

Un ambiente di lavoro in cui non si riesce a raggiungere una cooperazione sana è un problema a tutti gli effetti. Per poter capire come risolverlo conviene prima chiedersi: perché questo problema esiste? È strano pensare che in un Product Team, spesso composto da figure brillanti e con importanti esperienze alle spalle, possano verificarsi frequenti situazioni disfunzionali.

Dopo tutto, i membri del Product Team lavorano per risolvere gli stessi problemi… Ma ne siamo certi?

Product Manager e Software Engineer: il Product Team

Un Product Team ideale è composto da:

• un Product Manager
• Software Engineer (solitamente gestito da un Team Lead, Tech Lead o Engineering Manager)
• uno o più designer che si occupano di UI e UX
• Quality Assurance Engineer
• un Data Analyst

Un nutrito numero di persone e di professionalità diverse. Come mai, allora, mi concentro solo sul rapporto tra Product Manager e Software Engineer?

Tutte le figure citate danno un grande contributo al successo del prodotto, ma, come temo accade a molti, il più delle volte mi è capitato di lavorare in team composti solamente da Product Manager e Software Engineer. Agli occhi delle aziende gli altri ruoli vengono spesso percepiti come figure di supporto e i cui compiti possono essere svolti da Product Manager e Software Engineer. Non è raro nel corso della mia carriera di essermi occupato anche della QA delle feature sviluppate e del design delle soluzioni o di vedere questi compiti svolti dal Product Manager.

Product Manager e Software Engineer sono quelle figure su cui un’azienda di prodotto non può permettersi di fare a meno: il primo definisce la vision del prodotto e le priorità; il secondo concretizza la vision realizzando il prodotto stesso.

Origini della disfunzione: le differenze

Quando sorge il sole, un Product Manager si sveglia

Per capire quali sono gli obiettivi che un Product Manager vuole raggiungere ogni mattina quando inizia la sua giornata lavorativa, partiamo da una definizione:

A product manager is the person who identifies the customer need and the larger business objectives that a product or feature will fulfill, articulates what success looks like for a product, and rallies a team to turn that vision into a reality.[1]

Da questa definizione è evidente che tra i suoi obiettivi principali ci sia l’individuazione e risoluzione dei problemi dell’utente finale. Il Product Manager ha quindi un interesse diretto nei confronti dei problemi dell’utente e costruire una soluzione per i suoi problemi è il suo l’obiettivo ultimo.

Quando sorge il sole, un Software Engineer si sveglia

Vediamo ora quali sono quelle di un Software Engineer, partendo sempre da una definizione:

[Software engineering is] the practical application of scientific knowledge to the creative design and building of computer programs. It also includes associated documentation needed for developing, operating, and maintaining them.[2]

L’accento viene messo principalmente sull’utilizzo di conoscenze scientifiche al servizio dello sviluppo e manutenzione di programmi. A differenza del Product Manager, quindi, per il Software Engineer trovare una soluzione per l’utente è un obiettivo indiretto, dove invece le sue energie sono impiegate nel risolvere problemi principalmente di carattere tecnico, sviluppando software.

Il paradiso di uno è il purgatorio dell’altro

Anche facendo parte dello stesso Product Team e lavorando verso il raggiungimento di un outcome comune, abbiamo visto come Product Manager e Software Engineer risolvono problemi da punti di vista differenti. Da una parte il focus è sulla risoluzione dei problemi degli utenti, dall’altra sul risolvere problemi tecnici.

Se questa affermazione è vera, dovremmo chiederci se anche le aspettative delle due figure in termini di ambiente ideale per svolgere al meglio il proprio lavoro siano diverse.

Proviamo quindi a elencare quali potrebbero essere delle condizioni ottimali per un Product Manager:

• Poter trovare con precisione i problemi degli utenti e le giuste soluzioni
• Riuscire a testare le proprie ipotesi e soluzioni rapidamente
• Garantire rilasci veloci e puntuali delle soluzioni all’utente finale

Stesso esercizio, ma elencando delle ipotetiche condizioni ottimali per un Software Engineer:

• Poter lavorare su requisiti ben definiti e facilmente traducibili in specifiche
• Avere il tempo per scrivere del codice di qualità e testato
• Avere il tempo per fare refactoring e rimanere aggiornato sulle ultime tecnologie

Salta subito all’occhio come da una parte il Product Manager cerchi velocità e prontezza nel cambiamento ma dall’altra il Software Engineer cerchi tempo per la qualità e manutenibilità. Ciò che è il desiderata dell’uno è l’indesiderata dell’altro.

Questi parallelismi tra obiettivi e condizioni di lavoro ideali ci permettono di evidenziare che, come spesso accade nelle relazioni, le differenze tra i due ruoli possano essere tra le cause principali di frizioni e mancanza di una comunicazione e collaborazione efficace.

Facciamo funzionare questa collaborazione

Fortunatamente esistono delle buone pratiche e strategie per poter colmare queste differenze. Ecco quelle che ho applicato o visto applicare nel corso della mia carriera e che hanno avuto gli impatti maggiori.

Coinvolgere il Software Engineer il prima possibile nel design della soluzione

Il Software Engineer ha la conoscenza tecnica per poter definire cosa sarebbe fattibile o semplice da realizzare e cosa è infattibile nei tempi desiderati o complesso da realizzare. Pensate, ad esempio, a un Mobile Engineer. Sicuramente conosce cosa la piattaforma mobile mette a disposizione con poco effort piuttosto che ricreare elementi grafici, interazioni o animazioni custom.

Condividere i dati raccolti per misurare l’impatto della soluzione

Come Software Engineer ho sempre trovato confortante lavorare su feature o change request guidate dai dati. Questo mi ha permesso di approcciare il problema sapendo che avrebbe avuto buone chance di portare un effettivo valore all’utente. Credo che siano poche le cose che possano frustrare di più un Software Engineer di rilavorare la stessa feature più volte per via di decisioni fatte con un approccio “di pancia”.

Accettare che una semplice richiesta non è sinonimo di uno sviluppo semplice

Ci saranno diverse situazioni in cui farete richieste di lavorazioni che potrebbero sembrare banali. Spesso, all’atto pratico, queste lavorazioni possono nascondere sfide che a uno sguardo tecnicamente non esperto possono sfuggire. Potrebbero esserci diversi edge case da gestire, potrebbe essere necessario toccare del codice legacy di difficile gestione, potrebbe essere necessario lavorare con codice di terze parti non particolarmente affidabile o ben documentato etc. L’importante è comunicare con i Software Engineer per capire quali di queste difficoltà potrebbero esserci, in modo tale da essere preparati a tempi di realizzazioni più lunghi e pianificare strategie per gli sviluppi delle prossime funzionalità.

Definire e comunicare efficacemente aspettative e requisiti

Lavorare su task troppo generici il più delle volte conduce a male interpretazioni nello svolgimento del task stesso. Il più delle volte questo porta a perdere tempo nelle fasi iniziali della lavorazione per tentare di ottenere le informazioni mancanti o, peggio ancora, a perdere tempo al completamento del task, quando, in fase di verifica, ci si rende conto che il risultato finale è diverso da quello atteso. È quindi importante capire il livello di dettaglio necessario al Software Engineer per poter ridurre il più possibile il grado d’incertezza nella comprensione del task e la forma con cui comunicare queste informazioni (User Story, Acceptance Criteria, Definition of Done, wireframe etc).

Condividere la roadmap

Condividere quali sono gli obiettivi almeno nel breve-medio termine può aiutare la sinergia tra Product Manager e Software Engineer. La condivisione aiuta da una parte il Software Engineer a capire su quali parti del prodotto software dovrà lavorare, eliminare o aggiungere, potendo quindi pianificare efficacemente le prossime lavorazioni, e dall’altra permette al Product Manager di avere una stima sull’effort necessario dal punto di vista dello sviluppo dei singoli obiettivi.

Dare importanza ad allineamenti e retrospettive

Gli allineamenti (meglio se giornalieri, anche con dei rapidi stand up) sono il momento ideale per verificare che gli sviluppi stiano andando senza intoppi e, se presenti, farli presenti e correre ai ripari. Ma, personalmente, trovo che siano le retrospettive ricorrenti a dare il maggior impatto. Questo è il momento in cui si può condividere e analizzare cosa è stato fatto (e come) e confrontarsi su cosa è andato bene duranti gli ultimi sviluppi e cosa si potrebbe migliorare. Nei team in cui ho lavorato, le retrospettive sono state fondamentali per portare miglioramenti significativi all’operatività nel team, alla comunicazione con gli stakeholder e per ultimo, ma certamente non per importanza, all’umore del team stesso.

Coinvolgere nelle riunioni solo chi è veramente necessario

Raramente ho avuto a che fare con Software Engineer che amassero partecipare alle riunioni. In questi casi la strategia che ho trovato più efficace è d’interagire principalmente solo con la figura di riferimento del team d’ingegneria (Team Lead, Tech Lead o Engineering Manager) e di coinvolgere l’intero team solo quando strettamente necessario. “Ci sono troppe riunioni” è una frase che mi è capitata spesso di sentire nel corso di one-to-one e, soprattutto, retrospettive.

Conclusioni

Abbiamo quindi approcciato il problema della collaborazione tra Product Manager e Software Engineer identificandone prima le cause principali e successivamente le strategie per migliorarla di cui ho avuto la fortuna di vederne l’applicazione e l’efficacia.

Alla base di tutto, riassumerei questa breve analisi in 2 semplici concetti:

• Identificare le cause principali di un problema è fondamentale per trovare strategie efficaci per risolverlo. In questo caso, riconoscere che il Product Manager lavora per risolvere direttamente i problemi dell’utente, mentre il Software Engineer indirettamente, e che questo genera aspettative diverse;
• L’ascolto attivo, la condivisione di obiettivi e aspettative e il desiderio di far sempre al meglio il proprio lavoro con miglioramenti continui, basati su iterazioni frequenti, possono essere strategie applicabili sin da subito per portare la collaborazione tra Product Manager e Software Engineer a un altro livello.

E tu come vivi o hai vissuto questa collaborazione? Hai trovato qualche strategia o buona pratica che ti ha aiutato a migliorarla? Se ti va, contattami! Mi farebbe molto piacere confrontarci e condividere le nostre esperienze!

Se ti è piaciuto quello che hai letto, iscriviti alla nostra Newsletter. Riceverai direttamente nel tuo inbox i nostri articoli insieme a tante altre sorprese 

Fonti

1. Sherif Mansour. “Product Manager: The role and best practices for beginners”. 
2. Matthew Martin. “What is Software Engineering? Definition, Basics, Characteristics”. 12/02/2022.