Como organizar e gerenciar seus KPIs?

Conforme dito por Raphael Albino, uma referência em métricas na comunidade de agilidade brasileira, KPIs precisam lhe ajudar a responder perguntas. Não adianta criar KPIs sem um motivo claro, pois eles apenas irão te desfocar do seu objetivo principal e tomarão seu tempo medindo informações que não são relevantes para aquele momento. Além disso, procure manter um número reduzido de indicadores, apenas o necessário para lhe ajudar a responder essas perguntas.

Uma solução visual interessante para organizar seus KPIs é criá-los no formato de uma árvore de indicadores, ligando os indicadores como “folhas” às respectivas perguntas que eles ajudam a responder. Segue um exemplo que elaborei baseado nessas orientações:
‍

Albino reforça ainda alguns “mandamentos” ao analisar métricas e indicadores:

• Métricas devem ser utilizadas para evoluir fluxos e não para cobrar ou comparar pessoas ou equipes
• Sempre leve em conta o contexto no qual o número está relacionado, antes de tomar conclusões
• Foque mais em analisar tendências do indicador e menos no número preciso em si

Por último, estabeleça ritos periódicos para analisar os KPIs com o seu time, como por exemplo as Reuniões de Retrospectiva. De nada adianta ter os números se não há uma discussão rotineira sobre eles, definição de ações e conclusão de aprendizados.

Sugestões de KPIs para times de tecnologia:

Bom, uma vez comentado sobre definições e boas práticas de KPIs, segue abaixo uma lista de alguns indicadores que utilizo ou já utilizei, além de outros que já li/ouvi a respeito, mas ainda não apliquei.

Neste artigo darei uma visão mais macro desses indicadores, mas pretendo me aprofundar em alguns deles em artigos futuros,ok?

Como disse anteriormente, cabe a você entender quais perguntas precisam ser respondidas neste momento para definir quais serão os seus KPIs, sempre buscando um número reduzido desses indicadores. 

Dimensão: Qualidade

Possíveis perguntas que o KPI pode responder:

• Estou entregando produtos de qualidade? 
• Estou entregando produtos seguros?
• Existe um problema que é mais importante ser resolvido do que essa nova feature?
• O usuário está tendo uma experiência fluida?

KPIs:

• Número de bugs identificados
  ‍
• Número de bugs críticos identificados
  ‍
• Número de vulnerabilidades identificadas
  ‍
• Número de vulnerabilidades críticas identificadas
  ‍
• % de cobertura de testes: indica a porcentagem de código-fonte testada em relação ao total, podendo ser focada em linhas de código, ramificações (branches), funções, etc.
  ‍
• % de incidentes decorrentes de mudanças: indica dentre os incidentes críticos ocorridos em produção, àqueles que tiveram como causa raiz uma mudança no produto realizada pelo time.
  ‍
• Taxa de reversão de código: a quantidade de reversões de commits de código em relação ao total de commits.
  ‍
• Frequência de deploys: volume de deployments que o time executa em um período de tempo. Pode parecer estranho eu ter colocado essa métrica na dimensão de qualidade, mas, como Nicole Forgren escreveu em seu livro "Accelerate", quanto mais frequentes são seus deploys, mais rapidamente você obtém feedback, aprende com o que está sendo implantado e lança features com maior qualidade.
  ‍
• % de conversão dos fluxos: normalmente obtido através de instrumentações injetadas nos códigos que rastreiam as ações realizadas pelos usuários e analisadas em ferramentas de Product Analytics 
  ‍
• Deployment Confidence: uma métrica medida através de pesquisa, que indica o quanto as pessoas do time se sentem seguras e confortáveis para subir um código para produção.

Dimensões de análise:

• Por período de tempo, versão, produto, time, etc.

Dimensão: Fluxo de Trabalho

Possíveis perguntas que o KPI pode responder:

• Estou entregando features e produtos em uma cadência regular?
  ‍
• Ao ser perguntado sobre “previsão de entrega de uma atividade”, consigo passar uma visão de probabilidade de prazo de maneira assertiva? (e nunca uma data específica!)
  ‍
• Existe algum fator que está bloqueando o fluxo de entrega?

KPIs:

• Lead Time: o tempo decorrido desde o momento em que o time se comprometeu com a implementação da tarefa, até a sua entrega final. Nesse caso, cabe ao time definir em suas políticas o que significa o “início” e “fim” do fluxo, podendo o início ser desde o processo de discovery ou somente a partir do momento em que ela é priorizada para a próxima sprint do time, ou seja o ponto de comprometimento. Já para o final do fluxo, podemos utilizar normalmente o momento em que o código vai para produção ou quando a feature está de fato na mão do usuário final (no caso de liberações faseadas via loja de aplicativos).
  ‍
• Throughput: o número de tarefas concluídas em um período de tempo.
  ‍
• WIP, Work In Progress: ou trabalho em progresso, que mede o volume de atividades iniciadas e ainda não concluídas em um dado período de tempo.

Dimensões de análise:

• Por tipo de tarefa (estória, bug, vulnerabilidade, épico), time.

‍Dimensão: Operação‍

Possíveis perguntas que o KPI pode responder:

• Qual o volume de incidentes ocorridos em produção?
• Quais são as principais causas dos incidentes em produção e como evitá-las? 
• Estou detectando rapidamente um incidente em produção?
• Estou recuperando rapidamente meu ambiente após incidentes?
• Meu fornecedor parceiro está entregando uma solução de qualidade?
• Estou prontamente atendendo meus clientes e resolvendo seus problemas/dúvidas?

KPIs:

• Disponibilidade dos produtos: utilizo dois tipos de medidas: uma baseada no percentual do tempo em que o produto esteve disponível para o usuário final sobre o período total apurado, a partir do registro prévio dos incidentes que afetaram o ambiente. Outra baseada na métrica apdex, Application Performance Index, analisando o percentual do tempo em que os serviços relacionados a um produto estiveram com uma pontuação acima da meta estipulada.
  ‍
• % de incidentes por causa raiz: o número de incidentes por cada tipo de causa raiz
  ‍
• % de incidentes recorrentes: percentual de incidentes que se repetiram sobre o total
  ‍
• Tempo médio para detecção de incidentes: o tempo médio que leva desde o início do incidente até que alguém do time de desenvolvimento tome ciência de que ele está ocorrendo e comece a atuar, o MTTD Mean Time To Discovery
  ‍
• Tempo médio entre falhas: o MTBF Mean Time Between Failures, que mede quanto tempo o sistema tende a funcionar antes de experimentar uma falha. Normalmente é o tempo total analisado, dividido pelo número de falhas ocorridas.
  ‍
• Tempo médio de reparo, ou MTTR Mean Time To Repair: tempo médio que a equipe leva para reparar um sistema, obtido pelo tempo total de indisponibilidade dividido pelo número de incidentes. Além desse, podemos criar um indicador semelhante para medir não o tempo total da indisponibilidade, mas até o momento em que a equipe aplica uma solução de contorno não solucionando a indisponibilidade, mas amenizando seu impacto.
  ‍
• % de tickets resolvidos dentro do prazo: métrica muito utilizada em operações e Customer Success, mede o percentual de tickets abertos pelos(as) usuários(as) que foram resolvidos em um tempo menor ou igual ao estipulado
  ‍
• % de tickets resolvidos em primeiro atendimento: mede a eficácia do Service Desk, ou seja, o percentual de tickets abertos pelos(as) usuário(as) resolvidos no primeiro contato com o Service Desk, sem haver a necessidade de acionamento de outros times de operações, desenvolvimento, etc.

Dimensões de análise:

• Por período de tempo, por produto, por feature, por serviço, etc

Dimensão: Pessoas

Possíveis perguntas que o KPI pode responder:

• O meu time está feliz?
• Tenho as senioridades adequadas nos meus times?
• Tenho os perfis (fullstack, backend, frontend) adequados nos meus times?

KPIs:

• eNPS, Employee Net Promoter Score: indica o nível de satisfação e engajamento do time, normalmente medido através de uma pergunta semelhante a “Em uma escala de 0 a 10, o quanto você recomendaria (a empresa, a área, o time) como um ótimo lugar para trabalhar?”
  ‍
• % de fullstack, frontend, backend: para identificar eventuais desbalanceamentos. 
  ‍
• % de juniores, plenos, seniores e especialistas: também para identificar eventuais desbalanceamentos. Uma informação adicional que incluo é colocar pontos por cada nível, ou seja 1-junior, 2-pleno, 3-sênior e 4-especialista. Com isso determinar quantos pontos tem cada time e ter uma ideia de times mais ou menos experientes.
  ‍
• “Tempo de casa” médio de cada time
  ‍
• Índice de turnover voluntário e não voluntário: calculado pelo número de desligamentos no mês, divididos pelo número de pessoas no mês anterior.
  ‍
• % de pessoas em cada faixa salarial: uma vez que normalmente os salários de pessoas colaboradoras são classificados por faixas, é uma métrica importante para saber se os salários do seu time estão acompanhando o mercado

Dimensões de análise:

• Por times, por áreas

Dimensão: Financeira

Possíveis perguntas que o KPI pode responder:

• Como está a saúde financeira da minha área?

KPIs:

• Receita: nesse caso essas métricas são bastante dependentes do modelo de negócio da empresa, podendo ser por exemplo, licenciamento e serviço de suporte para empresas que vendem software, mensalidade para serviços SaaS, Software as a Service, take rate (taxa de ganho por transação em relação ao valor total transacionado em vendas, o GMV Gross Merchandise Value) para marketplaces. A partir dessa Receita Bruta, gera-se a Receita Líquida após deduções de impostos, devoluções e abatimentos. 
• COGs: Cost of Goods Sold: Custo dos Produtos Vendidos, que são os custos que a área tem para criar e suportar os produtos, como por exemplo, custo de infraestrutura cloud, custo dos times de desenvolvimento/suporte, custo com terceiros (quando parte do desenvolvimento é terceirizado), custos de licenciamento de propriedade intelectual, etc.
  ‍
• Despesas Operacionais: demais despesas que não estão diretamente relacionadas à produção do produto, exemplo:  despesas com marketing e vendas, despesas com pesquisa e desenvolvimento, aluguel/compra de equipamentos (e sua depreciação).
  ‍
• Lucro Operacional: A partir do valor da Receita Líquida é deduzido o valor de COGs para se atingir o Lucro Bruto e a partir dele, deduzimos o valor das despesas operacionais para se atingir o Lucro Operacional da minha área. Essa é talvez a principal métrica financeira para indicar o valor que a área de tecnologia está gerando para a empresa.

Dimensões de análise:

• Período de tempo

‍

Na Mentoria CTO da IFTL, você aprende no detalhe o uso e aplicação dessas métricas de orçamento. Confira os tópicos abordados na aula Modelos de Negócios:

• Estágios de uma empresa

• Métodos de valuation - Empresa SAAS

• Métodos de valuation - Empresa Serviço

• Métodos de valuation - Empresa Marketplace

• Eventos de liquidez e dividendos - Paydays

• Desenvolvendo budget para área de tecnologia

• Exemplos de budget para área de tecnologia

Acredito que com essa lista de métricas apresentadas você tenha uma “caixa de ferramentas” apropriada para “navegar pelos mares revoltos e apaixonantes” da gestão de uma área de tecnologia.

Gostou da lista? Faltou alguma coisa? Gostaria que eu aprofundasse em alguma dessas dimensões?

Dê seu feedback e me ajude a construir artigos futuros!