Já recebi muita solicitação de orçamento que chega com “quero um sistema de gestão”. Só isso. Às vezes uma segunda linha: “igual ao que tem no mercado mas personalizado pra mim”.
O desenvolvedor que aceita esse briefing sem mais perguntas vai te dar um número que não tem relação com o que você precisa. E o projeto vai virar uma série interminável de reuniões onde você vai percebendo, devagar e com dinheiro gasto, que o que foi construído não era o que você imaginava.
Não é desonestidade. É ausência de especificação.
O que é uma especificação, sem enrolação
Não é um documento de 80 páginas com diagramas e linguagem técnica. É o suficiente para um desenvolvedor entender o que precisa ser construído, por quem vai ser usado e o que acontece quando algo dá errado.
Simples assim. Mas chegar lá exige trabalho que a maioria das pessoas não faz antes de ligar pra um desenvolvedor.
Tem uma crença comum de que especificar é responsabilidade de quem vai construir. “Eu explico o problema, ele descobre o que precisa fazer.” Funciona em alguns contextos, principalmente quando você tem um time interno com conhecimento do negócio. Quando você está contratando alguém de fora, seja pessoa física ou empresa, a falta de especificação tem um custo muito específico: tudo vira escopo a interpretar, e interpretações diferentes custam dinheiro e prazo.
Onde a maioria das pessoas começa errado
Começam pela solução.
“Quero um sistema com tela de cadastro, dashboard com gráficos, relatório em PDF e integração com o Mercado Pago.”
Tudo bem, mas quem vai usar esse cadastro? Com que frequência? O que acontece depois que alguém se cadastra? O dashboard é pra quem toma decisão ou pra quem opera? O relatório é enviado por e-mail, gerado sob demanda ou exportado em lote?
Quando você começa pela lista de funcionalidades sem ter mapeado o processo antes, você descreve o que acha que precisa, não o que de fato vai resolver o problema. Já vi sistema entregue no prazo, dentro do orçamento, com todas as funcionalidades listadas, que nunca foi usado porque o fluxo não fazia sentido pra como a empresa trabalhava de verdade.
O que precisa estar no papel antes de contratar
Processo vem primeiro. Antes de qualquer funcionalidade, documente o que acontece hoje sem sistema. Quem faz o quê, em que ordem, onde tem gargalo, onde tem retrabalho. Não precisa ser bonito nem formatado. Uma lista de etapas em sequência já ajuda mais do que uma wireframe bem desenhada sem processo por trás.
Depois, usuários. Quem vai usar o sistema? São funcionários internos ou clientes externos? Uma pessoa ou duzentas? Isso muda arquitetura, muda custo, muda absolutamente tudo. Um sistema que vai ser acessado por 5 pessoas da equipe interna é um projeto diferente de um que vai ser acessado por 500 clientes simultâneos. Se você não sabe o volume, estima com honestidade. Estimativa honesta é mais útil do que deixar em aberto.
Aí vêm as integrações. Com que sistemas o seu precisa conversar? Planilha que existe hoje, ERP já instalado, API de pagamento, e-mail marketing, qualquer coisa. Toda integração tem um custo de desenvolvimento e um custo de manutenção que raramente entra no orçamento quando não está na especificação.
Regras de negócio. Esse é o ponto mais difícil e mais importante. Regra de negócio é o que não é óbvio pra um desenvolvedor que não conhece a sua operação. Desconto acima de 15% precisa de aprovação do gerente. Pedido cancelado depois de 48 horas tem multa de 10%. Fornecedor com inadimplência não aparece como opção no cadastro de compras. Essas regras existem na cabeça das pessoas que trabalham com você. Às vezes nas cabeças delas apenas, nunca escritas em lugar nenhum.
Se as regras de negócio não estiverem documentadas, o sistema vai ser construído sem elas. E você vai descobrir na hora de usar.
O que você não precisa decidir antes
Tecnologia. Laravel, React, Node, Python, banco relacional ou não. Você não precisa saber isso antes. Você precisa de alguém que indique o que faz mais sentido pra sua situação, não de uma lista de tecnologias no briefing. Especificação focada em tecnologia antes de entender o problema é sinal de que o processo está invertido.
Aliás, isso acontece com frequência quando a empresa tem alguém interno com conhecimento técnico superficial. A pessoa sabe nomes de tecnologia mas não sabe especificar o problema. Aí o briefing chega cheio de siglas e vazio de processo. É um dos briefings mais difíceis de trabalhar.
Design de interface detalhado também não precisa estar resolvido antes. Um esboço do fluxo em papel ou numa apresentação qualquer é suficiente. Detalhes visuais finos vêm depois, quando você já entendeu com o desenvolvedor o que vai ser construído de fato.
Um sinal de que você está no caminho certo
Quando você consegue sentar com alguém da sua equipe e explicar o sistema sem falar em tecnologia, e a pessoa consegue entender o que vai mudar no trabalho dela, a especificação está boa.
Olha, isso é menos comum do que parece. A maioria das pessoas que chega pra contratar desenvolvimento sabe o que quer no final, mas não consegue articular o caminho do que existe hoje até lá. Preencher essa lacuna antes de contratar é o trabalho que pouca gente faz e que salva projetos inteiros.
O que acontece quando você não faz isso
Escopo cresce. Toda reunião traz uma funcionalidade nova que parecia óbvia mas não estava especificada. O desenvolvedor cobra extra, ou absorve e fica insatisfeito, ou entrega sem a funcionalidade e você fica insatisfeito. Ninguém ganha.
Prazo estica. É consequência direta do escopo crescendo no meio do projeto. Você começa a negociar o que entra e o que fica pra depois, e o “depois” vira outro projeto, outro contrato, outra rodada de orçamento.
E o pior: você entrega um sistema que tecnicamente funciona mas que não resolve o problema original porque o problema nunca foi documentado claramente. Já vi isso acontecer com projetos de seis meses, com investimento relevante, onde o resultado final não era mais útil do que uma planilha bem organizada teria sido.
Por que acontece? Porque durante o desenvolvimento, quando o problema aparece, já existe pressão de prazo, já existe expectativa criada, já existe dinheiro comprometido. Mudar de direção nesse ponto custa muito mais do que teria custado no início.
Especificar é trabalho. Mas é trabalho que você faz uma vez, antes de contratar. A alternativa é fazer esse mesmo trabalho fragmentado, mais caro, durante o desenvolvimento, com um desenvolvedor esperando decisão e o relógio girando.
Sinceramente, essa conversa de “o que você quer de fato” é a parte mais importante de qualquer projeto. E ela quase nunca acontece antes do contrato ser assinado.
Esse é o tipo de conversa que tenho antes de fechar qualquer projeto. Se você está planejando contratar desenvolvimento e quer entender o que precisa estar resolvido antes de começar, entra em contato pelo gabriels.dev.br.