Criando um Modelo de Precificação de Software com IA e Vibe Coding

Há alguns meses, nos cobraram um sistema de precificação de software, com gestão de custos e de usuários. Basicamente, para descobrir se o resultado compensa o custo. Nós nunca tínhamos feito nada parecido, então dei uma vasculhada na internet para encontrar boas práticas. Infelizmente achei muitos caminhos, sem ter certeza de qual seria o melhor a seguir. Ia desde contagens de ponto por função até custo por entrega, passando por alguns que tinham timesheet (eu jurava que isso não existia mais). Vi que a maioria não era muito compatível com o que nós fazíamos; então resolvi bater um papo com a IA para descobrirmos o que nos dava melhor. 

O prompt para criação do modelo de precificação

Comecei a conversa com o Grok apresentando exatamente o meu problema e pedindo soluções possíveis. Eis o prompt (senta que lá vem história):

Olá, somos a Coordenadoria de Soluções Corporativas do TRE-RJ e temos o seguinte desafio: precisamos precificar o custo de desenvolvimento de software para gestão e auditoria do CNJ. As regras iniciais estão no processo anexo. Nós utilizamos o desenvolvimento ágil de software, com alguns times praticando Kanban e outros, Scrum com Kanban. Os times são estáveis e de longa duração, compostos por um número variável de desenvolvedores que atuam em um projeto de cada vez. Além disso, 1 Product Owner e 1 Scrum Master, que, em algumas ocasiões, podem ser compartilhados entre mais de um time. Além disso, é importante frisar que esses desenvolvedores são responsáveis por manter o software que já desenvolveram, tendo que realizar manutenções nele quando solicitadas. 

Fazemos a gestão de nossos projetos com um relatório automatizado para o público externo à coordenadoria, por meio do software Task Tabulo, que registra o time, a data de início e a última entrega do projeto antes de ele entrar em manutenção evolutiva. A gestão da criação do produto é feita no Taiga.io e temos acesso à base de dados para consulta. A gestão de manutenções corretivas e evolutivas está no 4Biz. Também temos acesso à base de dados. Também temos acesso à consulta dos salários pagos a cada pessoa, mês a mês. Esse método de gestão de custos não deve ser rígido e deve ser 100% automatizado. Não quero nem apertar um botão. Quero agendar um script que gere o resultado para nós.

Modelo sugerido

Fizemos algumas interações  e, resumidamente, o modelo foi: com base no rendimento bruto mensal de cada pessoa. Quebrar em 30 dias de trabalho para obter o valor diário. Com base no Taiga, contabilizar a quantidade de dias, o número de desenvolvedores e o salário diário necessários para realizar cada entrega, considerando que é possível que haja, embora não seja desejado, paralelismo entre as entregas. Nesse caso, o valor é rateado em partes iguais para facilitar o cálculo. Caso contrário, o desenvolvedor teria que ficar dizendo se trabalhou 20% do tempo no item A, 30% no item B, e isso acrescentaria uma carga administrativa indesejada para os desenvolvedores. O custo dos demais papéis (PO, SM) é rateado pela quantidade de projetos em que atuam simultaneamente.

Já as manutenções foram divididas em três tipos. Evolutivas grandes, menores e corretivas. As grandes evolutivas têm o mesmo tratamento que os projetos e, portanto, seguem o mesmo rito de cálculo. As evolutivas menores e as corretivas utilizaram os percentis de tempo de entrega que já medíamos no passado. Com base no percentil 85 (85% das entregas levaram esse tempo ou menos). As evoluções menores são entregues em 2,3 dias (arredondamos para três) e as correções em três horas. 

Vamos implementar com Vibe Coding

Uma vez que o modelo foi definido, precisamos construir a solução. Pedi para o Grok resumir a nossa conversa sem resumir o modelo final que nós criamos. Abri o Trae e colei a conversa. completa. Pedi para criar um software que, primeiramente, agrupasse todas as informações em um único banco de dados, o Oracle. Passei para eles todas as consultas que eu já tinha e que estavam disponíveis. Aquelas que eu não tinha, fui passando o DDL das tabelas e das views para ele me ajudar a montar as consultas.

Também pedi ao Trae que gerasse os DDLs de criação de tabelas para armazenar os dados que estávamos trazendo de várias tabelas. Ele criou todas as tabelas; por questões de segurança, eu executei os scripts de criação, porém, sem fazer nenhuma alteração nas tabelas.

Ele também criou os módulos de importação de dados acessando tanto o PostgreSQL quanto o Oracle. Após isso, criou todos os métodos necessários para o cálculo de custos. Ele fez em Python, porém, por regras da organização, tive que pedir que ele convertesse tudo para PL/SQL. Então fizemos alguns ajustes nas tabelas e nas consultas, porém, rapidamente, a calculadora voltou a funcionar. Por fim, como há importação de múltiplos bancos, ele criou um Jenkins Pipeline para realizar as importações e disparar o PL/SQL de cálculo.

Quanto tempo levou para criar o modelo e o sistema de precificação, do zero, até o problema ser resolvido?

Quatro dias de uma pessoa que não teve dedicação exclusiva para isso. Tive que participar de reuniões, resolver diversos processos administrativos (obrigado, Gemini, por todo o apoio) e acompanhar todos os times e as demandas dos clientes.

Quantas linhas de código eu escrevi?

Com exceção das consultas que eu já tinha por outros motivos, zero. Obviamente, meu conhecimento em codificação ajudou a verificar e direcionar o Trae pelos melhores caminhos. Mas, realmente, as únicas coisas que eu fiquei fazendo foram copiar e colar DDL e informar sobre o acesso seguro aos bancos de dados. Fora isso, não encostei a mão no código.

Testes e Qualidade

Quando foi a hora de testar e garantir a qualidade do produto, adivinhem o que eu fiz? Pedi à IA que gerasse os testes unitários e de integração. Essa foi a parte em que eu mais olhei o código para verificar se os testes eram satisfatórios e cobriam bem todos os casos possíveis. Pedi para ele incluir o coverage.py para ter uma ideia da cobertura de testes.

Performance

Pedi para incluir marcações de tempo na importação. No geral, cada execução ficava abaixo de 2 segundos. Com exceção de uma consulta que levou 2m50s. Fiquei esmerilhando essa consulta com o Trae até reduzi-la a 2 minutos. Depois, ele sugeriu a criação de índices, o que reduziu para 1m14s. Não é o ideal, mas já está bom o suficiente, afinal , é uma redução de mais de 50%.

Surpresa com Vibe Coding

Além de criar o produto, tive uma grata surpresa com as sugestões do Trae. Ele fez algumas sugestões que achei relevantes; poderão entrar no backlog que ele mesmo irá desenvolver. Dentre elas:

  • Registrar em uma tabela específica todas as interrupções de projetos (início e fim da interrupção), quantas houver
  • Impedir ou solicitar confirmação para que a pessoa ocupe múltiplos papéis, por exemplo, o de Product Owner e o de Desenvolvedor. Avaliamos o histórico e havia algumas distorções nesse sentido.
  • Criação de papéis de trabalho parciais: pessoas que atuam em um momento específico do projeto e depois saem. Por exemplo, DBAs.

Resultado da precificação com vibe coding

Já temos uma parte do nosso modelo de precificação para o que já fizemos. O próximo passo é estimar a precificação do que vamos fazer, com base no nosso histórico. 

Fluxograma do modelo de precificação de software mostrando como o salário bruto diário é distribuído entre construção, pequenas evoluções e manutenções para calcular o custo final do produto.
Fluxo de cálculo do custo do produto, considerando a criação, a evolução e a manutenção contínuas.

Optamos por incluir o custo de manutenção na precificação do produto, pois a ideia é a gestão de custos e a auditoria. Se fosse venda, obviamente não consideraríamos, uma vez que o custo de manutenção é o custo do erro e o cliente não deveria pagar por ele.

Principais vantagens desse modelo de precificação

Alinhamento com o modo de trabalho real

Não tentamos “encaixar” a organização em um método externo como ponto de função, COSMIC etc. Afinal, o modelo parte do fluxo real de entrega, da configuração dos times e da responsabilidade contínua pela manutenção. Isso reduz o ruído e a resistência cultural.

Custo baseado em tempo de fluxo real (e não estimativa subjetiva)

Ao usar rendimento bruto mensal → dia → distribuição automática por item entregue, evitamos: timesheet e subjetividade (“acho que passei 20% no item”), reduzimos a carga cognitiva nos times e aumentamos a acurácia e a auditabilidade, pois é um custo ex-post (real), não ex-ante (chute).

Manutenções classificadas por tempo histórico (Percentil 85)

Sair do achismo para algo real. Isso cria: previsibilidade; repetibilidade; estabilidade na comunicação com a auditoria e com a CNJ; base para estimar a capacidade futura; e sem pedir esforço extra a ninguém, pois já temos o valor.

Precificação utiliza integração contínua com as ferramentas existentes

Usar:

  • Taiga (desenvolvimento)
  • 4Biz (manutenção)
  • Task Tabulo (gestão dos grandes marcos)
  • Folha de pagamento
  • Jenkins (servidor de integração) + PL/SQL para cálculo

Isso significa que não tivemos planilhas paralelas, sem retrabalho, sem duplicação de fontes de verdade e sem dependência da memória das pessoas.

Transparência e auditabilidade

  • Cada valor pode ser rastreado:
  • Quem estava no time?
  • Quanto custava aquela pessoa naquele mês?
  • Quanto tempo durou aquela entrega?
  • Quais papéis estavam envolvidos?

Em outras palavras, é ideal para TCU, CNJ, auditorias internas e para prestação transparente à sociedade.

Conclusão

Imagem mostrando as ferramentas utilizadas no processo: Grok para ideação e Trae com Python para codificação.
Ferramentas utilizadas na ideação e no desenvolvimento da solução. Python foi apenas uma escolha por familiaridade minha.

Em resumo, desenvolvemos um modelo de precificação Scrum/Kanban totalmente alinhado ao nosso modo de trabalho, baseado em dados reais de fluxo, custo total de propriedade, capacidade dos times e estabilidade operacional. A Inteligência Artificial participou ativamente de todo o processo, desde a definição conceitual do modelo até a implementação do produto, utilizando Vibe Coding para gerar consultas, DDLs, integrações e rotinas automatizadas de cálculo, o que reduziu o esforço manual e acelerou a entrega em ritmo absurdo. O resultado é um produto vivo, auditável e evolutivo, que consolida nossa governança financeira em um patamar de maturidade entre ML3 e ML4 no Kanban Maturity Model, fortalecendo nossa tomada de decisão de portfólio e preparando o caminho para estimativas cada vez mais precisas.

 

Quer aprender mais sobre como utilizar IA na gestão do produto

Product AI

Agora, se você quiser aprender mais sobre Vibe Coding e como tirar o melhor proveito dela para criar produtos incríveis do zero até o app, sem saber codificar. Dá uma olhada nesse treinamento aqui:

Vibe Coding com Lovable & Skip

Tem uma dica incrível sobre integração da sua aplicação com IA através de vibe coding nesse artigo aqui: Vibe coding acaba com o terror de integrar sua aplicação com IA. Boa leitura.

Se quiser ver como a IA está mudando o mundo de desenvolvimento de software, veja esse artigo: A Inteligência Artificial mudou todo o mercado; tudo o que tínhamos no passado deixou de servir. Cuidado, pode ser você.

Avelino Ferreira Gomes Filho
Sobre o autor

Avelino Ferreira Gomes Filho

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Clique aqui para baixar PDF do Test Card 2.0 formato retrato PDF do Test Card 2.0 formato paisagem Imagem do Test Card 2.0 no formato retrato Imagem do Test Card 2.0 no formato paisagem Você trabalha com desenvolvimento de produtos….

Marcos Garrido, Sócio-fundador e Trainer na K21

O Usage-Driven Development (UDD) não é uma metodologia cheia de cerimônias e artefatos. É o nosso jeito, aqui na Nower/K21, de pensar produto na era da Inteligência Artificial (IA). E, como todo jeito de pensar, ele se sustenta em princípios:…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Existem organizações que parecem funcionar. Tudo acontece dentro da “normalidade”. Projetos são entregues, reuniões acontecem, relatórios circulam e indicadores são apresentados. Mesmo assim, há um cansaço estrutural no ar. As pessoas já estão tão cansadas de matar um leão por…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Lidar com pessoas difíceis jamais será fácil. Elas podem ser clientes, gestores, colegas ou até mesmo seus pares. Elas vêm em diferentes formas e atrapalham nossa vida e estragam o ambiente para toda a equipe. É ruim. É chato, porém…