É 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:
- 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.
- ê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.
Métricas essenciais
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:
- 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;
- Deployment frequency, que implica, fatalmente, na quantidade de “novidades” em cada deploy (batch size)
- Change fail percentage apontando a proporção de deliveries que geram falhas percebidas em produção
- Mean time to restore (MTTR) indicando o tempo em que uma falha de deploy destrói valor.
As duas primeiras métricas influenciam na geração de valor colocado em produção no melhor tempo, com o mínimo de represamento. As duas últimas objetivam qualidade. Processos de engenharia excelentes são ótimos em todas as quatro dimensões.
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.
MTTR ou MTBF?
Métricas criam “tensões” na operação que direcionam decisões e padrões operacionais. A “tensão” gerada pelo MTBF, que é uma métrica bem intencionada, é espaçar problemas em produção o máximo possível, evitando prejuízos percebidos. O problema é que, implicitamente, essa métrica acaba encorajando, também, o prolongamento dos intervalos entre deploys, afinal, em um sistema que está funcionando bem, toda mudança é fonte potencial de problemas. Indiretamente, em função de menos entregas em produção, há aumento do lead time e também do tamanho de cada entrega, gerando, curiosamente, aumento nas chances de falhas no ambiente produtivo, mais difíceis de identificar, prejudicando o MTTR.
NPS
Outra métrica que tem sido bastante aplicada é o NPS (Net promoter score). De maneira simples, ela aponta a satisfação dos “clientes” a partir da disposição destes para recomendar um produto ou serviço. A premissa é que clientes mais satisfeitos recomendam mais, são promotores. Enquanto isso, clientes insatisfeitos desencorajam novos consumidores, são detratores.
Algumas métricas financeiras
Além das métricas propostas por Forsgren, Humble e Kim, destaco ainda alguns indicadores financeiros importantes:
- orçamento da área sobre o faturamento
- custo da folha sobre o faturamento
- 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
Antes de avançar para o próximo capítulo, considere implementar as seguintes iniciativas:- Construa uma “planilha” consolidando os indicadores financeiros que apontamos nesse capítulo
- 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?
- 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?
- 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.
Concordo, e adicionaria a lei de Conway na medição do NPS para clientes externos, pois está diretamente relacionada com a qualidade das práticas de engenharia e seus resultados.