MVP de software: o que entra e o que fica fora

A reunião de escopo começa com dez funcionalidades e termina com quarenta. Cada área lembra de uma exceção, cada diretor tem um relatório que não pode faltar, e a "primeira versão" vira um sistema completo que leva o tempo de três. Quando finalmente sai, metade das premissas já mudou.

MVP, produto mínimo viável, é a resposta a esse padrão. Mas o termo foi tão usado que virou sinônimo de coisa malfeita ou de protótipo para jogar fora. Não é nenhuma das duas. Este texto traz o conceito para o contexto de sistemas B2B e internos e propõe um método que cabe numa reunião para decidir o que entra, o que fica manual e o que fica fora.

MVP não é versão malfeita nem protótipo descartável

Protótipo serve para testar uma ideia sem código de produção: telas navegáveis, fluxos simulados, validação com usuários. Ele é descartável por definição.

MVP é software de verdade, em produção, usado por pessoas reais para fazer trabalho real. Ele é mínimo em abrangência, não em qualidade. Faz poucas coisas, mas faz direito, com dados corretos, segurança e uma base que aguenta crescer.

A confusão entre os dois gera os dois erros clássicos. Tratar o MVP como protótipo produz código que precisa ser jogado fora justamente quando o sistema começa a dar certo. Tratar o protótipo como MVP produz meses de desenvolvimento antes de qualquer validação.

No contexto de uma startup, o MVP valida se existe mercado. Num sistema interno ou B2B, o mercado a validar é a sua própria operação: se o fluxo desenhado funciona no chão, se as pessoas adotam, se a informação que o sistema produz é confiável o bastante para decidir com ela. A lógica é a mesma, a hipótese é outra.

Comece pela hipótese, não pela lista de funcionalidades

Lista de funcionalidades não tem critério de corte. Tudo parece necessário quando o ponto de partida é "o que o sistema precisa ter".

O ponto de partida melhor é uma frase: "Acreditamos que, se [quem] puder [fazer o quê] no sistema, então [resultado observável]." Exemplos:

• Se os técnicos de campo registrarem a ordem de serviço no celular, com foto e assinatura, o faturamento deixa de esperar a papelada chegar ao escritório.
• Se o comprador receber as cotações dos fornecedores num só lugar, com comparação automática, o ciclo de compra encurta e as aprovações ficam rastreáveis.
• Se o cliente B2B consultar pedidos e boletos sozinho, o time de atendimento deixa de responder as mesmas perguntas todos os dias.

Com a hipótese escrita, cada funcionalidade proposta passa por um filtro simples: ela é necessária para testar essa hipótese? Se não é, vai para depois. Não para nunca, para depois.

Se a empresa não consegue escrever uma hipótese clara, esse é o sinal de que o problema ainda não está entendido, e o passo certo é um discovery de software antes de qualquer escopo.

A fatia de ponta a ponta que já troca um processo real

O erro mais comum de corte é horizontal: fazer primeiro todos os cadastros, depois todas as telas de operação, depois os relatórios. Durante meses nada funciona de ponta a ponta, e ninguém consegue usar.

O corte certo é vertical. Escolha um fluxo e faça ele inteiro, do começo ao fim, de forma que já substitua um processo que hoje é feito em planilha, e-mail ou papel. Um fluxo pequeno, mas completo:

• entra um dado real;
• passa pelas etapas necessárias, com as pessoas certas;
• produz um resultado que alguém usa de verdade.

Às vezes a fatia certa é uma filial, um tipo de produto, uma equipe ou um cliente piloto. Tudo bem começar pequeno em abrangência, desde que o fluxo esteja inteiro para aquele recorte.

Para quem está saindo de planilhas, esse é exatamente o caminho recomendado: trocar um processo, não a empresa toda.

Corte exceções, não telas

Quando o escopo aperta, a tentação é cortar telas: tira o painel, tira a consulta, tira o relatório. Às vezes funciona. Mas o que realmente infla um sistema são as exceções: o pedido com três endereços de entrega, o cliente que paga metade no boleto e metade no cartão, o produto que é vendido por peso em uma filial e por unidade em outra.

Para cada regra de negócio, pergunte:

1. Com que frequência isso acontece? Todos os dias, toda semana, algumas vezes por ano?
2. O que acontece hoje quando acontece? Existe um jeito manual de resolver?
3. Qual o custo de tratar à mão durante os primeiros meses?

Exceções raras, com contorno manual conhecido, ficam fora do MVP. O sistema precisa apenas não atrapalhar: permitir registrar uma observação, marcar o caso como especial, ou deixar uma pessoa autorizada fazer o ajuste. O caminho principal, que representa a maior parte do volume, é o que precisa estar impecável.

O que pode ser manual nos bastidores no início

Nem tudo que o usuário vê como automático precisa ser automático no começo. Alguns exemplos típicos do que pode ficar manual, sem prejudicar a validação:

• Integração com o ERP pode começar como exportação de arquivo conferida por alguém, se o volume permitir, enquanto a integração definitiva é construída.
• Relatórios gerenciais podem sair de uma consulta exportada para planilha nas primeiras semanas.
• Cadastros de baixa frequência, como tabelas de parâmetros, podem ser carregados pela equipe técnica em vez de ganhar tela.
• Notificações podem começar por e-mail simples antes de ir para WhatsApp.

O cuidado é deixar claro, por escrito, o que é provisório e quem faz. Processo manual sem dono vira falha silenciosa.

O que nunca fica de fora: segurança e dados

Há coisas que não se cortam para economizar no MVP, porque o custo de fazer depois é muito maior que o de fazer agora:

• Autenticação e controle de acesso. Quem vê o quê, desde o primeiro usuário.
• Modelo de dados correto. Tabela mal desenhada no início contamina tudo o que vem depois e exige migração dolorosa.
• Registro de quem fez o quê nas operações que mexem com dinheiro, estoque ou dados de clientes.
• Backup e recuperação testados.
• LGPD. Se há dados pessoais, a base legal, o controle de acesso e o descarte já precisam estar pensados.
• Publicação automatizada e ambientes separados, para que as correções dos primeiros dias saiam rápido e sem medo.

Um MVP pode ter poucas telas. Não pode ter fundação ruim.

Escrevendo o que fica fora e como medir o MVP

O escopo de um MVP é um documento curto com quatro partes:

1. A hipótese, na frase do início.
2. O que entra: o fluxo de ponta a ponta, os perfis de usuário e as regras obrigatórias.
3. O que fica fora, explicitamente, com o motivo. Essa lista é tão importante quanto a outra. É ela que protege o projeto das inclusões de última hora e que mostra às áreas que o pedido delas foi ouvido e tem lugar numa fase seguinte.
4. Como vamos saber se deu certo: poucos indicadores, medidos antes e depois.

Bons indicadores de MVP medem uso e resultado, não existência do sistema:

• quantos dos casos previstos passaram de fato pelo sistema;
• tempo do processo antes e depois;
• quantos contornos manuais ainda acontecem, e por quê;
• quantas vezes alguém voltou para a planilha antiga;
• satisfação de quem usa todo dia, colhida em conversa, não só em formulário.

Defina também o que acontece com cada resultado possível. Se a hipótese se confirmar, qual é a próxima fatia? Se não, o que muda?

Quando um MVP não é o caminho

A abordagem incremental é o padrão certo para a maioria dos projetos, mas há casos em que o "mínimo" não pode ser tão mínimo:

• Substituição obrigatória com data marcada. Se o sistema antigo vai ser desligado, ou uma exigência legal entra em vigor, a primeira versão precisa cobrir tudo o que a operação não consegue fazer sem sistema. Ainda assim, vale ordenar as entregas por risco e testar cada parte com usuários reais antes da virada.
• Processos regulados ou fiscais. Emissão de nota, folha, obrigações acessórias e rastreabilidade sanitária não aceitam contorno manual improvisado. O que for legalmente exigido entra inteiro.
• Fluxos que não se dividem. Às vezes o valor só aparece quando duas áreas estão no sistema ao mesmo tempo, como venda e separação. Nesse caso, a fatia fica maior, mas o recorte por filial, produto ou cliente piloto continua valendo.

Mesmo nesses cenários, o raciocínio do MVP ajuda: escrever a hipótese, separar o obrigatório do desejável e deixar por escrito o que vem depois.

Erros que fazem o MVP não sair

• Um MVP por departamento. Cada área inclui o seu item "mínimo" e o total deixa de ser mínimo.
• Cortar sem hipótese. Sem critério, o corte vira negociação política.
• Esquecer a migração de dados. O sistema está pronto, mas ninguém trouxe os cadastros.
• Não ter dono do produto do lado do negócio, com autoridade para dizer não.
• Lançar para todos de uma vez, sem grupo piloto que absorva os ajustes dos primeiros dias.

Checklist rápido

• A hipótese está escrita numa frase?
• O MVP completa um fluxo real de ponta a ponta?
• As exceções raras têm contorno manual definido?
• Os processos manuais provisórios têm dono?
• Segurança, dados e backup estão dentro?
• A lista do que fica fora está escrita e aprovada?
• Os indicadores foram medidos antes do lançamento?

Da hipótese ao sistema em uso

Na Pervian Tech, definimos o MVP junto com quem vai usar o sistema: hipótese escrita, fluxo de ponta a ponta, lista explícita do que fica para depois e indicadores combinados antes do lançamento. O desenvolvimento é sob medida, em ciclos curtos, dentro do nosso trabalho de desenvolvimento web.

O investimento depende do tamanho da primeira fatia, das integrações e das regras envolvidas, por isso é definido sob consulta, depois de um diagnóstico inicial gratuito. Se você tem uma lista de funcionalidades que não para de crescer, conte o problema que quer resolver e a gente ajuda a achar o corte certo.