DX Core 4: medindo produtividade de times de software

Adriano Croco
8 min readJan 2, 2025

--

Olá!

No texto de hoje, eu gostaria de explorar um abordagem para medição de produtividade de pessoas desenvolvedoras que me parece bastante promissora e prática.

O que é?

O DX Core 4 (irei me referir a ele como DX de agora em diante) é um framework/método que de medição de produtividade de pessoas desenvolvedoras que é uma expansão dos aprendizados a partir do DORA, SPACE e do DevEx.

Minhas considerações sobre todos esses métodos anteriores estão aqui.

A galera que tá envolvida nesse trabalho se fez a seguinte pergunta:

  • Esses frameworks atuais (principalmente o SPACE), são díficeis de medir, dá para melhorar isso?
  • Como resolver o problema de incentivos perversos?
  • Será que perguntas *qualitativas* são realmente tão ruins assim?

Ou seja, com uma base estatística forte e as perguntas certas, acho que finalmente temos algo prático para medir produtividade.

Mas antes, um disclaimer: o DX é um produto. Devido a isso, existem métricas que eles usam que são pagas. Então, irei deixar isso claro quando for oportuno.

Dimensões

O DX utiliza quatro: Velocidade, Efetividade, Qualidade e Impacto no Negócio.

Se parar para analisar, tudo que importa tá contemplado nessa classificação, ao mesmo tempo que não é verboso sem necessidade (o que é um ótimo sinal).

Os objetivos principais acabam sendo responder as seguintes perguntas:

Como podemos inovar e entregar software mais rapidamente?

Quais são as principais áreas de atrito que estão desacelerando os engenheiros?

O tempo dos desenvolvedores está sendo gasto em atividades que geram mais valor?

No fim, todas as práticas tidas como “modernas”, como Agile, DevEx e outras nem tão novas assim, como o STP, se resumem a isso: como fazer mais rápido com menos esforço? Onde estão os gargalos? Estamos trabalhando no que realmente importa?

São perguntas simples, porém, bastante efetivas.

O que medir?

As métricas granulares são as seguintes:

Vou comentar brevemente sobre elas.

Velocidade: métrica chave (Diffs per Engineer)
O principal erro que outras metodologias cometem é usar essa métrica isolada das outras, gerando incentivos perversos. Portanto, a observação aqui é a seguinte: meça a taxa de PRs por pessoa, considerando a organização como um todo. Ou seja, ponderando o contexto dos times no processo. Essa é uma forma de evitar a criação de um incentivo distorcido.

Diga-me como me medes e eu te direi como me comportarei. (Eliyahu M. Goldratt do livro “A Meta”).

Para medir isso, dá para fazer manualmente, via Actions ou via ferramentas pagas, como o Graphite.

Velocidade: métricas secundárias
Aqui, são as métricas já consolidadas da Agilidade e do DORA, como Lead Time e Deployment Frequency. Para medir isso é fácil, dá para fazer isso no Jira ou fazer cálculos manuais em um Excel.

Um detalhe é relevante sobre a métrica perceived rate of delivery (taxa percebida de entrega). Essa é uma métrica qualitativa que pode ser medida rapidamente com surveys, desde que sejam respeitadas algumas boas práticas de análise estatística. Para mais detalhes, esse artigo aqui do Abi Noda ilustra bem todos os detalhes relacionados.

Mas, só dando um TL;DR rápido sobre métricas qualitivas que acho que vale reforçar: a forma como as perguntas são feitas impactam nos resultados, perguntas com respostas abertas são fontes valiosas de dados, faça segmentação por times/personas, compare os resultados com benchmarks consolidados e não faça pesquisas demais em um curto período de tempo, para que não vire SPAM.

Efetividade: métrica chave (Developer Experience Index)
Essa é uma métrica proprietária do produto. É uma métrica multi-variável que tem algumas promessas relacionadas. Mais detalhes aqui. Mas o resumo é o da imagem abaixo:

Resumo da correlação entre a DXI e o tempo perdido

Ou seja, quanto maior a DXI, menos tempo perdido. O que faz sentido. Eu vi isso acontecer tanto na literatura quanto na minha experiência também. A grosso modo, o que essa métrica diz é o seguinte: uma pessoa desenvolvedora que tem uma boa experiência de desenvolvimento é mais produtiva de uma maneira geral.

Efetividade: métricas secundárias
Nessa dimensão temos dois conceitos interessantes: Tempo para a 10ª PR e Saida Voluntária. O primeiro, basicamente mede quanto tempo leva para alguém se tornar independente. Afinal, na décima PR, você já passou por onboarding e já teve todos os auxílios iniciais. Se essa métrica estiver ruim, significa que você tem um processo que pode ser melhorado, seja em documentação, setup de ambiente, passagem de conhecimento e similares. Se você quiser ouvir o argumento direto da fonte, tá aqui. A Laura Tacho faz parte do grupo que fez o DX.

A segunda mede o turnover voluntário a nível da organização (lembrando que medir no nível individual gera incentivos perversos). Ou seja, quantas pessoas saem por iniciativa própria em pouco tempo (geralmente, entre 3~6 meses). Se você tem muitas pessoas que chegam e não ficam muito tempo, geralmente é indício de um processo de contratação errado, que não trouxe pessoas adequadas para aquela cultura específica. Eu stou assumindo que os problemas de rotatividade relacionados a cultura em questão não sejam relacionados a toxicidade. Para esses casos, não há framework que resolva.

Facilidade de Delivery é uma métrica qualitativa comum que mede a percepção de esforço para se colocar algo em produção. Nesse caso, o conselho é simples: ouça genuinamente o que as pessoas estão tentando dizer, pois é uma métrica de percepção. Sem isso, ela não serve para muita coisa.

Dimensão: Qualidade
Todas as métricas desse quadrante são bastante relacionadas ao DORA, ao meu ver.

Esse é o quadrante mais “tradicional” e conhecido, digamos assim. Todas métricas propostas: taxa de falhas por mudança, MTTR, indicadores advindos de APMs (como uso de CPU, memória e similares) e indicadores de segurança, não devem ser nenhuma novidade para qualquer time de tecnologia minimamente funcional atualmente.

Portanto, a recomendação é simples: continue a olhar para esses dados, pois eles são muito importantes!

Acho essa dimensão um ótimo sinal, inclusive. Qualquer método que prometa ser revolucionário geralmente não o é. Então, soluções que partam de lugares conhecidos e melhorem incrementalmente aquele domínio geralmente são as mais viáveis de se implementar na prática.

Impacto no negócio: métrica chave (% time spent on new capabilities)
Nesse caso, uma simples classificação das tarefas do time já resolve. Ou seja, você precisa medir no que o time está trabalhando no momento e classificar entre bug, dívida técnica ou feature. Isso é o mínimo necessário e não é muito dificil de fazer e medir.

Em um mundo ideal, um time de tecnologia deveria estar trabalhando 100% do tempo em novas features. Portanto, mais do que tentar atingir esse 100% utópico, a pergunta norteadora tem que ser: o que temos de trabalho de manutenção/suporte que pode ser automatizado para que o time consiga focar em novas coisas? Caso não estejamos conseguindo fazer isso, qual o motivo? E por aí vai.

Novamente, nada de muita novidade.

Impacto no negócio: métricas secundárias
Apesar de relativamente óbvias (como medir progresso das iniciativas e ROI), ainda hoje eu vejo boa parte das empresas só medindo progresso e esquecendo de calcular o retorno sobre o investimento dos projetos. Por mim, o argumento do quanto custa vs qual o retorno esperado deveria ser obrigatório em toda decisão de qual projeto executar primeiro.

Além disso, as demais métricas dessa dimensão valem um comentário mais específico.

Receita por engenheiro é algo que é válido e facilmente calculável. Nesse ponto, se você é dev, fique tranquilo. Se o que você faz não estivesse dando no mínimo de 2 a 3 vezes o seu salário de retorno, você provavelmente não estaria empregado. Essa conta eu já fiz inúmeras vezes nos times que liderei. Em alguns casos, a receita por engenheiro chegava a 10x ou até mais.

Por fim, a última métrica (pesquisa e desenvolvimento como % da receita) é algo muito legal na intenção. Afinal, todo mundo tem uma certa noção que são pesquisas em inovação que fazem o negócio evoluir. Porém, boa parte dos executivos não vêem valor nisso ou não sabem como fazer P&D. Ou seja, é uma métrica que você pode até medir, mas, a menos que a empresa seja de tecnologia (já explico porque isso é relevante mais adiante), provavelmente vai ser mais secundária.

Como começar?

As recomendações do time do DX são as mesmas de qualquer iniciativa geral de gestão:

Comece pequeno: evite alterações que afetem todos os times de uma vez e foque em iniciativas de alto impacto com pouco esforço;

Estabeleça linhas de base: meça o que der (mesmo que seja de forma qualitativa), antes de começar as alterações maiores;

Transparência na comunicação: forneça explicações de como as métricas serão coletadas e porque elas são importantes. Lembre-se de explicar porque não serão coletadas métricas individuais para evitar o problema dos incentivos perversos.

Relatórios mínimos e rápidos: é importante que os dados sejam fornecidos para a liderança o mais rápido possível para que possam tomar decisões. Como uma dica minha geral: por favor, não complique mais do que o necessário na visualização dos dados.

Empodere times com alta performance: com acesso aos dados da pesquisa liberados, os times podem melhorar sem tanto input de líderes, por exemplo. Uma outra recomendação é se comparar com o restante da indústria (mais detalhes adiante).

Analise os dados de forma contextual: tenha em mente que apesar de algumas métricas serem organizacionais, é importante levar em consideração particularidades de times específicos (ex: times mobile possuem ritmos de deploy peculiares, por causa das lojas da Apple/Google). Cuidado para não deixar passar esses detalhes importantes ao olhar somente para o todo (mas, continue com o cuidado com incentivos perversos).

Compare usando benchmarks: felizmente, o time do DX disponibiliza um benchmark com as principais métricas geradas por eles. É um excelente ponto de partida. Lembre-se de se comparar com empresas do mesmo segmento/porte/estrutura que a sua. Inclusive, se a sua é uma empresa de tecnologia ou não, essas diferenças aparecem nos dados. Obviamente, empresas de tecnologia possuem métricas de DX melhores que as de outros segmentos.

Caso tenha problemas com o link da planilha, os dados são os seguintes:

Benchmark do DX (2024)

E por fim, stakeholders não técnicos não sabem o que é experiência do desenvolvedor. Devido a isso, muitas vezes eles também não se importam também. Portanto, cuidado redobrado na comunicação. Quanto mais simples for a explanação das métricas, melhor. Fazer paralelos com métricas conhecidas de outras áreas (ex: ROI, taxa de falhas, etc), pode ajudar a angariar aliados.

Caso você consiga implementar essas ideias na sua empresa, poderia me mandar uma mensagem? Eu adoraria conversar mais sobre.

Por fim, como o DX é um produto, você pode ignorar tudo que eu disse e só comprar a solução deles mesmo e jogar dinheiro no problema😆

Espero que o texto seja útil para você de alguma forma.

Até!

Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.

--

--

Adriano Croco
Adriano Croco

No responses yet