← blog

MVP em seis semanas: o que a gente corta e o que nunca corta

A conversa de escopo de um MVP sempre chega no mesmo ponto: a lista tem 30 itens, o prazo cabe 12, e ninguém quer ser quem tira algo da lista. O que destrava é trocar a pergunta. Em vez de "isso é importante?" — porque tudo é importante para alguém — a pergunta passa a ser: sem isso, dá para alguém usar o sistema de ponta a ponta e chegar ao resultado?

O que quase sempre pode esperar

  • Painel de relatórios. Nas primeiras semanas há pouco dado para relatar. Uma exportação simples resolve até existir volume que justifique gráfico.
  • Perfis de permissão detalhados. Comece com dois papéis. Cinco níveis de acesso é uma decisão que fica mais fácil depois que o processo real aparece.
  • Configurações personalizáveis. Cada tela de configuração é um caminho a mais para testar. Deixe fixo no código o que ainda não mudou nenhuma vez.
  • Aplicativo nativo. Um site que funciona bem no celular atende a maior parte dos casos até existir usuário recorrente suficiente.

O que nunca cortamos

  • Autenticação feita direito. Improvisar login gera dívida que custa caro e cedo.
  • Backup automático. Perder dado do cliente na primeira semana encerra a confiança do projeto.
  • Registro de quem fez o quê. Um log básico de alterações salva horas de investigação no primeiro conflito de versão.
  • Um caminho de erro visível. Sistema que falha em silêncio faz o usuário achar que deu certo. Isso é pior do que a falha.

Por que seis semanas, e não três meses

Prazo curto não é pressa: é um limite que força a escolha. Escopo com prazo de três meses tende a crescer até ocupar os três meses, e a primeira validação real com usuário fica para o fim — quando mudar de rumo já custa caro.

Com seis semanas, a primeira versão vai para a mão de alguém enquanto ainda é barato mudar de ideia.

Para empresa pequena e média — o perfil da maior parte dos nossos clientes no Piauí — isso importa ainda mais: o orçamento não comporta descobrir no sexto mês que o sistema resolveu o problema errado. É assim que conduzimos todo desenvolvimento de software sob medida em Teresina: primeira versão curta, validada com usuário real.

O teste que aplicamos em cada item da lista: se essa funcionalidade não existir na primeira versão, o usuário trava ou só fica incomodado? Trava, entra. Incomoda, espera.