Diagnóstico antes da proposta: o que uma boa proposta de software mostra, e como montamos a nossa com IA
Uma boa proposta de desenvolvimento de software mostra que o fornecedor entendeu o problema antes de orçar: traz diagnóstico com achados medidos e datados, escopo, o que fica fora dele, método, manutenção e uso de IA. A IA pode encurtar a montagem do documento, mas diagnóstico, recomendação e preço continuam decisão de pessoas.
Neste artigo6 partes
Os sinais de uma proposta genérica
Uma proposta genérica é aquela que serviria para qualquer empresa do seu setor com a troca do logo. Ela fala da qualidade do fornecedor, lista serviços e tecnologias, traz prazo e preço, e não diz nada específico sobre o seu problema.
Os sinais costumam ser fáceis de reconhecer quando se sabe o que procurar:
- Escopo vago. Itens como "desenvolvimento do site" ou "integração com sistemas" sem dizer quais páginas, quais sistemas, quais regras.
- Nenhum diagnóstico. A proposta não menciona nada que o fornecedor tenha olhado, medido ou encontrado no seu caso.
- Linguagem de catálogo. Muito adjetivo sobre a empresa, pouca informação sobre o projeto.
- Nada fora do escopo. Se a proposta não diz o que não está incluído, a discussão vai acontecer depois, no meio do projeto.
- O depois não existe. Nenhuma linha sobre o que acontece depois do lançamento.
A proposta genérica não nasce de preguiça, na maior parte das vezes. Nasce de um processo comercial em que montar o documento já toma tanto tempo que não sobra tempo para olhar o caso. O fornecedor reaproveita o modelo anterior, ajusta o nome e o valor e envia. É um problema de processo, e problema de processo tem solução de processo.
Nenhum desses sinais prova que o fornecedor é ruim. Mas todos indicam que ninguém entendeu o problema ainda, e orçamento sem entendimento tende a esconder risco. Esse é um dos critérios do guia sobre como contratar uma software house para um projeto com IA, e talvez o mais fácil de verificar: está no papel que você já recebeu.
Proposta boa mostra que o fornecedor entendeu o problema antes de dar preço. O resto é catálogo.
Compartilhar esta frase
O que um diagnóstico real traz
Um diagnóstico real traz o que o fornecedor olhou, o que mediu e o que encontrou, com data. Ele transforma a proposta de uma promessa em uma leitura do seu caso. E muda a conversa: em vez de discutir opinião, as duas partes discutem evidência.
Na Pocket Lab, toda proposta parte de um diagnóstico do prospect, com prints datados e achados medidos. Não é um relatório de cem páginas. É o suficiente para mostrar o ponto de partida e justificar cada recomendação.
O que se mede e por quê
Mede-se o que sustenta a recomendação. Num site institucional, por exemplo, isso costuma incluir desempenho no celular das páginas principais, erros técnicos que afetam a busca, o caminho de um formulário de contato até quem deveria recebê-lo e a forma como o site é encontrado hoje. Num sistema interno, o foco muda para o processo: quantas etapas manuais existem, onde a informação se perde, quem depende de quem.
A regra é medir o que vai entrar na decisão, e não tudo o que é possível medir. Achado que não muda a recomendação é ruído.
Por que datar o achado
Porque site e sistema mudam. Um problema visto hoje pode ter sido corrigido amanhã, ou piorado. A data registra em que momento o achado era verdadeiro e evita discussão sobre o que "sempre foi assim".
Um diagnóstico também não é auditoria completa nem projeto feito de graça. É uma leitura focada, suficiente para que a recomendação não seja um chute. Quando o problema exige uma investigação maior, como a análise de um sistema legado inteiro, o diagnóstico diz isso com clareza, e a investigação vira a primeira etapa do projeto.
Datar também protege o próprio cliente. Se o projeto for aprovado meses depois, a primeira tarefa é refazer a medição. E, se algo mudou nesse intervalo, a proposta precisa mudar junto.
Como a Pocket passou de semanas para menos de uma hora
O tempo de montar uma proposta comercial na Pocket Lab passou de semanas para menos de uma hora. O ganho não veio de escrever menos nem de pular etapas. Veio de mudar o processo: a IA assumiu a parte operacional, e as pessoas ficaram com o que exige julgamento.
O caminho é este. As reuniões com o prospect são gravadas e transcritas. A transcrição alimenta ferramentas próprias, que organizam o que foi dito e montam a base da proposta e, depois, do case. Uma pessoa revisa tudo antes de sair. É o mesmo raciocínio que aplicamos a qualquer uso de IA, e ele aparece em detalhe no texto sobre onde a IA funciona numa empresa e onde ainda não funciona.
O que a IA faz: transcrição, organização, montagem
A IA transcreve a conversa, separa o que é problema, o que é restrição, o que é dúvida em aberto e o que é próximo passo. Organiza essas informações na estrutura da proposta e monta a primeira versão do texto. É trabalho repetitivo, reversível e revisável, exatamente o perfil de tarefa que entregamos à máquina.
O ganho prático é que ninguém mais começa a proposta de uma página em branco, nem gasta horas relendo anotações soltas para lembrar o que o cliente disse sobre o processo de aprovação interna.
O que continua humano: diagnóstico, recomendação, preço e o não
Quatro coisas nunca saem da IA. O diagnóstico, porque depende de olhar o caso e decidir o que importa. A recomendação, porque envolve contexto de negócio, risco e prioridade. O preço, porque é um compromisso da empresa. E o não: a decisão de recusar um projeto que não vai dar resultado, ou de sugerir um caminho menor e mais simples.
A IA organiza. Quem assina é gente.
O tempo que a máquina devolve vai para essas quatro decisões. É isso que torna possível olhar o caso de cada prospect com atenção, medir o que precisa ser medido e voltar à mesa com uma recomendação que se sustenta. A velocidade da montagem é consequência. O ganho real está em sobrar tempo para pensar.
| Etapa | IA | Pessoa |
|---|---|---|
| Registro da reunião | Transcreve e resume | Confere se o essencial foi captado |
| Organização | Separa problema, restrição e dúvida | Decide o que é prioridade |
| Diagnóstico | Organiza os achados | Escolhe o que medir e interpreta |
| Recomendação | Monta o rascunho do texto | Decide a solução e o escopo |
| Preço e aceite | Nada | Define o valor e decide se vale fazer |
Proposta como página web, e não como PDF genérico
As propostas da Pocket Lab são publicadas como página web, e não como PDF anexado a um e-mail. A escolha tem três motivos práticos.
O primeiro é leitura. Uma página funciona bem no celular, onde boa parte dos decisores lê, e permite navegar direto para a parte que interessa a cada pessoa: o diretor vai ao diagnóstico e ao investimento, o técnico vai ao escopo e à arquitetura.
O segundo é atualização. Se algo muda depois da reunião, a página é atualizada e todos passam a ver a mesma versão. Acabam as cópias desencontradas circulando por e-mail.
O terceiro é evidência. Prints datados, achados medidos e exemplos ficam visíveis ao lado da recomendação que eles sustentam, em vez de escondidos num anexo.
Há ainda um efeito interno. Escrever para uma página que vai ser lida por várias pessoas da empresa do cliente obriga a ser claro. Não dá para esconder um escopo vago atrás de uma diagramação caprichada quando o leitor pode ir direto ao trecho que importa para ele e encontrar ali só generalidade.
O formato não substitui o conteúdo. Uma página bonita com texto genérico continua sendo uma proposta genérica. Mas, quando há diagnóstico real, o formato ajuda a mostrá-lo.
O que pedir numa proposta de software
Peça os itens que permitem comparar fornecedores pelo mesmo critério. Se uma proposta não traz algum deles, pergunte por escrito antes de decidir:
- Diagnóstico do problema. O que foi olhado, medido e encontrado, com data.
- Escopo. O que será entregue, com detalhe suficiente para saber se algo ficou de fora.
- Fora do escopo. O que não está incluído. É ali que mora a maior parte das surpresas.
- Método. Como o projeto será conduzido, em que momentos você aprova e o que é preciso da sua equipe.
- Quem participa. Quem gerencia, quem desenvolve e quem estará nas reuniões.
- Manutenção depois do lançamento. Quem hospeda, quem monitora, quem responde quando algo quebra.
- Uso de IA e revisão. Onde a IA entra no projeto e quem revisa o que vai para produção.
- Propriedade do código. De quem é o código e como é a entrega se o contrato terminar.
Se você recebeu uma proposta que não traz algum desses itens, não descarte o fornecedor por isso. Pergunte. A forma como ele responde, se completa com clareza ou se desvia, já é parte da avaliação.
Com esses oito itens lado a lado, as diferenças entre as propostas aparecem com clareza, e o preço passa a ser comparado com o que ele de fato compra.
Leve para a reunião de apresentação da proposta
- O que vocês olharam e mediram no nosso caso, e quando?
- Qual achado mais pesou na recomendação?
- O que está fora do escopo desta proposta?
- Quem vai gerenciar e quem vai desenvolver o projeto?
- O que acontece depois do lançamento, e quem responde quando algo quebra?
- Onde a IA entra no projeto, e quem revisa o resultado?
- Em que situação vocês recomendariam não fazer este projeto?
Quando não vale a pena usar IA para montar a proposta
A IA ajuda a montar a proposta. Não ajuda em tudo, e há situações em que ela atrapalha:
- Quando o diagnóstico exige presença ou análise técnica. Há projetos em que o essencial não está na conversa: está numa visita à operação, numa leitura de código ou num teste de ambiente. A transcrição não captura isso, e quem confia só nela entrega uma proposta incompleta.
- Quando a proposta sai sem revisão humana. Uma proposta gerada e enviada sem que alguém leia com atenção é um risco comercial e técnico. Pode prometer o que ninguém decidiu prometer.
- Quando a IA decidiria preço, recomendação ou promessa. Esses três itens são compromisso da empresa. Nunca saem da máquina.
- Quando a reunião foi rasa. Se a conversa não chegou ao problema, a IA só vai organizar bem uma informação insuficiente. A resposta certa é marcar outra conversa.
- Quando o projeto não deveria existir. A IA monta qualquer proposta que receber. Decidir que o melhor é não fazer, ou fazer algo menor, é trabalho de gente.
Teste as propostas que sua empresa recebeu: marque o que vale para elas
Marque os itens. O resultado aparece aqui.
Recusar trabalho que não vai dar resultado é parte de como trabalhamos, e isso começa na proposta. Se a sua empresa está recebendo propostas agora, conheça como trabalha a Software House da Pocket Lab e peça a ela o mesmo diagnóstico que você deveria pedir a qualquer fornecedor.
Perguntas frequentes
O que uma proposta de desenvolvimento de software deve conter?
Diagnóstico do problema, escopo e o que está fora dele, método, quem participa, manutenção depois do lançamento, uso de IA e revisão, e propriedade do código.
Por que o diagnóstico vem antes do orçamento?
Porque o orçamento feito sem entendimento do problema tende a esconder risco e a gerar mudança de escopo no meio do projeto.
A IA pode montar a proposta inteira?
Pode montar a base. Diagnóstico, recomendação, preço e a decisão de recusar o que não vai funcionar seguem com pessoas.
Este artigo foi útil?
Quem escreveu
Vinícius Mont SerratCofundador e diretor executivo da Pocket Lab
Trabalha com internet desde 2008. Na Pocket Lab, responde pela estratégia, pelas grandes contas e pela Software House. Texto com revisão técnica do time.