Dare e Ricevere: 6 Modi in cui Ingegneri e Product Manager Possono Aiutarsi a Vicenda

Dimenticate tutto ciò che avete sentito sulla rivalità tra ingegneri e product manager: è un paradigma che deve morire. Il mondo tecnologico di oggi si muove troppo velocemente, e l'unico modo per andare avanti è attraverso una collaborazione basata sul dare e avere. Questo articolo svela sei modi in cui ingegneri e PM possono evitare di scontrarsi e rimanere concentrati sulla missione.

1. PM: Condividere la Visione Generale; Ingegneri: Condividere i Vincoli Tecnici

Dare: I PM possono aiutare gli ingegneri fornendo una chiara comprensione degli obiettivi aziendali e delle esigenze dei clienti dietro un progetto. Questo aiuta gli ingegneri a capire perché una particolare funzionalità o scadenza è importante. Condividere il contesto in anticipo permette agli ingegneri di allineare il loro lavoro con obiettivi più ampi.

Prendere: Gli ingegneri, in cambio, dovrebbero comunicare apertamente i vincoli tecnici e le complessità coinvolte in un progetto. Se una funzionalità apparentemente piccola richiederà importanti modifiche al backend, spiegarlo in anticipo aiuta i PM a prendere decisioni migliori riguardo la priorità e le tempistiche.

Esempio: Un PM spiega che una funzionalità è fondamentale per vincere un importante cliente o per affrontare una minaccia competitiva, il che aiuta gli ingegneri a darle priorità. Allo stesso modo, quando un ingegnere condivide che una funzionalità richiederà più tempo a causa di problemi di scalabilità, un PM può adeguare le aspettative.

Risorsa

Per i PM: "Product Management in Practice" di Matt LeMay – Una guida completa per comprendere e comunicare gli obiettivi di prodotto.

Where the World Designs Electronics

Break down silos and enhance collaboration across all aspects of electronics development

Find Out More

Per gli Ingegneri: "The Pragmatic Programmer" di Andrew Hunt e David Thomas – Un libro che enfatizza la comunicazione e la presa di decisioni tecniche nel processo di sviluppo.

2. PM: Evitare il Micromanagement; Ingegneri: Coinvolgetevi nel Processo di Ideazione

Dare: I responsabili di prodotto dovrebbero resistere alla tentazione di controllare ogni dettaglio dell'esecuzione del prodotto. Fidatevi degli ingegneri per gestire gli aspetti tecnici e date loro lo spazio per risolvere i problemi a modo loro. Un management troppo prescrittivo può soffocare la creatività e portare al disimpegno.

Prendere: Gli ingegneri dovrebbero prendere l'iniziativa nel processo di ideazione. Non aspettate di essere invitati—offrite suggerimenti e idee su come migliorare il prodotto. Molti ingegneri hanno intuizioni preziose che possono migliorare la funzionalità, le prestazioni o il design del prodotto. Essere proattivi dimostra che siete investiti nel successo del prodotto oltre che semplicemente a scrivere codice.

Esempio: Un PM delinea gli obiettivi aziendali e chiede input invece di dire agli ingegneri come implementare una funzionalità. Nel frattempo, gli ingegneri offrono soluzioni tecniche proattivamente e contribuiscono alle sessioni di brainstorming.

Risorsa

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

Per i PM: "Empowered" di Marty Cagan e Chris Jones – Questo libro esplora come potenziare i team affinché assumano la proprietà dell'esecuzione del prodotto.

Per gli Ingegneri: "Creative Confidence" di Tom Kelley e David Kelley – Una grande risorsa per gli ingegneri che cercano di contribuire creativamente all'ideazione del prodotto.

3. PM: Dare Credito Generosamente; Ingegneri: Supportare Pubblicamente le Decisioni sul Prodotto

Dare: Una lamentela comune tra gli ingegneri è che i PM si prendono il merito del successo del progetto poiché sono spesso loro a presentarlo alla leadership. I PM possono aiutare a costruire fiducia condividendo il merito con il team di ingegneria e dando agli ingegneri l'opportunità di presentare il loro lavoro.

Prendere: Gli ingegneri, in cambio, possono supportare le decisioni dei PM quando presentano ad altri team o stakeholder. Anche se non si è d'accordo su alcuni aspetti, sostenere pubblicamente le decisioni sul prodotto mostra unità e favorisce una cultura collaborativa.

Esempio: Dopo un lancio di successo, un PM invita gli ingegneri a presentare i risultati tecnici. Gli ingegneri, in cambio, supportano pubblicamente le decisioni sui prodotti dei PM nelle riunioni con gli stakeholder.

Risorsa

Per i PM: "Radical Candor" di Kim Scott – Un libro che fornisce spunti su come costruire relazioni forti e dare credito dove è dovuto.

Per gli ingegneri: "Crucial Conversations" di Al Switzler, Joseph Grenny e Ron McMillan - Impara come avere conversazioni efficaci e di supporto con colleghi e leadership.

4. PMs: Siate aperti alle discussioni sul debito tecnico; Ingegneri: Siate realistici riguardo ai tempi

Da parte dei PMs: I PM possono aiutare gli ingegneri essendo aperti a conversazioni sul debito tecnico e sulla manutenzione. È allettante dare priorità a nuove funzionalità, ma trascurare il fondamento tecnico può portare a problemi maggiori. Consentire tempo per il necessario rifacimento del codice o miglioramenti dell'infrastruttura dimostra una comprensione della salute del prodotto a lungo termine.

Da parte degli ingegneri: Gli ingegneri dovrebbero anche essere realistici su quanto tempo le cose richiederanno. Se fornite stime eccessivamente conservative, i PM potrebbero sentirsi sotto pressione a spingere per tempi più brevi. Fornire tempi realistici e comunicare i ritardi in anticipo aiuta i PM a pianificare efficacemente.

Esempio: Gli ingegneri comunicano i rischi del debito tecnico e i PM concedono tempo per il rifacimento, mentre gli ingegneri forniscono stime di tempo realistiche per gestire le aspettative.

Risorsa

Per i PM: "Technical Debt 101" di ThoughtWorks - Un ottimo primo approccio per comprendere il debito tecnico e come gestirlo.

Per gli Ingegneri: "The Phoenix Project" di Gene Kim, Kevin Behr e George Spafford – Un romanzo che illustra l'impatto dell'equilibrio tra debito tecnico e priorità aziendali.

5. PMs: Includere gli Ingegneri nel Feedback dei Clienti; Ingegneri: Rispettare le Priorità Aziendali

Dare: I PM possono aiutare gli ingegneri condividendo direttamente il feedback dei clienti. Gli ingegneri spesso si sentono più connessi al prodotto quando ascoltano come i clienti lo stanno utilizzando, quali problemi stanno affrontando e quali funzionalità amano.

Prendere: Gli ingegneri, a loro volta, dovrebbero rispettare le priorità aziendali che i PM stanno bilanciando. Anche se può essere frustrante lanciare una funzionalità non perfetta, farlo può talvolta essere cruciale per mantenere la competitività.

Esempio: Un PM invita gli ingegneri a partecipare alle sessioni di feedback dei clienti, e gli ingegneri comprendono l'importanza di certi lanci di funzionalità, anche quando sentono che alcuni aspetti necessitano di ulteriori rifiniture.

Risorsa:

Per i PM: "The Lean Product Playbook" di Dan Olsen – Una guida pratica per comprendere il feedback dei clienti e tradurlo in strategie di sviluppo prodotto azionabili.

Per gli Ingegneri: "The Mythical Man-Month" di Frederick P. Brooks – Questo libro classico affronta le sfide relative alle tempistiche di sviluppo del software e alle aspettative aziendali.

6. PM: Stabilire Obiettivi Chiari e Raggiungibili; Ingegneri: Essere Orientati alla Soluzione

Dare: Una delle cose più preziose che un PM può fare per gli ingegneri è stabilire obiettivi chiari e raggiungibili. Requisiti vaghi o priorità in costante cambiamento possono causare frustrazione. Definendo cosa significa il successo e attenendosi a quei parametri, i PM possono aiutare gli ingegneri a concentrarsi e lavorare in modo efficiente.

Prendere: Gli ingegneri dovrebbero affrontare i problemi con un approccio orientato alla soluzione. Invece di elencare motivi per cui qualcosa non può essere fatto, offrire alternative o soluzioni alternative. Essere costruttivi aiuta il PM e il team a progredire senza rimanere impantanati da ostacoli tecnici.

Esempio: Un PM fornisce metriche di successo chiare per un progetto, mentre gli ingegneri offrono soluzioni pratiche quando sorgono vincoli tecnici.

Risorsa

Per i PM: "Measure What Matters" di John Doerr – Impara a stabilire obiettivi chiari e risultati chiave misurabili (OKR) che si allineano con gli sforzi del tuo team.

Per gli ingegneri: "Progettare Applicazioni Data-Intensive" di Martin Kleppmann – Una risorsa tecnica che aiuta gli ingegneri a riflettere sulla costruzione di sistemi scalabili e affidabili, bilanciando i requisiti del prodotto.

Esempio dal Mondo Reale: L'Algoritmo in 5 Passi di Elon Musk per Ridurre la Burocrazia Interna

Elon Musk è noto per il suo stile di gestione audace in Tesla e SpaceX. Nella sua ricerca per tagliare la burocrazia interna, Musk ha sviluppato un algoritmo in cinque passi, dettagliato nella sua recente biografia scritta da Walter Isaacson, che fornisce un quadro d'azione per semplificare i processi.

1. Mettere in Discussione Ogni Requisito: Musk consiglia di mettere in discussione ogni requisito, anche se proviene da una "persona intelligente". Assegnare un nome a ciascun requisito e continuare a chiedersi se sia necessario. Se non lo è, eliminarlo.
2. Eliminare Qualsiasi Parte del Processo Possibile: Musk sottolinea che la semplicità è fondamentale. Eliminare i passaggi non necessari—andare oltre ciò che si pensa sia necessario. Se non si deve aggiungere almeno il 10% in più, non si è eliminato abbastanza.
3. Semplificare e Ottimizzare: Solo dopo aver eliminato i passaggi non necessari si dovrebbe semplificare e ottimizzare ciò che rimane. Evitare l'errore di razionalizzare processi che non dovrebbero esistere in primo luogo.
4. Accelerare i Tempi di Ciclo: Una volta che il processo è ottimizzato, concentrarsi su come accelerarlo. Musk avverte contro il perdere tempo ad accelerare parti del processo che sono ridondanti o non necessarie.
5. Automatizzare alla Fine: L'ultimo passo di Musk è l'automazione, ma solo dopo aver messo in discussione a fondo, eliminato e semplificato il processo. Automatizzare troppo presto può portare a una complessità non necessaria.

Il metodo di Musk può essere un potente esempio di come i PM e gli ingegneri possono lavorare insieme per sfidare le inefficienze, ottimizzare i flussi di lavoro e migliorare la produttività. Continuando a mettere in discussione le ipotesi e semplificando i processi, i team di sviluppo prodotto possono ridurre drasticamente gli ostacoli interni e migliorare la collaborazione.

Meno Stress, Più Passione

Come ha saggiamente detto Simon Sinek, "Lavorare duramente per qualcosa che non ci interessa si chiama stress; lavorare duramente per qualcosa che amiamo si chiama passione." Lo stesso si applica alla relazione tra ingegneri e PM. Quando lavorano insieme con rispetto reciproco e passione, accadono grandi cose. Lasciate che questo spirito di dare e ricevere guidi il prossimo grande rilascio di prodotto del vostro team.