Medindo o desempenho técnico: você provavelmente está fazendo isso errado

Olá, seja bem-vindo ao Road to Excellence (Caminho da excelência). Todos provavelmente estamos envolvidos, tentando o melhor para se tornar performático, medir nosso desempenho e ao longo do caminho, identificando apenas os OKRs e KPIs e ABCs corretos.

Infelizmente, essa tarefa pode ser difícil de fazer, especialmente quando trabalhamos em organizações complexas e muitas vezes herdamos medições dos fantasmas da tecnologia e do gerenciamento passado.

Embora não exista uma métrica verdadeira que importe, existem algumas diretrizes ótimas a serem seguidas e outras com erros comuns e que vejo com frequência. Delineamos as diretrizes para uma boa medição em meu novo livro, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, em coautoria com Jez Humble e Gene Kim. Essas duas regras simples são bastante diretas e ajudam a entender por que os erros que vemos muitas vezes na medição fracassam de forma tão espetacular.

Duas diretrizes simples para métrica de software

1. Utilize medidas com foco em resultados, não na entrega;
2. Utilize medidas que otimizem resultados globais ou da equipe, não de resultados locais ou individuais.

É isso aí. Muitos problemas com métricas e problemas resultantes de incentivos que vêm com a falta de alinhamento normalmente podem ser rastreados e até ter medidas que não seguem essas duas diretrizes simples. Isso ocorre porque as métricas moldam nossos incentivos e demonstram nosso comportamento. Então, precisamos começar com as métricas certas.

Exemplos comuns de péssimas métricas de software

A maioria das tentativas de medir o desempenho em software concentra-se na produtividade e elas geralmente ignoram as duas diretrizes descritas acima. Agora, um olhar no espelho e talvez um pouquinho de aprendizagem com erros alheios, vamos começar com alguns "não" em métricas:

Linhas de código. Em software, estamos medindo a produtividade em termos de linhas de código a muito tempo. Algumas empresas exigem que os desenvolvedores registrassem as linhas de código enviados por semana (existe uma boa história sobre como a equipe do projeto Lisa da Apple descobriu que não tinham sentido utilizar as linhas de código como métrica de produtividade). Mas, honestamente, preferimos 10 linhas para a solução do que 1.000 linhas para um problema. Recompensar os desenvolvedores por escrever código extra resulta em um software inchado que incorre em custos elevados para manutenção e mudança. E o outro extremo? A minimização de linhas de código também não funciona. Realizar uma tarefa em uma única linha de código que ninguém mais pode entender resulta em um código sem possibilidade de manutenção. O ideal seria recompensar os desenvolvedores pela solução de problemas de negócios com a quantidade mínima de código, melhor ainda se pudermos resolver um problema sem escrever código ou excluir o código (talvez por uma mudança no processo de negócios).

Utilizar linhas de código como uma métrica de produtividade viola nossas diretrizes, concentrando-se na produção e não nos resultados. Elas medem apenas o que as pessoas criaram (linhas de código), porque às vezes é fácil medir de forma automatizada, mas geralmente ignoram as métricas do que estão sendo realizado em termos de metas, porque essas são muito mais difíceis de articular e medir. Mas não é isso que realmente importa?

Velocidade. A velocidade é uma métrica que vem do movimento ágil, no qual os problemas de trabalho são divididos em pontos de história e os pontos são atribuídos a uma quantidade de esforço por parte dos desenvolvedores. Quando o trabalho é aceito pelos clientes, os pontos concluídos são a velocidade de uma equipe. No entanto, esta é uma ferramenta de planejamento de capacidade para uma equipe. Existem diversas falhas quando utilizamos velocidade como uma métrica de produtividade. Primeiro, a velocidade é uma medida relativa e dependente da equipe, não absoluta. As equipes geralmente têm contextos significativamente diferentes, o que torna a comparação de velocidades inapropriada. Segundo, quando a velocidade é usada como uma medida de produtividade é muito provável que as equipes burlem esta métrica inflando suas estimativas e concentram-se na conclusão do máximo de histórias possíveis às custas da colaboração com outras equipes. O que pode diminuir sua velocidade e aumentar a velocidade da outra equipe, fazendo com que pareçam ruins. Isso não destrói apenas a utilidade da métrica de velocidade para o propósito pretendido, mas também inibe a colaboração entre equipes.

A velocidade como uma métrica de produtividade viola nossas diretrizes quando focam em métricas locais e não em métricas globais. Isso é particularmente óbvio na segunda crítica, quando as equipes (compreensivelmente) fazem escolhas para otimizar sua própria velocidade e muitas vezes não colaboram com outras equipes. Isso geralmente resulta em cenários em que soluções com padrão de desempenho baixo estão disponíveis para a organização porque não há um foco nas medidas globais.

Utilização. Finalmente, muitas organizações medem a utilização como um proxy de produtividade. Uma vez que a utilização fique acima de um certo nível, não há capacidade de reserva (folga) para absorver o trabalho não planejado, as mudanças no plano ou soluções de melhoria. Isso resulta em prazos mais longos para concluir o trabalho. A teoria de filas em matemática diz que, à medida que a utilização se aproxima de 100% os tempo de espera se aproximam do infinito, em outras palavras, quando você alcança níveis muito altos de utilização as equipes demoram mais tempo para fazer qualquer coisa. Como o tempo de espera, uma medida da rapidez com que o trabalho pode ser concluído, é uma métrica de produtividade que não sofre com as desvantagens das outras métricas que vimos, é essencial gerenciar a utilização e equilibrar o tempo de espera de forma economicamente razoável.

A utilização como métrica de produtividade viola nossas diretrizes porque se concentra na produção e não nos resultados. Também se concentra em métricas individuais e não globais. Eles se juntam de uma maneira ruim para parecer que tiramos o máximo do pessoal (dando mais trabalho). Quando na verdade criamos uma situação em que apenas tornamos o trabalho impossível (sem esforço e sem trabalho).

Bons exemplos de métricas em tecnologia

Nem toda a esperança está perdida! Temos alguns bons exemplos de como medir a produtividade na tecnologia.

Software. Na pesquisa apresentada no livro Accelerate, usamos uma métrica de desenvolvimento e entrega de software que chamamos de desempenho de entrega de software. É composto por quatro medidas em duas categorias:

• Tempo:

• Prazo de entrega: o tempo que leva para ir do código enviado para o código executado com sucesso na produção;
• Frequência de implantação: com que frequência uma equipe implanta o código.

• Estabilidade:

• Hora de restaurar o serviço: quanto tempo leva para restaurar o serviço do aplicativo ou serviço principal em que ele trabalha quando ocorre um incidente de serviço (por exemplo, interrupção não planejada, redução no serviço);
• Taxa de falha de alteração: qual porcentagem de alterações para o aplicativo ou serviço primário em que eles trabalham resultam em degradação do serviço ou subsequentemente requerem correção (por exemplo, levar a problemas de serviço ou interrupções, exigem um hotfix (correção rápida), uma reversão, um encaminhamento ou patch (correção).

Essas métricas seguem nossas diretrizes porque são métricas de resultado e métricas globais, ou seja, elas se concentram em colocar o software em produção, o que pode valorizar a organização e os clientes, e não em pontos pequenos e localizados que podem ser burlados sem ajudar no objetivo geral. Descobrimos que tempo e estabilidade são ambos possíveis juntos, com altos desempenhos indo bem ambos em conjunto.

Nossa pesquisa constatou que concentrando-se nessas métricas o desempenho organizacional é impulsionado com alto desempenho, sendo duas vezes mais propenso a atingir metas de lucratividade, produtividade e participação de mercado. Assim como metas de eficácia, eficiência e satisfação do cliente.

Banco de dados. Outro ótimo exemplo vem ao medir o desempenho do banco de dados. Isso é complicado porque muitas vezes (inteligentemente e necessariamente) nos atolamos em detalhes: dados de entrada, dados de saída, se os dados estão protegidos, como é nossa telemetria, se estamos escolhendo algo que agrega, etc. Para tudo isso é necessário ter uma boa compreensão de como são nossos dados e bancos de dados. No entanto, se quisermos pensar sobre o desempenho do banco de dados devemos dar um passo para trás e considerar as métricas e os resultados globais.

Neste ponto gosto da orientação de Laine Campbell e Charity Majors da Database Reliability Engineering (no qual eles investigam os detalhes e o alto nível, a propósito). Eles apontam duas questões-chave em seu capítulo sobre visibilidade operacional: Seu serviço está funcionando? Os consumidores estão com dor? Aqui, eles dizem com muita inteligência que "as verificações de ponta a ponta são a ferramenta mais poderosa em seu arsenal, porque refletem mais de perto a experiência do cliente" (página 64).

Adoro a orientação clara deles e me concentro nessas medidas porque, mais uma vez, é aí que se fecha o laço proverbial, reunindo as equipes de banco de dados e desenvolvimento para gerar valor e garantir que software de qualidade (código de aplicativo e banco de dados) sejam entregues em conjunto. A propósito, focar nessas medidas também ajuda a colocar o banco de dados em uma conversa de valor sobre sua tecnologia e oferta. Se seus clientes sofrem porque suas equipes de desenvolvimento quase-multifuncional escrevem aplicativos que ignoram sua equipe de banco de dados, que não têm outra opção senão implantar manualmente suas alterações de esquema de banco de dados para acompanhar as mudanças de aplicativos, talvez seja hora de começar expandindo essa tenda.

Qualidade. Foco na qualidade é importante para todas as organizações e uma das métricas mais difíceis de se falar universalmente. Por que isso? Nas palavras do especialista em qualidade de software Jerry Weinberg, Quality is value to some person.”¹E, como todos sabemos, as organizações trabalham em contextos diferentes, atendendo a diferentes funções e pessoas.

Mas a "qualidade", pense nisso em seu contexto, é muitas vezes uma boa medida de produtividade porque se concentra em métricas e resultados globais. Geralmente pensamos nos clientes, usuários finais ou no estado final do produto. Em nossa pesquisa, um exemplo de medida de qualidade que capturamos é a porcentagem de tempo gasto em retrabalho ou trabalho não planejado, incluindo trabalho em quebras/correções, implantações e correções de emergência, respostas a solicitações urgentes de documentação de auditoria e assim por diante. Descobrimos que a quantidade de tempo gasto em novos trabalhos, trabalho não planejado ou retrabalho e outros tipos de trabalho foi significativamente diferente entre os de alto desempenho e baixo desempenho. Em outras palavras, os funcionários de alto desempenho estavam criando qualidade, portanto, tinham que gastar menos tempo corrigindo erros. Como na figura a seguir.

Concentrando-se nas medidas e nos resultados globais, estará no caminho certo para planejar ótimas métricas para ajudá-lo a ter sucesso.

Quando se concentra em resultados globais como qualidade, a produtividade acompanha. Outras pessoas também observaram isso, John Seddon deu ótimo exemplo: "O paradoxo é que quando os gerentes se concentram na produtividade, raramente são feitas melhorias de longo prazo. Por outro lado, quando os gerentes se concentram na qualidade, a produtividade melhora continuamente ".

Sobre a autora

Nicole Forsgrené especialista em impactos de TI e mostra aos líderes e profissionais de tecnologia como liberar o potencial da mudança tecnológica. Ela é consultora, especialista e pesquisadora em DevOps, adoção e impactos de TI e gerenciamento de conhecimento. Ela é co-fundadora, CEO e cientista chefe na DevOps Research and Assessment (DORA), uma joint venture com Gene Kim e Jez Humble. Ela é membro do Conselho Editorial da ACM Queue e Parceira Acadêmica da Clemson University e da Florida International University. Nicole é doutora em Sistemas de Informação Gerencial e tem um mestrado em Contabilidade, também publicou vários artigos em periódicos revisados por pares e recebeu bolsas de pesquisa públicas e privadas (entre os financiadores estão inclusos a NASA e a NSF).

Referências

¹Weinberg, Gerald M. Quality Software Management. Volume 1: Systems Thinking. New York: Dorset House Publishing, 1992.