Imaginemos que você precisa cumprir a ousada tarefa de dar banho em um elefante, porém, todos os itens necessários para essa tarefa estão em uma cabana há 5 quilômetros de distância. Você terá que entrar em um veículo, separar os itens necessários e levá-los até o local da tarefa. Se você, por acaso, esquecer algum item, terá que retornar, duplicando o seu tempo inicial. Após finalmente lavar o elefante (que não é uma tarefa fácil dado o tamanho do animal), você precisará levar de volta todos os itens que utilizou. Essas idas e vindas e possíveis percalços farão aumentar a complexidade da tarefa que já não é fácil, você demoraria, basicamente, um dia inteiro para cumprir seus afazeres e a menor falha custaria muito tempo.

Bom, de certo que a sua experiência como lavador de elefantes está ruim. Eis que um belo dia, alguém decide construir uma cabana próximo de onde fica o elefante, e mover para lá todos os itens necessários para o banho. A partir desse momento a sua vida mudou! Tudo agora está à mão e a tarefa flui facilmente, o seu esforço cognitivo é diminuído drasticamente e você pode focar muito mais na tarefa em si, que é o banho. Devido a isso, você desenvolve novas técnicas de banhar elefantes, tornando-se cada vez melhor nisso. O custo geral também diminui para você, já que um veículo para ir e voltar com itens de banho já não é mais necessário. Com o tempo extra você passou a manter um controle dos itens mais utilizados no banho e agora os compra em grandes quantidades, otimizando ainda mais os custos. O que antes levava um dia inteiro, de forma morosa e custosa, agora leva menos da metade do dia e ocorre de maneira fluida e mais especializada.

Se você substituir esse elefante por um sistema complexo, e o banho pela tarefa de desenvolver e manter sistema, você terá visualizado exatamente a importância de uma boa Developer Experience: ou seja, como a organização externa, processos, ferramentas e todo o entorno está influenciando - positivamente ou negativamente - na concepção técnica do seu produto e, consequentemente, nos seus resultados. Vamos analisar, então, os pormenores de tudo isso.

A Developer Experience é uma camada de análise que visa prover o melhor ambiente, condições e ferramentas para que pessoas desenvolvedoras tenham uma experiência fluida, natural e sem grandes esforços no processo de concepção, manutenção, depuração e integração de softwares, alcançando assim melhores resultados em menos tempo. A DevEx (por vezes também escrita como DX) abarcará tudo o que influencia no fluxo prático do desenvolvimento, e como isso está ajudando ou dificultando as metas da empresa ou dos integradores de um determinado produto. A DX pode aparecer em alguns diferentes contextos, sendo os mais comuns:

O contexto interno da empresa. Basicamente, as pessoas desenvolvedoras que são colaboradoras ou prestadoras de serviço estão experienciando o dia a dia de trabalho, e como essa experiência está afetando a esteira do produto e, consequentemente, as metas e resultados.

O contexto externo da empresa. Esse é o caso das empresas que fornecem produtos para outros desenvolvedores como: ferramentas, integrações, pacotes open source e serviços em geral. A DX aqui está ligada a como a pessoa desenvolvedora, enquanto consumidora, se relaciona com o seu produto. Essa DX também afeta as metas e resultados, uma vez que mais pessoas integradoras utilizando seu produto de maneira mais fácil se converte em fatores de sucesso para o seu negócio.

É importante ter em mente que uma boa Developer Experience é construída por todos os agentes do seu fluxo de desenvolvimento e pode representar uma mudança lenta e gradual de pensamento e cultura de uma empresa. Não há uma resposta exata para como ter uma boa DX, isso porque cada produto é um produto e cada contexto é um contexto. Porém, existem alguns pontos específicos que você pode averiguar a fim de de definir alguns start points:

Processos: verifique se as fases, processos e priorizações do seu setor de desenvolvimento estão bem definidas, fazem sentido e são bem compreendidas por todos no time

Documentação: Verifique se as demandas geradas pelos desenvolvedores estão bem documentadas e se essa documentação é de fácil acesso. Esse ponto é especialmente importante caso você esteja servindo produtos de integração para a comunidade, softwares open source, APIs públicas e afins: é preciso que os utilizadores de seus produtos e integrações tenham uma ótima documentação à mão.

Comunicação: Verifique se a comunicação é fácil e fluída nos times de desenvolvimento e também entre outros times. Em caso de Outer Source, verifica se é fácil reportar um problema, tirar dúvidas ou se aproximar do seu produto. A nível de time: tenha certeza que suas metas foram muito bem definidas, e que elas estão muito bem comunicadas e refletidas em seu processo organizacional.

Cultura: Verifique se a cultura do seu time e da empresa em si comporta um grau de conforto e tranquilidade necessários para um bom trabalho. Se não há nenhum tipo de hostilidade, competições desnecessárias, fricções sociais, incertezas desnecessárias, etc.

Autonomia: Certifique-se que cada agente tenha o máximo de autonomia sobre o seu fluxo de trabalho. Ex: desenvolvedores devem ter acesso a ferramentas adequadas, base de código, acessos privilegiados, bom hardware para trabalhar e afins. Gerenciar ferramentas e infra-estrutura também não deve ser um problema a nível técnico. Forneça autonomia.

Escute o seu time: Faça reuniões constantes para medir a temperatura do time. Verifique as dores e extraia oportunidades do que for falado.

Uma boa DX se converte em benefícios para toda a empresa, sendo alguns deles:

1. Bom ambiente e rotina previsível: Uma rotina melhor para as pessoas desenvolvedoras gera um esforço cognitivo mais leve e um ambiente psicologicamente saudável, o que se converte em melhor performance. Você pode descobrir mais detalhes sobre isso nesse post: How psychological safety affects employee productivity

2. Economia de Tempo: Em um ambiente amigável e adequado, tarefas e demandas fluirão numa esteira muito mais ágil, fricções como configurações morosas e confusas de ambiente, pequenas descobertas constantes que travam as tarefas, ambientes incertos, falta de documentação constante, comunicação incerta e morosa etc. contribuem fortemente para um fluxo mais lento e frágil, transformando tarefas simples em demandas cansativas e complexas, o que se converte em perda de tempo. Uma boa DX ajuda a diminuir drasticamente esse problema.

3. Otimização de Custos: Uma boa DX também ajuda a otimizar custos, cada pessoa desenvolvedora terá suas horas melhor aproveitadas, e isso também se reflete em todas as outras cadeiras do time, fora otimizações em infra estrutura, menos retrabalho e menos horas de planejamento incerto. Uma DX ruim leva geralmente a: mais horas de depuração, mais pessoas desenvolvedoras envolvidas num mesmo problema, mais horas aplicadas na depuração e desenvolvimento de soluções incertas, mais reuniões, desperdício de recursos, infra estrutura inadequada, bugs frequentes, etc. Isso tudo se converte em custo.

4. Mais Inovação: Uma boa experiência o custo cognitivo de problemas triviais em níveis mais baixos, possibilitando a pessoa desenvolvedora a também explorar as melhores maneiras de executar suas tarefas, gerando melhor performance e por vezes: inovação. Uma experiência de desenvolvimento ruim faz com que parte do esforço cognitivo seja aplicado em manter o que já existe e não quebrar nada enquanto mudanças são aplicadas no software.

5. Multiplicação: Todos os pontos acima tornam o produto mais previsível e compreensível, fazendo com que a troca de informações de dev para dev ou de um time para time seja muito mais rápida e clara, ajudando na multiplicação do conhecimento a respeito do produto.

Todos esses pontos se convertem em um produto mais saudável, o que se converte em uma cultura mais saudável, em custos menores e um ambiente de trabalho mais leve e assertivo.

• Change Failure Rate (CFR): Quantos incidentes críticos afetaram seus deploys? Roll backs, bugs críticos, problemas de infraestrutura, erros de release, etc. Passe a observar esse número por alguns meses, defina um valor aceitável e trabalhe sua DX para diminuí-lo sempre.

• Change Scope Rate (CSR): Quantas vezes os planos ou definições de uma tarefa mudam no meio do caminho? Isso geralmente gera retrabalho, perda de tempo e uma DX ruim. O ideal é que esse número esteja abaixo de um quarto do número total de iniciativas.

• Time to Start (TS): Uma vez que uma nova demanda é definida conceitualmente, quanto tempo ela demora para sair do planejamento e entrar para a esteira de desenvolvimento? Essa métrica pode ser cruzada com a CFR para insights interessantes, ex: Se sua TS está baixa (rápida) mas a CFR está alta, pode indicar fraqueza nas definições, seu time pode estar recebendo pouco contexto sobre as demandas.

• Mean Time To Recovery (MTTR): Em quanto tempo uma falha demora para ser recuperada? Veja que aqui não é o tempo para arrumar o problema, mas para remover o sintoma do fluxo de produção. O ideal é que uma falha possa ser estancada em horas ou menos.

Atingir metas de forma assertiva e rápida é um fator importante e, por vezes, decisivo no desenvolvimento e mantenimento de produtos inovadores. Um dos pilares para possibilitar isso é que a experiência da pessoa desenvolvedora ao lidar com a cultura interna, ferramentas, análise e comunicação, esteja clara e fluida. Isso se converterá em beneficios em todas as cadeiras: desde a técnica, até a gestão, até o usuário final, convertendo-se em boa reputação para o produto, otimização de custos e um bom ambiente de trabalho.

Quanto à indagação inicial, a do título do post, podemos dizer: Developer Experience está ligada à maneira com que todos os aspectos em torno do processo de desenvolvimento de um produto afetam os resultados, e em como otimizar esses aspectos para se ter bons resultados. E esse é per-si um ótimo motivo para se preocupar com a DX na sua empresa: obter bons resultados.