6 minutos de leitura

O que é experiência do desenvolvedor (DX)?

DX ou DevEx é sobre analisar todos os componentes do ecossistema da pessoa desenvolvedora — do ambiente aos fluxos de trabalho e ferramentas — e busca entender como eles estão contribuindo para a produtividade, a satisfação e o impacto operacional dos desenvolvedores.

Com o DevEx, todos os aspectos da jornada de um desenvolvedor são questionados.

C = Colaboração, o multiplicador em todo o DevEx.

A fórmula DevEx do GitHub leva em consideração:

• Produtividade: com que rapidez e simplicidade uma alteração pode ser feita em uma base de código
• Impacto: quão fácil é passar da ideia à produção
• Satisfação: como o ambiente, os fluxos de trabalho e as ferramentas afetam a felicidade do desenvolvedor

Otimizar o DevEx significa criar um ambiente colaborativo que permita aos desenvolvedores aumentarem sua produtividade, impacto e satisfação.

Impacto na minha experiência como desenvolvedor

Há 18 anos, iniciei minha trajetória como desenvolvedor e, fazendo um recap da minha atuação hoje, tenho consciência de como DX impactou diretamente na minha produtividade:

• Eficiência, tempo de foco:

Trabalhei em empresas onde meu trabalho normal era interrompido regularmente, e me sentia muito improdutivo. Não conseguia entrar no tal do “flow” do desenvolvedor. Basicamente, o time de tech tinha muita cobrança das outras áreas (a pergunta recorrente era “quando isso vai ser entregue”), com pouco tempo de foco, porque grande parte do tempo era desperdiçada com reuniões desnecessárias ou pouco objetivas.

• Produção, monitoramento:

Em outra experiência, tínhamos um produto com muitos usuários em produção. Existia uma cobrança exagerada para ter um tempo de resposta rápido, considerando o MTTR (Mean Time To Recover) do DORA, mas, na prática, por mais que me esforçasse, não conseguia atingir as expectativas.

Quando existia um incidente, não tinha confiança de que conseguiríamos resolvê-lo rapidamente. Não tínhamos um bom sistema de logs e o que tínhamos estava espalhado em múltiplas ferramentas e não nos dizia realmente qual era a causa raiz do problema.

VEJA TAMBÉM: Checklist – sinais de uma squad de alta performance

• Implantações e versionamento:

Esse é outro problema que gerava fricção. A cobertura de testes era algo essencial, mas a eficácia dos mesmos era muito baixa. Basicamente, o time fazia os testes para passarem de qualquer forma e deixar o indicador sempre alto.

Tínhamos também um problema em fazer deploy. Era sempre uma demora excessiva para passar todas as etapas da nossa pipeline (tinha que esperar 20 minutos) em cada deploy. Imagina em um time de quase 100 desenvolvedores, o quanto isso é improdutivo.

• Colaboração e conhecimento:

Nosso time passava pouco tempo aprendendo com nossos erros e falando sobre esses problemas que geravam fricção.

Exemplos:  “Nosso processo de revisão de código nos ajuda a fazer uma release de código melhor?”
ou “Nossa documentação realmente ajuda no onboarding dos novos desenvolvedores?”

• Codebase:

Era muito difícil encontrar a causa raiz dos incidentes porque nossa codebase tinha uma baixa qualidade. Muita coisa precisava ser refatorada, mas tarefas de refatoração nunca eram consideradas prioridade.

• Planejamento do projeto, processos de equipe:

Em outra experiência, o time de tecnologia tinha a fama de “sempre atrasar” porque nunca conseguíamos dar vazão às tarefas planejadas.

O que ninguém via é que as tarefas eram mal escritas, o que nos levava a gastar muito tempo tirando dúvidas e os objetivos nunca eram realmente claros. Não era perceptível que nosso trabalho gerava valor para o negócio.

• Produtividade percebida:

Levantando todos os pontos acima, o que fica claro na minha experiência é que havia muita cobrança sobre “ser produtivo” e pouca reflexão sobre “o quão produtivo eu me sentia” e sobre “o que reduziria o atrito no meu trabalho diário”.

Isso é sobre DX. Antes de olhar apenas para métricas, pergunte para o seu time qual o ponto de vista deles sobre produtividade. Os desenvolvedores não tem motivos para mentir sobre o que vai tornar o dia a dia deles mais produtivo e você pode trabalhar em direção a isso (ao menos reservar um tempo para isso). 

Pesquisas

De acordo com um levantamento de oportunidades da Forrester , as equipes podem reduzir o tempo de lançamento no mercado e aumentar a receita criando uma maneira mais fácil para os desenvolvedores escreverem códigos, criarem software e enviarem atualizações aos clientes. Como resultado da melhoria do DevEx:

• 74% dos entrevistados disseram que podem aumentar a produtividade do desenvolvedor
• 77% podem reduzir o tempo de lançamento no mercado
• 85% podem impactar o crescimento da receita
• 75% conseguem atrair e reter mais clientes
• 82% podem aumentar a satisfação do cliente

Greg Mondello, do GitHub, diz que não é surpresa que a DevEx tenha visto um aumento significativo no investimento nos últimos cinco anos.

“Na maioria dos contextos, a capacidade de desenvolvimento de software é o fator limitante da inovação”, afirma. “Portanto, melhorias na eficácia do desenvolvimento de software são inerentemente valiosas.”

Além disso, o desenvolvimento está cada vez mais complexo. A construção de software hoje envolve muitas ferramentas, tecnologias e serviços de diferentes fornecedores, o que exige que os desenvolvedores gerenciem ambientes muito mais complexos.

Na melhor das hipóteses, um DevEx bem concebido fornece maior consistência entre ambientes, processos e fluxos de trabalho, ao mesmo tempo que automatiza os processos mais tediosos e manuais.

“Isso permite que empresas com melhor DevEx superem seus concorrentes, independentemente da vertical”, diz Mondello.

O que constitui uma boa experiência para o desenvolvedor?

Um bom DevEx é onde os desenvolvedores têm as informações de que precisam e podem alternar entre o foco e a colaboração.

Os desenvolvedores enfrentam muitos tipos de atrito durante seu fluxo de trabalho de ponta a ponta, especialmente se estiverem usando várias ferramentas. De reuniões a solicitações e muitos outros tipos de interrupções, os desenvolvedores muitas vezes precisam reunir o contexto de fontes fragmentadas e desatualizadas, o que prejudica sua capacidade de serem produtivos e escreverem códigos de alta qualidade.

Embora descrever os componentes exatos possa ser complicado, os especialistas concordam que um DevEx forte abrange o seguinte:

• Colaboração
• Velocidade
• Ciclos curtos de feedback
• Altos graus de automação e integração
• Baixos níveis de atrito ou trabalho
• Processos transparentes e bem documentados

Quais são as principais métricas de experiência do desenvolvedor?

Não existem métricas padronizadas do setor para medir o DevEx. No entanto, tem uma correlação direta com DevOps Research and Assessment (DORA), que olha as boas práticas da cultura DevOps.

Dentro do estudo de DORA metrics, você tem as boas práticas de tech capabilities que são preditivas da performance da entrega de software (Lead time for change, Deploy Frequency, Failure Rate e Time to Restore Service).

 

Ao enviar pesquisas com foco em DX, você vai conseguir olhar para dados subjetivos que ajudam a identificar o que vai ser priorizado de Tech Capabilities (preditivo de DORA).

Exemplos: 

“Meu MTTR (Mean Time To Recovery) está baixo. O DX pode nos ajudar com informações como “Os desenvolvedores têm dificuldade de encontrar logs das nossas aplicações. Precisamos priorizar nossa tech capabilities “Monitoring and Observability” . 

“Lead time for change está longo. O DX pode nos ajudar com informações como “A baixa qualidade da codebase aumenta o tempo de desenvolvimento.” Precisamos priorizar nossa tech capabilities “Code maintainability” . 

Conclusão

Escute seus Desenvolvedores: Antes de olhar apenas para métricas, pergunte para o seu time sobre o ponto de vista deles sobre produtividade.

Priorize: Use métricas objetivas, como DORA, para cruzar dados de pesquisa e entender o que deve ser priorizado.

Reduza o Atrito: Identifique e elimine obstáculos que diminuam a produtividade ou satisfação do time.

Quando você cruza dados qualitativos de DX, com métricas quantitativas como DORA, as chances de você identificar as falhas do seu processo são muito maiores, e uma vez identificadas, o DORA Core Model, e a própria pesquisa de DX, te darão o caminho para solucioná-las, com isso seu time estará a um passo da máxima produtividade.