Métricas que importam em um projeto de software: além de prazo e orçamento

Por que prazo e orçamento não contam a história toda

Você já deve ter ouvido ou dito algo assim:
“Estamos um pouco atrasados, mas dentro do orçamento.”
“Entregamos no prazo, dentro do custo combinado.”

E aí, quando o sistema entra no ar, a operação reclama, a adoção é baixa e surgem planilhas paralelas de novo. Ou seja, o projeto foi “um sucesso” nos relatórios, mas um problema no dia a dia.

Prazo e orçamento são métricas básicas. Mostram se o projeto está sob controle do ponto de vista financeiro e de cronograma. Não mostram se ele está resolvendo o problema certo, nem se o resultado se sustenta depois.

Gestor que quer usar tecnologia como alavanca de negócio precisa de mais algumas lentes simples para olhar o projeto.

A seguir, as principais perguntas que costumam aparecer em conversa com diretores e donos de negócio. E que métricas fazem diferença de verdade em cada uma delas.

“Como eu sei se o projeto está gerando valor, não só entregando tarefa”

Aqui entram métricas ligadas ao impacto no negócio, não à quantidade de coisas feitas.

Alguns exemplos práticos que funcionam bem:

• Tempo de execução de um processo
  Quanto tempo levava antes e quanto tempo leva depois para fazer a mesma atividade
  Exemplo: cadastro de cliente, aprovação de pedido, fechamento de contrato
• Volume de retrabalho
  Quantas vezes o mesmo pedido ou atividade volta por erro, falta de dado ou falha de sistema
• Erros que impactam cliente ou faturamento
  Quantos erros viram ligação, reclamação ou afetam recebimento de receita

Essas métricas são simples, mas exigem uma decisão: escolher de duas a quatro e combinar com o time desde o começo do projeto. Sem isso, o software vira medição de esforço, não de resultado.

Dica prática

Se você só conseguir escolher uma métrica de valor, escolha tempo do processo principal. É objetiva, fácil de medir e todo mundo entende.

“Como eu enxergo se o time está avançando ou só se ocupando”

Horas trabalhadas e tarefas concluídas muitas vezes enganam. O time pode estar ocupado e o projeto parado em termos de resultado.

Métricas que ajudam aqui:

• Entregas utilizáveis aprovadas
  Quantas partes do sistema já podem ser usadas por alguém real, mesmo que em grupo pequeno
• Frequência de demonstrações para o negócio
  Quantas vezes por mês o time mostra algo funcionando para quem vai usar
• Tempo entre ideia e primeira versão em uso
  Quanto tempo passa entre definir uma necessidade e ter uma primeira versão simples em produção ou piloto

Essas métricas mostram se o projeto está aprendendo rápido ou só empilhando especificações.

Se você percebe que passam meses sem ninguém do negócio ver nada funcionando, acende um alerta, mesmo que o relatório de horas esteja bonito.

“Como medir a qualidade sem entrar no detalhe técnico”

Nem todo gestor quer ou precisa entrar em defeito técnico. Mas precisa saber se o que está sendo colocado no ar está estável.

Métricas de qualidade em linguagem simples:

• Incidentes em produção
  Quantas falhas atrapalham o uso normal do sistema em um período
• Gravidade dos incidentes
  Quantos travam o negócio, quantos atrapalham um pouco, quantos são incômodos mas não críticos
• Tempo para resolver um problema que afeta operação
  Quanto tempo leva entre ser avisado de um problema e ter uma solução que permita seguir a vida
• Volume de pedidos de correção logo após o lançamento
  Se a lista de correções explode nas primeiras semanas, é sinal de que algo na validação antes do go live falhou

O importante aqui é separar ajuste natural de erro grave. Projeto de software sempre tem ajuste. Descontrole aparece quando problema crítico vira rotina.

“E a adoção? Como saber se o sistema vai ser usado de verdade”

A empresa pode ter investido bem, o time ter entregue dentro do combinado, e ainda assim o sistema ficar encostado. Isso acontece mais do que parece.

Métricas de adoção que qualquer gestor consegue acompanhar:

• Percentual de uso em relação ao processo
  De todos os pedidos ou atendimentos, quantos passam pelo sistema e quantos ainda rodam fora dele
• Usuários ativos
  Quantas pessoas acessam o sistema em período relevante para aquele processo
• Aderência ao fluxo padrão
  Quantas vezes o time precisa “driblar” o sistema com atalhos, e mail, mensagem ou planilhas para conseguir trabalhar
• Satisfação básica do usuário interno
  Não precisa ser pesquisa complexa. Pergunta simples funciona:
  De zero a dez, o quanto este sistema ajuda seu trabalho

Essas métricas evitam o cenário de sistema que existe, mas o negócio continua rodando como antes.

“Como evitar que o projeto vire um buraco sem fundo de demanda”

Todo projeto de software puxa mais demanda. Depois que as pessoas veem algo funcionando, surgem novas ideias. Isso é bom, mas pode virar fila infinita sem critério.

Algumas métricas ajudam a manter essa fila saudável:

• Entrada versus saída de demandas
  Quantas demandas entram por mês e quantas são concluídas
• Tempo médio em fila antes de alguém começar a trabalhar
  Se tudo demora meses para sair da gaveta, o sistema passa a imagem de que não evolui
• Percentual de demandas ligadas ao objetivo principal do projeto
  Quantas novas demandas são alinhadas ao objetivo original e quantas são só “seria legal se tivesse”

Esses números ajudam a ter conversa adulta sobre prioridade. E evitam que o projeto se perca tentando agradar todo mundo ao mesmo tempo.

“O que eu deveria olhar como patrocinador do projeto, sem afundar em detalhe”

Patrocinador é quem assina o projeto e responde por ele na empresa. Essa pessoa normalmente não tem tempo para painéis cheios de números.

Um conjunto enxuto funciona bem:

• Uma métrica de valor de negócio
  Exemplo: tempo de processo, taxa de erro, tempo de atendimento
• Uma métrica de estabilidade
  Exemplo: incidentes críticos que param operação
• Uma métrica de avanço de entrega
  Exemplo: percentual de escopo relevante já utilizável
• Uma métrica de adoção
  Exemplo: percentual de operações que já passam pelo novo sistema

Com esse pequeno grupo, em meia hora de reunião você sabe se o projeto está:

• gerando valor ou não
• estável ou não
• avançando ou empacado
• sendo usado ou ignorado

“Quais métricas atrapalham mais do que ajudam”

Alguns números parecem bonitos, mas pouco ajudam a tomar decisão melhor.

Alguns exemplos:

• Contar tela, campo ou linha de código
  Não diz nada sobre valor para o negócio
• Medir só produtividade do time de desenvolvimento
  Se o foco é só “velocidade do time”, a conversa tende a virar cobrança interna, não alinhamento com o negócio
• Acompanhar quantidade de horas gastas sem contexto
  Horas sozinhas não dizem se o tempo foi bem usado ou não
• Buscar uma métrica perfeita para tudo
  Não existe indicador mágico. Melhor ter meia dúzia simples e consistentes do que um indicador sofisticado que ninguém entende

“Como colocar esse tipo de métrica na rotina sem virar burocracia”

O medo de muitos gestores é transformar projeto em festival de relatório. Não precisa ser assim.

Alguns cuidados práticos:

• Escolha poucas métricas
  De quatro a oito no máximo, agrupadas entre valor, qualidade, avanço e adoção
• Defina frequência realista
  Alguns números fazem sentido toda semana, outros a cada quinze dias, outros por mês
• Use o que já é medido hoje
  Muitas vezes, a área já mede tempo de processo, volume de erro, reclamação de cliente. O projeto pode usar essa base em vez de inventar tudo do zero
• Traga as métricas para a conversa
  Métrica boa não é a que está em painel bonito. É a que orienta discussão e decisão na reunião de status

Mini plano de ação para ajustar suas métricas de projeto

Se você quiser começar algo ainda neste mês, um caminho simples é:

Semana 1

• Reunir patrocinador, alguém do negócio e alguém do time de tecnologia
• Definir de duas a quatro métricas de valor e adoção para o projeto atual

Semana 2

• Mapear como medir essas métricas com o que já existe de dado
• Ajustar só o que for essencial para começar a acompanhar

Semana 3

• Incluir essas métricas na reunião de acompanhamento
• Combinar decisões ligadas a elas, por exemplo, priorizar algo que reduz retrabalho em vez de mais uma funcionalidade “legal de ter”

Semana 4

• Rever o conjunto de métricas
• Tirar o que não ajudou em nada na conversa e reforçar o que de fato guiou decisão

Depois de um ciclo desses, dificilmente você volta a olhar só prazo e orçamento.

Onde a CodeOn costuma ajudar nesse tema

Na CodeOn, a conversa com gestores costuma começar justamente aqui:

O projeto está andando, mas o patrocinador sente que não enxerga bem se aquilo tudo vai virar resultado de negócio.

Em muitos casos, ajudamos a:

• traduzir o objetivo de negócio em meia dúzia de métricas simples
• montar um painel enxuto para as reuniões de acompanhamento
• ajustar o jeito de priorizar para focar no que mexe nesses indicadores
• organizar a sustentação e evolução do sistema já pensando nessas métricas

Se você sente que seus projetos estão “andando”, mas não consegue dizer com segurança o quanto eles estão entregando de valor, uma conversa rápida de diagnóstico já pode clarear bastante que métricas fazem sentido no seu contexto e como colocá-las na prática.