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.

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

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
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
