Métricas que o CTO precisa conhecer e observar

Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, e não há sucesso no que não se gerencia.
William Edwards Deming
Como dissemos no capítulo 1, o CTO é o responsável pela engenharia para construção e manutenção de produtos tecnológicos, tanto para uso interno quanto para uso externo. Dessa forma, entre seus principais interesses estão a melhoria dos métodos de trabalho, tecnologias adotadas, técnicas empregadas, além, é claro, da composição e organização do time.

É 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.

Métricas essenciais

Nicole Forsgren, Jez HumbleGene 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 timeou 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.

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?

Além do MTTR, é comum encontrar empresas medindo o MTBF (mean time between failures – tempo médio entre falhas). A intenção geralmente é boa, mas o resultado pode ser diferente do que se espera.
0
Você tem boas experiências medindo MTBFx

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.

Os riscos do MTBF podem ser bastante mitigados se o deploy acontecer em “anéis” e a métrica ficar restrita apenas ao anel mais amplo.
0
Há outras formas de mitigar os riscos do MTBF?x

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.

Quando os produtos tecnológicos desenvolvidos pela organização são usados externamente, o NPS atribuído a empresa acaba sendo, indiretamente, indicativo também da qualidade das práticas adotadas engenharia e devem, sim, ser avaliados pelo CTO. Por outro lado, quando os produtos tecnológicos são exclusivos para uso interno, a medição de NPS com o “cliente interno” pode reforçar a cultura do “nós-e-eles” destruindo oportunidades de colaboração e, em consequência, a agilidade.
1
Você concorda?x

Algumas métricas financeiras

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

Antes de avançar para o próximo capítulo, considere implementar as seguintes iniciativas:
  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.

 

Referências bibliográficas

FORSGREN, Nicole; HUMBLE, Jez; KIM, Gene. Accelerate: the science of lean software and devops: building and scaling high performing technology organizations. Portland, Or: Lean It Strategies Llt, 2018.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
1 Comentário
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Giovanni Vicente
Giovanni Vicente
3 anos atrás
Feedback no conteúdo deste capítulo Quando os produtos tecnológicos desenvolvidos pela organização são usados externamente, o NPS atribuído a empresa acaba sendo, indiretamente, indicativo também…" Ler mais »

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.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentorias

para arquitetos de software e executivos

Elemar atua há mais de 20 anos desenvolvendo software de classe mundial e liderando times de tecnologia de alta performance. Conheça o programa de mentoria.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

TECH

&

BIZ

-   Insights e provocações sobre tecnologia e negócios   -   

55 51 9 9942 0609  |  me@elemarjr.com

55 51 9 9942 0609  |  me@elemarjr.com

bullet-1.png

51 99942 0609  |  me@elemarjr.com

1
0
Quero saber a sua opinião, deixe seu comentáriox
()
x