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.