O problema de definir objetivos em projetos técnicos
A maioria dos projetos que eu já acompanhei sofreu porque ninguém conseguiu responder a qual era o objetivo real da entrega. E não estou falando de um "objetivo bem escrito no documento de escopo". Estou falando daquele momento em que o time acha que entregou algo e o cliente pergunta "e agora?".
Qual era o objetivo: a pergunta que ninguém quer fazer
No meu trabalho com infraestrutura e deploy de sistemas, a gente costuma pular direto para a execução. A equipe recebe uma issue no Jira, abre o código e começa a trabalhar. Isso é errado na maior parte do tempo. O problema aparece semanas depois quando o código funciona, mas não resolve o que precisava resolver. Eu lembro de um caso específico onde estávamos otimizando uma query de banco de dados que estava levando 4 segundos para retornar resultados. O objetivo declarado era "reduzir o tempo de resposta". Bom, reduziu para 0,3 segundos. O cliente ficou satisfeito até perguntar por que a tela de relatórios ainda demorava 12 segundos para carregar. A query que a gente otimizava era a segunda mais lenta do sistema. O verdadeiro gargalo estava numa junção que ninguém tinha mapeado porque ninguém tinha perguntado qual era o objetivo de fato: melhorar a experiência do usuário ou otimizar uma query específica.
Como formular um objetivo que não seja inútil
Na prática, um bom objetivo técnico tem três camadas. A primeira é o que a pessoa pede. A segunda é o problema real por trás do pedido. A terceira é o que aconteceria se aquele problema não fosse resolvido. Pegue o exemplo anterior. Pedido: otimizar a query X. Problema real: a página de relatórios trava no carregamento. Consequência se não resolver: o usuário desiste de usar o sistema e vai para o concorrente. Quando você tem essas três camadas, consegue tomar decisões que um objetivo mal formulado nunca permitiria.
O método que eu uso agora leva cerca de dez minutos e evita horas de trabalho desperdiçado. Antes de abrir qualquer IDE, eu escrevo uma frase simples no formato: "Como [personagem], quero [ação], para que [resultado mensurável]". Parece básico, mas a parte do resultado mensurável é onde a maioria das pessoas falha. "Melhorar a performance" não é mensurável. "Reduzir o tempo de carregamento da tela de relatórios de 12 segundos para menos de 3 segundos" é mensurável.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que eu vejo todo dia
O primeiro erro é confundir objetivo com métrica. Objetivos dizem o que você quer alcançar. Métricas dizem como você vai medir se alcançou. Elas se complementam, mas não são a mesma coisa. Um objetivo sem métrica é apenas uma opinião. Uma métrica sem objetivo é apenas um número flutuando no vácuo. O segundo erro é ter mais de três objetivos no mesmo sprint ou ciclo de desenvolvimento. Quando você define quatro prioridades, na prática nenhuma delas é prioridade. A equipe acaba diluindo esforço em todas e entregando mediocreidade em cada uma. Eu vejo times inteiros fazendo isso todo mês.
O terceiro erro, e talvez o mais grave, é não revisar o objetivo periodicamente. O mercado muda. As necessidades do usuário mudam. O que fazia sentido na semana zero do projeto pode não fazer sentido na semana oito. Eu tenho um hábito de revisar o objetivo a cada duas semanas, especialmente se alguma variável do projeto mudou significativamente. Isso custa pouco tempo e evita entregar a solução certa para o problema errado.
Quando o objetivo simplesmente não existe
Às vezes você chega num projeto e percebe que nunca houve um objetivo claro. O cliente pediu coisas soltas, a equipe implementou, e agora tudo funciona mas nada se encaixa. Nesse caso, a solução não é tentar adivinhar o objetivo original. É parar tudo, conversar com as partes interessadas e reconstruir o objetivo do zero. Isso dói no curto prazo porque exige reunir pessoas e tempo. No longo prazo, é muito mais barato do que refazer o trabalho que já foi feito. Eu costumava ter preguiça desse passo e pulava direto para implementar. A experiência me mostrou que cada hora gasta definindo o objetivo economiza pelo menos cinco horas de retrabalho posterior.
O formato que eu recomendo pra quem tá começando é o OKR simplificado. Um objetivo qualitativo seguido de dois ou três resultados chave quantitativos. Não precisa de ferramenta especializada. Uma planilha simples ou até um documento de texto resolve. O importante é que todo mundo no time tenha acesso e consiga responder em dez segundos qual é o objetivo atual sem precisar procurar em três lugares diferentes.
