Antes de aprovar o orçamento, rode o processo na mão
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.
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. 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, 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: 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, 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, 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 é uma conversa de 30 minutos sobre a sua operação, sem compromisso.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem compromisso.
Agendar diagnóstico