Após a definição do seu Minimum Viable Product

Os próximos passos após a definição do seu Minimum Viable Product (veja o post anterior desse blog) é justamente contruir e validar esse MVP.


Que funcionalidades precisam estar disponíveis para que seus Early Adopters comecem a utilizar seu produto?
Abaixo encontram-se as Histórias de Usuário para o MVP de LiveSource:


MVP 1: LiveSource é um Toolkit para web que carrega o código fonte de seu software e gera uma versão de fácil leitura desse código, compreensível por todos os integrantes da equipe de desenvolvimento inclusive pelos não-programadores.

• "Como um usuário, eu gostaria de visualizar a lista dos meus projetos de software."
• "Como um usuário, eu gostaria de visualizar a lista de todos os arquivos fontes de cada um dos meus projetos."
• "Como um usuário, eu gostaria de uma visualização de fácil compreensão para cada um dos arquivos do código fonte de cada projeto."

LiveSource é um projeto bastante extenso e complexo, mas como vocês podem observar só existem três Histórias de Usuário no meu MVP. É assim que um projeto Lean deve ser: começar pequeno, eliminar o desperdício, entregar rapidamente, etc...

Junto com a lista de Histórias de Usuário, é importante ter também um rascunho de como seria a interface com o usuário de seu produto. Pode ser algo bem simples, como um desenho em um pedaço de papel, ou a foto de um rabisco num quadro de trabalho. Chamamos isso de Low-Fidelity Prototype.

Figure 1: Low Fidelity Prototype for the LiveSource MVP

Neste ponto do processo de desenvolvimento, já estou utilizando algumas das técnicas do Desenvolvimento Ágil. Podemos agora começar a planejar uma Sprint, definir um Product Backlog, estimar e priorizar as Histórias de Usuário, etc.

Para simplificar ao máximo, para essa primeira entrega do MVP vamos descartar as páginas de login e até mesmo a necessidade de um banco de dados. Vamos carregar todo o código fonte a partir de um repositório de arquivos remoto, como Git ou Subversion.

Para o exemplo de LiveSource, vamos considerar as três histórias acima como prioridade e vamos inserí-las na primeira Sprint do produto. E então vamos descrever todas as tarefas necessárias para implementar essas histórias.

Tarefas para a Interface com o Usuário:

• Listar todos os projetos disponíveis.
• Quando o usuário clica em um projeto da lista, o sistema exibe uma lista com todo o arquivos do código fonte armazenado no repositório desse projeto.
• Quando o usuário clica em um arquivo na lista do código fonte, o sistema exibe uma versão de fácil leitura para esse código fonte.

Tarefas do lado do Servidor:

• Criar uma conexão com o servidor remoto de arquivos dos projetos.
• Carregar a lista de todos os arquivos fonte do projeto armazenados no repositório remoto.
• Carregar o conteúdo do arquivo fonte quando selecionado.
• Extrair todos os comentários e a documentação do conteúdo de um código fonte.

Eu poderia adicionar algumas Spikes a essa lista, como por exemplo uma tarefa para estudar as APIs para conectar com o repositório de arquivos dos projetos, ou uma outra tarefa para explorar como extrair a documentação e os comentários de um código fonte. Cada uma dessas tarefas podem ser complexas e se estender por dias de trabalho. Só não vou adicioná-las a minha lista neste momento porque eu já tive esses tópicos explorados enquanto eu estava desenvolvendo o protótipo do meu produto.

O próximo passo é distribuir as tarefas pela equipe de desenvolvimento. Deixe que cada programador escolha quais tarefas quer implementar e quando cada um pode se comprometer em implementá-las.

Enquanto estiver implementando seu MVP, tente construí-lo o mais independente possível. Quando novas funcionalidades surgirem, tente não simplesmente adicioná-las ao seu MVP já existente, mas sim, tente criar um novo MVP, também independente, de uma maneira que se possa conectar ou desconectar funções sem afetar o sistema como um todo.

Enquanto estiver implementando seu MVP você já deve permanecer em contato com seus ealy adopters, carregar dados reais e testar a usabilidade do sistema. O quanto antes você começar a receber feedback melhor. A idéia é que você já termine a implementação com seus early adopters utilizando o sistema.

A principal mensagem desse post é: Não inicie um novo MVP enquanto os seus early adopters ainda não estiverem utilizando os MVPs que você já desenvolveu. Há muito o que se ajustar depois que se começa a receber feedback dos clientes, e esses ajustes na maioria dos casos são muito mais importantes do que novas funções a serem desenvolvidas.

O melhor momento para se começar a adicionar novas funções ao sistema é quando já se estabeleceu a marca de 40% dos usuários declarando que ficarão "Muito Desapontados" se eles não mais puderem utilizar o seu produto. Essa técnica é chamada de Product/Market Fit.

Se você não está atingindo o seu Product/Market Fit, o que se tem a fazer é reiniciar todo o processo de desenvolvimento de clientes novamente. Retorne ao protótipo e ouça mais os seus early adopters. Que razões eles alegam para utilizar ou não o seu produto. Ajuste o seu MVP até que você atinja o seu Product/Market Fit.

Não é nada fácil atingir esse ponto. Exige-se muita determinação, e normalmente necessita-se de várias iterações para estar pronto para um crescimento em escala. O processo descrito aqui é um bom caminho inicial para o sucesso no final.