MPV - Minimo produto viável.

MVP

Na prática não é tão fácil construirmos um MVP, porque sempre tendemos ao perfeccionismo e consequentemente queremos construir algo caro e demorado para só então testar com os clientes.



Com este breve texto espero ajudar a construir um MVP de forma mas simples e rápida.

“Se você não tem vergonha de lançar seu produto, já passou da hora de lançar” Bruno

Pesquisa de mercado

“Não é a empresa que define o mercado. É o cliente” - Peter Drucker.

Por quê fazer uma pesquisa de mercado?

• Entender melhor seus clientes
• Se preparar para escalar as operações
• Determinar mercados-alvo de forma realista
• Ter mais dados para resolver um desafio específico do seu negócio
• Planejar estratégias efetivas

Tenha um objetivo claro ao realizar a pesquisa

Antes de fazer a pesquisa certifique se que tem clareza suficiente para responder essas 3 perguntas.

• Qual o motivo de sua pesquisa?
• Que informação será sondada?
• Como a informação será usada?

Exemplo prático

Alguns anos atrás (2012) havia uma ideia de fazer um aplicativo de controle financeiro similar ao Guia Bolso. Para entender melhor os futuros clientes do aplicativo e suas reais necessidades, fiz pesquisas de mercado. Uma dentre os concorrentes e outra através do formulário (link).

Qual foi o motivo da pesquisa?

As pesquisas tinham por motivo levantar as dificuldades de controle financeiro das pessoas no Brasil e com a compilação dos dados gerar uma proposta de aplicativo para resolver esses problemas.

Que informação foi sondada?

Informações pertinentes ao controle financeiro pessoal e familiar agrupados por faixa média de renda familiar.

Dificuldades no modo atual de controle financeiro.

O que não existe em questão de software (aplicativo) que iria ajudar no dia a dia financeiro.
Como os atuais sistemas de controle financeiro funcionam.

Como a informação foi usada?

A informação foi utilizada para gerar um documento de requisitos (explicado adiante) e um protótipo.

Breve estudo de caso - League of Legends

League of Legends (abreviado como LoL) é um jogo eletrônico do gênero multiplayer online battle arena. É um jogo gratuito para jogar e inspirado no modo Defense of the Ancients de Warcraft III: The Frozen Throne.

Mas porque estudar o LOL?

É um case de grande sucesso: Em julho de 2012, foi o jogo para computador mais jogado na América do Norte e Europa em termos de número de horas jogadas. Em 2017 League of Legends arrecadou US$ 2,1 bilhões.

Nasceu através de uma análise de mercado com base em dois grandes jogos na época. Foi identificado pequenos modos de jogar e ações que os jogadores desejavam.

Ele não foi uma ideia nova e revolucionária, apenas adaptou um grande jogo que já existia para atender as necessidades do mercado.

Com essas breves informações quero destacar que:

• Caso exista algo parecido com o que você quer fazer descubra o que o concorrente não faz. Ou que faz de forma precária e melhore seu negócio.
• Você não precisa ter grandes idéias. “Trabalho duro vale mais que grandes idéias” - Murilo Gun

Geralmente as pessoas são mais acessíveis do que você pensa

Parafraseando Tim Ferris ao dizer que ‘não tenha medo de falar com seu Yoda’, as pessoas que você considera grandes mestres, mentores, ou simplesmente é um grande fã, são mais acessíveis do que você pensa, basta tentar contactá-las.

Em meados de 2006 ou 2007 no meu ensino médio, uma colega de classe era super fã do cantor Sérgio Lopes. Pela internet ela conseguiu o contato com ele, organizou um evento beneficente para ele em Recife e o conheceu pessoalmente.

Ao fazer a pesquisa para o aplicativo de gestão financeira, entrei em contato autores de livros simplesmente enviando um e-mail. Tive um bom índice de resposta. Como foi o caso de Vera Rita escritora do livro Psicologia econômica.

Caso diretamente não consiga entrar em contato com seu ‘Yoda’ (Mestre), segue algumas dicas faladas por Thiago Niro (Primo Rico) no youtube em ‘os 4 passos para você desenvolver seu networking’.

Requisitos

“No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento.”

Segundo o dicionário requisitos são condições necessárias, geralmente obrigatórias, para se conseguir algo; quesitos: tinha os requisitos para fazer a inscrição.

Sintomas de uma Especificação de Requisitos inadequada

Se você nunca viu o expert em linhas vermelhas, assista quando tiver um tempinho (em inglês - vídeo de humor).

Nem sempre as pessoas sabem o que querem. Recomendo que haja um documento descrevendo as funcionalidades (requisitos funcionais) do sistema agrupados por assunto (ex.: controle de estoque, controle de caixa, etc) e identificados no seu nível de importância (Desejável, Importante e Necessário).

Escreva tudo

Na primeira versão do documentos de requisitos, escreve tudo que julgue que o sistema de ter.

Tendo uma boa classificação dentre o que é necessário (que não pode faltar), importante (que é bom ter mas pode não ter) e desejável (que é bom mas não é importante) podemos separar o o backlog para o primeiro MVP.

Não se preocupe em deixar o documento bonito e com tudo que o software terá. Isso será impossível. O documento estará em constantes atualizações.

Protótipo papel vs Protótipo funcional

Recomendo fazer protótipos sempre que possível. Eles nos permitem identificar possíveis falhas e tornar o aplicativo mais intuitivo.

Com um simples papel e caneta podemos fazer um protótipo no papel. Ideal para analisar a usabilidade do aplicativo de forma barata. Porém há coisas que só se enxerga quando se vê na tela. Construa o mais rápido possível telas que não funcionam e botões que chamam outras telas que não funcionam. Assim temos uma forma de avaliar novamente se a usabilidade está realmente boa.

Qual metodologias é melhor para desenvolver um aplicativo?

A resposta para essa pergunta dependerá dos seus objetivos e da sua equipe de desenvolvedores. Cada equipe trabalha de um jeito e tem facilidade em utilizar um método. Não há a necessidade de segui-los ao pé da letra.

Uma metodologia bem adaptável e ágil, que pode não ser a melhor para a sua empresa, mas é produzirá um MVP rápido é a SCRUM.

Por que desenvolver aplicativos em Scrum?

A grande questão do desenvolvimento de aplicativos é que, em geral, não se sabe ao certo como ele irá ficar no final do processo. Existe uma ideia inicial e funcionalidades fundamentais sobre o qual o aplicativo será construído, mas apenas durante o desenvolvimento se tornam claros os recursos e as características que permitirão ao aplicativo cumprir sua finalidade e lhe darão sua identidade.

Durante o desenvolvimento de aplicativos surge a necessidade de diversas funcionalidades que, embora não tenham sido pensadas no início do processo, agregam muito ao produto final de modo que por vezes são até essenciais para que ele cumpra seu papel. Em contrapartida podem haver outras que no começo do desenvolvimento faziam todo sentido mas que acabam se revelando desnecessárias.

Além da parte funcional do aplicativo existe também a questão do design. É muito difícil para o time de desenvolvimento criar um aplicativo que tenha as características desejadas pelo cliente e que funciona exatamente da maneira que ele espera apenas com uma descrição inicial de como tudo deve ser. Para que o aplicativo fique como esperado o processo de desenvolvimento deve ocorrer em ciclos nos quais uma pequena parte do projeto é desenvolvida e em seguida mostrada ao cliente que validará ou requisitará uma mudança encerrando o ciclo.

SCRUM

Não irei explicar o SCRUM, apenas descrever uma forma de aplicá-lo. Não use essa forma ao pé da letra, adapte a sua realidade.

Com o scrum, em resumo, iremos expandir os requisitos de uma funcionalidade justificando seu benefício em um documento chamado histórias do usuário. Não vamos expandir todos os requisitos, no decorrer do projeto os requisitos vão sendo amadurecidos e convertidos em histórias de usuários.

Release

De forma simplificada, teremos uma release (versão) do produto como uma entrega mensal. Cada release deve conter algo que gere valor para o produto. Algo que possa ir para produção mesmo de forma incompleta. Se seu objetivo por exemplo é fazer um software de edição de texto similar ao word da microsoft, inicie com um bloco de notas na primeira release e vá evoluindo.

Sprint

Cada release mensal é dividida em sprints semanais.

Antes de iniciar a primeira sprint devemos separar dentre os requisitos o que será feito na release, expandir os requisitos detalhando-os o máximo possível quebrando tudo em pequenas atividades de preferência diárias.

Reuniões diárias

A equipe deve ter rápidas reuniões diárias, em pé para acabar mais rápido, onde deve ser compartilhado com todos o que cada um está fazendo e dificuldades encontradas. Assim toda a equipe estará ciente de tudo e poderá ajudar melhor uns aos outros.

Aprender o mínimo necessário de programação

Independente do seu negócio, principalmente se está começando com poucos recursos, recomendo aprender o mínimo de programação, fazer um pequeno site com um armazenamento de dados.

Com isso você terá uma boa noção das reais dificuldades ao se fazer um programa e poderá negociar melhor valores e prazos com programadores (ou você mesmo fazer seu aplicativo).

Você não é obrigado a aprender programação. Essa é a minha opinião sobre o assunto.

Bibliografia

https://pluga.co/blog/marketing/como-fazer-pesquisa-de-mercado/

https://pt.wikipedia.org/wiki/League_of_Legends

https://medium.com/lfdev-blog/como-escrever-requisitos-de-software-de-forma-simples-e-garantir-o-mínimo-de-erros-no-sistema-app-74df2ee241cc

https://www.umov.me/metodologia-agil-no-desenvolvimento-de-aplicativos/

https://cursos.alura.com.br/forum/topico-historia-de-usuario-x-requisito-66032

https://fluxoconsultoria.poli.ufrj.br/blog/tecnologia-informacao/desenvolvimento-de-aplicativos/

https://www.ideianoar.com.br/como-desenvolver-um-mvp-de-verdade/

https://usemobile.com.br/metodologias-para-desenvolver-um-aplicativo/