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.

 

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