GESTÃO DE PROJETOS NA ERA DA IA: COMO OS SQUADS ESTÃO SE REINVENTANDO

A inteligência artificial está provocando uma mudança estrutural no desenvolvimento de software, não apenas na forma como o código é produzido, mas em todo o ciclo de gestão de projetos. Este artigo explora como práticas tradicionais estão sendo tensionadas, como novas abordagens começam a emergir e como equipes, como a da Axoma, estão adaptando seus processos para operar com mais clareza, qualidade e eficiência nesse novo contexto.

A adoção de inteligência artificial no desenvolvimento de software não está apenas transformando a forma como código é escrito, mas redefinindo como projetos são concebidos, planejados e entregues. Estruturas tradicionais de gestão, que por anos sustentaram a previsibilidade em squads ágeis, começam a mostrar sinais de desgaste em um cenário onde a produtividade não é mais linear.

Se antes o esforço estava majoritariamente concentrado na construção, hoje ele se distribui entre especificação, geração assistida, validação e revisão crítica. Esse deslocamento exige uma revisão profunda das práticas de gestão.

Estimativas sob nova lógica: quando velocidade deixa de ser previsível

A relação clássica entre esforço e tempo está sendo tensionada. Tarefas que antes demandavam dias podem ser executadas em poucas horas com apoio de IA. Ao mesmo tempo, atividades aparentemente simples passam a exigir ciclos mais longos de validação e testes, especialmente quando envolvem regras de negócio mais sensíveis. O resultado é um ambiente menos previsível.

Mais do que recalibrar estimativas, squads começam a lidar com um novo tipo de incerteza: não sobre “quanto tempo leva para construir”, mas sobre “quanto esforço será necessário para validar e garantir qualidade”.

O novo papel de PO/PM: da priorização à precisão

Se a qualidade do código gerado por IA depende diretamente da qualidade do input, então, as especificações deixam de ser apenas direcionais e passam a ser estruturais.

O papel de Product Owners e Product Managers evolui: menos foco em backlog grooming superficial e mais responsabilidade sobre clareza, completude e consistência das specs. Ambiguidade, que antes era resolvida ao longo da implementação, agora se transforma em output inconsistente.

Isso aproxima o desenvolvimento de abordagens como Spec-Driven Development (SDD), onde a especificação deixa de ser um artefato auxiliar e se torna o núcleo do processo.

SDD (Spec-Driven Development): da documentação ao núcleo do processo

Em abordagens tradicionais, a especificação orienta o desenvolvimento. No SDD, ela estrutura e, em muitos casos, viabiliza a própria execução, especialmente quando o código é gerado a partir dessas definições. Na prática, isso significa que a qualidade do software passa a depender diretamente de três fatores: clareza, nível de detalhamento e ausência de ambiguidades.

Como afirma Kauan Costa, líder técnico da Axoma:

“Hoje, com a IA, há menos espaço para interpretação durante a execução. Se antes lacunas eram preenchidas ao longo da implementação, agora elas tendem a se materializar imediatamente em outputs inconsistentes ou incorretos. As limitações da IA ficam evidentes quando a especificação é fraca.”

Ele reforça:

“Com o SDD, há um deslocamento do tempo de desenvolvimento para a construção e refinamento das especificações.”

Ainda assim, é importante um ajuste de expectativa. O SDD não é uma metodologia consolidada como Scrum. Trata-se de uma abordagem em evolução, sem padronização formal ampla.

“O SDD é uma metodologia que ainda está em forte transformação. Estamos vivendo aqui na Axoma um momento de aprendizado contínuo e adaptação, testando e investigando os melhores caminhos para uso desta abordagem.”

Esse modelo também traz um ponto de atenção: quanto maior a dependência de especificações detalhadas, maior o risco de rigidez. Nem todos os contextos permitem clareza total no início, e detalhamento excessivo pode limitar a adaptação.

Equipes mais maduras tendem a buscar equilíbrio: estruturam o suficiente para orientar a IA, mas preservam flexibilidade para aprendizado ao longo do processo.

IA também transforma o lado do cliente

Um efeito menos evidente, mas cada vez mais relevante, é que a IA não está impactando apenas quem desenvolve software, ela também está mudando profundamente a forma como o cliente pensa, valida e comunica suas necessidades.

Tradicionalmente, havia um “gap de tradução” entre negócio e tecnologia. O cliente descrevia intenções em linguagem abstrata, e o time técnico interpretava, estruturava e transformava isso em solução. Esse processo era, por natureza, iterativo e sujeito a ambiguidades.

Com a IA, esse gap começa a diminuir. A inteligência artificial passa a atuar como uma camada intermediária, permitindo que o cliente avance na formalização de suas ideias antes mesmo do envolvimento técnico mais profundo. Ele consegue explorar possibilidades, testar hipóteses e transformar descrições em representações mais concretas.

Um dos exemplos mais claros dessa mudança está na prototipação, como explica o tech lead da Axoma, Leonardo Lopes da Paz: 

“Hoje nossos clientes conseguem nos mandar um mockup funcional. Antes isso exigia muito mais esforço, usando ferramentas como o Figma. Agora, com IA, o cliente consegue chegar em algo muito próximo do que quer com uma fração do esforço.”

Kauan complementa:

“Os protótipos feitos com IA são extremamente visuais. Os botões funcionam, dá para testar a navegação. Não tem integração, mas é uma representação muito próxima do que o cliente espera.”

Isso altera diretamente a qualidade da definição de requisitos.Antes, grande parte do estava em interpretar o que o cliente queria dizer. Agora, o ponto de partida já é mais concreto, o que reduz ambiguidades, acelera decisões e melhora o alinhamento entre as partes.

“A gente perdia dias ajustando detalhes visuais no final do processo. Agora isso já vem muito mais resolvido desde o início.”

O cliente chega mais preparado, com hipóteses mais estruturadas e expectativas mais tangíveis. O time técnico, por sua vez, passa a trabalhar com um nível maior de clareza desde as primeiras etapas.

No entanto, esse avanço traz um efeito colateral importante: a falsa sensação de completude. Protótipos gerados por IA podem parecer “prontos”, mas não contemplam regras de negócio, integrações ou cenários de exceção. Isso exige um olhar mais criterioso por parte do time técnico para evitar decisões baseadas em uma percepção superficial de definição.

Nesse novo contexto, o papel da consultoria ganha ainda mais relevância. Não se trata apenas de desenvolver software, mas de ajudar o cliente a estruturar melhor a solução do problema, interpretando, refinando e complementando o que a IA torna visível, mas não de forma completa.

Code review: menos sintaxe, mais arquitetura

Com a IA assumindo parte relevante da escrita de código, o papel do code review também muda. Erros básicos tendem a ser reduzidos, mas isso não significa menos trabalho, significa um trabalho diferente.

O foco se desloca para decisões arquiteturais, aderência ao domínio do negócio e consistência do sistema como um todo. Nesse cenário, validar se “o código funciona” já não é suficiente. É preciso avaliar se ele faz sentido.

Métricas em crise

A introdução de IA também expõe uma limitação que já existia, mas era menos evidente: muitas métricas tradicionais não mediam valor diretamente, mas sim sinais indiretos, como volume de código, esforço estimado ou velocidade de entrega.

Essas métricas funcionavam como boas aproximações em um contexto mais estável. Com a IA, no entanto, a relação entre esforço, volume e valor se torna menos linear. Produzir mais rápido ou em maior volume já não significa, necessariamente, entregar mais valor e essas aproximações passam a ser mais suscetíveis a distorções.

Na prática, isso significa que alguns indicadores começam a perder relevância ou até se tornar enganosos:

Linhas de código (LOC)

A IA pode gerar grandes volumes de código em segundos, inflando a métrica sem refletir complexidade ou qualidade. Em alguns casos, aumenta inclusive o risco de código redundante ou desnecessário.

Velocidade da sprint (velocity) 

A aparente aceleração na entrega de histórias pode mascarar um gargalo crescente em revisão e validação. O time “entrega mais pontos”, mas não necessariamente entrega valor mais rápido.

Tempo de commit até pull request 

Esse intervalo tende a cair drasticamente, já que a geração de código é quase imediata. No entanto, a métrica deixa de capturar o esforço real, que agora está concentrado na interpretação e refinamento.

Cobertura de testes (quando automatizada por IA) 

A geração automática pode inflar a cobertura sem garantir efetividade. Testes podem validar a implementação, mas não necessariamente o comportamento esperado do negócio.

O risco aqui é operacional: organizações continuam acompanhando indicadores que parecem positivos, enquanto a qualidade real, o risco e o retrabalho aumentam silenciosamente.

Ao mesmo tempo, começa a emergir uma nova lógica de mensuração, mais orientada a qualidade, eficiência real e impacto:

Taxa de aceitação de código gerado por IA 

Qual porcentagem do código sugerido é utilizado com poucas ou nenhuma modificação? Essa métrica ajuda a avaliar tanto a qualidade dos prompts quanto a maturidade do uso da IA no time.

Tempo de revisão (review time) 

Se a geração acelera, a revisão tende a se tornar o novo gargalo. Medir esse tempo passa a ser essencial para entender onde o fluxo está travando.

Densidade de defeitos durante a produção 

Com maior volume de código, cresce o risco de bugs mais sutis. A qualidade passa a ser melhor representada por estabilidade e confiabilidade durante a produção.

Time-to-market real 

Mais do que medir partes isoladas do processo, ganha relevância o tempo total até a entrega de valor, incluindo retrabalho e validações adicionais.

Produtividade orientada a valor 

Em vez de medir quanto código é produzido, passa a ser mais relevante entender o impacto gerado: problemas resolvidos, eficiência criada e valor entregue ao negócio.

Experiência do desenvolvedor (DevEx)

 A IA reduz tarefas repetitivas, mas pode aumentar a carga cognitiva em revisão e validação. Monitorar a experiência do time ajuda a evitar ganhos de curto prazo com custo humano elevado no médio prazo.

Na prática, a Axoma já está vivendo esse processo de revisão.

“Quando começamos com Scrum, também tivemos dificuldade com métricas. Elas foram sendo ajustadas conforme o time amadurecia. Agora estamos passando por um processo parecido com a IA.” — Kauan Costa

Neste momento, ainda há mais percepção do que consolidação:

“Existe um feeling de que estamos entregando mais rápido, mas ainda estamos definindo qual é a melhor forma de medir nosso trabalho com a IA.”

O que já está claro é a redistribuição do esforço:

“Estamos passando menos tempo escrevendo código, mas mais tempo em especificação e testes.”

E também uma mudança no foco de qualidade:

“Hoje uma das principais métricas é o que volta de produção — quantidade de bugs e gravidade dos problemas encontrados. E muitas vezes isso está ligado a falhas na especificação inicial.”

Esse ponto conecta diretamente prática e conceito: à medida que o esforço se desloca para a definição, a qualidade da especificação passa a ter impacto direto nos indicadores finais.

O desenvolvedor como orquestrador

Se antes a principal habilidade do desenvolvedor era construir, agora passa a ser orientar, validar e integrar múltiplas saídas geradas por IA. Surge o desenvolvedor-orquestrador: alguém que entende o problema, define o caminho e usa IA como instrumento, não como substituto.

Isso exige um conjunto diferente de competências como capacidade de abstração, pensamento crítico, conhecimento sólido de arquitetura e habilidade de formular boas instruções. A execução pura perde espaço. A responsabilidade estratégica aumenta.

Kauan comenta sobre isso:

“Uma das coisas que estamos trabalhando com a equipe é a importância de entender o produto. A IA ajuda a escrever código, mas não ensina a construir um produto funcional. Isso exige uma mudança de postura. A gente incentiva o time a questionar: por que estamos fazendo isso? Quem vai usar? Qual o impacto? Não é só implementar, é entender o contexto.”

IA não funciona sozinha: o papel do processo

"Um dos aprendizados mais relevantes observados na prática é que a eficácia da IA está diretamente ligada à qualidade do processo em que ela é utilizada", observa Leonardo.

“Todos os desenvolvedores usam IA hoje em dia, mas os que trabalham com specs mais detalhadas têm uma percepção muito mais positiva do que ela consegue fazer.”

Ele traz um caso concreto que ilustra essa relação:

“Tivemos um desenvolvedor que não estava animado com o uso da IA. Ele enfrentava muito retrabalho, inconsistência, código fora do padrão. Quando começou a trabalhar com specs mais estruturadas e ferramentas de apoio a SDD, a percepção mudou completamente.”

Ou seja, a IA não substitui processo,  ela amplifica suas qualidades e suas falhas.

Conclusão: mais do que velocidade, clareza

A gestão de projetos na era da IA não é apenas uma questão de acelerar entregas. Trata-se de uma mudança estrutural na forma como o trabalho é organizado.

Na prática, o que se observa é:

• deslocamento do esforço para especificação e validação

• maior importância da clareza na definição

• necessidade de revisão crítica mais sofisticada

• revisão das métricas tradicionais

A experiência da Axoma mostra que esse processo não é imediato nem linear. Exige experimentação, ajustes e aprendizado contínuo. Mas também aponta para um caminho claro: equipes que conseguem estruturar melhor seus processos, especialmente na definição e no entendimento do problema, tendem a extrair mais valor da IA.

Em um cenário de transformação acelerada, a vantagem competitiva não está apenas em adotar novas ferramentas, mas em saber como integrá-las de forma consistente ao processo.

Mais do que acompanhar a mudança, trata-se de aprender a operá-la com intenção e clareza. É esse movimento que começa a separar organizações que apenas utilizam IA daquelas que, de fato, conseguem transformar sua forma de construir software.