# Antes de aprovar o orçamento, rode o processo na mão > Recebeu o orçamento do sistema? Rode o processo manualmente por três semanas antes de assinar. O registro do teste vira a especificação do software. - Autor: Marlon Trettin - Publicado: 2026-07-27 · Atualizado: 2026-08-29 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/validar-processo-antes-de-aprovar-orcamento --- O orçamento do sistema está na sua mesa e a pergunta é se aprova. Antes de assinar, rode o processo manualmente com clientes reais por duas a quatro semanas. Planilha, formulário e mensagem bastam. O que sair dali não é só um sim ou não: é a especificação do software que você ia encomendar no escuro. ## TL;DR - A Pendo analisou o uso real de 615 produtos e encontrou [80% das funcionalidades raramente ou nunca usadas](https://www.pendo.io/resources/the-2019-feature-adoption-report/). Escopo definido em reunião produz sobra; escopo definido por uso real, não. - O orçamento responde quanto custa construir. Não responde o que construir, e é essa a pergunta que o teste manual fecha. - Rodar o processo na mão custa semanas de uma pessoa e devolve três coisas: demanda medida, exceções mapeadas e o registro que vira especificação. - O teste valida demanda e fluxo. Não valida escala, segurança nem integração — essas chegam depois, e são decisões de arquitetura. ## Por que tanto software nasce para ninguém usar? Porque a decisão de construir costuma vir antes da evidência. A Pendo, plataforma de análise de uso de produtos, estudou 615 softwares em operação e concluiu que [80% das funcionalidades do produto médio raramente ou nunca são usadas](https://www.pendo.io/resources/the-2019-feature-adoption-report/). Pelo cálculo do mesmo estudo, só as empresas de nuvem de capital aberto investiram até US$ 29,5 bilhões nessas funcionalidades. O levantamento é de 2019 e virou referência do setor justamente porque o padrão não mudou: quem define escopo por intuição constrói sobras. O mecanismo é o mesmo dentro de uma empresa que já fatura. A lista de requisitos sai de uma reunião com quem imagina o processo, não com quem o executa. O fornecedor orça o que a lista pede, entrega o que foi orçado, e as telas que ninguém abre já estavam no escopo aprovado. Você não tem um problema de tecnologia. Tem um problema de arquitetura da decisão: falta o passo entre "queremos um sistema" e "eis o que ele precisa fazer", e nenhum orçamento preenche essa lacuna. ## O que o orçamento não responde Um orçamento responde quanto custa construir aquilo. Não responde se aquilo é o que a operação precisa. Três perguntas ficam abertas, e nenhuma delas se resolve pedindo uma proposta mais detalhada. A primeira: o problema incomoda o suficiente para alguém mudar de comportamento? A segunda: quem vai usar aceita o fluxo que o sistema impõe, ou vai contorná-lo na primeira semana? A terceira: o fluxo se sustenta com as exceções e as pressas do dia a dia, ou só funciona no caminho feliz que alguém desenhou no slide? Repare no que essas perguntas têm em comum: nenhuma exige software para ser respondida. Exigem usuários reais, um processo desenhado e alguém disposto a operar esse processo por algumas semanas. ## Como validar sem escrever uma linha de código? Rodando o processo na mão, como se o sistema já existisse. O pedido chega pelo canal que o cliente já usa, alguém registra na planilha, o retorno sai por e-mail. Por trás do balcão é trabalho manual; para quem está do outro lado, é o serviço funcionando. Esse formato tem nome em gestão de produto, teste concierge, e cabe em qualquer empresa de médio porte: a infraestrutura necessária já está no seu negócio hoje. A base digital, aliás, já existe na maioria delas: [47% dos pequenos negócios brasileiros usam softwares de gestão](https://agenciasebrae.com.br/inovacao-e-tecnologia/digitalizacao-recorde-pequenos-negocios-no-brasil-atingem-nivel-historico-em-2025/), vinte pontos percentuais acima de 2018, segundo o Sebrae. Duas regras mantêm o teste honesto. Primeira: rode com quem vai usar de verdade, não com a equipe do projeto. Interesse declarado não é adesão. Segunda: registre tudo, do pedido que entrou à pergunta que apareceu duas vezes. Esse registro é o subproduto mais valioso do teste, porque a versão manual do processo é o rascunho da arquitetura do sistema. As exceções que apareceram na semana dois são exatamente as que derrubariam o software na semana dois de produção. Há um limite que precisa ficar claro: o teste manual valida demanda e fluxo. Não valida escala, segurança nem integração com o que você já usa. Essas perguntas chegam depois, e são perguntas de arquitetura. ## Quando o processo merece virar sistema? Quando a operação manual passa a doer por excesso de demanda, não por falta dela. Três sinais costumam aparecer juntos: você já não dá conta do volume na mão, o ganho medido cobre uma fração relevante do orçamento na mesa, e o fluxo parou de mudar toda semana. Nesse ponto, o desenvolvimento deixa de ser aposta. Ele automatiza um processo que já se provou, com escopo definido pelo que as pessoas de fato usaram. Esse é também o momento de decidir o tamanho do próximo passo. Quando o processo se provou mas você ainda quer testar a solução antes de construí-la inteira, o degrau seguinte é a [prototipagem rápida](/blog/prototipagem-rapida-validar-antes-de-investir): em vez de não construir nada, você constrói pequeno de verdade, com hipótese e critério de sucesso escritos. Teste manual e protótipo respondem perguntas diferentes, e nessa ordem. O caminho vale para produto novo e para sistema interno. O [Nuleite](/cases/nuleite), ferramenta de controle de custos para produtores de leite, nasceu com escopo enxuto e cresceu sobre demanda observada, não sobre uma lista de funcionalidades especulativas. Na [SuperVida](/cases/super-vida), a gestão de contratos rodava numa base improvisada em Airtable, e foram justamente os dados e os fluxos que já rodavam ali que definiram o ERP sob medida que veio depois. O contraste com o dado da Pendo é direto: escopo definido por uso real é o antídoto para os 80% de funcionalidades que ninguém abre. ## Como isso funciona na prática? Um cenário hipotético, construído sobre situações que se repetem. Uma distribuidora de materiais elétricos com faturamento de R$ 600 mil por mês recebeu o orçamento de um portal de pedidos para os 90 clientes de revenda. O número assusta, e o dono decide testar antes: durante três semanas, envia o catálogo em PDF com um formulário simples de pedido para 15 clientes selecionados e registra tudo em uma planilha. O resultado muda o projeto. Os pedidos pelo formulário até funcionam, mas as mensagens que chegam junto revelam outra dor: os clientes perguntam duas vezes mais sobre saldo em aberto e status de entrega do que sobre produtos. O portal orçado era um catálogo; o portal necessário é uma central de autosserviço com posição financeira e rastreio. O dono descobriu isso por três semanas de trabalho de uma pessoa, não pelo preço do sistema errado construído inteiro. E o orçamento seguinte foi outro documento. Em vez de uma lista de telas imaginadas, ele descrevia um fluxo observado, com as exceções que apareceram no teste. A conversa com o fornecedor deixou de ser sobre o que a empresa achava que queria. ## Perguntas frequentes **Como saber se o investimento em sistema vai ter retorno?** O teste manual entrega os números que faltavam para essa conta. Depois dele, você sabe quantas pessoas usam, com que frequência, e quantas horas o processo consome na mão. O retorno deixa de ser projeção de fornecedor e passa a ser cálculo sobre dados da sua própria operação. **Minha equipe vive de planilhas. Isso atrapalha o teste?** Ajuda. A planilha é o instrumento natural do teste manual: registra o fluxo e expõe as exceções, sem exigir treinamento de ninguém. E como quem opera participa desde o primeiro dia, a resistência clássica ao sistema novo diminui, porque o sistema nasce do processo que a equipe mesma rodou. **Não tenho equipe técnica. Consigo fazer isso mesmo assim?** Consegue, porque o teste não pede código, pede método. O que ele produz, registro do fluxo, exceções mapeadas e demanda medida, é a matéria-prima que qualquer caminho técnico posterior vai usar. Chegar à conversa com o fornecedor com o processo documentado reduz o custo de todas as opções. ## O próximo passo depois do teste Se o processo passou no teste manual, a pergunta muda: deixa de ser "vale construir?" e vira "o que construir primeiro, e sobre qual base?". Essa é uma decisão de arquitetura, e é onde a maioria dos projetos validados ainda tropeça. Se quiser examinar esse desenho com quem faz isso há 25 anos, o [Diagnóstico de Arquitetura Operacional](/contato) é uma conversa de 30 minutos sobre a sua operação, sem compromisso.