O MVP permite que a equipe de possa entregar um produto nas mãos de usuários rapidamente, à um baixo custo. No entanto, essa velocidade precisa ser equilibrada com a sustentabilidade, e é aí que entra a Arquitetura Mínima Viável (MVA). 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 — em inglês, Minimum viable Architecture (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.
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:
- An Introduction to Minimum Viable Architecture – InfoQ
- Minimum Viable Architecture – SoftwareYoga
- MVA (minimum viable architecture) – LinkedIn
Leia mais sobre MVA e DevOps para MVP em DevOps para entrega de produtos enxutos
