Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo (Portuguese Edition)

by Paulo Caroli

A visão mais ingênua sobre o desenvolvimento de software ágil é a que todo mundo chega e começa a escrever o código sem gastar um tempo inicial descobrindo o que fazer.

mas ainda reconhecemos que há valor em começar algo com um senso de direção inicial.

lembrarmos de que nada nos ensina mais sobre o que queremos do que um produto incompleto que foi lançado, usado, testado.

O resultado não é um plano de trabalho detalhado, que descobrimos rapidamente que se torna irrelevante, mas sim um conjunto de objetivos-guias que nos levam na direção correta.

Ele não planeja um produto final,

com todas as funcionalidades que nossos usuários precisam, mas foca em um produto inicial que podemos lança...

O estilo colaborativo e dinâmico da Lean Inception é o segredo de tanto sucesso!

MVP (minimum viable product ou produto mínimo viável) – uma versão simples do produto que é entregue aos usuários para validar as principais premissas do negócio.

Mas como resolvemos o que precisa estar no MVP para iniciar o projeto ágil o mais rápido possível?

Mesmo num projeto ágil, antes de sair fazendo, é preciso alinhar e definir os objetivos, as estratégias e o escopo do produto. Não queremos exagerar e definir todo produto, mas na prática percebemos que é necessário fazer algo.

As inceptions variavam de um projeto para outro, mas elas geralmente forneciam alinhamento entre o negócio e o pessoal técnico e criavam uma lista ordenada de histórias de usuários com estimativas além de um plano de lançamento do produto.

a característica principal de um MVP é que fazemos algo para aprender se vale a pena continuar construindo o produto.

Grandes projetos usam as Lean Inceptions para começar a trabalhar de forma enxuta, entregando valor mais rápido e com maior frequência.

O workshop ajuda a escolher e validar as funcionalidades que são realmente valiosas para seus usuários.

Organizações menores (como startups) usam as Lean Inceptions para pegar uma ideia que foi testada por alguns MVPs pré-software e a transformam em um produto de software.

Ele não substitui as sessões de ideação, as entrevistas com os usuários, a pesquisa de mercado, a revisão da arquitetura, a análise da concorrência ou o canvas de mapeamento de projetos e negócios.

É uma técnica específica que é parte do entendimento do que é necessário para construir um produto de sucesso.

Os benefícios de entregar o mínimo viável irão ajudá-lo a levar o produto ao mercado muito mais rápido, a minimizar os gastos e a evoluir o produto baseado na necessidade real dos seus usuários.

MVP é a versão mais simples de um produto que pode ser disponibilizada para a validação de um pequeno conjunto de hipóteses sobre o negócio.

o objetivo do MVP é somente a validação do primeiro passo, do produto mínimo, bem menos elaborado do que a versão final.

porém viável – para verificar se o direcionamento está correto. Esse é o conjunto inicial de funcionalidades necessárias para o processo de validação de hipóteses e aprendizagem sobre o negócio.

A expressão minimum viable product apareceu pela primeira vez em 2000, em um artigo de Willian Junk, chamado O equilíbrio dinâmico entre custo, cronograma, recursos e qualidade em projetos de desenvolvimento

a ideia por trás de MVP é o desenvolvimento validado e guiado pelos resultados iniciais.

É muito importante compreender que o MVP promove uma criação evolutiva. Logo, a arquitetura, bem como o ferramental

construção do produto, deve permitir a evolução gradual e contínua.

enquanto que o processo de criação tradicional não fornece qualquer valor até o final, quando todo o projeto está pronto.

Coloque algumas vigas de madeira em diferentes locais do riacho e depois verifique qual delas é a mais utilizada para a travessia.

Pense grande, comece pequeno, aprenda rápido! É extremamente necessário ter uma visão ampla, pensar grande. Porém, você deve começar pequeno. Dê um passo curto e aprenda com ele. Esse passo é o MVP. MVP serve para validar hipóteses, para falhar e aprender rápido. Nesse contexto, menos é mais. Não desperdice tempo, dinheiro e esforço criando o produto errado.

M é de mínimo, por isso, muito provavelmente, há somente uma hipótese, somente um pequeno aspecto do negócio, para um segmento específico de usuários, com apenas uma ou poucas funcionalidades.

O fator “uau” é aquilo que diferencia o seu produto no mercado, aquilo que conquista seus usuários e os transforma em ávidos promotores do produto.

A ilustração acima reitera a importância desses quatro fatores. O MVP é uma fatia fina do produto, contendo cada um desses fatores.

O início do Facebook ilustra a ideia de uma fatia fina de MVP. Veja como era simples, inacabado, incompleto. Entretanto, era factível, usável, tinha valor

era incrível. Uau, os usuários queriam mais!

Reproduções de telas de abertura e de perfil de usuário no Facebook, em 2004.

O MVP deve ser factível (de ser criado), facilmente usável, gerar muito valor e ser incrível – Uau!

“Errar e aprender rápido”, tenha muita cautela ao usar essa frase.

Existem erros e erros. Ninguém quer um erro grande, aquele que não tem reparo e deixa o seu cliente com uma péssima impressão.

“Validar e aprender rápido”, eu prefiro essa frase. Você vai criar um MVP que o ajude a validar algo, mas que não deixe o usuário ...

Se cair, não era um MVP. Era menos do que isso, pois não era viável, e seus usuários não deveriam ter sido expostos a isso. Você não pode deixar a ponte cair.

Respeite a arquitetura, mas construa o MVP de ponta a ponta, com uma experiência completa.

Ou seja, o produto não é arquitetado bloco a bloco, mas sim de MVP a MVP, de forma que, os arquitetos de blocos (as pessoas técnicas que decidem as partes internas do produto) ampliem a estrutura do produto conforme a evolução dele.

“Para cada problema complexo, há uma resposta clara, simples e errada.”

A pessoa facilitadora da Lean Inception é um guia que estará liderando as discussões dos participantes durante o workshop.

o papel de liderar a discussão não necessita que a facilitadora seja a participante principal. Muito pelo contrário.

Uma persona representa um usuário do produto ou serviço, descrevendo não só o seu papel, mas também suas necessidades específicas.

A descrição de uma funcionalidade deve ser o mais simples possível: o usuário está tentando fazer uma coisa, então o produto deve ter uma funcionalidade para isso. Qual funcionalidade é essa?

O que deve ter no produto para atender às necessidades da persona? Quais funcionalidades devemos construir para atingir esse objetivo do produto?

Se estivéssemos com um orçamento muito curto e pudéssemos trabalhar em apenas um objetivo, qual seria esse?

Qual é a combinação mínima de funcionalidades que devem ser disponibilizadas para validar um pequeno conjunto de hipóteses sobre o negócio?

Considere uma dupla de desenvolvedores. Um sabe mais do negócio, outro menos. Um mais sênior, outro mais júnior. Um mais experiente na tecnologia, outro mais novato. Quanto tempo leva para eles completarem tal tarefa?