“Quanto custa um sistema para a minha empresa?” É uma pergunta legítima, e quase impossível de responder bem.
Não por falta de vontade, mas porque “um sistema” pode significar coisas muito diferentes. Um cadastro com três telas e um fluxo de aprovação com dez integrações são, ambos, “um sistema”. Sem entender o problema, qualquer número é um palpite. E orçamento baseado em palpite costuma virar aditivo, atraso ou uma solução que não resolve o que precisava.
Sintoma não é causa
Muitos pedidos chegam descritos pela solução que a pessoa imagina: “precisamos de um aplicativo”, “queremos um portal”, “precisamos de um chatbot”. Por trás de cada um existe um problema, e nem sempre é o que parece.
- A equipe que pede um aplicativo pode estar sofrendo, na verdade, com informações que não chegam a tempo.
- O portal pode ser uma forma de reduzir o volume de pedidos repetitivos por e-mail.
- O chatbot pode estar tentando compensar um processo de atendimento que ninguém mapeou.
Separar sintoma de causa é o que evita construir a coisa certa para o problema errado.
As perguntas que vêm antes do escopo
Antes de falar em telas, tecnologia ou prazo, estas perguntas ajudam a entender o que realmente precisa mudar:
- Quem usa? Quem são as pessoas envolvidas e o que cada uma precisa fazer?
- O que precisa acontecer? Qual ação ou resultado o negócio espera?
- Como funciona hoje? Passo a passo, com as planilhas, os e-mails e os improvisos.
- O que dá errado? Onde estão os atrasos, os erros e o retrabalho?
- Quais sistemas participam? O que já existe e precisa continuar funcionando?
- Como vamos saber que deu certo? Qual critério faria alguém dizer “resolveu”?
Nenhuma dessas perguntas exige conhecimento técnico. Todas exigem conhecimento do negócio, que é exatamente o que a empresa tem.
Do contexto ao escopo
Com as respostas, o problema começa a ganhar forma:
- Problema definido: o que precisa mudar, em uma ou duas frases.
- Objetivo: o resultado esperado, em linguagem de negócio.
- Critérios de sucesso: como medir se funcionou.
- Escopo mínimo: a menor versão que resolve o problema principal, deixando o resto para depois.
Só a partir daí um orçamento passa a ter base. E o escopo costuma encolher, porque deixa de incluir o que não era necessário.
O que um bom diagnóstico entrega
Quando o problema é mais difuso (vários sistemas, várias áreas, prioridades em disputa), vale um diagnóstico estruturado antes de qualquer proposta de construção. O resultado não é um relatório genérico, e sim um mapa de oportunidades com:
- contexto;
- problemas observados;
- impacto potencial;
- oportunidades;
- dependências;
- prioridades;
- próximos passos recomendados.
Com esse mapa, a empresa decide o que construir primeiro, e com quem.
Como se preparar para a primeira conversa
Você não precisa de briefing nem de especificação técnica. Ajuda muito trazer:
- exemplos reais: a planilha, o print da tela, o e-mail que sempre gera confusão;
- números que você já tem: volume de pedidos, horas gastas, prazos que estouram, sem precisar calcular nada novo;
- as pessoas certas: alguém que decide e alguém que vive o problema no dia a dia;
- o que já foi tentado, e por que não funcionou.
Com isso, a conversa sai do “quanto custa” e chega ao “o que precisa mudar”. É dessa pergunta que nascem boas soluções, e orçamentos que não se desfazem no meio do projeto.
Quando o problema ainda não está claro, começamos pelo Cloudbe Assessment. Quando a necessidade já está definida e nenhuma ferramenta pronta resolve, o caminho é Digital Products.
