Imagem: Playbuzz (Google Images)

#produto Você viaja com luxo ou não passa da esquina com o seu MVP?

Raul Teodoro
Aug 22, 2017 · 3 min read

Muito projetos, principalmente os de software, falham nas entregas porque são construídos e interpretados de forma errada em vista da expectativa do cliente. Este texto tem como objetivo exemplificar o pensamento sobre o processo de construção Ágil de um MVP (Minimum Viable Product) a partir de uma conversa com o amigo Gilberto Nunes (http://bit.ly/2wmaEJV).

Pois então… Você já viu esta imagem abaixo antes?

Not like this…

Desenhado por Henrik Knieberg, a primeira fileira da imagem (Not like this…) sugere justamente o erro comum sobre o desenvolvimento iterativo e incremental de um produto.

Neste caso o desejo do cliente é construir um carro. A pergunta que ele faz é: "Quem quer metade de um carro?". O que o cliente vai fazer com apenas uma roda neste momento? A resposta é nada, e se continuar assim até você construir o carro por completo o cliente continuará insatisfeito por não poder testá-lo, dar feedback e contribuir para cumprir o objetivo inicial.

Pensando assim, todo este tempo que o time desprendeu esforço para construir o que o cliente "queria" foi um grande risco, pois até a entrega final o mercado pode ter mudado, o potencial usuário final pode ter mudado de ideia sobre comprar um carro, e todo o esforço ($$$) será em vão.

Like this!

A segunda abordagem (Like this!) da imagem, até então sugerida como correta, propõe o mesmo desejo do cliente que é construir um carro, porém agora o foco se dá em entender melhor qual o objetivo do cliente ao construir o carro. Sendo assim, descobre-se que o objetivo real é deslocar-se do ponto A até o ponto B rapidamente.

O principal objetivo desta entrega inicial é receber feedback do cliente antes de cair nas mãos do usuário final. Então, o time entrega a menor parte do que seria um produto viável, ou seja, um Skate que cumprirá o objetivo inicial do cliente. Isto é o que chamamos de MVP, ou como diz o próprio Henrik, "Earliest testable/usable/lovable Product". O cliente recebe vários produtos minimamente viáveis para utilização e, consequentemente, vai dando feedback sobre o que acha, sendo possível assim melhorar/evoluir o produto.

Mas peraí… Um Skate não evolui para uma bicicleta, que não evolui para um carro...

Pois é… Veja na imagem que ao receber um Skate o cliente continua triste e desapontado com a entrega realizada, como no primeiro exemplo, pois não recebeu um produto "Lovable". Sendo assim, é bem provável que o usuário também fique desapontado se receber o mesmo produto, ou até mesmo fique desinteressado ao esperar para receber o carro. Vendo por este lado, That’s NOT OK! receber feedback por algo que não cumpre o real objetivo do cliente.

Talvez a analogia a partir do Skate não represente bem o modo Ágil de desenvolvimento iterativo e incremental afinal. Apesar de um Skate resolver o problema inicial do cliente que é ir do ponto A ao ponto B, a primeira pergunta que se deve fazer sempre é: Eu estou evitando o desperdício ao resolver o problema real do meu cliente desenvolvendo este produto inicial?. Pode ser que neste caso eu esteja criando vários projetos que serão jogados fora, e não evoluindo do mesmo.

Em geral, o Skate não está resolvendo o mesmo problema que um carro, a menos que o problema seja, por exemplo, chegar na esquina com baixo esforço.

O que acha? Comenta aí…

)

Raul Teodoro

Written by

Agile Methodologies, Scrum, Kanban, XP, Lean… Design Thinking/Sprint, Marketing, Web, Mobile: https://www.linkedin.com/in/raulteodoro/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade