Se você tivesse que liderar o desenvolvimento de um produto de software, provavelmente se perguntaria - como ajudar a equipe a se mover mais rápido? E como você sabe o quão rápido você está se movendo?
Parece lógico usar métricas para responder a essas perguntas. Afinal, nós os usamos há muito tempo e com sucesso para os próprios produtos de software. Existem métricas de desempenho, carga do servidor de produção, tempo de atividade. Existem também métricas de produto com base no comportamento do usuário, como conversão e retenção. O benefício das métricas não é apenas uma compreensão mais clara do estado atual, mas, mais importante, fornecer feedback. Você faz uma mudança para melhorar em algo e pode ver pelas métricas quantas melhorias (ou deterioração) você obtém. A sabedoria popular de programação diz: toda otimização do desempenho do programa deve começar com medição, e isso faz muito sentido.
Uma vez que podemos aplicar métricas com sucesso aos próprios produtos de software, por que não aplicá-las à velocidade de desenvolvimento desses produtos? Neste caso, poderíamos tentar algumas melhorias nos processos e ver visualmente se ajudam a andar mais rápido. E o problema de determinar um salário justo para os programadores também seria simplificado. Quais métricas você pode usar?
Não temos boas métricas para isso.
A velocidade de desenvolvimento é a quantidade de trabalho concluído por unidade de tempo. Podemos medir o tempo, tudo é simples aqui. Mas como medir a quantidade de trabalho realizado? As tentativas de fazer isso começaram há muitas décadas, com o nascimento da própria indústria de programação. No entanto, toda vez que a métrica era usada como meta de melhoria, algo estava fadado a dar errado. Por exemplo:
- . , , , . , , , ;
- . , , ;
- . . , , . , , ;
- . , . , , , ;
- . , , , — , ;
- … .
Os desenvolvedores são perspicazes e criativos, e se especializam na solução de problemas complexos. Qualquer que seja a métrica que você fornecer, eles encontrarão a maneira mais fácil de melhorar seu desempenho, mas muito provavelmente, não terá nada a ver com o volume real e a qualidade do trabalho executado. Eles usarão esses métodos de “trapaça”? Não necessariamente, depende da sua situação particular, incluindo a força do incentivo que você cria. Mas eles certamente perceberão que avaliar sua produtividade tem pouco a ver com valor. Isso não só desmotiva, mas também desvia o trabalho real.
Mas por que?
Por que as métricas funcionam muito bem para melhorar as propriedades dos produtos de software, mas não para medir o trabalho realizado pelos programadores? Talvez seja algum tipo de conspiração de programadores? Na verdade, se olharmos além do desenvolvimento de software, veremos outros exemplos, em alguns dos quais as métricas funcionam bem e em outros não.
Exemplos de onde as métricas funcionam bem são fabricação em massa ou vendas. Que haja produção e venda de canecas. Você pode medir o volume de produção - o número de xícaras por unidade de tempo, sua qualidade (porcentagem de sucata), o custo de uma xícara. Em vendas - volume de vendas, margem. Essas métricas são usadas com bastante sucesso na gestão. Por exemplo, pode ser atribuída ao gerente de produção a tarefa de reduzir a taxa de refugo, mantendo o preço de custo, e ao gerente de vendas - aumentando as vendas enquanto mantém o preço. Melhorias nessas métricas vão beneficiar o negócio, por isso podem ser consideradas indicadores de desempenho dos responsáveis.
Um exemplo de quando as métricas não funcionam é a avaliação do desempenho científico. Os cientistas conduzem pesquisas, que são publicadas como artigos científicos. Essa área também tem suas próprias métricas numéricas - o número de artigos, o número de citações, a significância estatística dos resultados etc. É possível dizer que um cientista que divulgou 10 artigos científicos trouxe ao mundo o dobro de benefícios do que um cientista que divulgou 5 artigos? É improvável, porque o valor de seu trabalho pode ser muito diferente e, ao mesmo tempo, mesmo em um nível subjetivo, pode ser difícil entender qual trabalho foi mais valioso. O problema de "trapacear" em citações e publicações é amplamente conhecido na comunidade científica, portanto, infelizmente, não são consideradas indicadores confiáveis de valor. Também existe o problema de manipular a significância estatística .
Dois critérios principais
Independentemente do contexto, as métricas que funcionam bem têm duas coisas em comum:
- Relacionamento direto (não indireto) com valor;
- Exatidão, ou seja, a métrica é baseada na medição do número de algumas unidades de valor e essas unidades são iguais entre si;
Vamos dar uma outra olhada nos exemplos que vimos acima: As
métricas para produção em massa e vendas atendem a ambos os critérios. Na produção de canecas, o valor é o produto - as próprias canecas. A ligação é direta, a empresa precisa produzir canecas. E como a produção é em massa, as unidades de valor (círculos) são iguais entre si. Se estamos falando de vendas, as unidades de valor são dinheiro. O propósito da empresa é obter lucro, portanto, a relação com o valor, novamente, é direta. E como cada dólar ganho é igual a outro, podemos construir métricas precisas.
Na avaliação de trabalhos científicos, esses critérios não podem ser atendidos. Não podemos encontrar uma unidade de medida que determine diretamente o valor do trabalho científico, porque todos os trabalhos científicos são únicos. Não pode ser de outra forma, partindo simplesmente da própria essência da ciência - para descobrir novos conhecimentos. Não faz sentido para um cientista escrever outro trabalho científico que repetiria exatamente outro. Cada trabalho científico deve trazer algo novo.
Como não podemos encontrar métricas que medem diretamente o valor do trabalho científico, ficamos apenas com as indiretas - por exemplo, o número de publicações e citações. O problema com as métricas indiretas é que elas se correlacionam mal com o valor e tendem a ser facilmente enganadas. Se você começar a usar essa métrica como meta, você mesmo criará um incentivo para encerrá-la artificialmente.
Voltar para medir a produtividade do programador
O que temos lá? Linhas de código, número de confirmações, tarefas, pontuação de tarefa em horas ou storypoints ... Se você tentar verificar essas métricas em relação a dois critérios principais, verá que nenhum deles os atende:
- Não existe uma relação direta com o valor. Não fornecemos aos nossos clientes linhas de código, horas-homem ou storypoints. Os usuários não se importam com quantos commits fizemos ou quantas tarefas fechamos;
- Eles não são precisos. Commit to commit são diferentes, uma linha de código não é igual a outra, as tarefas também são diferentes e as horas de trabalho e os storypoints são estimados subjetivamente, portanto, também serão diferentes.
Portanto, não é surpreendente que nenhuma dessas métricas funcione - todas são indiretas e imprecisas.
Por que não há métricas diretamente relacionadas ao valor do trabalho de um programador? Pelas mesmas razões pelas quais os cientistas não os possuem. Os programadores, como os cientistas, estão constantemente criando coisas novas. Eles não escrevem exatamente o mesmo código repetidamente - isso não faz sentido. O código escrito anteriormente pode ser reutilizado de diferentes maneiras, separado em um módulo ou biblioteca separada, ou simplesmente copiado, na pior das hipóteses. Portanto, cada dia de trabalho para os programadores é único. Mesmo que resolvam problemas semelhantes, eles os resolvem cada vez em um contexto diferente, em novas condições.
O trabalho dos programadores é uma produção parcial, não uma produção em massa. Eles não produzem os mesmos resultados repetíveis, portanto, não há linha de base para medição. Métricas que funcionam tão bem na produção em massa ou vendas não funcionam aqui.
Não existe algo mais moderno, baseado em pesquisas?
É claro que hoje ninguém fala seriamente sobre medir o trabalho de um programador por linhas de código. Deve haver algumas métricas mais modernas com base em pesquisas, certo?
Há alguns. Em seu livro “Accelerate” de 2018, os autores citam os resultados de um estudo com 2.000 organizações de diferentes setores. Os autores tentaram descobrir quais métricas mediam o desempenho:
Fonte: Nicole Forsgren, Jez Humble e Gene Kim, “Measuring Performance,” em Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations
Aqui estão quatro métricas. Vamos ver quais estão relacionados ao valor e podem ser medidos com precisão:
- . , . , . . . . , , . , . , — ;
- Lead time — , . , , . , , , — ;
- (MTTR) — , , , . . -, . , MTTR . -, , . , — ;
- , . , . , , , . Linux, “ — ”. SaaS- . , — - , , - . , . , — . , — .
Conclusão: nenhuma dessas quatro métricas é precisa e nem sempre têm uma relação clara com o valor do cliente. Existe uma oportunidade para “trapacear” neste caso? Certo. Entregue mudanças triviais de baixo risco com a maior freqüência possível e todas as métricas, exceto o tempo de processamento, terão uma ótima aparência.
Quanto ao Lead time - mesmo se omitirmos o fato (importante) de que é impreciso, a ênfase nele levará à priorização dos desejos mais simples do cliente e empurrando para o canto mais distante de tudo que o cliente claramente não pediu - geralmente são refatorações, testes e apenas quaisquer melhorias que ele não tivesse pensado.
Portanto, eu não recomendaria usar essas métricas como metas.
Mas talvez possamos encontrar novas métricas?
Claro, você pode dizer: “Espere, se nenhuma métrica adequada foi encontrada ainda, isso não significa que não possa haver nenhuma! Somos pessoas inteligentes, vamos nos esforçar e inventar alguma coisa ”. Infelizmente, temo que não. Existe uma razão fundamental pela qual não existem boas métricas nesta área. Como dissemos acima, os bons atenderiam a dois critérios principais:
- Relacionamento direto (não indireto) com valor;
- Precisão, ou seja, a métrica é baseada na medição do número de algumas unidades de valor, e essas unidades são iguais entre si.
Não podemos medir com precisão o valor direto, porque todos os resultados do trabalho dos programadores são diferentes, eles nunca produzem nada exatamente igual. Esta é uma produção por peça para tarefas únicas e não repetitivas. E uma vez que não há nada repetitivo, também não há base para comparação e medição. Ficamos apenas com os procuradores, mas como eles são pouco relacionados ao valor e propensos a trapacear, confiar neles é prejudicial.
Você pode melhorar áreas para as quais não existem boas métricas?
As métricas são ótimas porque fornecem feedback. Você faz algumas mudanças no processo e pode ver claramente se elas levaram a melhorias ou não. Se não houver métricas, o feedback se torna menos óbvio e pode até parecer que você está se movendo às cegas. Existe um ditado famoso atribuído a Peter Drucker:
Você não pode controlar o que você não pode medir.
Só isso não é verdade. De acordo com o Drucker Institute, Peter Drucker não tinha realmente a ilusão de que uma métrica pudesse ser encontrada para qualquer atividade e nunca disse essas palavras . Nem tudo que é valioso pode ser medido e nem tudo que pode ser medido é valioso.
Complexidade com métricas não significa que nada pode ser melhorado. Algumas empresas lançam software muito mais rápido do que outras e sem sacrificar a qualidade. Isso significa que existem algumas diferenças significativas e, portanto, melhorias devem ser possíveis.
Resumo
É possível e necessário melhorar seu produto de software usando métricas. Desempenho, carga, tempo de atividade ou métricas de produto como conversão e retenção de clientes são seus amigos.
Porém, você não deve tentar acelerar o processo de desenvolvimento com o auxílio de métricas, devido à falta de métricas adequadas. Muitos indicadores nesta área foram inventados, mas, infelizmente, são todos indiretos ou imprecisos, e mais frequentemente os dois ao mesmo tempo, portanto, ao tentar usá-los como objetivos, apenas o dano é obtido.
Mas não desanime - há esperança! A falta de boas métricas para velocidade de desenvolvimento é triste, mas isso não significa que melhorias de velocidade sejam impossíveis. Como é possivel. Sim, temos apenas avaliações qualitativas subjetivas para feedback. No entanto, há um número suficiente deles para implementar melhorias e entender se há um efeito delas. Por exemplo, uma das coisas que pode ser melhorada é a comunicação entre desenvolvedores e gerenciamento . O link acima fornece exemplos de como melhorar a comunicação e por que vale a pena focar nisso.
Isso é tudo, escreva nos comentários o que você pensa. Boa sorte com suas implantações, mesmo às sextas-feiras.