Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

Arquitetura Mínima Viável (MVA)

O MVP permite que a equipe de possa entregar um produto nas mãos de usuários rapidamente, à um baixo custo. Quanto mais cedo o produto for utilizado, mais se pode aprender com os usuários para melhorá-lo. A melhor maneira de aprender e evoluir é ouvir de usuários que utilizam o software, não de pessoas olhando para uma folha de papel em branco tentando visualizar como um sistema deve funcionar.

 

Um dos desafios que a abordagem MVP apresenta é de que ela pode levar à falta de uma arquitetura. Quando construindo um produto do zero, a pressa para entregá-lo pode vir ao custo de uma arquitetura sustentável. Deve haver balanço entre velocidade de entrega e qualidade. É necessária uma arquitetura mínima viável (MVA). Isso implica em ser capaz de desenvolver novas features rapidamente e medir logo o seu impacto. A sua arquitetura precisa ser otimizada para isso.

mva-ptbr

Então, como definimos qual o MVA? Essas perguntas ajudam:

 

– Quantos usuários utilizarão o sistema no lançamento inicial? Nos primeiros 6 meses? Dentro de um ano?

– Os usuários iniciais serão internos, externos, ou ambos?

– Quantas transações por segundo esperamos no lançamento? Nos primeiros 6 meses? Dentro de um ano?

– Como os usuários começarão a utilizar o sistema?

– Qual o nível de segurança e auditabilidade exigido no lançamento? Dentro de 6 meses? Dentro de um ano?

 

Há diversas outras perguntas para guiar a discussão. Estas perguntas ajudam a equipe a definir os requisitos básicos para lançar no mercado. Embora não entre no mérito de definir uma arquitetura completa e perfeita para o produto final, isto é diferente de ignorar a definição de uma boa arquitetura. O foco é no quanto de investimento é necessário para lançar e, em seguida, definir um plano para evoluir a arquitetura conforme o número de usuários aumenta e requisitos são adicionados.

 

Tentar construir o sistema perfeito raramente é a abordagem correta. Vamos dizer que a resposta do dono do produto para estas perguntas sejam as seguintes:

 

– Haverá apenas cinco usuários internos nos primeiros três meses. Seis meses a partir de agora os nossos dois primeiros clientes externos estarão usando os sistemas em modo piloto. Um ano a partir de agora lançaremos o sistema para todos os clientes.

– No lançamento haverá uma quantidade trivial de transações. Daqui a seis meses o tráfego será moderado. No próximo ano, o tráfego será extremo.

– Inicialmente, adicionaremos usuários ao sistema através de uma interface. No futuro, os clientes terão gestão de ID self-service. Espero que isto aconteça em um ano a partir de agora.

– Nós só precisamos de segurança mínima para a primeira versão. Para o piloto, precisamos de segurança e auditoria completos.

 

Com base nessas respostas, muita discussão e definição pode ser adiada para após o lançamento da primeira versão. Por que gastar tempo na estratégia de cache agora, quando não vemos a necessidade no horizonte de um ano? Nós podemos colocar fora diversas tarefas de gerenciamento de ID para mais tarde também. Deve-se evitar discussões imediatas sobre requisitos que só virão no futuro, de forma que seja implementado apenas o estritamente necessário da melhor forma possível. É por isso que o MVA é tão importante.

 

Esta abordagem depende da disciplina e confiança entre o dono do produto e da equipe de desenvolvimento, para garantir que ambas obtenham os resultados desejados: o produto é entregue rapidamente com um sistema bem arquitetado e com pouca dívida técnica.

Seguem alguns links sobre MVA:

Leia mais sobre MVA e DevOps para MVP em DevOps para entrega de produtos enxutos

Paulo Caroli

Paulo Caroli é um consultor, autor e palestrante altamente respeitado, conhecido por criar a metodologia Lean Inception. Como autor de cinco livros influentes sobre agilidade nos negócios, incluindo o best-seller Lean Inception, ele traz uma vasta experiência prática para seu papel como Inception & OKR advisor na Thoughtworks - Expert in Product and Project Inception, Advisor on Team OKR. Paulo está profundamente envolvido em workshops estratégicos, desenvolvimento de produtos digitais e na orientação de equipes sobre agilidade nos negócios e estratégia de produto.
Lean Inception seguida pelo PBB

Lean Inception seguida pelo PBB

Neste artigo, você aprenderá como combinar Lean Inception e Product Backlog Building (PBB) para otimizar o desenvolvimento de produtos. Primeiro, a Lean Inception define funcionalidades e cria o Canvas MVP. Em seguida, o PBB detalha essas funcionalidades em itens de backlog e histórias de usuário, priorizando e planejando as entregas em Sprints. Essa combinação proporciona uma abordagem eficiente e colaborativa, resultando em um backlog bem estruturado e um plano de entrega claro.

ler mais
O Canvas MVP

O Canvas MVP

Construir produtos de muito sucesso, reduzindo tempo, uso de recursos e alinhados às necessidades dos usuários, é o desejo de qualquer organização ou negócio. Neste artigo, o criador do método Lean Inception, Paulo Caroli, traz a você mais detalhes sobre o Canvas MVP, importante ferramenta utilizada para validar ideias de produtos.

ler mais
Construir ou Comprar MVP: Matriz para tomada de decisão

Construir ou Comprar MVP: Matriz para tomada de decisão

O artigo “Construir ou Comprar MVP” ajuda na decisão crucial de desenvolver ou comprar software para novos empreendimentos, enfatizando a rápida validação de ideias de negócios. Ele apresenta uma matriz de decisão e uma ferramenta Excel para ajudar as partes interessadas a pontuar e comparar opções, garantindo que a decisão de construir ou comprar esteja alinhada com os objetivos estratégicos e operacionais. Essa abordagem promove um processo de tomada de decisão colaborativo e baseado em dados.

ler mais

Pin It on Pinterest