Produtividade em Engenharia de Software

Há algum tempo me pergunto se efetivamente seria possível medir produtividade em times de desenvolvimento de software. O tema é complexo, difícil de ser abordado, parece não ter consenso entre os grandes nomes da área e vêm sendo discutido há anos sem grandes resultados. Assim, talvez fosse mais fácil simplesmente ignorar o tema e focar em outros desafios aceitando que não podemos medir produtividade

Entretanto, sou gestor de um lado e engenheiro de outro. O trabalho de um gestor é gerir e gerir sem conseguir compreender/mensurar não funciona. Por sua vez, o trabalho do engenheiro é resolver problemas difíceis. Seria assim que realmente não deveríamos nem tentar mergulhar nesse tema?

Nesse artigo vou discutir um pouco sobre o que tenho lido, estudado e debatido sobre produtividade. Entretanto, não fique frustrado se você não encontrar uma solução ao final dele. Como foi dito, o tema parece não ter consenso. Use os pedaços que aplicarem melhor para você. Conheça o seu time, a sua empresa e o seu momento. Isso é ser gestor.

Histórico

Os mais novos talvez nem se lembrem disso, mas cogitou-se medir produtividade por meio de linhas de códigos. Times que escreviam mais eram mais produtivos que escreviam menos. A ideia atualmente é tão absurda que não vou me aprofundar no debate.

Em um segundo momento surgiu o conceito de pontos de função que tentava olhar menos para a quantidade linhas e mais para a quantidade de funcionalidades implementadas. O conceito parecia melhor, tanto que ainda é aplicado em alguns contratos firmados pela administração pública, mas sinceramente não funciona bem e não mede a entrega de valor ao cliente.

Anos depois, conceitos mais atentos à entrega de valor surgiram e metodologias como o Scrum e do Kanban emergiram trazendo consigo conceitos como velocity e throughput. Ambos conceitos ainda muito adotados, mas que também sofrem por entregar uma visão excessivamente ampla de produtividade. Os dois não servem para fazer comparação e podem ser facilmente manipulados se atrelados aos incentivos errados. Assim, na perspectiva executiva os indicadores são pouco recomendados.

Accelerate

Após compreender um pouco do histórico e dos principais problemas até então, podemos discutir mais sobre uma das poucas literaturas que parece ser consenso sobre o tema, o livro Accelerate e DORA Metrics.

Esse livro é bastante famoso e duvido que se você tenha gastado 10 minutos pesquisando sobre o tema produtividade não tenha se esbarrado com ele. O conceito é simples, interessante e baseado em um longo estudo. Assim, acredito que esse seja um excelente ponto de partida. Basicamente, o livro identifica que times de alta performance apresentam bom desempenho nas 4 métricas abaixo:

• Lead Time (Tempo que um commit gasta para chegar em produção)
• Deploy Frequency (Quantidade de entregas feitas em um período de tempo)
• Change Failure Rate (Relação da quantidade de entregas com sucesso pela quantidade de entrega com erros)
• MTTR (Tempo para restaurar um serviço uma vez que ele apresenta erro)

Será que para conseguirmos medir produtividade deveríamos focar nisso? Seria a DORA Metrics o santo Graal da Produtividade?

Acredito que não… Evidentemente esse indicador é um excelente norteador executivo, recomendo para todos e profissionalmente utilizo ele para compreender se estamos no caminho certo. Entretanto, observo que uma vez que sua empresa atinge um determinado nível de maturidade digital o valor extraído pelo DORA começa a cair.

Ao guiar-se pelas métricas do Accelerate, você irá empurrar sua organização para um bom “Continuous Integration” e “Continuos Delivery” reduzindo o Lead Time e aumentando o Deploy Frequency. Provavelmente em busca de otimizar o MTTR você vai reforçar boas práticas de governança para compreensão de causas raízes de incidentes. Querendo um melhor Change Failure Rate você vai desenvolver boas esteiras de testes automatizados. Behaviour Driven Development, Test Driven Development, Trunk Based Development, … Inúmeras outras práticas corroborarão para você ter boas DORA metrics.

A Simples Pergunta

Tudo que foi citado acima é positivo e realidade na minha empresa atual, mas talvez o simples cenário abaixo, muito comum para gestores, pode mostrar como esses indicadores não resolvem tudo.

A ferramenta X promete organizar nosso fluxo de trabalho e aumentar a produtividade do time. Ela tem o custo de 1 milhão de reais. Alguns desenvolvedores demonstram amplo interesse nela. Você decide rodar uma prova de conceito com ela esse mês para entender o impacto. Como vamos medir o percentual de aumento na produtividade que a ferramenta entregou? O gasto se justifica?

Aqui poderíamos estar falando da adoção de uma ferramenta de comunicação, de um novo JIRA, de uma nova ferramenta de Q&A, de uma nova IDE, …. Esse é um exemplo de questão que o Accelerate tem dificuldade em responder. Teríamos então que recorrer a indicadores com maior granularidade? Como seguir?

Git Analytics

Algumas vezes para responder questões como acima, outras vezes para encontrar gargalos nos times e até mesmo para microgerenciar temos visto uma nova linha de métricas ganhar popularidade e também controvérsia.

Estamos falando das métricas baseadas no uso do Git, a ferramenta mais popular para desenvolvimento de software. Nela extraímos informações sobre cycle, coding, pickup, review e deploy time. Observamos também métricas sobre o tamanho de Pull Request, os principais revisores de código, as quantidade de entregas de cada desenvolvedor e muitas outras.

Basicamente essas métricas são obtidas por ferramentas que fazem introspecção no GIT e procuram entender as conexões, os delays e os gargalos do processo de desenvolvimento de software.

Segue a lista de algumas das ferramentas mais populares que atuam nessa linha.

— Pluralsight, LinearB, JellyFish, AllStack, WayDev

Todas essas dessas ferramentas não abordam somente o conceito de métricas baseada em Git, mas todas elas possuem esse tema em comum.

Aqui destaco que sei que muitas pessoas não gostam de Git Analytics, mas entendo que não podemos culpar o conceito dessa métrica em si. O uso da métrica está atrelado aos gestores ou à cultura de uma empresa. Assim, o seu bom ou mau uso depende disso. Como exemplo, um executivo que compara Velocity entre times tem grande chance de estar cometendo um erro grave, ainda assim Velocity pode ser bastante útil para auxiliar em estimativas ou na avaliação de evolução do seu time.

Outra crítica relevante é que a maioria desses gargalos/conexões que as ferramentas de Git Analytics auxiliam a encontrar, poderiam ser facilmente descobertas em conversas com os times. Por isso, não seria necessário uma ferramenta para isso. Acredito nesse ponto, mas assim como números de scout podem ajudar um técnico esportivo, acredito que os números possam ajudar aqui. Lembrando que nem sempre as estatísticas contam o que realmente foi a partida.

Acho que o mais sensível nessas ferramentas é escolher as métricas analisadas. Em busca de entregar ainda mais valor, algumas das empresas acima prometem inferir métricas como “impacto do time ou da pessoa” o que sou bastante cético, por isso nem vou entrar nesse tópico.

Entendendo que problema não é a métrica em si, falemos um pouco sobre como podemos usá-la para identificar times que precisam de ajuda e se ela poderia nos ajudar com o cenário da compra de ferramentas que falamos anteriormente.

Segue abaixo um exemplo de Benchmark feito com uma empresa do segmento para identificar times de alta performance, assim como a tabela do estudo feito pelos autores do Accelerate com o mesmo propósito.

Identificando times de alta performance olhando para métricas com Git

Identificando times de alta performance olhando para métricas do Accelerate

Ao olharmos ambos os estudos fica evidente que eles possuem bastante sinergia, entretanto o estudo que faz uso Git Analytics é mais específico na etapa de desenvolvimento. Como exemplo, ele detalha as etapas do cycle time permitindo você encontrar gargalos, mesmo em empresas de alta maturidade digital.

Como experiência própria, ao mensurarmos o Review Time médio dos Pull Requests encontramos variações enormes. Descobrimos que isso era um dos principais ofensores em uma das nossas stacks e isso nos permitiu entender as motivações, mudar os processos internos e apoiar os gerentes mais junior na melhora da produtividade desses times. Os ganhos foram significativos. Assim como tivemos ganhos ao usar o DORA metrics do Accelerate, o uso de Git Analytics também entregou valor ao nos permitir entender e eventualmente medirmos a produtividade.

Tudo bem que o Git Analytics trouxe aumento de produtividade para nossos times, mas será que ele responde a pergunta que fizemos lá atrás sobre a compra de uma ferramenta?

Bem, talvez sim, talvez não.

Com esse tipo métrica quantitativa e números bem específicos talvez você consiga chegar no percentual de aumento de produtividade obtido pela contratação do ferramental. Entretanto, para termos certeza precisaríamos aprofundar ainda mais em algum caso concreto.

Agora, como engenheiros, sabemos que é difícil isolar as variáveis e ter certeza da correlação entre o uso da ferramenta e uma eventual melhora em indicadores.

SPACE

Essa dificuldade e um certo ceticismo com as métricas de produtividade atuais fizeram um grupo de pesquisadores trazer uma nova proposta. Uma proposta menos baseada apenas em números. Eles trouxeram algo mais qualitativo, por meio da compreensão que o tema é na verdade um teia/grafo que interconecta várias dimensões.

Assim, o grupo apresentou o SPACE, um framework que busca analisar diferentes dimensões e níveis para entender a produtividade. Segue abaixo uma imagem que ilustra as 5 dimensões e 3 níveis do Framework.

Framework do Space — Dimensões e Níveis — Métricas de Exemplo

Como podemos ver o Framework se baseia em Satisfação/Bem-estar, performance, atividade, comunicação/colaboração e eficiência/fluxo. Assim, o Space prega que nenhuma métrica deve ser observada sobre uma única perceptiva. Os indicadores sempre devem ser compostos por uma combinação de pelo menos três dimensões e precisam ter dados qualitativos (extraídos de pesquisas) e quantitativos (extraídos de ferramentas).

Como exemplo peguemos Code Review e façamos uma análise sobre as diferentes dimensões e níveis:

Satisfação: Podemos observar se o Code Review é enxergado com algo que gera valor e conhecimento para quem oferece/recebe ou como algo negativo que sobrecarrega o desenvolvedor e que raramente faz diferença na entrega.

Performance: Podemos entender o tempo gasto com code review na visão individual.

Atividade: Podemos entender a quantidade de code reviews feitos por pessoa.

Comunicação: Podemos entender se existem silos dentre de sistemas ou times analisando apenas as interações das pessoas dentro dos code reviews.

Eficiência: Podemos entender como interrupções causadas pela espera de um code review impactam o indivíduo ou times.

Acredito que a maioria dos gestores entendam e até achem óbvio em ter essa visão multidimensional das coisas, mas o fato dos autores terem estruturado isso em um framework facilita o debate ao criar uma linguagem única. Seria uma “Ubiquitous Language” do DDD para o mundo da gestão.

De modo geral, o SPACE parece começar a ganhar popularidade. Inclusive algumas empresas estão surgindo prometendo ajudar gestores a implementar o framework, sendo que a GetDX é uma delas.

Volta a Pergunta

Entretanto, será que utilizar esse framework ajudaria você gestor a responder aquela pergunta do começo do artigo sobre a contratação ou não do fornecedor?

A resposta curta seria sim. O SPACE se propõe a olhar produtividade de maneira objetiva e subjetiva. Não só em um olhar macro, mas também em um olhar mais granular. Sendo justo, o framework por si só não irá resolver seu problema, mas poderá guiá-lo na escolha de um conjunto de métricas de produtividade que responderia a pergunta se o gasto com a ferramenta se justificaria.

Produtividade na Prática

Até então, vimos diferentes indicadores, estudos ou frameworks que se apresentam como alternativa para compreender a produtividades de time de engenharia de software. Agora vamos transformar aquela pergunta abstrata sobre a contratação de uma ferramenta de produtividade em algum exemplo concreto e depois vamos para alguns cenários que enfrentamos como gestores para compreender como podemos aplicar tais conceitos e responder algumas das nossas dúvidas sobre produtividade.

Prática 1:

A contratação de uma ferramenta de Q&A

Em busca de melhorar a produtividade seu time de engenharia sugere a contratação de uma ferramenta de Q&A. Surgi, então, a questão: “Como vamos medir o aumento produtividade?”

Explorando mais o tema com o time chegamos a conclusão que os novatos e os especialistas seriam os dois grandes grupos beneficiados. Os primeiros porque apresentam muitas dúvidas durante o onboarding e os segundos porque acabam respondendo a mesma coisa inúmeras vezes. Assim, baseado na compreensão que tivemos do tema produtividade optamos pelas seguintes métricas.

• Tempo médio para entregar 10 PR’s (Atividade — Individual — Quant.)
• Survey Percepção de Produtividade (Eficiência — Individual — Qualitativo)
• # de Usuários ativos no Fórum (Colaboração — Time — Quantitativo)

Nesse caso, a diminuição do tempo médio de entrega dos Pull Requests nos ajuda a quantificar um eventual aumento de produtividade, enquanto as métricas de outras dimensões nos ajudam o cenário como um todo. Finalmente a separação em dois grupos de controle (ativo e não ativos) facilita algumas análises estatísticas.

Prática 2

Tech Managers avaliando a evolução do seu time ao longo de um ciclo

Para Tech managers de um único time procurando compreender como a produtividade do seu time tem evoluído ao longo de sua gestão, poderíamos trabalhar com outro conjuntos de métricas.

• Lead Time e Cycle Time (Atividade — Time — Quant.)
• Pesquisa de Satisfação do time (Bem Estar — Time — Qualitativa)
• Pesquisa sobre Quantidade de Interrupções (Eficiência — Indiv — Quant)

Nesse caso, uma possibilidade foi compreender uma visão do time mais também individual em várias dimensões. Permitindo ao Tech manager observar o mais importante que seria evolução do time, mas com insumos sobre a individualidade.

Prática 3

Executivo avaliando a produtividade de sua tribo

Para um executivo na liderança de uma tribo procurando compreender a produtividade de seus times, ele poderia explorar métricas como a seguir:

• DORA Metrics (Atividade /Perfomance — Sistema — Quant.)
• Alocação em Bugs x Features x Manutenção (Eficiência — Time — Quant.)
• Pesquisa de Satisfação do time + Turnover (Bem Estar — Time — Quali.)
• Entregas no Prazo (Perfomance — Sistema — Quant.)

A DORA métricas darão uma visão mais ampla sobre velocidade de entrega e estabilidade. Enquanto, a alocação dará uma visão sobre eficiência no time. As entregas no prazo ajudaram a gerenciar expectativas e a satisfação qualitativa lhe dará nuanças que possam estar escapando do dia a dia.

Conclusão

Depois de ter feito uma revisão sobre o tema e ter tentado ilustrar alguns casos concretos, precisamos entender que as métricas de produtividade certas a serem usadas contam muito sobre a cultura da empresa e seu estilo de gestão.

Entendo que talvez alguns possam sair frustrados por não terem encontrado uma única métrica para saber a produtividade do teu time. Talvez você gostaria que eu afirmasse que bastaria olhar a evolução do throughput (ágil) ou avaliar o número de Pull Request’s dos times.

Entendo também a frustração daqueles que esperavam por métricas para produtividade individual.

Bem, não foi dessa vez. Infelizmente ou felizmente a gestão é uma questão complexa. Você vai ter que entender o estágio e a cultura da tua empresa. Espero ao menos ter ajudado, mas claro se você discorda ou queira debater mais sobre o tema não deixe de comentar ou me procurar no LinkedIn. Quem sabe faço um outro post para abordar mais do assunto.