Desenvolvimento de MVP e Produto

O desenvolvimento de MVP serve para responder a uma pergunta antes de gastar o orçamento todo: alguém vai usar isto? Traga a ideia. Nós transformamo-la num produto que utilizadores reais podem abrir, usar e julgar, com pensamento de nível empresarial, à medida e ao preço de uma empresa em crescimento. Cortamos o âmbito até ao que prova valor, não até ao que enche uma lista de tarefas. O resto vai para o roadmap, que é o sítio dele. Em quinze anos de engenharia de software vimos que um produto mínimo viável falha mais vezes por excesso do que por falta.

O problema, nas suas palavras

«Temos uma ideia e um orçamento limitado, e não podemos dar-nos ao luxo de construir a coisa errada.» «As propostas que recebemos são projetos longos sem nada para ver até ao fim, ou modelos prontos que não aguentam utilizadores reais.» «Precisamos de saber se as pessoas vão usar isto antes de apostar a empresa nisso.»

São preocupações legítimas. Raramente um produto em fase inicial falha por causa do código. Falha porque se gastam meses em funcionalidades que ninguém pediu, enquanto a pergunta que importa fica sem resposta. Um MVP dá-lhe essa resposta cedo, com software em que pode confiar.

Sinais de que precisa disto

• Tem uma ideia de produto, uma nova linha de negócio ou uma ferramenta interna, e não tem capacidade de engenharia para a testar.
• Escreveu uma longa lista de funcionalidades e desconfia que metade ainda não interessa.
• Quer engenharia sénior a testar a ideia sem contratar uma equipa inteira para descobrir se funciona.
• Precisa de mostrar a investidores, parceiros ou à administração algo que funcione, e não um diapositivo.

Como trabalhamos

1. Problema. Primeiro ouvimos. Quem é o utilizador, o que faz hoje em vez disto e o que o convenceria de que a ideia funciona? Escrevemos isso como o teste que o MVP tem de passar.
2. Ideia. Orientamos as escolhas técnicas e comerciais até à versão mais pequena que vale a pena construir. Se uma ferramenta pronta já prova o que quer provar, dizemos. Reinventa-se a roda mais vezes do que devia.
3. Desenho e construção. Desenhamos e construímos em iterações de âmbito fixo. Tem uma versão publicada nas mãos desde a primeira semana, atualizada à medida que o trabalho avança, por isso nunca fica à espera de uma grande revelação. O desenho, a construção e o lançamento ficam nas mesmas mãos, sem passagens de testemunho entre si e quem escreve o seu código.
4. Entrega. Lançamos para utilizadores reais, ficamos por perto enquanto chegam as primeiras reações e ensinamos a sua equipa a gerir o produto. O código é seu.

O que recebe

• Uma definição de produto com o âmbito bem cortado: os utilizadores, o problema, a medida de sucesso e o que fica deliberadamente de fora.
• Um MVP a funcionar com as peças que interessam: modelo de dados, API, interface, publicação e o trabalho pouco vistoso de fiabilidade que evita que um lançamento se transforme num incidente.
• Um roadmap para o que vem a seguir, ordenado pelo que os primeiros utilizadores fazem de facto.
• Uma base de código que é inteiramente sua, no seu repositório e na sua infraestrutura, onde pode continuar a construir com quem quiser.

Como decorre o trabalho

1. Uma conversa curta. Traga a ideia no estado em que estiver. Sai com uma opinião honesta sobre a versão mais pequena que vale a pena construir.
2. Definição do âmbito. Fica por escrito a primeira iteração: o que entra, o que fica de fora e o que significa «feito».
3. Iterações. Iterações de âmbito fixo, normalmente de duas a seis semanas cada, com preço fechado antes de começar. Normalmente começamos duas semanas depois de fecharmos o âmbito.
4. Lançamento e passagem de conhecimento. Utilizadores reais e um produto que a sua equipa consegue gerir, com a documentação de como se publica e se altera.

O que faz variar o custo. Não publicamos preços, porque raramente dois MVP custam o mesmo. O que mais pesa é o número de tipos de utilizador e de permissões, as integrações com sistemas que já usa, se basta funcionar na web ou se também precisa de uma aplicação móvel, a sensibilidade dos dados, o nível de acabamento da primeira versão e o que já existe e pode ser aproveitado. Fica tudo por escrito antes de começar. Sem faturas-surpresa.

Pedir uma proposta

Perguntas frequentes

Quão pequeno é «mínimo»? Pequeno o suficiente para responder à sua pergunta principal com utilizadores reais, e não mais pequeno do que isso. Se não se pode confiar no produto, também não se pode confiar na resposta que ele dá. Cortamos funcionalidades, não fiabilidade.

Vamos ter de deitar o MVP fora mais tarde? Não é esse o plano. Construímos sobre fundações que podem crescer: um modelo de dados claro, fronteiras limpas e publicação automatizada. Algumas partes vão mudar, e é para isso que serve. O MVP é a primeira versão do produto, não um protótipo descartável.

De quem é o código? Seu. O trabalho feito à medida é-lhe cedido com o pagamento integral, no seu repositório e na sua infraestrutura. A passagem de conhecimento faz parte do trabalho, não é um extra.

Precisamos primeiro de um sócio técnico? Não. Muitas empresas procuram-nos precisamente porque não o têm. Orientamos as decisões técnicas consigo e explicamo-las pelo caminho, para que no fim saiba mais do que quando começou.

O que acontece depois do lançamento? Ficamos por perto nas primeiras reações e planeamos consigo a iteração seguinte. Não fazemos contratos de manutenção corrente. O produto cresce em iterações definidas, ou a sua equipa leva-o para a frente.

Serviços relacionados

• Arquitetura de Soluções: quando o produto é suficientemente importante para querer o mapa antes da viagem.
• Orientação Técnica e de Negócio: quando precisa de uma resposta honesta sobre se deve sequer construí-lo.

Traga-nos a ideia

Uma ideia num guardanapo ou um produto parado nos 80%. Diga-nos o que quer provar. Respondemos num dia útil, normalmente com perguntas e uma primeira opinião honesta.

Começar um projeto