Métricas de qualidade de software: as três que eu meço em vez de procurar culpado

Métricas de qualidade de software que um dono cobra sem ler código: erros por dia, tempo até o diagnóstico e quantas pessoas explicam o trecho. E por que o campo de culpado apaga

Na montagem metálica o relatório pede desenho, lote e data. Nunca o nome de um culpado.

Três números respondem o que você quer saber quando o sistema falha, e nenhum deles é um nome. Quantos erros o sistema produziu ontem, com a série dos últimos quinze dias do lado. O tempo entre um erro aparecer e alguém conseguir dizer de onde ele veio. E o número de pessoas na sua empresa capazes de explicar, em uma frase, o que aquele trecho do sistema faz.

Os três cabem numa reunião de vinte minutos, você cobra os três sem ler uma linha de código, e os três ficam piores no dia em que a sua primeira pergunta depois de um bug passa a ser "quem fez isso".

Essa pergunta tem endereço. Um gestor decidiu criar um campo de "pessoa a quem culpar" em todo relatório de bug da equipe dele, e um dos desenvolvedores foi ao Stack Exchange perguntar como convencer o chefe de que a ideia era ruim. A pergunta acumulou 716 pontos, 29 respostas e mais de 138 mil visualizações. Quase toda a discussão de lá é dev falando para dev. Eu leio de outro lugar, porque já fui o gestor que queria o nome.

Eu já pedi o nome de quem errou, e paguei caro por ele

Pergunte quantos erros o sistema deu ontem. Se não vier número em um minuto, ninguém está medindo.

Minha primeira empresa alugava equipamento para construção civil, no formato que em 2016 todo mundo chamava de Uber de alguma coisa. Contratei desenvolvedores sem entender com profundidade o que eles me diziam. Não sabia julgar prazo, não sabia julgar entrega, e toda sexta a sprint fechava sem a coisa que eu tinha entendido que viria.

Então eu fazia a pergunta que me parecia a mais razoável do mundo: de quem foi? Achava que o nome ia me devolver o prazo.

Voltou silêncio. Nas reuniões seguintes, o problema parou de aparecer cedo. Passou a aparecer na véspera, quando já não dava para reagir, embrulhado em frases que não acusavam ninguém. Eu tinha trocado informação por paz, sem notar que informação era exatamente o que eu estava comprando naquelas reuniões. Levei perto de três anos para entender. A empresa morreu antes.

Anos antes, eu assinava estrutura metálica como responsável técnico, inclusive na montagem do Autódromo de Interlagos. O relatório de não conformidade de lá não tinha campo de culpado. Tinha número do desenho, índice de revisão, lote da peça, data e o que foi feito. O nome do montador às vezes aparecia, às vezes não, e nunca era o motivo de o documento existir. O motivo era descobrir se outra peça do mesmo lote já estava pendurada em algum ponto da estrutura.

Software não inventou a vontade de achar culpado. Software só tornou muito fácil registrar culpa e muito difícil registrar lote.

O campo de culpado apaga justamente o dado que você precisa

No dia em que o nome vira campo obrigatório, o relatório de bug muda de função. Deixa de ser o registro do que aconteceu e passa a ser a abertura de um processo interno. A partir dali três coisas acontecem sem ninguém combinar nada: quem encontra o problema pensa duas vezes antes de abrir o registro, quem corrige descreve a causa na versão mais vaga possível, e o campo se enche de nomes de quem estava de plantão em vez do nome de quem tomou a decisão que gerou aquilo.

O gestor que cria o campo quer uma coisa legítima. Ele quer parar de ser surpreendido. O campo entrega o oposto, porque surpresa é consequência de informação atrasada, e o campo atrasa informação.

"Mas se ninguém responde por nada, nada melhora"

Essa objeção está certa pela metade. Responsabilidade clara é obrigatória. Só que a unidade de responsabilidade é o pedaço do sistema, não o bug. Dono da rota de checkout, dono da integração com o meio de pagamento, dono do serviço de preço: isso é nome em planilha, é cobrável e resolve. Nome colado num bug específico serve para uma conversa só, e ela acontece no RH.

A troca que fez diferença na minha mesa foi parar de perguntar de quem foi e começar a perguntar quando a gente soube, do mesmo jeito que parei de perguntar quanto tempo leva e passei a perguntar o que faz a data mudar.

Número um: erros por dia, com a série ao lado

Quando só uma pessoa sabe explicar a tela que fatura, o risco virou da empresa.

Já entrei em sistema que, para quem pagou por ele, estava funcionando. Tinha perto de 400 erros por dia e nenhum alarme tocando. O dono não era desatento, ele simplesmente nunca tinha recebido o número, e normalmente descobre a queda depois do próprio cliente.

O pedido é literal: pergunte ao seu time quantos erros o sistema deu ontem. Se a resposta não vier com número em um minuto, não existe medição, existe impressão. E olhe a série, não o valor isolado. Uns 90 erros por dia há duas semanas e 300 hoje diz muito mais que 300 sozinho.

Aqui vale um aviso de quem já viu a fantasia montada: endpoint de saúde que responde 200 sem encostar no banco e painel colorido com dado vazio contam como zero. O instrumento precisa medir alguma coisa que acontece de verdade, e vale desconfiar quando o relatório é bonito demais para um sistema que o time evita abrir.

Número dois: quanto tempo passa entre o erro e a frase "é aqui"

Consertar costuma ser rápido. Descobrir de onde veio é o que demora.

Pegue o último problema que o seu cliente sentiu e anote duas horas: a hora em que o primeiro cliente foi afetado e a hora em que alguém do time disse "achei, é essa chamada". A diferença entre as duas é o seu segundo número. Em sistema que não anota nada, esse intervalo é tempo de adivinhação, e adivinhação cresce junto com o tamanho do código.

Esse é também o termômetro de dívida técnica em linguagem de caixa. Cada remendo que entrou sem registro estica o intervalo um pouco, e o efeito aparece no orçamento do trimestre seguinte, quando uma mudança miúda chega com prazo de obra. Já atendi pedido de trocar uma regra de preço que virou quase um mês de trabalho, e nada daquilo era complexidade do preço.

Número três: quantas pessoas sabem explicar aquele trecho

Três da manhã, sistema parado, e a pessoa que saberia explicar o que aquele arquivo faz não trabalha mais na empresa. Esse é o número que ninguém mede e todo mundo sente.

Faça o inventário mais chato possível: liste as cinco telas por onde entra dinheiro na sua empresa. Para cada uma, pergunte quem consegue explicar o que acontece por baixo. Se três delas devolverem o mesmo nome, e esse nome for de uma pessoa só, o risco passou a ser da sua empresa e não dela. É a mesma conta de quem é dono do seu código, só que medida em cabeças em vez de contrato.

E é nesse número que o campo de culpado cobra o juro mais alto. Conhecimento só se espalha onde errar em público é barato. Quando errar custa o nome no formulário, cada pessoa guarda o que sabe como seguro pessoal, e a sua empresa fica refém de três pessoas sem nunca ter decidido isso.

O modelo de contratação ensina o fornecedor a não medir

Tem um lado disso que não é sobre o seu time. Preço fechado sem previsão de continuidade faz o fornecedor entregar a casca: ele sabe que vai embora, e não tem motivo nenhum para deixar o seu sistema contável. Deixar contável custa tempo e não aparece na demonstração de sexta.

Quem contrata cobra o que sabe avaliar, e tela bonita é o que qualquer pessoa sabe avaliar. Daí a lista de perguntas que valem antes de assinar com quem vai mexer no seu código, e daí a nossa regra aqui dentro: quando a squad entra num sistema que não escrevemos, as duas primeiras semanas vão para medir esses três números antes de propor qualquer mudança. Não é cortesia, é a única forma de existir régua pelo resto do contrato.

O que você cobra na reunião de segunda

Três perguntas, nessa ordem, e nenhuma delas pede nome:

1. Quantos erros o sistema deu ontem, e como estava esse número há duas semanas?
2. No último problema que o cliente sentiu, quantas horas passaram entre o primeiro cliente afetado e o time saber a causa?
3. Quais das nossas cinco telas que faturam têm só uma pessoa capaz de explicar?

Se a sua empresa tem dois desenvolvedores e um produto que ainda não cobra de ninguém, isso é cedo. Mede o primeiro e para. E vale dizer o que esses três números não fazem: eles não dizem se o produto é bom, nem se a arquitetura foi uma boa escolha. Eles dizem se você está enxergando o que paga.

Abra o relatório de bug da sua empresa agora. Se existe um campo com nome de pessoa e não existe um campo com a hora em que o primeiro cliente foi afetado, você montou um arquivo de culpa e não um instrumento de gestão. E se mesmo assim você quiser o nome, responda sozinho, antes de pedir: o que você ia fazer com ele?