O Objetivo (Ainda) é Valor
Adotar IA não é a mesma coisa que entregar resultados
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
“Se tem uma coisa que aprendemos com IA, é que a gente não sabe o que é produtividade em software”. Essa foi uma frase que ouvi de outro líder de engenharia e que ficou na minha cabeça.
A IA está transformando a forma como os times trabalham de maneiras impossíveis de prever há poucos anos. A distância entre a ideia e a execução nunca foi tão pequena. Com isso, é natural que a gente tente aprender a usar as novas ferramentas da melhor forma possível.
É exatamente isso que a indústria de software está fazendo. As ferramentas mudam todo dia, os métodos mudam todo dia. Estamos no primeiro ano dessa transformação e, nos últimos 6 meses, já vimos muita coisa. Agentes rodando em loops, gastar tokens como estratégia e, na sequência, budgets para conter esse gasto, para citar alguns exemplos. E isso sem contar toda uma variedade de técnicas de desenvolvimento que surgiram pelo caminho.
Algumas dessas ideias eram claramente falhas desde o início. Mesmo assim, estamos tentando mudar a forma como trabalhamos. Inovar e falhar faz parte.
O problema é que estamos experimentando com o método e não medindo o resultado de verdade.
Muitas vezes medimos resultados intermediários em vez do objetivo real
“Nossos times estão commitando 90% dos PRs com IA”. Quando líderes da indústria exibem a adoção de IA como uma conquista, o que eles estão destacando é o quão bons são em embarcar numa tendência. O que precisa voltar para a conversa é valor. IA é uma ferramenta, como tantas outras, dentro do processo de entregar valor para o cliente.
Enquanto o exemplo do CEO é óbvio, o mesmo desafio aparece em várias outras áreas. Recentemente participei de uma demo de uma ferramenta de métricas de engenharia que ajudava a analisar quais prompts de IA levavam a mais PRs sendo mergeados. E o meu pensamento ao ver aquilo provavelmente foi o mesmo de quem escuta esses CEOs: como isso se conecta a entregar mais valor?
O problema aqui também não é usar mais dados para falar sobre como os times trabalham. Precisamos ficar melhores em entender a efetividade dos times, e dados fazem parte disso. Esse é um argumento que eu defendo por completo. Mas não podemos sair do “achismo” para uma falsa precisão.
Me mostre o tempo (e o dinheiro)
O problema recorrente com esse tema é que sempre acabamos voltando para a mesma pergunta: o que é valor? Se formos amplos demais, não conseguimos medir, o que significa que não conseguimos avaliar se alguma coisa está funcionando. Por outro lado, elevar métricas de output para um nível mais alto também não é a solução. Métricas não funcionam em todos os níveis de uma organização.
Se você é o CEO de uma empresa, o gasto com tokens não significa muita coisa além do tamanho da sua conta de IA. Se você é uma pessoa desenvolvedora, não vai conseguir mudar a previsão de receita do ano. Dependendo de onde você está na sua organização, vai ter que encontrar o trade-off certo entre ser o mais amplo possível e ter algo sobre o qual você consiga agir e entender os resultados.
Métricas que são úteis em um nível da organização não são necessariamente úteis em níveis diferentes.
Se você lidera um time de software (ou um grupo de times), a sua resposta provavelmente é uma combinação de dinheiro e tempo para entregar um resultado valioso para o cliente. Em outras palavras: investimento e cycle time.
A parte do cycle time é, espero, clara. Se existe uma necessidade percebida do cliente, por exemplo se ele quer conseguir encontrar o produto certo mais rápido, então o que o seu time precisa otimizar é a velocidade com que consegue entregar esse resultado. Quanto tempo passa desde o momento em que o cliente expressou a necessidade, seja de forma direta ou indireta, até você entregar a funcionalidade que a atende?
Usar cycle time para medir o desenvolvimento de software traz várias vantagens. Primeiro, ele foca no valor real, que é difícil de manipular por meio de passos intermediários. Seus clientes não se importam com quantos tokens você gastou ou economizou para entregar o resultado, ou se os agentes eram sencientes enquanto construíam aquilo. Eles se importam se os problemas deles foram resolvidos e com que rapidez isso aconteceu. É verdade que dá para “burlar” o cycle time reduzindo o tamanho de cada fatia. Mas isso é um movimento positivo, já que batches menores levam a uma performance melhor. Uma situação em que todo mundo ganha, como se diz.
E o cycle time também permite criar métricas intermediárias que usam o mesmo princípio. O cycle time até o valor mencionado acima inclui toda a cadeia e também a capacidade da sua empresa de perceber os requisitos dos clientes. Para um time de engenharia, pode ser suficiente pensar no tempo entre os requisitos chegarem ao time (como um projeto, por exemplo) e serem entregues aos clientes. Dentro disso, você também pode pensar no cycle time de cada ticket, representando uma fatia daquele valor, ou de cada PR, focando no trabalho de engenharia do dia a dia. É a mesma métrica aplicada em diferentes níveis de detalhe do sistema, e todos têm o mesmo objetivo.
Diferentes métricas estão medindo o mesmo conceito em níveis diferentes: quanto tempo leva para uma mudança ser concluída?
No entanto, tempo não é tudo, e isso fica cada vez mais evidente à medida que o gasto com tecnologia deixa de ser só com humanos e passa a incluir humanos e agentes. Por muito tempo, empresas de tecnologia operaram sob uma versão do princípio “construa e vai valer a pena”. A ideia é que, se você consegue construir algo útil em software, aquilo vai escalar o suficiente para tornar o custo justificável.
Isso nunca foi uma boa prática, mesmo antes da IA, já que muitas empresas teriam dificuldade para escalar. Mas isso costumava ficar escondido por trás de muitos anos de runway de investimento. Dava para ver em toda empresa: um projeto é entregue com ótimo feedback e todo mundo ganha um bolo. Não importa que o projeto tenha levado três anos, custado dez milhões de dólares e vá gerar apenas 100 mil de retorno.
À medida que a capacidade de investimento diminuiu e a conta de IA se somou aos custos, a questão da materialidade de um investimento fica ainda mais crítica. A pergunta que os líderes de engenharia precisam aprender a responder melhor é quanto investimento será necessário para entregar determinado valor. Investimento que é composto por tempo, com a remuneração das pessoas engenheiras e demais membros do time, e por ferramentas, com o custo dos tokens de IA.
E os líderes de engenharia deveriam se aproximar dessa pergunta, não se afastar dela. Focar a conversa em investimento e tempo nos força a perguntar o que realmente leva a uma entrega mais rápida e mais barata. Quais práticas, quais ferramentas, quais princípios? Em outras palavras, isso nos diz como entregar mais valor.
Comentários