Troca de Favores: 6 Maneiras de Engenheiros e Gerentes de Produto se Ajudarem Mutuamente

Esqueça tudo o que você ouviu sobre rivalidade entre engenheiros e gerentes de produto — é um paradigma que precisa morrer. O mundo da tecnologia de hoje se move muito rápido, e a única maneira de avançar é através da colaboração mútua. Este artigo revela seis maneiras pelas quais engenheiros e PMs podem evitar conflitos e permanecer focados na missão.

1. PMs: Compartilhem a Visão Geral; Engenheiros: Compartilhem as Restrições Técnicas

Dar: Os PMs podem ajudar os engenheiros fornecendo uma compreensão clara dos objetivos de negócios e das necessidades dos clientes por trás de um projeto. Isso ajuda os engenheiros a entenderem por que um recurso específico ou prazo é importante. Compartilhar o contexto desde o início permite que os engenheiros alinhem seu trabalho com objetivos mais amplos.

Receber: Os engenheiros, em retorno, devem comunicar abertamente as restrições técnicas e complexidades envolvidas em um projeto. Se um recurso aparentemente pequeno exigir grandes mudanças no backend, explicar isso desde o início ajuda os PMs a tomar melhores decisões sobre priorização e cronogramas.

Exemplo: Um PM explica que um recurso é chave para conquistar um grande cliente ou enfrentar uma ameaça competitiva, o que ajuda os engenheiros a priorizá-lo. Da mesma forma, quando um engenheiro compartilha que um recurso levará mais tempo devido a problemas de escalabilidade, um PM pode ajustar as expectativas.

Recurso

Para Gerentes de Produto: "Product Management in Practice" por Matt LeMay – Um guia abrangente para entender e comunicar os objetivos do produto.

Where the World Designs Electronics

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

Find Out More

Para Engenheiros: "The Pragmatic Programmer" por Andrew Hunt e David Thomas – Um livro que enfatiza a comunicação e a tomada de decisões técnicas no processo de desenvolvimento.

2. GPs: Evite a Micromanagement; Engenheiros: Envolva-se no Processo de Ideação

Dar: Gerentes de produto devem resistir à vontade de controlar cada detalhe da execução do produto. Confie nos engenheiros para lidar com os aspectos técnicos e dê a eles espaço para resolver problemas à maneira deles. Uma gestão excessivamente prescritiva pode sufocar a criatividade e levar ao desengajamento.

Receber: Engenheiros devem tomar a iniciativa no processo de ideação. Não espere ser solicitado—ofereça sugestões e ideias sobre como melhorar o produto. Muitos engenheiros têm insights valiosos que podem aprimorar a funcionalidade, o desempenho ou o design do produto. Ser proativo mostra que você está investido no sucesso do produto além de apenas escrever código.

Exemplo: Um GP delineia objetivos de negócios e pede por contribuições em vez de dizer aos engenheiros como implementar uma funcionalidade. Enquanto isso, engenheiros oferecem soluções técnicas proativamente e contribuem para as sessões de brainstorming.

Recurso

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

Para Gestores de Produto (PMs): "Empowered" de Marty Cagan e Chris Jones – Este livro explora como empoderar equipes para assumirem a propriedade da execução do produto.

Para Engenheiros: "Confiança Criativa" de Tom Kelley e David Kelley – Um ótimo recurso para engenheiros que procuram contribuir de forma criativa para a idealização do produto.

3. PMs: Dê Crédito Generosamente; Engenheiros: Apoiem as Decisões do Produto Publicamente

Dar: Uma reclamação comum entre engenheiros é que os PMs recebem o crédito pelo sucesso do projeto, já que são frequentemente eles que o apresentam à liderança. Os PMs podem ajudar a construir confiança compartilhando o crédito com a equipe de engenharia e dando aos engenheiros oportunidades para apresentarem seu trabalho.

Receber: Em retorno, os engenheiros podem apoiar as decisões dos PMs quando apresentarem a outras equipes ou stakeholders. Mesmo que você discorde de alguns aspectos, apoiar publicamente as decisões do produto mostra unidade e fomenta uma cultura colaborativa.

Exemplo: Após um lançamento bem-sucedido, um PM convida engenheiros para apresentarem os feitos técnicos. Em retorno, os engenheiros apoiam publicamente as decisões do produto dos PMs em reuniões com stakeholders.

Recurso

Para PMs: "Radical Candor" de Kim Scott – Um livro que oferece insights sobre construir relacionamentos fortes e dar crédito onde é devido.

Para Engenheiros: "Conversas Cruciais" de Al Switzler, Joseph Grenny e Ron McMillan – Aprenda como ter conversas eficazes e de apoio com colegas e liderança.

4. Gerentes de Projeto: Estejam Abertos a Discussões Sobre Dívida Técnica; Engenheiros: Sejam Realistas Sobre os Prazos

Dar: Os gerentes de projeto podem ajudar os engenheiros estando abertos a conversas sobre dívida técnica e manutenção. É tentador priorizar novas funcionalidades, mas negligenciar a base técnica pode levar a problemas maiores. Permitir tempo para o necessário refatoramento de código ou melhorias na infraestrutura demonstra um entendimento da saúde do produto a longo prazo.

Receber: Os engenheiros também devem ser realistas sobre quanto tempo as coisas vão levar. Se você fornecer estimativas excessivamente conservadoras, os gerentes de projeto podem se sentir pressionados a questionar os prazos. Fornecer prazos precisos e comunicar atrasos antecipadamente ajuda os gerentes de projeto a planejar efetivamente.

Exemplo: Engenheiros comunicam os riscos da dívida técnica e os gerentes de projeto permitem tempo para refatoração, enquanto os engenheiros fornecem estimativas de tempo realistas para gerenciar expectativas.

Recurso

Para Gerentes de Projeto: "Dívida Técnica 101" da ThoughtWorks – Um ótimo guia inicial sobre entender a dívida técnica e como gerenciá-la.

Para Engenheiros: "O Projeto Fênix" por Gene Kim, Kevin Behr e George Spafford – Um romance que ilustra o impacto de equilibrar a dívida técnica e as prioridades de negócios.

5. PMs: Incluam os Engenheiros no Feedback dos Clientes; Engenheiros: Respeitem as Prioridades de Negócios

Dê: Os PMs podem ajudar os engenheiros compartilhando diretamente o feedback dos clientes. Os engenheiros muitas vezes se sentem mais conectados ao produto quando ouvem como os clientes estão usando-o, quais problemas estão enfrentando e quais funcionalidades eles amam.

Receba: Os engenheiros, por sua vez, devem respeitar as prioridades de negócios que os PMs estão equilibrando. Embora possa ser frustrante lançar uma funcionalidade que não é perfeita, fazer isso às vezes pode ser crucial para manter a competitividade.

Exemplo: Um PM convida engenheiros para participar de sessões de feedback dos clientes, e os engenheiros entendem a importância de lançar certas funcionalidades, mesmo quando sentem que alguns aspectos precisam de mais refinamento.

Recurso:

Para PMs: "O Manual do Produto Enxuto" por Dan Olsen – Um guia prático para entender o feedback dos clientes e traduzi-lo em estratégias de desenvolvimento de produto acionáveis.

Para Engenheiros: "O Mítico Homem-Mês" por Frederick P. Brooks – Este livro clássico aborda os desafios dos cronogramas de desenvolvimento de software e as expectativas empresariais.

6. PMs: Definam Metas Claras e Atingíveis; Engenheiros: Sejam Orientados para Soluções

Dar: Uma das coisas mais valiosas que um PM pode fazer pelos engenheiros é definir metas claras e atingíveis. Requisitos vagos ou prioridades que mudam constantemente podem causar frustração. Ao definir como o sucesso se parece e manter-se fiel a esses parâmetros, os PMs podem ajudar os engenheiros a se concentrarem e trabalharem de forma eficiente.

Receber: Os engenheiros devem abordar os problemas com uma mentalidade orientada para soluções. Em vez de listar razões pelas quais algo não pode ser feito, ofereçam alternativas ou soluções alternativas. Ser construtivo ajuda o PM e a equipe a avançar sem ficar presos por obstáculos técnicos.

Exemplo: Um PM fornece métricas claras de sucesso para um projeto, enquanto os engenheiros oferecem soluções práticas quando surgem restrições técnicas.

Recurso

Para PMs: "Measure What Matters" por John Doerr – Aprenda a definir objetivos claros e resultados-chave mensuráveis (OKRs) que se alinham com os esforços da sua equipe.

Para Engenheiros: "Designing Data-Intensive Applications" por Martin Kleppmann – Um recurso técnico que ajuda engenheiros a pensar na construção de sistemas escaláveis e confiáveis, equilibrando requisitos do produto.

Exemplo do Mundo Real: O Algoritmo de 5 Passos de Elon Musk para Cortar a Burocracia Interna

Elon Musk é bem conhecido por seu estilo de gestão ousado na Tesla e na SpaceX. Em sua busca para cortar a burocracia interna, Musk desenvolveu um algoritmo de cinco passos, detalhado em sua recente biografia por Walter Isaacson, que fornece um framework acionável para agilizar processos.

1. Questionar Todo Requisito: Musk aconselha a desafiar cada requisito, mesmo que venha de uma "pessoa inteligente". Atribua um nome a cada requisito e continue perguntando se é necessário. Se não for, elimine-o.
2. Eliminar Qualquer Parte do Processo que Puder: Musk enfatiza que a simplicidade é a chave. Delete etapas desnecessárias—vá além do que você acha que deveria. Se você não precisar adicionar pelo menos 10% de volta, você não eliminou o suficiente.
3. Simplificar e Otimizar: Somente após eliminar etapas desnecessárias é que você deve simplificar e otimizar o que resta. Evite o erro de agilizar processos que não deveriam existir em primeiro lugar.
4. Acelerar o Tempo de Ciclo: Uma vez que o processo esteja otimizado, foque em acelerá-lo. Musk adverte contra o desperdício de tempo acelerando partes dos processos que são redundantes ou desnecessárias.
5. Automatizar por Último: O último passo de Musk é a automação, mas somente após questionar, deletar e simplificar exaustivamente o processo. Automatizar cedo demais pode levar a uma complexidade desnecessária.

O método de Musk pode ser um exemplo poderoso de como PMs e engenheiros podem trabalhar juntos para desafiar ineficiências, otimizar fluxos de trabalho e aumentar a produtividade. Ao questionar continuamente as suposições e simplificar processos, as equipes de desenvolvimento de produtos podem reduzir drasticamente os obstáculos internos e melhorar a colaboração.

Menos Estresse, Mais Paixão

Como Simon Sinek sabiamente disse, "Trabalhar duro por algo que não nos importamos é chamado de estresse; trabalhar duro por algo que amamos é chamado de paixão." O mesmo se aplica à relação entre engenheiros e PMs. Quando trabalham juntos com respeito mútuo e paixão, coisas grandiosas acontecem. Deixe esse espírito de dar e receber impulsionar o próximo grande lançamento de produto da sua equipe.