A equipe de engenharia do Compass teve um problema. Na teoria, nossos recursos estavam normais, mas faltava algo: amor genuíno pelo cliente. Éramos bons em escrever código, mas estávamos resolvendo os problemas certos?
Como gerente sênior de engenharia na Atlassian, passei anos enfrentando esse desafio ao trabalhar com o Compass. Minha equipe e eu somos responsáveis por criar ferramentas que ajudem as equipes de desenvolvimento a gerenciar componentes e recursos de software em grande escala. Quando me juntei à equipe, notei um padrão que muitas organizações de engenharia enfrentam: somos ótimos em oferecer recursos, mas às vezes erramos na entrega de valor.
Vi em primeira mão como a cultura de engenharia pode causar o sucesso ou a ruína de um produto. Na Atlassian, não só criamos ferramentas para equipes de software, mas vivemos e lidamos com os mesmos desafios que nossos clientes enfrentam todos os dias. Assim, temos uma perspectiva única sobre a transformação da cultura de engenharia, e é por isso que acho tão importante compartilhar o que aprendemos.
A desconexão tradicional da engenharia
Vamos falar sobre uma equipe de produto hipotética cuja história pode parecer familiar.
Tina é uma desenvolvedora sênior conhecida por sua excelência técnica. Embora seu código fosse impecável, ela se viu presa em um ciclo familiar: receber requisitos, escrever código e implantar recursos. "Eu estava escrevendo código sem contexto", Tina admite. "Não tinha ideia se o que eu estava criando resolvia problemas reais dos clientes." Tina queria mais contexto do cliente, mas se sentia limitada por seu foco apenas na implementação.
Rita, designer de produtos da equipe, enfrentou as próprias dificuldades. Ela passava semanas criando designs aperfeiçoados até os mínimos detalhes, apenas para receber um feedback crucial durante o desenvolvimento, o que gerava grandes revisões. "No momento em que os desenvolvedores apontam as restrições técnicas, pode ser tarde demais para manter a visão original do design", ela explica. Rita precisava de uma melhor integração com o processo de desenvolvimento e uma forma de validar os projetos mais cedo.
E Paul, o gerente de produtos, tentava manter tudo sob controle. Ele passava inúmeras horas escrevendo documentos de requisitos detalhados, mas algo sempre era mal interpretado. "É como brincar de telefone sem fio", diz Paul. "Quando os recursos chegam aos clientes, eles já se transformaram em algo diferente do que imaginamos no começo." Ele buscava com urgência uma melhor colaboração entre as equipes de engenharia e design, mas o processo tradicional de transição continuava criando barreiras.
Rick, o gerente de programas, teve talvez o papel mais desafiador de todos. Coordenar as dependências entre várias equipes e, ao mesmo tempo, equilibrar velocidade de entrega com qualidade o mantinha acordado à noite. "Quando as equipes trabalham em silos, alterações simples podem se transformar em semanas de atrasos", comenta Rick. Ele precisava de uma maneira de promover uma melhor colaboração e visibilidade entre equipes.
Na supervisão, estava Anna, a líder de engenharia, que lutava para transformar a forma como suas equipes operavam. Embora valorizasse a excelência técnica, ela sabia que algo estava faltando. "Temos engenheiros muito talentosos, mas não estamos entregando de forma consistente o valor que nossos clientes precisam." Anna queria mudar a cultura da equipe, mas o modelo de desenvolvimento tradicional dificultava o equilíbrio entre excelência técnica e valor para o cliente.
A experiência dessa equipe reflete um padrão mais amplo no desenvolvimento de software. Embora organizada e previsível, a abordagem sequencial tradicional cria desconexões naturais entre as pessoas que criam e as que usam o produto.
Cultura: a chave para a transformação
"A cultura devora a estratégia no café da manhã." Embora essa citação seja atribuída ao guru da administração Peter Drucker, ela ganhou destaque quando Mark Fields a exibiu na sala de conferências da Ford em 2006. Essa mensagem não é apenas uma frase cativante, ela transmite uma verdade fundamental que vemos com constância no setor de tecnologia: até mesmo a estratégia mais brilhante vai falhar se entrar em conflito com a cultura organizacional.
Quando decidimos transformar nossa cultura de engenharia no Compass, descobrimos algo profundo: a excelência técnica por si só não é suficiente. Precisávamos preencher a lacuna entre nossos engenheiros e clientes. Os números confirmam isso: empresas com culturas fortes têm um crescimento de receita quatro vezes maior em comparação com seus concorrentes.
Nossa jornada de transformação no Compass ilustra bem isso. Passamos de um processo tradicional de ciclo de vida de recursos, que podia levar de seis a oito semanas para ser concluído, para um processo de descoberta iterativo que nos aproximou muito mais dos problemas dos clientes. Não foi apenas uma alteração no processo, foi uma mudança fundamental da mentalidade de achar que sabemos tudo para uma mentalidade aberta a aprender, em que cada recurso se tornou uma oportunidade de aprender com nossos clientes.
A evolução da engenharia de produtos
De forma tradicional, a engenharia de software é responsável por transformar requisitos em código funcional por meio de design, desenvolvimento e testes sistemáticos. Os engenheiros se concentram mais na execução técnica: escrever código eficiente, manter sistemas e garantir a qualidade.
Porém, a engenharia de produto representa uma mudança fundamental na forma como pensamos sobre a criação de software. Ela mantém o rigor técnico da engenharia de software, mas adiciona um elemento crucial: profundo entendimento do cliente e aprendizado contínuo. Os engenheiros de produto não apenas escrevem código, eles participam da descoberta e da solução de problemas dos clientes, oferecendo informações técnicas para as decisões de produto e controlando os resultados do trabalho.
O modelo tradicional de engenharia de software
No modelo tradicional, o desenvolvimento segue um caminho linear. Os requisitos fluem do gerenciamento de produto, passando pelo design, até as equipes de engenharia que os implementam. Pense nesse processo como uma corrida de revezamento, em que cada equipe passa o bastão para a próxima.
O antigo fluxo de trabalho da nossa equipe refletia essa abordagem linear:
- Os documentos de requisitos levavam meses para serem criados e aprovados
- Arquitetos e designers trabalhavam de maneira isolada
- Engenheiros codificavam de acordo com especificações exatas
- Os testes e a implantação eram feitos no final
- O feedback de clientes era filtrado em várias camadas
Essa abordagem funcionava bem quando os requisitos eram estáveis e a mudança era cara. Nos mercados em rápida evolução atuais, precisávamos de algo mais adaptável e centrado no cliente.
O ciclo contínuo da engenharia de produto
Nossa transformação se concentrou na substituição desse processo linear por um ciclo de aprendizado contínuo. Em vez de tratar o desenvolvimento como uma corrida de revezamento, agora operamos mais como um time de futebol: todos se movem juntos, se adaptam às alterações nas condições e mantêm o foco no objetivo de entregar valor ao cliente.
Neste novo modelo:
- Os engenheiros participam de entrevistas com clientes e sessões de descoberta
- O desenvolvimento e o design acontecem de forma colaborativa, com prototipagem e testes rápidos
- As decisões técnicas são validadas de acordo com as necessidades do cliente
- A implantação se torna uma oportunidade de aprendizado, não apenas um marco de entrega
- As equipes medem o sucesso com base no impacto no cliente, não apenas por métricas técnicas
Da implementação para o envolvimento
Para engenheiros como Tina, essa transformação resultou na evolução da implementação pura para o verdadeiro envolvimento. Agora, os engenheiros podem:
- Participar da definição do problema e da procura por uma solução
- Inserir perspectivas técnicas em discussões iniciais
- Validar as suposições com os clientes
- Ter resultados de recursos além da qualidade do código
- Acompanhar as métricas de negócios e o impacto no mercado
Os resultados falam por si só: as organizações que adotam esse modelo têm um tempo de comercialização mais rápido e maiores taxas de adoção de recursos do que aquelas que usam abordagens tradicionais de engenharia. Talvez ainda mais importante, vimos um maior engajamento da equipe, melhores decisões técnicas e um alinhamento mais forte entre nossas soluções técnicas e as necessidades dos clientes.
Como conquistamos nossa transformação
Transformar o modo como os engenheiros trabalham exigiu mais do que apenas uma mudança de mentalidade: precisávamos da base certa. Para nossa equipe, a peça crucial dessa base foi o Jira Product Discovery, uma ferramenta que incluiu o contexto do cliente no nosso fluxo de trabalho diário de forma natural.
O primeiro desafio era tornar os insights dos clientes acessíveis a todos. Antes, o feedback dos clientes e os requisitos de produto estavam nos documentos do Confluence, nos tópicos do Slack e nos tickets do Jira. O Jira Product Discovery trouxe todo esse contexto para nosso fluxo de trabalho de desenvolvimento. Agora, os engenheiros podem ver entrevistas com clientes, sessões de feedback e padrões de uso junto ao seu trabalho de desenvolvimento, tornando as necessidades do cliente tangíveis e imediatas, em vez de abstratas e distantes.
Essa acessibilidade mudou de forma radical a forma como nossas equipes colaboravam. Quando uma designer como Rita criava novos designs, ela podia vincular isso de forma direta aos pontos críticos do cliente que os engenheiros conseguiam ver e entender. Quando Paul priorizava os recursos, ele conseguia conectar com facilidade o impacto do cliente à complexidade técnica, levando a decisões mais bem embasadas. Mais importante ainda, nossos engenheiros puderam por fim ter uma visão completa: não apenas o que estávamos construindo, mas por que isso era importante para nossos clientes e como isso afetaria o trabalho deles.
Para as equipes que estão pensando em fazer uma transformação semelhante, é importante lembrar que não se trata de escolher entre excelência técnica e foco no cliente, mas sim uma união dos dois aspectos para criar produtos que os clientes adorem de verdade. Quando os engenheiros entendem tudo sobre as necessidades dos clientes, eles tomam decisões técnicas melhores, projetam soluções mais elegantes e encontram mais significado no trabalho porque podem ver o impacto direto.
Quer saber mais sobre como essa transformação aconteceu? Confira o webinar: A mágica por trás da engenharia de produto: transformando os problemas dos clientes em funções que eles adoram, onde vou me aprofundar na jornada da Atlassian e compartilhar estratégias e práticas que você pode implementar com sua própria equipe.