Quanto tempo leva para desenvolver um MVP

O que é um MVP — e o que não é

MVP (produto mínimo viável) é a menor versão do produto que resolve o problema central para um grupo real de usuários. Não é um protótipo de apresentação, nem uma versão precária do produto final: é software em produção, com gente usando.

O erro mais comum é chamar de MVP um produto completo com o prazo cortado ao meio. O resultado é um projeto que atrasa ou uma entrega que não funciona. MVP é escopo pequeno com qualidade de produção — não escopo grande com qualidade reduzida.

O cronograma típico, semana a semana

Um MVP de 8 semanas na Olympio se organiza assim:

• Semanas 1 e 2 — Discovery e protótipo. Entrevistas, mapeamento do fluxo, protótipo navegável e definição do escopo fechado.
• Semanas 3 a 6 — Desenvolvimento em sprints quinzenais. A cada duas semanas uma versão funcional para você testar; o backlog é reordenado a cada ciclo.
• Semana 7 — Testes, ajustes e preparação de produção. Ambientes, pipeline de deploy, medição de uso.
• Semana 8 — Lançamento com um grupo controlado de usuários, acompanhamento próximo e correção rápida.

MVPs de 12 semanas seguem a mesma estrutura com mais ciclos de desenvolvimento — geralmente por causa de integrações ou de mais de um perfil de usuário.

O que define se serão 6 ou 12 semanas

• Número de fluxos principais. Um MVP com um fluxo (cadastro, pedido, pagamento) é diferente de um com três.
• Integrações. Cada sistema externo adiciona tempo de entendimento, testes e tratamento de erro.
• Perfis de usuário. Cliente, operador e administrador significam três interfaces, não uma.
• Disponibilidade do cliente. Reuniões de validação a cada sprint e respostas rápidas mantêm o ritmo.
• Material pronto. Marca, textos, regras de negócio documentadas e acesso aos sistemas atuais encurtam o discovery.

Onde o prazo costuma estourar

Depois de muitos projetos, os atrasos têm sempre as mesmas causas:

• Escopo que cresce durante o projeto. "Já que estamos fazendo, coloca também..." é a frase que mais atrasa MVPs.
• Decisões pendentes. Uma pergunta sem resposta por uma semana é uma semana de atraso.
• Integração com sistema sem documentação. O tempo para descobrir como um sistema antigo funciona é imprevisível.
• Aprovação das lojas de aplicativos. A revisão da Apple pode levar dias e pedir ajustes; conte com isso no cronograma.
• Dependência de terceiros. Contratação de gateway de pagamento, liberação de API de parceiro, cadastro de domínio.

Como chegar no prazo

• Escreva o escopo e trate mudanças como mudanças: o que entra, o que sai, o que muda no prazo.
• Nomeie uma pessoa com poder de decisão do seu lado, disponível para as validações quinzenais.
• Resolva as dependências externas antes de o desenvolvimento começar: contas, contratos, acessos.
• Aceite lançar com o núcleo. O que ficou de fora vai para a lista da versão seguinte — com dados de uso reais para priorizar.

E depois do MVP?

O MVP é o começo, não o fim. As primeiras semanas em produção mostram o que os usuários realmente fazem, e essa informação vale mais do que qualquer reunião de planejamento. A partir dela, o produto evolui em ciclos: novas funcionalidades priorizadas por uso, não por opinião.

Na Olympio, a evolução pode continuar com o mesmo time, em contrato de sustentação e evolução, ou passar para um time interno — o código é seu desde o primeiro dia.