Escopo de sistema sob medida: o que definir antes de pedir orçamento

Uma empresa decide tirar o controle de pedidos da planilha, manda o mesmo e-mail para três fornecedores pedindo orçamento de um sistema e recebe três respostas: 18 mil, 65 mil e 190 mil reais. A primeira reação é achar que alguém está tentando enganar. Na maioria das vezes, ninguém está. Cada fornecedor imaginou um sistema diferente, porque o pedido cabia em três sistemas diferentes.

Esse é o problema que o escopo resolve. Escopo é a descrição do que o sistema vai fazer, para quem, com quais regras e, tão importante quanto, o que ele não vai fazer. Sem ele, o orçamento é um chute educado, o prazo é uma esperança e a discussão sobre o que estava incluído começa no dia da entrega.

Este guia é para o dono ou gestor que vai contratar um sistema sob medida, seja um sistema online, um portal para clientes ou um aplicativo, e quer chegar na conversa com o fornecedor sabendo o que pedir. Não é preciso saber programar. É preciso saber descrever o próprio negócio com precisão, e isso a empresa sabe melhor do que ninguém.

Por que o mesmo pedido gera orçamentos tão diferentes

Pense em um pedido simples: "um sistema para controlar os pedidos dos clientes". Agora repare em quantas perguntas ficaram sem resposta.

• Quem registra o pedido: o vendedor, o próprio cliente pela internet, ou os dois?
• O pedido gera nota fiscal, boleto ou cobrança por cartão, ou isso continua em outro sistema?
• Quantas pessoas vão usar, com quantos perfis de acesso diferentes?
• Precisa funcionar no celular, na rua, sem internet?
• Os dados antigos da planilha precisam ser importados?
• Precisa conversar com o estoque, com o ERP da contabilidade, com o WhatsApp?

O fornecedor de 18 mil respondeu tudo isso pelo lado mais simples: um cadastro de pedidos com uma tela de consulta. O de 190 mil respondeu pelo lado mais completo: portal do cliente, integração fiscal, aplicativo e painel gerencial. Os três orçamentos podem estar certos, e nenhum deles é comparável aos outros.

Quando o escopo existe, a pergunta muda de "quanto custa um sistema" para "quanto custa este sistema", e aí os preços passam a ser comparáveis de verdade.

O que é escopo, e o que ele não precisa ser

Escopo assusta porque muita gente imagina um documento técnico de cem páginas, cheio de diagramas. Para uma pequena ou média empresa, não é isso. Um bom escopo inicial cabe em poucas páginas e é escrito na língua do negócio, não na do programador.

Ele precisa responder com clareza a cinco coisas:

1. Qual problema o sistema resolve, em uma ou duas frases.
2. Quem usa, separado por tipo de usuário.
3. O que cada um faz no sistema, passo a passo.
4. Quais regras o sistema precisa aplicar, como descontos, prazos e aprovações.
5. O que fica de fora desta versão.

O detalhamento técnico, como banco de dados, linguagem e arquitetura, é trabalho do fornecedor. O que só a empresa pode fazer é descrever o processo real, com as exceções que aparecem no dia a dia e que nenhum fornecedor adivinha.

Comece pelo problema, não pela lista de telas

O erro mais comum é abrir o escopo com uma lista de funcionalidades: cadastro de clientes, cadastro de produtos, relatórios, dashboard. Essa lista parece objetiva, mas esconde o essencial, que é o motivo de tudo isso existir.

Compare dois começos:

• Fraco: "Precisamos de um sistema com cadastro de clientes, pedidos e relatórios."
• Forte: "Hoje o pedido entra pelo WhatsApp, é digitado em três planilhas e leva em média dois dias para chegar à produção. Queremos que o pedido seja registrado uma vez e apareça na fila da produção no mesmo minuto."

O segundo dá ao fornecedor o critério para tomar decisões. Se uma funcionalidade não ajuda o pedido a chegar mais rápido na produção, ela pode esperar. Se você ainda está decidindo se o problema é grande o bastante para virar sistema, o post sobre a planilha que virou sistema da empresa ajuda a fazer essa conta antes.

Quem usa o sistema, e o que cada um faz

Liste os tipos de usuário, não os nomes das pessoas. Em um sistema de pedidos, por exemplo: vendedor, produção, financeiro, gerente e, talvez, o próprio cliente. Para cada um, descreva o que ele faz em uma frase que comece com um verbo.

Escreva como história, não como tela

Um formato simples e muito usado é o de história de usuário: "como [tipo de usuário], quero [fazer algo], para [obter um resultado]". Alguns exemplos:

• Como vendedor, quero registrar um pedido pelo celular durante a visita, para não precisar digitar de novo no escritório.
• Como produção, quero ver a fila de pedidos do dia por ordem de entrega, para saber o que começar primeiro.
• Como financeiro, quero ver os pedidos entregues e ainda não pagos, para cobrar no prazo.
• Como cliente, quero acompanhar o status do meu pedido, para não precisar ligar perguntando.

Cada história vira um pedaço do sistema que pode ser estimado, construído e testado. E elas revelam rapidamente o que é essencial e o que é desejável.

Inclua a frequência e o volume

Quantos pedidos por dia? Quantos usuários ao mesmo tempo? Quantos produtos no catálogo? Um sistema para 20 pedidos por dia e um para 2 mil podem ter as mesmas telas e custos de infraestrutura muito diferentes. Números aproximados bastam, desde que sejam honestos.

As regras de negócio são o que mais encarece, e o que mais se esquece

Tela é a parte visível do sistema. Regra é a parte cara. "O cliente do atacado tem 5% de desconto acima de 3 mil reais, exceto na linha nova, e o desconto precisa de aprovação do gerente se passar de 8%." Essa frase, que alguém da empresa aplica de cabeça há anos, vira lógica, validação, tela de aprovação, notificação e teste.

Por isso, o escopo precisa trazer as regras escritas, inclusive as exceções. Algumas perguntas que ajudam a encontrá-las:

• Quais cálculos alguém faz hoje à mão ou numa planilha auxiliar?
• O que precisa de aprovação, e de quem?
• O que acontece quando um pedido é cancelado, alterado ou devolvido no meio do caminho?
• Há prazos que o sistema precisa controlar, como validade de orçamento ou vencimento de contrato?
• Há algo que só certas pessoas podem ver, como margem, comissão ou dados pessoais do cliente?

Regra que aparece depois do orçamento fechado é a principal causa de aditivo. Não porque o fornecedor esteja sendo oportunista, mas porque ninguém consegue estimar o que não foi contado.

O que fica de fora também é escopo

A lista do que não entra é tão útil quanto a do que entra. Ela evita o mal-entendido mais caro de todos: a empresa achar que algo estava incluído e o fornecedor achar que não.

Alguns itens que costumam gerar essa confusão, e que vale declarar explicitamente como dentro ou fora:

• Importação dos dados antigos. Limpar e importar uma planilha de dez anos dá trabalho real.
• Emissão de nota fiscal e integração bancária. Dependem de serviços de terceiros, com custos próprios.
• Aplicativo nas lojas da Apple e do Google. Muitas vezes um sistema web instalável resolve, e custa bem menos. A diferença está explicada em aplicativo ou site que instala no celular.
• Relatórios. "Ter relatórios" não é escopo. Quais relatórios, com quais filtros, para quem?
• Treinamento e suporte depois da entrega. Por quanto tempo, por qual canal, com qual prazo de resposta.

Primeira versão enxuta: o escopo que cabe no orçamento

Depois de escrever tudo, a lista quase sempre fica maior do que o orçamento disponível. Isso é normal e é bom, porque agora dá para escolher com consciência. A ideia é separar o que forma a primeira versão útil, aquela que já resolve o problema principal e entra em uso, do que vem depois.

Um jeito prático de fazer essa separação é classificar cada história em três grupos:

1. Sem isso o sistema não resolve o problema. Entra na primeira versão.
2. Melhora muito, mas dá para conviver sem por alguns meses. Segunda etapa.
3. Seria bom ter. Fica anotado e é reavaliado depois que o sistema estiver em uso.

Muita coisa do terceiro grupo deixa de fazer sentido quando a equipe começa a usar o sistema de verdade, e outras coisas, que ninguém tinha pensado, aparecem. Entregar em etapas não é economizar, é aprender antes de gastar. E cada etapa entregue já devolve parte do investimento em horas economizadas.

Integrações: o pedaço que depende de outra empresa

Toda integração com sistema de terceiro, como ERP, emissor de nota, gateway de pagamento, transportadora ou WhatsApp, traz uma dependência que o fornecedor do seu sistema não controla. Para cada uma, o escopo deve dizer:

• Qual sistema, e em qual versão ou plano a empresa está hoje.
• Se esse sistema tem API documentada, e se o plano atual dá acesso a ela.
• Qual informação vai e qual volta, e com que frequência.
• Quem é o contato técnico do outro lado.

Integração costuma ser o item com maior margem de incerteza no orçamento. Ter essas respostas antes reduz a incerteza e, junto com ela, a gordura que o fornecedor precisa colocar no preço para se proteger.

O que perguntar ao fornecedor junto com o escopo

O escopo descreve o sistema. Algumas perguntas descrevem a relação com quem vai construí-lo, e elas pesam tanto quanto o preço:

• Como vocês entregam? Tudo no fim, ou em etapas que a empresa pode testar e usar?
• Como funciona uma mudança de escopo? Ela vai acontecer. O importante é saber como é estimada e aprovada.
• Onde o sistema vai rodar, e em nome de quem? Hospedagem, domínio e banco de dados devem ser da empresa.
• Quem fica com o código-fonte? Esse ponto merece um capítulo próprio, e ele está em código-fonte do sistema e do aplicativo: de quem é.
• Quanto custa manter depois da entrega? Hospedagem, atualizações e ajustes. O raciocínio é o mesmo de quanto custa manter um aplicativo.
• Como a empresa exporta os próprios dados, se um dia quiser trocar de fornecedor?

Escopo também é proteção para a empresa

Existe um motivo menos óbvio para escrever o escopo, e ele tem a ver com controle. Quando o conhecimento sobre como o sistema deve funcionar existe só na cabeça do fornecedor, a empresa depende dele para qualquer mudança, para qualquer dúvida e para qualquer troca futura.

Um escopo escrito, atualizado a cada etapa, é a documentação do próprio negócio. Ele permite que outra equipe entenda o sistema, que um funcionário novo aprenda o processo e que a empresa negocie com segurança. Junto com o domínio no nome da empresa, a hospedagem com backup que ela pode restaurar e o código entregue, ele fecha o círculo: o sistema é da empresa, e não emprestado de quem o construiu.

Vale também decidir, junto com o escopo, onde o sistema vai rodar. Se a empresa ainda está entre um sistema instalado no computador e um sistema acessado pelo navegador, o comparativo em sistema instalado ou sistema online mostra o que muda em custo, acesso e segurança.

Um modelo simples para começar hoje

Se a ideia é sair deste texto com algo nas mãos, abra um documento e preencha estes tópicos. Uma ou duas horas bastam para uma primeira versão:

1. O problema: como o processo funciona hoje e o que dá errado, com números se possível.
2. O objetivo: o que precisa estar diferente quando o sistema estiver em uso.
3. Os usuários: tipos de usuário e quantas pessoas de cada tipo.
4. As histórias: o que cada tipo de usuário faz, no formato "como, quero, para".
5. As regras: cálculos, aprovações, prazos e exceções.
6. Os volumes: pedidos, clientes, produtos, acessos simultâneos.
7. As integrações: com quais sistemas, e o que vai e volta.
8. Fora do escopo: o que não entra nesta versão.
9. A primeira versão: quais histórias são indispensáveis.

Esse documento não precisa estar perfeito. Um bom fornecedor vai fazer perguntas sobre ele, e as perguntas que ele fizer dizem muito sobre a qualidade do trabalho que vem depois. Desconfie de quem devolve um preço fechado sem perguntar nada.

A NSWeb desenvolve sistemas online e aplicativos sob medida para pequenas e médias empresas, e a primeira conversa costuma ser exatamente essa: transformar o processo da empresa em um escopo claro, com uma primeira versão que cabe no orçamento e tudo rodando no domínio e na hospedagem da própria empresa. Fale com a gente pelo formulário de contato e conte qual processo você quer tirar do improviso.

Perguntas frequentes

As dúvidas que mais aparecem quando a empresa começa a escrever o escopo de um sistema sob medida.