Gestão de Produto para Engineering Managers
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Colaboração EM/PM por MidJourney
O objetivo principal de um Engineering Manager (EM) é criar um time eficaz. Com isso em mente, ele vai passar a maior parte do tempo focado no trabalho de engenharia e em como os engenheiros trabalham. No entanto, isso não deveria ser tudo. Um time de engenharia de produto trabalha dentro de um sistema mais amplo, e um EM eficaz também deve garantir que esse sistema seja o mais eficaz possível.
A motivação para isso é simples. O contexto onde um time de engenharia opera vai impactar significativamente os resultados que podem ter. Portanto, entender e agir sobre o sistema mais amplo é uma forma direta de os EMs influenciarem positivamente seu time.
E a área mais crítica para observar é Gestão de Produto. O pensamento de produto define não apenas no que um time de engenharia vai trabalhar, mas também como vai trabalhar, dependendo de como as ideias são moldadas e executadas.
Como Duas Ervilhas em uma Vagem
A parceria entre o Product Manager (PM) e o EM é a mais importante em um time multifuncional de engenharia de produto. Produto define o quê, e engenharia define o como. Ambos estando em sincronia significa que o time vai trabalhar nas coisas certas da forma certa, correto?
Correto. No entanto, estar alinhado nem sempre significa trabalhar de forma eficaz juntos. Uma parceria bem-sucedida entre PM e EM é mais do que concordar sobre o que será entregue. É sobre criar um sistema eficaz, da ideia à produção, onde o trabalho pode ser executado com sucesso, entregando valor ao cliente.
Da perspectiva de um EM, isso significa garantir que o processo de produto ajude o time de engenharia a ser eficaz. E isso significa que eles trabalham nas coisas certas e fazem isso da forma certa.
Nem Água e Óleo
Infelizmente, é comum ver times onde tanto PM quanto EM estão alinhados e concordam, mas o time ainda sofre com colaboração ineficaz. Isso porque todo mundo fica na sua própria raia demais. PMs se sentem desconfortáveis perguntando “Por que isso está demorando tanto?” enquanto EMs focam em executar o que lhes é dito.
Um processo onde produto entrega o que fazer e depois engenharia executa é o que processos waterfall são, e colocar as pessoas no mesmo time não resolve isso por padrão. Colaboração significa trabalhar junto, não trabalhar lado a lado.
Como o desenvolvimento de produto influencia todo o trabalho feito pelo time, esse antipadrão pode levar a problemas de diversas formas. Aqui estão alguns que já vi:
Em um time que gerenciei no passado, tínhamos um ciclo de pesquisa de produto independente que durava vários meses, o qual definiria como o time resolveria um problema do cliente. Como resultado, designers e product managers passavam muito tempo entrevistando clientes, definindo opções de design e obtendo feedback sem consultar nenhum engenheiro (ou pelo menos não consultando-os com frequência).
Como esperado, isso resultou em decisões de produto ineficazes em toda parte, que não consideravam o esforço envolvido e as alternativas às soluções projetadas. O pico aconteceu em um projeto específico, onde um engenheiro interrompeu uma reunião de kick-off do projeto (que havia passado por extensa pesquisa com clientes) após cinco minutos, pois a proposta de produto não poderia ser feita sem uma reescrita do nosso sistema.
Em outro time, engenharia estava executando bem, mas frequentemente abaixo das expectativas em relação a quanto conseguia entregar em um período específico de tempo. Como resultado, embora o time entregasse trabalho, era decepcionante. Depois de um tempo, ficou claro que o antipadrão comum era que decisões de produto e design frequentemente não estavam prontas (o suficiente) quando o trabalho começava, levando a ciclos constantes de perguntas e redesign enquanto o trabalho estava em andamento.
Embora a colaboração em tempo real entre produto, design e engenharia durante a execução seja muito saudável, trabalho trocando de mãos por períodos prolongados não é. Geralmente significa que parte do processo precisa ser corrigida antes do trabalho chegar aos engenheiros.
Em um terceiro exemplo, um time perdeu um prazo crítico em um projeto estratégico. Embora todos trabalhassem diligentemente no que lhes foi atribuído, havia uma falta de entendimento compartilhado entre produto e engenharia sobre qual trabalho estava sendo executado. Isso geralmente se manifesta como tickets tecnicamente focados que PMs têm dificuldade em entender, levando as pessoas a torcer para que o que os engenheiros estão trabalhando seja a coisa certa a fazer. Infelizmente, neste caso, não era. Isso levou o escopo a aumentar significativamente dentro do projeto e frustração generalizada.
Pense Globalmente, Aja Globalmente
No final das contas, EMs precisam pensar em gerenciar seu time de ponta a ponta. Isso significa gerenciar engenheiros, onde têm autoridade e poder de decisão, e também em produto e design, onde têm apenas influência mas também são impactados pelas decisões.
Ao pensar sobre isso, há alguns princípios amplos e críticos nos quais os EMs devem focar para seus times:
Pense da ideia à produção — o escopo de interesse do EM não deve ser apenas como o código é escrito. Deve ser sobre como problemas se tornam ideias e como essas ideias são moldadas e executadas. Isso significa entender o processo de produto na sua empresa e influenciá-lo quando necessário.
Menor lead time significa maior valor — ao influenciar o processo da sua empresa, foque em reduzir o lead time da ideia à produção. O sucesso de um time não é definido por quão bem engenharia executa, mas por quão rápido conseguem entregar trabalho de alta qualidade e impactante aos seus clientes. Isso significa tomar decisões que incentivem ciclos curtos de feedback, iterações curtas e colaboração próxima entre disciplinas em todos os âmbitos.
Foque em alinhamento antecipado — o principal benefício de times multifuncionais de engenharia de produto é ter diferentes perspectivas moldando o produto em todas as fases do desenvolvimento. Por causa disso, é essencial incentivar alinhamento antecipado entre produto, design e engenharia, garantindo que todos entendam e concordem com o que estão construindo, por que estão construindo e como vão fazer. Um processo prático que usei para alcançar isso são workshops de Inception para planejamento, assegurando que todo o time tenha voz desde o início.
Escope o desenvolvimento em iterações de qualidade — a forma mais fácil de evitar o aperto final é garantir que sempre haja uma versão do produto que esteja live ou pronta para ir ao ar. Isso transforma qualquer conversa desconfortável sobre escopo (“Por que essa feature ainda não está live?”) em uma decisão de negócio mais amigável (“Devemos lançar a versão 0.2, que está pronta agora?”). A melhor técnica para isso é User Story Mapping, que permite que times pensem em escopo em gradientes e não em chaves liga/desliga.
Crie espaço para conversas desafiadoras — EMs precisam garantir que outras disciplinas entendam o trabalho e os trade-offs sendo feitos, permitindo que participem da conversa de engenharia. Na prática, isso significa escrever todo o escopo da perspectiva do cliente, incentivar discussões saudáveis sobre escopo e esforço, e permitir que todos os lados questionem o valor de qualquer trabalho sendo executado dentro do time.
No final das contas, engenheiros e EMs precisam focar em impacto, e impacto em um time de engenharia de produto não é definido apenas por escrever código — quanto mais ampla a conversa que EMs conseguirem criar em torno disso, melhores serão os resultados que terão.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.