Como manter produto e engenharia alinhados sem mais reuniões

O time de Produto conhece a necessidade do usuário, o objetivo do negócio, o contexto do mercado e o raciocínio estratégico por trás do roadmap. O time de Engenharia conhece as restrições técnicas, as implicações de arquitetura, as estimativas de esforço e os riscos operacionais. Quando esses dois corpos de conhecimento se conectam, a equipe constrói a coisa certa e bem feita. Quando isso não acontece, uma de duas coisas ocorre: a engenharia constrói algo tecnicamente excelente que não resolve o problema do usuário, ou o produto especifica algo que é inviável de construir e precisa ter seu escopo redefinido no meio da sprint.

A resposta padrão para esse desalinhamento é mais reuniões: planejamento de sprint, refinamento de backlog, sincronizações multifuncionais, sessões de pré-planejamento e as várias vertentes de "vamos colocar todo mundo em uma sala". Essas reuniões ajudam, mas estão tratando o sintoma (desalinhamento) em vez da causa (conhecimento desconectado).

Por que reuniões não resolvem o alinhamento

As reuniões proporcionam alinhamento no momento em que acontecem. O alinhamento se deteriora imediatamente porque o contexto compartilhado na reunião foi compartilhado verbalmente e não está disponível para quem não estava lá, ou para quem estava lá mas esqueceu os detalhes uma semana depois.

Uma reunião de planejamento de sprint em que o produto explica o contexto do usuário e a engenharia explica as restrições técnicas produz alinhamento para as pessoas na sala, para aquela sprint. O PM que entra no meio da sprint não tem o contexto. O engenheiro que estava ausente não o tem. As decisões tomadas durante a reunião não são documentadas, por isso, quando surge uma dúvida mais tarde ("por que decidimos desconsiderar a funcionalidade X?"), a resposta precisa ser reconstruída de memória.

O resultado são mais reuniões para reestabelecer o alinhamento que foi alcançado na reunião anterior. A carga de reuniões cresce não porque a equipe não está se comunicando, mas porque a comunicação não está persistindo.

Contexto compartilhado como a correção estrutural

A correção estrutural consiste em tornar o conhecimento de cada equipe acessível à outra, pesquisável e atualizado, sem a necessidade de reuniões para preencher essa lacuna.

Contexto de produto para engenharia. Quando o PRD, as pesquisas com usuários e a justificativa do roadmap são pesquisáveis junto com os registros de decisão e a documentação do sistema da engenharia, os engenheiros conseguem entender o "porquê" por trás do que estão construindo, sem precisar esperar que um gerente de produto explique isso em uma reunião.

Contexto de engenharia para produto. Quando as restrições de arquitetura, os registros de decisões técnicas e a documentação do sistema são pesquisáveis pelos gerentes de produto, os PMs podem avaliar a viabilidade e o escopo antes de levar as demandas para a engenharia, o que significa menos reuniões de "conseguimos construir isso?" e mais propostas do tipo "aqui está o que queremos construir, com base no que sei sobre as restrições".

Histórico de decisões compartilhado. Quando as decisões de produto e de engenharia estão na mesma base de conhecimento pesquisável, qualquer pessoa pode rastrear o raciocínio desde a necessidade do usuário, passando pela decisão de produto, até a implementação técnica. A cadeia de raciocínio fica visível em vez de trancada em silos de equipes separados.

Documentações autoescrituráveis geradas a partir dos canais do Slack, reuniões e atividades do GitHub de ambas as equipes criam esse contexto compartilhado de forma automática. As discussões de produto sobre as necessidades dos usuários e as discussões de engenharia sobre restrições técnicas fluem para a mesma camada de conhecimento pesquisável, visível para ambas as equipes.

O que muda na prática

O planejamento da sprint torna-se mais rápido. Quando a engenharia já leu o contexto do produto e o produto já leu as restrições técnicas, a reunião começa a partir de um entendimento compartilhado, em vez de gastar os primeiros trinta minutos para estabelecê-lo.

Dúvidas no meio da sprint são respondidas sem reuniões. Um engenheiro que se pergunta "por que este requisito está estruturado desta forma?" pesquisa na base de conhecimento do produto e encontra a pesquisa de usuário ou a discussão com stakeholders que explica isso. O PM que se pergunta "seria viável adicionar isso?" pesquisa nos documentos de engenharia e encontra o contexto de arquitetura que responde à pergunta.

Novos membros da equipe adquirem contexto mais rápido. Um gerente de produto que entra na equipe lê o histórico de decisões de engenharia. Um engenheiro que entra lê a justificativa do produto. Ambos tornam-se produtivos mais cedo porque o contexto está documentado e acessível, em vez de guardado na cabeça dos colegas.

Perguntas frequentes

Nós já usamos o Jira/Linear para alinhamento. Como isso é diferente? Ferramentas de gestão de projetos acompanham o que está sendo construído e quando. Elas não capturam por que está sendo construído daquela forma, qual necessidade do usuário atende, quais alternativas foram consideradas ou quais restrições técnicas moldaram a abordagem. A base de conhecimento fornece o contexto que as ferramentas de gestão de projetos pressupõem, mas não contêm.

Isso não vai apenas transferir o problema das reuniões para os documentos? Apenas se os documentos exigirem criação e manutenção manuais, e é por isso que os documentos autoescrituráveis importam. A documentação é gerada a partir da atividade existente, em vez de ser criada como uma tarefa separada. A equipe trabalha da mesma forma de sempre. O contexto persiste automaticamente.

E quanto ao aspecto de relacionamento do trabalho multifuncional? O contexto compartilhado cuida da transferência de conhecimento que atualmente acontece em reuniões. A construção de relacionamentos, a colaboração criativa e a resolução de conflitos, que também acontecem em reuniões multifuncionais, devem continuar de forma síncrona. Reduzir as reuniões informativas libera tempo para as reuniões de relacionamento.

Leituras recomendadas: Como reduzir reuniões, Como construir uma base de conhecimento de produto, A taxa de coordenação. Páginas relacionadas: Documentos autoescrituráveis, Para gerentes de produto, Para equipes de engenharia.