Comparação entre frameworks de medição de produtividade de pessoas desenvolvedoras
Olá!
O artigo de hoje tem como objetivo analisar diferentes métodos de mensuração de produtividade para pessoas desenvolvedoras, comparando abordagens que encontrei ao longo do tempo.
DORA Metrics
Antes de falar de métricas, precisamos definir alguns termos comuns. A definição de produtividade que irei utilizar está neste artigo anterior. Vou reutilizar a mesma definição, porém, para que você não tenha que ler o outro texto, aqui está a fórmula resumida:
Produtividade = Desempenho / Empenho.
Aqui começa o primeiro desafio: o que medir dentre as várias variáveis possíveis no processo de desenvolvimento de software para melhorar o desempenho reduzindo o empenho?
Somente em 2018 surgiu uma abordagem relativamente consensual na indústria de software para medir algo semelhante à produtividade. Embora houvesse pesquisas sobre o tema por décadas, o conhecimento ainda era compartilhado empiricamente (por meio de perspectivas que já abordei anteriormente, como a Lei de Brooks e as Leis de Lehman, por exemplo).
Na minha opinião, no livro Acelerate, as coisas mudaram um pouco. Nesse livro, houve uma comparação dos métodos de trabalho de diversas empresas e seu impacto na produtividade resultante. Esse estudo ficou conhecido como DevOps Research and Assessment (DORA). A principal métrica usada como indicador de produtividade foi a quantidade de implantações realizadas, gerando as seguintes categorizações:
Em outras palavras, quanto mais implantações por dia, melhor. A partir desse estudo, quatro métricas foram popularizadas (conhecidas como DORA Metrics) e são agora utilizadas em qualquer material sério sobre DevOps:
Deployment Frequency: frequência de implantação do código em produção. Equipes de alto desempenho tendem a realizar implantações com maior frequência.
Lead Time for Changes: tempo necessário para ir de um commit de código para a implantação em produção. Tempos curtos frequentemente indicam processos eficientes de desenvolvimento e implantação.
Mean Time to Recover (MTTR): tempo médio necessário para se recuperar de uma falha ou incidente na produção. Um MTTR baixo indica uma resposta eficaz a incidentes.
Change Failure Rate: percentual de mudanças que resultam em falhas ou requerem reversão. Taxas mais baixas sugerem implantações mais estáveis.
Atualmente, a equipe do Google Cloud realiza essa pesquisa anualmente, mantendo a ideia ativa. Abaixo, você pode ver a distribuição dos resultados desde o início do estudo:
O estudo de 2023 será publicado aqui em um futuro próximo caso você tenha curiosidade.
Se você ainda não está realizando medições em seu ambiente de trabalho, pode começar com esse método sem preocupações. Lembre-se de que o objetivo não é apenas descobrir o nível de desempenho e parar por aí; as métricas servem como meio para melhorar o processo como um todo. Muitas empresas descobrem seu nível atual e não tomam mais medidas, o que é um equívoco.
Quanto à validade em si, as métricas fazem sentido, mas não abrangem todos os aspectos da produtividade. Muitos aspectos ficam de fora, como a satisfação dos desenvolvedores e indicadores relacionados. Os próprios autores do estudo original mencionaram em algumas entrevistas que essas métricas são incompletas e podem ser expandidas. Isso levou à criação do SPACE.
As 5 dimensões do SPACE
Para uma análise mais aprofundada desse framework, resumirei as premissas do artigo que o sistematizou. A ideia principal é que avaliar a produtividade vai além de medir uma única dimensão, havendo diversos mitos associados. Abaixo, discutirei brevemente alguns deles:
Mito: produtividade é apenas sobre a atividade do desenvolvedor
Grandes volumes de trabalho podem resultar de diferentes fatores, como excesso de horas devido a sistemas ineficientes ou planejamento inadequado. Métricas de atividade, por si só, não podem recompensar ou penalizar, pois carecem de contexto. Métricas simples como commits ou revisões de código também podem conter erros e não consideram atividades como pair programming. Além disso, horas extras devido a prazos apertados por falta de planejamento ou cultura prejudicial comprometem a avaliação da produtividade.
Mito: produtividade é apenas sobre o desempenho individual
Focar excessivamente na produtividade pessoal pode prejudicar o coletivo, promovendo culturas heroicas. A grosso modo, em tais empresas, 20% dos indivíduos realizam 80% do trabalho, o que é prejudicial e deve ser combatido, não incentivado por métricas individuais.
Mito: uma métrica única de produtividade pode nos dizer tudo
É um equívoco pensar que uma única métrica universal pode avaliar equipes em toda a organização ou indústria. A produtividade abrange diversas dimensões importantes e é fortemente influenciada pelo contexto. Comparar startups com bancos, por exemplo, é inadequado.
Mito: medidas de produtividade são úteis apenas para gerentes
Muitos desenvolvedores acreditam que métricas de produtividade são inúteis, devido ao uso inadequado por líderes. Entretanto, essas métricas também beneficiam os próprios desenvolvedores, auxiliando na organização e compreensão das prioridades. Estudos indicam que alta produtividade está relacionada com maior satisfação e felicidade no trabalho.
Mito: produtividade se trata apenas de sistemas e ferramentas
Ferramentas não capturam atividades invisíveis como mentorias e compartilhamento de conhecimento, essenciais para a produtividade. Essas atividades “invisíveis” são tão cruciais quanto as medidas mais comuns.
O framework propõe cinco dimensões para medição, evitando problemas e mitos comuns. São elas (o acrônimo faz sentido em inglês e português, no caso):
(S)atisfação e bem-estar
(P)erformance
(A)tividade
(C)omunicação e colaboração
(E)ficiência e fluxo
Em relação às métricas sugeridas, temos categorias por dimensão, a nível individual, de equipe e sistêmico:
A primeira vez que vi esse material, achei exagerado. Imaginar coletar tantas métricas diferentes para um desenvolvedor médio é uma tarefa infrutífera. Isso exigiria uma equipe exclusiva para manter as métricas atualizadas, considerando as variadas ferramentas utilizadas. Algumas métricas também são difíceis de mensurar, como handoffs e transferência de conhecimento.
Devido ao esforço necessário, os autores recomendam medir cerca de três dimensões. Eu encontrei uma adaptação que utiliza apenas quatro, como o PACE (o motivo é que as dimensões selecionadas são mais facilmente automatizáveis). Ao adotar esses métodos, lembre-se de que as métricas moldam comportamentos; portanto, seja cuidadoso com os incentivos que deseja criar.
Ao mensurar a atividade, evite promover a valorização da ocupação em detrimento da qualidade. Focar apenas na colaboração pode resultar em muita discussão e pouca entrega. Portanto, a recomendação é evitar métricas isoladas.
Se uma única métrica é insuficiente e usar todas é complexo, existe uma solução?
Um material interessante que analisei relacionado a esse problema foi esse aqui, no qual há uma análise em perspectiva do DORA e do SPACE, além de mencionar que há muitas limitações no formato de pesquisas em surveys e os próprios autores admitem que o SPACE talvez seja complexo demais.
Porém, gostaria de reforçar 3 recomendações que achei utéis sobre surveys (mais adiante eu explico o motivo):
- Os itens do questionário precisam ser formulados com cuidado e cada pergunta deve abordar apenas um aspecto.
- Se você deseja comparar resultados entre questionários, não altere nenhuma palavra, pois impacta os resultados.
- Caso você altere qualquer palavra, será necessário realizar testes estatísticos rigorosos para conseguir tem uma base de comparação coerente.
Eu não sei você, mas eu não sei fazer testes estátisticos rigorosos. Portanto, eu não alteraria o questionário para facilitar a minha vida em uma atividade dessa natureza :)
DevEX
Com base nas limitações do SPACE e do DORA, os mesmos autores introduziram o DevEx (abreviação de Developer Experience). Seu propósito é estabelecer um método que se concentra na satisfação dos desenvolvedores em relação ao seu trabalho. O DevEx sugere três dimensões centrais a serem avaliadas:
Ciclos de feedback: visam minimizar os atrasos na entrega de software e aprimorar os tempos de resposta. Essencialmente, isso equivale ao conceito do DORA.
Carga cognitiva: aborda a redução do processamento mental necessário para as tarefas. Possivelmente, há influência das ideias do Team Topologies.
Estado de fluxo: refere-se ao nível de foco imersivo e engajamento no trabalho, correspondendo ao princípio do SPACE.
Resumindo, a essência do DevEx é a seguinte:
O artigo enfatiza a importância de avaliar tanto as percepções dos desenvolvedores quanto os dados objetivos do processo de desenvolvimento para obter uma visão holística. Além disso, recomenda uma elaboração criteriosa das pesquisas para capturar as atitudes e experiências dos desenvolvedores (é aqui onde as 3 sugestões sobre surveys entram em jogo) e advoga pela análise segmentada dos resultados por equipes e personas. A realização de benchmarks e a coleta de dados de ferramentas também podem ser empregadas.
Exemplificando as métricas adotadas pelo DevEx, estão as três dimensões previamente mencionadas, divididas entre percepções, fluxos de trabalho e KPIs. Diversas métricas do método podem ser avaliadas por meio de pesquisas com tamanho apropriado e pela utilização de medidas obtidas de ferramentas já empregadas pela equipe.
A meu ver, o DevEx é mais eficaz que os outros métodos, principalmente devido à sua simplicidade geral. Ressalto que nenhuma das métricas deve ser aplicada sem a correspondente definição de KPIs que orientem os objetivos a serem alcançados.
Minha recomendação é a seguinte: se você ainda não faz medições, comece pelo DORA. Se almeja progresso, adote o DevEx: estabeleça KPIs, conduza pesquisas e meça periodicamente os indicadores mais relevantes para atingir os KPIs (certifique-se de manter a consistência nas pesquisas entre medições para evitar distorções, usando as recomendações previamente mencionadas). Por último, não considere o SPACE. Na minha opinião, ele é excessivamente complexo e não justifica o investimento de tempo.
Até a próxima!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
