
#produto Você viaja com luxo ou não passa da esquina com o seu MVP?
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í…
