MVP sem atalhos perigosos: como definir a primeira entrega

MVP não é uma versão descuidada. É o menor experimento operacional capaz de testar uma hipótese relevante com risco controlado.

Um MVP não precisa conter pouco código. Precisa produzir aprendizado Uma equipe pretende criar uma plataforma para conectar prestadores de serviço a empresas. A primeira lista de funcionalidades contém: cadastro; perfis; busca; avaliações; chat; agenda; pagamentos; notificações; aplicativo; recomendação automática; painel administrativo; relatórios; planos; cupons. A direção pede um MVP. A reação comum é remover itens até que o prazo pareça possível. Permanecem cadastro, busca e chat. Segurança, suporte, logs, acessibilidade e recuperação são classificados como “melhorias posteriores”. Isso não é necessariamente um MVP. Pode ser apenas um produto menor com riscos invisíveis. Um MVP deve testar uma hipótese relevante por meio da menor solução capaz de gerar evidência confiável. Produto, protótipo e operação assistida não são a mesma coisa Antes de desenvolver, escolha o tipo de experimento. Protótipo Serve para avaliar: compreensão; fluxo; linguagem; navegação; interesse; viabilidade de interação. Não precisa processar dados reais nem possuir toda a infraestrutura. Landing page Pode avaliar: interesse; mensagem; origem; pedido de contato; prioridade de segmentos. Não prova que a equipe consegue entregar o serviço em escala. Concierge A experiência parece digital para o usuário, mas parte do processo é executada manualmente. Útil para testar: demanda; sequência; qualidade da entrega; exceções; disposição de uso. Wizard of Oz A interface simula automação, enquanto decisões são tomadas manualmente nos bastidores. Precisa ser usado com cuidado para não enganar usuários sobre capacidades ou tratamento de dados. MVP operacional Processa casos reais e precisa de: segurança; suporte; observabilidade; proteção de dados; recuperação; manutenção. Quanto mais real a operação, menor a justificativa para retirar controles básicos. Descoberta antes do MVP O GOV.UK Service Manual orienta usar a descoberta para compreender o problema e decidir se vale a pena avançar. Não recomenda começar a construir durante essa fase. Perguntas: qual problema ocorre hoje; quem é afetado; com que frequência; qual alternativa já é usada; por que ela é insuficiente; qual hipótese precisa ser testada; qual comportamento confirmaria a hipótese; qual evidência a invalidaria; qual risco não pode ser aceito. O artigo sobre tecnologia para operações reais ajuda a transformar pedidos de ferramenta em problemas verificáveis. O erro de validar cinco hipóteses ao mesmo tempo A plataforma hipotética pode conter hipóteses distintas: 1. empresas têm dificuldade em encontrar profissionais; 2. profissionais querem receber oportunidades; 3. empresas aceitam contratar pela plataforma; 4. pagamentos podem ser intermediados; 5. avaliações geram confiança; 6. recomendações melhoram correspondência. Construir o produto inteiro mistura todas elas. Se ninguém usar, a equipe não saberá qual estava errada. Um MVP mais preciso escolhe uma hipótese. Exemplo: Empresas de pequeno porte aceitam preencher um briefing estruturado para receber três prestadores compatíveis em até dois dias úteis. Essa hipótese pode ser testada sem marketplace, chat próprio ou algoritmo. Estudo de caso hipotético: serviço antes da plataforma Primeira versão: Componentes: landing page; formulário; painel interno simples; base de prestadores; processo manual; comunicação; métricas. O aprendizado pode incluir: taxa de conclusão do briefing; qualidade dos dados; tempo para selecionar; taxa de resposta; entrevistas iniciadas; motivos de rejeição; exceções operacionais. Se houver demanda e repetição, partes manuais podem ser automatizadas. O que pode ser removido Recursos podem sair quando: não são necessários para testar a hipótese; possuem alternativa manual segura; atendem volume futuro ainda inexistente; dependem de comportamento não comprovado; aumentam custo sem gerar evidência; podem ser adicionados sem reestruturar a base. Exemplos: aplicativo nativo; recomendação automática; chat próprio; programa de pontos; múltiplos planos; dashboard avançado; personalização extensa; arquitetura distribuída; suporte a múltiplos idiomas sem público atual. O que não deve ser removido por conveniência Controle de acesso Se o produto possui contas, cada pessoa deve acessar somente o que lhe pertence. Proteção de dados Colete apenas o necessário. Defina retenção, acesso e descarte. Segurança de segredos Credenciais não devem ser versionadas ou expostas. Backup e recuperação Se dados reais possuem valor, a recuperação precisa existir e ser testável. Logs essenciais Falhas precisam ser investigáveis sem registrar dados sensíveis desnecessários. Acessibilidade básica Fluxos precisam ser estruturados, utilizáveis por teclado, legíveis e compreensíveis. O W3C recomenda integrar acessibilidade ao processo de produção, em vez de tratá la como correção isolada. Tratamento de erros O produto precisa informar o que aconteceu e evitar operações duplicadas ou estados parciais. Responsável operacional Alguém precisa receber alertas, atender usuários e decidir em incidentes. Forma de retorno A primeira publicação precisa de rollback ou restauração. O NIST SSDF 1.1 recomenda integrar práticas de segurança a qualquer modelo de ciclo de desenvolvimento. “É apenas um MVP” não elimina o risco de vulnerabilidades ou dados expostos. Segurança não pode ser um adicional pago pelo usuário A iniciativa Secure by Design da CISA defende que segurança seja tratada como requisito central e responsabilidade do fornecedor, não apenas como configuração transferida ao cliente. No contexto de MVP, isso significa: padrão seguro; MFA quando o risco exige; permissões mínimas; sem senhas padrão; componentes atualizados; proteção de dados; vulnerabilidades tratáveis. Não é necessário implementar a estrutura de segurança de uma grande instituição. É necessário impedir que a redução de escopo crie um produto inseguro por padrão. Use risco para definir profundidade Área Baixo risco Alto risco Autenticação Link temporário ou provedor gerenciado MFA, sessão, recuperação e auditoria Dados Contato básico Dados financeiros, saúde ou documentos Pagamento Link externo Intermediação e conciliação Disponibilidade Processo alternativo manual Operação dependente em tempo real Erro Reenvio simples Idempotência e compensação Suporte Horário definido Resposta de incidente Backup Conteúdo republicável Dados transacionais A escolha deve ser documentada. Alto risco pode justificar reduzir ainda mais o escopo ou usar um provedor especializado. Um recurso pode ser manual, mas a responsabilidade não Suponha que a seleção de prestadores seja manual. Ainda é necessário definir: quem acessa os dados; como a equipe registra decisão; como conflitos são tratados; como um pedido é atribuído; como evitar que duas pessoas respondam; como o prazo é acompanhado; como o dado é removido; como o usuário recebe suporte. Operação manual sem processo apenas desloca o problema do código para uma planilha. Métrica de vaidade não valida a hipótese Visualizações e cadastros podem ser interessantes, mas não comprovam valor. Para a hipótese do matching: Etapa Métrica Interesse visitantes qualificados Intenção briefings iniciados Esforço aceito briefings concluídos Entrega seleções enviadas no prazo Qualidade opções consideradas adequadas Resultado conversas ou contratações iniciadas Sustentabilidade custo e tempo por atendimento Uma métrica deve permitir decisão. Exemplo: Se menos de 20% dos briefings completos resultarem em pelo menos uma entrevista, revisar critérios de seleção antes de automatizar. O número é hipotético e precisa ser definido pela equipe com base no modelo de negócio. Defina critérios de parada Um experimento também precisa dizer quando não avançar. Exemplos: público não reconhece o problema; esforço manual é inviável; custo de aquisição supera o aceitável; dados necessários não podem ser coletados adequadamente; risco regulatório não é compatível; integração crítica não possui viabilidade; resultado depende de comportamento que não ocorreu. Sem critério de parada, qualquer resultado pode ser reinterpretado como justificativa para continuar. A primeira arquitetura deve suportar aprendizado Evite começar com: dezenas de serviços; filas sem necessidade; múltiplos bancos; cluster complexo; aplicativo para cada plataforma; observabilidade desproporcional. Prefira: implantação simples; módulos claros; banco adequado; serviços gerenciados quando reduzem risco; logs e métricas essenciais; processo reproduzível; capacidade de mudança. O guia de arquitetura sem complexidade desnecessária apresenta critérios para decidir quando separar componentes. Checklist da primeira entrega Hipótese [ ] Existe uma hipótese explícita. [ ] O público está definido. [ ] O comportamento esperado é observável. [ ] Há critério de sucesso e parada. Escopo [ ] Cada recurso participa do teste. [ ] Recursos adiáveis foram removidos. [ ] Alternativas manuais possuem processo. [ ] Limitações são comunicadas. Segurança e dados [ ] Contas e permissões são controladas. [ ] Dados coletados são necessários. [ ] Segredos estão protegidos. [ ] Dependências são atualizadas. [ ] Logs não expõem dados indevidos. [ ] Retenção e descarte foram considerados. Acessibilidade [ ] Fluxos funcionam por teclado. [ ] Campos possuem rótulos. [ ] Erros são compreensíveis. [ ] Contraste e zoom foram avaliados. [ ] Conteúdo possui estrutura. Operação [ ] Existe responsável. [ ] Há monitoramento. [ ] Backup e retorno foram definidos. [ ] Suporte possui canal. [ ] Incidentes possuem procedimento mínimo. Aprendizado [ ] Eventos necessários são medidos. [ ] Métricas não dependem apenas de visualizações. [ ] Entrevistas ou feedback estão planejados. [ ] A próxima decisão é conhecida. O MVP pode ser uma decisão de não construir A descoberta pode mostrar que: uma ferramenta existente resolve; o processo precisa mudar antes; a demanda é insuficiente; o custo operacional é alto; a hipótese não se sustenta; o risco supera o retorno. Esse resultado evita investimento maior e também é aprendizado. O processo do briefing ao site no ar deve permitir prototipar, validar e interromper antes da construção completa. A definição operacional Um MVP é: a menor solução capaz de testar uma hipótese relevante com usuários ou condições representativas, produzindo evidência suficiente para decidir o próximo passo e mantendo controles proporcionais ao risco. “Mínimo” descreve o escopo. “Viável” descreve a capacidade de produzir valor e ser operado. “Produto” descreve algo que precisa funcionar para alguém. Remover funcionalidades é parte do trabalho. Remover responsabilidade não é.