Métricas que o CTO precisa conhecer e observar

É importante que o CTO, principalmente em empresas maiores, consiga avaliar de maneira objetiva as entregas de seu departamento. Para isso, é recomendável que ele observe um conjunto suficiente de métricas ao ponderar ganhos e perdas de cada iniciativa. A atenção dada a essas métricas, bem como as metas que forem determinadas são de suma importância para a geração de resultados de valor para o negócio, afinal, o esperado é que as pessoas se comprometam a entregar, melhor e primeiro, resultados que impactem positivamente as métricas que são observadas.

Boa parte das dificuldades dos CTOs em estabelecer métricas tem duas causas raízes:

1. geralmente há mais ênfase em outputs do que outcomes – nem sempre é fácil entender que features não representam, necessariamente, valor para o negócio. Tampouco volume de código escrito ou velocity são bons indicativos de performance.
2. ênfase no ótimo local e não no ótimo global – software (ou hardware) tem valor quando está em produção, ou seja, ser tremendamente eficiente para fazer entregas que ninguém usa é desperdício de recursos e não representa nada mais que “métrica para vaidade”.

Boas métricas precisam ser, ao mesmo tempo, valiosas além dos limites da área de tecnologia – ou seja, globais – e focadas na geração de valor percebido para o negócio. Nicole Forsgren, Jez Humble e  Gene Kim apontam, no excelente livro Accelerate (leitura mais do que recomendada) quatro métricas de engenharia que consideram (e eu concordo) essenciais:

1. Delivery lead time, ou seja, o tempo transcorrido entre um experimento (não gosto do termo “requisito”) estar “pronto para implementar” até efetivamente estar sendo testado em produção;
2. Deployment frequency, que implica, fatalmente, na quantidade de “novidades” em cada deploy (batch size)
3. Change fail percentage apontando a proporção de deliveries que geram falhas percebidas em produção
4. Mean time to restore (MTTR) indicando o tempo em que uma falha de deploy destrói valor.

Delivery lead time mais baixo com deployment frequency mais alto permite a área de engenharia colaborar com os times de negócio na execução de experimentações que podem resultar em ganhos no modelo operacional. Além disso, entregas mais frequentes garantem batch sizes menores, logo, mais fáceis de depurar e com prejuízo menos percebido quando um rollback for necessário.

MTTR menores indicam menos “dor para o negócio”, em ambiente produtivo. Enquanto isso, change fail percentage mais baixo indica sucesso na implementação de ações preventivas, como testes automatizados implementados (na medida certa, para atender o delivery lead time) e revisão por pares.

Além das métricas propostas por Forsgren, Humble e Kim, destaco ainda alguns indicadores financeiros importantes:

1. orçamento da área sobre o faturamento
2. custo da folha sobre o faturamento
3. faturamento per capta

Todos esses indicadores são úteis para comparações ao longo do tempo. O primeiro e o segundo, ajudam a entender o impacto dos gastos e despesas em tecnologia na companhia, uma vez que, quando seus valores crescem indicam investimento ou ineficiência. O terceiro, por sua vez, é útil para verificar se a empresa prioriza senioridade (menos gente, mais experiente e potencialmente mais cara) ou volume (mais gente, menos experiente e potencialmente mais “barata”).

Coisas que você precisa fazer

1. Construa uma “planilha” consolidando os indicadores financeiros que apontamos nesse capítulo
2. Reflita sobre a “flutuação” dos indicadores financeiros: sua empresa está investindo? seu departamento está menos ou mais eficiente? a ênfase é senioridade ou quantidade de membros no time?
3. Pondere sobre a coleta das métricas indicadas por Forsgren, Humble e Kim. Quanto “fácil” seria para sua empresa coletar essas métricas hoje?
4. As quatro métricas propostas por Forsgren, Humble e Kim costumam ser “balanceadas”, ou seja, todas estão bem ou todas estão mal. Avalie os resultados do seu time.