O que definir antes de desenvolver um sistema sob medida

Pedir orçamento de um sistema sob medida sem preparação costuma gerar duas situações ruins. Na primeira, cada fornecedor imagina um projeto diferente e os valores variam tanto que não dá para comparar. Na segunda, o orçamento é fechado com base em suposições e, no meio do projeto, aparecem regras e exceções que ninguém tinha mencionado, com impacto em prazo e custo.

Nenhuma das duas situações é culpa de um lado só. O fornecedor precisa de informação para estimar, e a empresa nem sempre sabe que informação é essa. Este artigo organiza o que vale definir antes do primeiro orçamento. Não é preciso ter um documento técnico: é preciso clareza sobre o processo, as regras, as pessoas e os dados envolvidos.

Por que a definição pesa tanto no resultado do projeto?

A gestão de requisitos é uma das causas mais citadas de projetos que não atingem seus objetivos. Em estudo do PMI (Project Management Institute) dedicado ao tema, quase metade (47%) dos projetos que não cumpriram suas metas teve como causa principal a gestão inadequada de requisitos (PMI, 2014). Em outras palavras: muitos projetos falham não porque a equipe técnica errou, mas porque o que deveria ser construído não estava claro.

Existe também o risco oposto: construir coisas demais. Um levantamento da Pendo, empresa de análise de uso de software, examinou 615 produtos e concluiu que 80% das funcionalidades de um software típico são raramente ou nunca usadas; em média, 12% das funcionalidades concentram 80% do uso diário (Pendo, 2019). O estudo trata de produtos digitais em geral, mas a lição vale para sistemas internos: escopo que não nasce de necessidades reais vira custo sem retorno.

As duas pesquisas apontam para a mesma direção. Definir bem não é burocracia: é a forma mais barata de evitar retrabalho e de concentrar o investimento no que a operação vai de fato usar.

1. Como o processo funciona hoje?

Descreva o processo atual, mesmo que ele seja feito em planilha, papel ou mensagem. O sistema novo vai substituir ou apoiar essa rotina, e entender como ela funciona é o ponto de partida de qualquer estimativa.

• Onde o processo começa? Um pedido, uma solicitação, um contrato, um chamado?
• Quais são as etapas, na ordem em que acontecem?
• Quem executa cada etapa e quem aprova?
• Quais documentos ou informações entram e saem em cada etapa?
• Onde o processo termina e como se sabe que terminou?

Um fluxograma simples, desenhado em uma folha ou em uma ferramenta gratuita, já ajuda muito. Não precisa seguir nenhuma notação formal: caixas para etapas, setas para a sequência e o nome de quem faz.

Separe o processo atual do processo desejado

É comum misturar o que acontece hoje com o que se gostaria que acontecesse. Mantenha os dois separados. O processo atual mostra a realidade, com seus atalhos e problemas. O processo desejado mostra a intenção. A diferença entre eles é o que o sistema precisa resolver, e é isso que o fornecedor precisa enxergar.

2. Quais são as regras e as exceções?

As regras definem o comportamento do sistema. São elas que mais impactam o esforço de desenvolvimento, e são as que mais costumam ficar de fora da conversa inicial porque parecem óbvias para quem vive a rotina.

• Regras de cálculo: preços, descontos, impostos, comissões, prazos.
• Regras de aprovação: quem aprova o quê, a partir de qual valor, em qual ordem.
• Regras de validação: o que não pode ser registrado, quais campos são obrigatórios.
• Regras de prazo: o que acontece quando algo atrasa, quem é avisado.

Depois das regras, liste as exceções. Pergunte à equipe: "o que acontece quando o caso foge do normal?". Pedido parcial, cliente com condição especial, devolução, cancelamento depois de aprovado, item sem cadastro. Cada exceção é uma regra adicional. Não é preciso resolver todas na primeira versão, mas é preciso saber que existem.

3. Quem vai usar o sistema, e com que permissões?

Liste quem vai usar o sistema e o que cada perfil precisa fazer. O número de perfis e a complexidade das permissões afetam diretamente o escopo.

• Quem registra informações?
• Quem apenas consulta?
• Quem aprova ou altera depois de registrado?
• Quem administra cadastros e configurações?
• Existem usuários externos, como clientes, fornecedores ou representantes?
• As pessoas usam o sistema no escritório, em campo, pelo celular?

Indique também quantas pessoas, aproximadamente, usam cada perfil. Dez usuários internos e quinhentos clientes externos são projetos muito diferentes em termos de suporte, segurança e infraestrutura.

4. Quais dados já existem?

Quase nenhum sistema começa do zero. Informe quais dados já existem e onde estão, porque migração e integração podem representar uma parte grande do trabalho.

• Cadastros que precisarão ser migrados: clientes, produtos, fornecedores, contratos.
• Histórico que precisa continuar acessível: pedidos antigos, atendimentos, documentos.
• Em que formato estão: planilhas, outro sistema, papel digitalizado.
• Qual a qualidade desses dados: há duplicados, campos vazios, padrões diferentes?

Integrações com outros sistemas

Liste os sistemas com os quais o novo precisa conversar, como ERP, emissor de notas, banco, plataforma de e-commerce ou ferramenta de e-mail. Para cada um, informe o nome do fornecedor e se você sabe se ele oferece API. Essa informação, sozinha, já muda bastante a estimativa.

5. Como saber se o sistema deu certo?

Defina como você vai saber se o sistema funcionou. Sem isso, o projeto pode ser entregue no prazo e no orçamento e ainda assim não resolver o problema que motivou o investimento.

• Redução do tempo de uma etapa específica, por exemplo, da aprovação de pedidos.
• Fim da redigitação entre duas áreas.
• Possibilidade de consultar o histórico de um cliente em segundos.
• Relatórios gerados sem montagem manual.

Sempre que possível, meça a situação atual antes de começar. Quanto tempo leva hoje? Quantos erros acontecem por mês? Esses números permitem comprovar o resultado depois.

6. Quais são as restrições e as prioridades?

Informe as restrições que o fornecedor precisa respeitar. Elas evitam propostas fora da realidade e ajudam a montar um plano de entregas viável.

• Prazo: existe uma data importante, como início de safra, mudança de lei ou temporada de vendas?
• Orçamento: uma faixa, mesmo aproximada, ajuda o fornecedor a propor o escopo certo.
• Tecnologia: há preferência ou exigência de linguagem, nuvem ou hospedagem?
• Conformidade: o sistema trata dados pessoais, financeiros ou de saúde que exigem cuidados adicionais?

Por fim, classifique o que foi levantado em três grupos: o que precisa existir na primeira versão, o que pode vir em seguida e o que é desejável, mas não essencial. Essa priorização é a ferramenta mais poderosa para controlar custo e prazo.

Como envolver a equipe no levantamento?

As pessoas que executam o processo são a principal fonte de informação, mas raramente têm tempo sobrando. Algumas práticas tornam a participação delas mais eficiente.

• Reuniões curtas e focadas: uma hora por tema (processo, regras, dados) rende mais que uma tarde inteira.
• Observação no posto de trabalho: acompanhar a rotina por uma ou duas horas revela passos que ninguém lembraria de mencionar.
• Exemplos reais na mesa: pedidos, contratos e planilhas do mês passado tornam a conversa concreta.
• Uma pessoa responsável por consolidar: alguém da empresa reúne as respostas e mantém o documento atualizado.
• Validação no final: a equipe lê o resultado e confirma que ele descreve a rotina de verdade.

Envolver a equipe desde o início também prepara a adoção. Quem ajudou a descrever o processo tende a reconhecer o sistema como uma solução para os próprios problemas, e não como uma imposição. Isso reduz a resistência na implantação e melhora a qualidade dos ajustes nas primeiras semanas de uso.

Se houver divergências entre áreas sobre como o processo funciona, registre-as em vez de tentar resolver na hora. Elas costumam indicar exatamente os pontos em que o sistema precisa de regras claras, e devem ser decididas pela gestão antes da construção.

O que pode ficar para depois?

Também é útil saber o que não precisa estar definido antes do orçamento. Tentar resolver tudo de antemão atrasa o início e, muitas vezes, gera decisões que mudam assim que as pessoas começam a usar o sistema.

• Layout detalhado das telas: será desenhado e validado com os usuários durante o projeto.
• Escolha técnica de banco de dados ou arquitetura: é responsabilidade do fornecedor justificar.
• Todos os relatórios: comece pelos três ou quatro mais usados.
• Todas as exceções raras: registre-as, mas trate as frequentes primeiro.

Como apresentar o levantamento ao fornecedor?

Não é preciso um documento formal. Um arquivo de duas a cinco páginas, com as seções deste artigo, já coloca a conversa em outro nível. Anexe exemplos reais: a planilha atual, prints de telas usadas hoje, modelos de documentos que o sistema vai gerar. Exemplos valem mais que descrições.

Envie o mesmo material para todos os fornecedores consultados. Assim, as propostas partem da mesma base e as diferenças de preço passam a refletir diferenças de abordagem, e não de entendimento.

Perguntas para fazer ao fornecedor

• Como vocês vão validar o entendimento do processo antes de começar a construir?
• Com que frequência vamos ver o sistema funcionando durante o projeto?
• Como são tratadas mudanças de escopo que surgirem no caminho?
• Quem será dono do código e dos dados ao final?
• Como funciona o suporte e a evolução depois da entrega?

Por que as propostas variam tanto?

Mesmo com um bom levantamento, é normal receber propostas com valores e prazos diferentes. Entender de onde vem a diferença ajuda a comparar com justiça, em vez de escolher apenas pelo preço.

• Interpretação do escopo: um fornecedor pode ter considerado as exceções e outro não. Peça que cada proposta liste o que está incluído e o que está fora.
• Etapas de descoberta: algumas propostas incluem um período de levantamento detalhado antes da construção; outras partem direto para o desenvolvimento.
• Qualidade e testes: testes automatizados, revisão de código e ambiente de homologação aumentam o custo inicial e reduzem o custo de manutenção.
• Infraestrutura e suporte: hospedagem, monitoramento e suporte depois da entrega podem estar incluídos ou ser cobrados à parte.
• Propriedade: o código e os dados ficam com a empresa? Há dependência de componentes proprietários do fornecedor?

Uma forma prática de comparar é montar uma tabela com essas linhas e preencher para cada proposta. Diferenças grandes de valor quase sempre se explicam por diferenças em uma ou mais delas.

Escopo fechado ou entregas por etapas: qual escolher?

Existem duas formas principais de contratar o desenvolvimento, e a escolha depende de quão bem definido está o que precisa ser feito.

Escopo fechado

Preço e prazo são definidos para um escopo descrito em detalhe. Dá previsibilidade de orçamento, mas exige que tudo esteja muito bem especificado antes. Mudanças no caminho viram aditivos, e a tendência é que o fornecedor inclua uma margem para cobrir incertezas. Funciona bem para sistemas pequenos e processos estáveis.

Entregas por etapas

O projeto é dividido em ciclos curtos, de duas a quatro semanas, com prioridades revisadas ao fim de cada um. A empresa vê o sistema funcionando cedo, corrige o rumo com base no uso real e pode parar quando o valor entregue for suficiente. Exige mais participação da empresa e um orçamento acompanhado por etapa. Funciona bem quando há incerteza sobre regras ou quando o processo vai mudar junto com o sistema.

Muitos projetos combinam os dois: uma primeira etapa de descoberta com escopo e preço fechados, que produz o levantamento detalhado, seguida de entregas por etapas para a construção. Essa combinação reduz o risco das duas partes.

Perguntas frequentes

Preciso contratar um analista para fazer esse levantamento?

Não necessariamente. As seis seções deste artigo podem ser preenchidas pela própria equipe, em linguagem do dia a dia. Um bom fornecedor vai complementar o levantamento com perguntas e, se o projeto for grande, propor uma etapa de descoberta para detalhar o que faltar.

Quanto tempo leva para fazer esse levantamento?

Para um processo de uma ou duas áreas, duas a três semanas costumam ser suficientes, contando com algumas reuniões curtas e a coleta de exceções no dia a dia. Processos que envolvem muitas áreas ou integrações levam mais.

E se o processo atual for ruim? Devo melhorar antes de criar o sistema?

Vale pelo menos discutir o processo desejado antes de construir. Automatizar um processo confuso tende a deixá-lo confuso e mais rápido. Mas não é preciso resolver tudo antes: o próprio desenvolvimento, feito em etapas e com participação da equipe, é uma boa oportunidade para simplificar o fluxo.

Sistema sob medida sempre custa mais que uma ferramenta pronta?

No investimento inicial, quase sempre. No custo total ao longo dos anos, depende: licenças por usuário, adaptações, integrações e o trabalho manual que a ferramenta pronta não elimina também entram na conta. A comparação justa considera um horizonte de três a cinco anos e o quanto cada opção atende às regras reais da operação.

Próximo passo

Reúna as pessoas que executam o processo e percorra as seis seções deste artigo em uma ou duas reuniões curtas. O resultado não precisa ser perfeito. Um levantamento honesto, com dúvidas marcadas como dúvidas, é muito mais útil do que um documento extenso escrito sem a participação da operação.