Métricas servem para ser um reflexo da nossa realidade e não uma representação de um cenário ideal ou desejável. Medimos para analisar e compreender profundamente o sistema de trabalho, identificar oportunidades de melhoria e apoiar na tomada de decisões com base em dados.
Dentro do universo de gestão de times de tecnologia, podemos falar de quatros pilares e seus respectivos indicadores, vide imagem.
⚠️ Atenção: Elas NÃO existem (e não devem ser usadas) para medir indivíduos, comparar equipes ou estimular vaidade! Individualizar as métricas desencadeia comportamentos individualistas. Comportamentos individualistas repelem a colaboração.
Por quê?
Fluxo Upstream e Downstream
- Upstream → Característica de alta incerteza. Obtém opções, avalia, refina e fatia.
- Downstream → Característica de baixa incerteza. Converte opções, materializa os compromissos.
Observe que toda vez que existe um Handoff (troca de mão), existe uma fila de espera. A ideia é mapear as filas de espera.
- Request Point → Ponto de Solicitação (identificada a demanda para ser feita).
- Commitment Point → Demanda deixa de ser uma possibilidade e passa a ser um compromisso. Entrou para o time.
- Delivery Point → Em produção.
Modelagem Demandas
As métricas devem considerar o item que representa algo potencialmente entregável ao cliente final! E não as pequenas partes dele (tarefas). Essas apenas representam a forma como você estrutura, divide e organiza seu trabalho internamente, mas para o seu cliente, é absolutamente irrelevante.
Caso queira visualizar as pequenas partes do seu entregável considere utilizar checklists ou sub-itens. Sempre existirá variabilidade no tamanho dos itens dentro do contexto em que trabalhamos. Mas conseguimos evitar os extremos!
Um framework para conseguir criar cards adequados é o INVEST:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Anatomia de um Card
- Código e Título
- Descrição detalhada. Escreva informações suficientes para guiar o desenvolvimento e validação da demanda. Explore checklists para atividades necessárias, critérios de aceite, evidências de Definition of Ready (DoR) e critérios de Definition of Done (DoD).
- Datas como Request Date, Commitment Date, Fixed Delivery Date e Delivery Date ajudam na gestão da demanda e a gerar métricas posteriormente.
- Pessoa responsável por executar
- Tipo do card (user story, bug, technical debt, incident, etc)
- Link com o Épico
- Link com outros cards que a demanda depende.
- Classe de Serviço (Expedite, Intangible, Standard, Delivery Fixed Date)
- Idade da Demanda desde o ponto de compromisso até o momento atual (aging).
- Flag para sinalizar bloqueio. Aqui também vale registrar informações adicionais como motivo do bloqueio, tempo de bloqueio e até um contador para contabilizar quantas vezes sofreu bloqueio.
