Blog
O custo do desalinhamento entre equipes

O desalinhamento interfuncional é um dos custos mais caros e menos medidos em uma empresa em crescimento. Ele se manifesta como retrabalho (a engenharia reconstrói uma funcionalidade porque a especificação mudou em uma reunião em que eles não estavam), negócios perdidos (a equipe de vendas descobre no meio da apresentação que a funcionalidade que estavam vendendo foi descontinuada) e insatisfação do cliente (foi prometido algo ao cliente que não existe ou que existe de forma diferente da que foi descrita).
Cada desalinhamento individual parece uma falha de comunicação: alguém não contou a outra pessoa algo que ela precisava saber. No conjunto, o padrão revela um problema estrutural: o conhecimento que cada equipe precisa das outras equipes não está acessível sem comunicação síncrona, e a comunicação síncrona não consegue acompanhar o ritmo das mudanças.
Os três desalinhamentos comuns
A equipe de vendas promete o que a de produto ainda não construiu. Um vendedor, trabalhando com materiais desatualizados ou com base em seu próprio entendimento do cronograma, diz a um cliente em potencial que uma funcionalidade existe ou estará disponível em breve. O cliente em potencial compra (ou o negócio é fechado) com base nessa promessa. Quando o cliente descobre que a funcionalidade não existe ou não está no cronograma de curto prazo, a confiança se desgasta e a conta fica em risco.
Causa raiz: a equipe de vendas não tem visibilidade atualizada do cronograma do produto, do status das funcionalidades ou do que foi descontinuado. As informações existem nas ferramentas da equipe de produto (Linear, Slack, discussões de reuniões), mas não são pesquisáveis pela equipe de vendas.
A equipe de produto constrói o que a de vendas não consegue vender. Uma funcionalidade é projetada e construída com base em pesquisas de usuários e raciocínio estratégico dos quais a equipe de vendas não participou e não compreende. A funcionalidade é lançada. A equipe de vendas não sabe como posicioná-la, não tem os argumentos de venda e não consegue articular o valor para os clientes em potencial. A funcionalidade fica sem uso, apesar de ter sido bem construída e bem pesquisada.
Causa raiz: a justificativa do produto (necessidade do usuário, raciocínio estratégico, posicionamento competitivo) vive na documentação e nas discussões de produto, e a equipe de vendas não tem acesso ou visibilidade a esse contexto. O conteúdo de marketing sobre a funcionalidade ou ainda não existe ou não pode ser encontrado.
A engenharia entrega algo que não corresponde à especificação. A especificação foi atualizada em uma reunião em que o engenheiro líder não compareceu. O escopo mudou em uma conversa do Slack que a equipe não viu. Os critérios de aceitação foram refinados em uma conversa entre o gerente de produto e um stakeholder que não foi documentada. A engenharia desenvolve de acordo com a especificação original e o resultado não corresponde ao que o produto agora espera.
Causa raiz: as mudanças nas especificações e atualizações de decisões não são registradas de forma visível para todos os afetados. A mudança ocorreu, mas a comunicação dessa mudança foi informal e incompleta.
A correção estrutural
Todos os três desalinhamentos têm a mesma causa raiz: o conhecimento que uma equipe cria ou atualiza não é visível para as equipes que precisam dele. A correção é uma camada de conhecimento compartilhado onde o contexto de cada equipe é pesquisável pelas outras.
Ferramentas conectadas trazem discussões de produto, documentação de engenharia, inteligência de vendas e conteúdo de marketing para uma camada pesquisável única. A equipe de vendas pode pesquisar o histórico de decisões do produto. A equipe de produto pode pesquisar a inteligência de campo das vendas. A engenharia pode pesquisar a especificação mais recente. Cada equipe acessa o conhecimento das outras sem navegar por ferramentas desconhecidas ou esperar por uma reunião.
Documentação autoescriturável garante que as mudanças sejam registradas conforme acontecem. Quando uma especificação muda em uma discussão no Slack ou em uma reunião, a documentação é atualizada. A mudança fica visível para qualquer pessoa que pesquise o tópico relevante, independentemente de ter participado da reunião ou visto a conversa no Slack.
As reuniões interfuncionais que existem atualmente para preencher essas lacunas de conhecimento não desaparecem totalmente, mas a parte informativa (atualizar todos sobre as mudanças) diminui drasticamente porque as mudanças já estão visíveis na camada de conhecimento compartilhado. As reuniões restantes podem focar no trabalho interativo que realmente importa: colaboração criativa, decisões complexas e construção de relacionamentos.
Perguntas frequentes
Como medimos o custo do desalinhamento? Monitore o retrabalho (funcionalidades reconstruídas devido a falhas de comunicação), compromissos não cumpridos (negócios afetados por informações incorretas sobre funcionalidades) e o custo de coordenação (reuniões que existem principalmente para compartilhar informações entre equipes). A maioria das empresas descobre que o total é surpreendentemente grande quando começa a medir.
Devemos criar uma equipe interfuncional para resolver isso? Equipes interfuncionais ajudam em projetos específicos, mas não resolvem o problema contínuo de compartilhamento de conhecimento entre equipes. A correção estrutural (conhecimento conectado e pesquisável entre equipes) funciona continuamente, em vez de se limitar aos projetos nos quais as equipes interfuncionais são formadas.
E se as equipes resistirem a compartilhar seu conhecimento? A resistência geralmente é ao esforço de compartilhar, não ao princípio. Quando o conhecimento flui para a camada compartilhada automaticamente a partir das ferramentas e canais existentes, a resistência desaparece porque nenhum trabalho extra é necessário.
Leitura relacionada: Mantendo engenharia e produto alinhados, A equipe de vendas não consegue encontrar o que o marketing produz, A taxa de coordenação, Como derrubar silos de informação. Páginas relacionadas: Busca única, Documentos autoescrituráveis, Conexões.
Outros posts do blog:

The Creative's Cold Start Problem

How to Stop Losing Momentum Between Study Sessions

Your Future Self Can't Read Your Mind

The Hemingway Bridge: Stop Working So You Can Start Again

Your ERP Has the Answers. Nobody Can Find Them.

The Usability Layer Your Business Systems Are Missing

Notas Feitas à Mão vs. Digitais: Você Não Deveria Ter que Escolher

Por que suas anotações manuscritas não podem ser pesquisadas (e o que fazer a respeito)