Pontos Principais
-
Após 15 anos de Agile e Lean Startup, a maioria das empresas - startups e grandes empresas - lançam novas iniciativas com Produto Mínimo Viável (MVP) e ciclos Construir-Medir-Aprender;
-
Existem algumas armadilhas comuns que as organizações caem ao construir um MVP;
-
O mínimo viável é uma compensação, e é difícil obter o equilíbrio certo;
-
Embora o MVP seja frequentemente planejado para ser descartado, raramente há tempo ou capacidade para começar do zero e o MVP se torna o produto de produção;
-
Existem algumas verificações que podem ser usadas para caminhar na linha tênue entre robustez e velocidade ao produzir um MVP.
Nestes tempos turbulentos, muitos executivos estão considerando a tecnologia da informação como um ativo estratégico para enfrentar os tempos difíceis que estão por vir. Projetos são lançados para criar produtos digitais e aproveitar novas oportunidades, mas mesmo com forte pressão para fazer os lançamentos o mais rápido possível, há lições importantes a serem lembradas a fim de evitar o desperdício de oportunidades vitais.
Depois de 15 anos trabalhando com Agile e Lean Startup, a maioria das empresas, tanto novas quanto consolidadas, lançam as iniciativas como um Produto Mínimo Viável (MVP, do inglês Minimum Viable Products) e usando ciclos de Construir-Medir-Aprender (Build-Measure-Learn), antes de embarcar em projetos de grande escala. A lógica está correta. Reunir uma pequena equipe, desenvolver em pequenos incrementos para conseguir feedback sólido do cliente com menos custo, validando as hipóteses técnicas e de negócios antes de comprometer grandes recursos em uma ideia, que pode ou não dar certo.
Mas o que acontece depois que o MVP é lançado?
O sucesso é uma opção! O MVP mostrou que há uma oportunidade de negócio a ser perseguida e a empresa sabe como se dirigir à ela. O movimento lógico neste estágio é trocar de marcha e acelerar com tudo, inserindo mais recursos para aproveitar a oportunidade.
É neste momento que os problemas começam:
- O CTO começa a adicionar novos desenvolvedores à equipe, mas os novos contratados se perdem nos códigos que foram montados às pressas e agora são incompreensíveis e que não possuem documentação;
- O número de bugs continua aumentando até que a equipe perceba que não foram detectados antes de chegarem aos clientes porque a cobertura do teste era mínima;
- Os desenvolvedores da equipe inicial agora precisam treinar outros engenheiros, mas são muito jovens ou não estão preparados para essa tarefa;
- Conforme a equipe de desenvolvimento cresce, os CTOs se veem incapazes de criar equipes diferentes porque a estrutura da base de código não permite que essas equipes trabalhem separadamente sem interromper umas às outras;
- A aplicação está começando a apresentar lentidão à medida que o número de usuários simultâneos aumenta, devido ao design inadequado do modelo de dados. Alterar o modelo do banco de dados resultaria em grandes mudanças no código existente;
- A equipe de SEO está solicitando grandes mudanças na estrutura das páginas web, mas a maneira como os componentes foram projetados, precisará reescrever boa parte do frontend;
- A equipe de infraestrutura quer adicionar mais instâncias no servidor para oferecer suporte à carga de trabalho crescente, mas a aplicação não oferece suporta.
Nesse ponto, os CTOs e suas equipes normalmente defendem uma reescrita completa, o que normalmente não condiz com a realidade. O produto começou a ganhar impulso, por isso a pressão vinda tanto do alto como do baixo escalão da empresa pode ser muito alta.
Esta é uma situação comum, tanto que foi o que aconteceu conosco quando estávamos trabalhando em um grande projeto na indústria de transportes. O projeto era ambicioso e arriscado, por isso a equipe inicial decidiu ser pragmática e não investir demais no primeiro MVP, que saiu rapidamente, validando a ideia por usuários entusiasmados, apressando todos os envolvidos para levar em consideração seus comentários para lançar uma segunda versão que iria encantar esses earlier adopters. Algumas versões depois, quando todo mundo estava correndo para não perder o momentum, a equipe foi pega de surpresa tendo que decidir coisas importantes e rapidamente, levando a um período muito difícil para todos os envolvidos. Este foi um chamado para o despertar, que nos levou a aprofundar essa questão.
Acontece que "Mínimo Viável", na verdade, tem desvantagens. Por um lado, antecipar muitas mudanças leva a uma aplicação inchada e muito design inicial, que é exatamente o problema que o Agile tenta resolver a priori. Por outro lado, seguir o caminho mais rápido e sujo, é uma receita certa para uma reescrita que será cara e que irá ocasionar meses de atrasos.
Figura 1 - A desvantagem do MVP.
O Lean oferece uma perspectiva comprovada sobre esse problema: bom entendimento, bons produtos. As soluções técnicas podem ser bastante discutidas, mas construir MVPs que podem ser dimensionados é, antes de mais nada, uma habilidade desenvolvida pelos engenheiros projeto após projeto.
Com o tempo, desenvolvemos uma melhor imagem do que torna um MVP escalável. Por exemplo, em um projeto recente, começamos a construir uma aplicação para fãs do esporte. A primeira versão da aplicação foi construída para um torneio local, com apenas alguns milhares de usuários. Na terceira geração, já estávamos lidando com milhões de usuários para eventos em todo o mundo.
O líder de tecnologia responsável pelo primeiro MVP sintetizou o desafio do dimensionamento em seis perguntas.
1. O modelo de dados é robusto?
A maneira mais rápida para construir o modelo de dados é analisar o primeiro conjunto de funcionalidades e desenhá-los de acordo com o que estava sendo apresentado na tela. Porém, depois de algumas evoluções, o modelo ficaria inchado e as mudanças seriam cada vez mais difíceis.
Ao invés disso, o líder de tecnologia passou algumas horas acertando o modelo de domínio, trabalhando com profissionais do esporte para entender melhor como modelar os torneios, jogadores e todas as outras informações pertinentes. Então, tentou descobrir como o modelo evoluiria com a escala, com centenas de jogos e milhões de usuários, para ter uma ideia de como configurar os dados e preparar as otimizações do banco de dados mais óbvias. O processo todo não exigiu muito tempo, mas resultou em um modelo robusto o suficiente para não exigir grandes mudanças depois de alguns meses. Uma das principais razões para esse sucesso é que ele estava trabalhando em suas habilidades de modelagem, inspirado nos conceitos por trás do Domain Driven Design, o conhecido DDD.
2. A base do código está sempre melhorando?
A primeira versão do MVP foi construída em um backend monolítico, simples de configurar e de administrar e, bastante suficiente para a carga de trabalho esperada. No entanto, o líder de tecnologia tinha a intenção de tornar o código administrável, o suficiente para permitir a divisão de funções entre diferentes instâncias de servidores no futuro, quando a estrutura da equipe ou as expectativas de desempenho exigissem.
Como regra geral, estava me perguntando continuamente: a base de código está melhorando ou está ficando cada vez mais degradada? Ele costumava pedir aos desenvolvedores que reservassem algum tempo para refatorar, a fim de remover duplicações óbvias ou dependências indesejadas. Mesmo que ele não visasse a perfeição, sempre manteve uma noção do estado geral do código e não o deixou degradar abaixo de um certo limite.
Outra área de foco foi a API. Ele sabia por experiência própria que errar nas APIs resultaria em muitas solicitações de evolução e problemas de desempenho, então, se certificou de projetar um conjunto de interfaces que formassem um todo coerente, independentemente das necessidades específicas das primeiras telas.
Acertar o código e as APIs não tomou muito tempo, porque foi baseado na educação pessoal do líder de tecnologia, que investiu tempo em dominar os princípios de design e estudar várias abordagens para projetar as APIs.
3. A cobertura dos testes está sempre melhorando?
Outra compensação comum ao escrever um MVP é decidir sobre o nível certo de cobertura de testes. Aqui, novamente, a perfeição não é o objetivo final. A abordagem foi guiada por três princípios:
- Comece imediatamente com uma mistura de testes de ponta a ponta, apenas para os principais cenários de sucesso e testes de unidade mais simples para os casos mais periféricos;
- Certifique-se de que a cobertura de testes está aumentando a cada semana;
- Nunca deixe os testes com falha se infiltrarem no conjunto de testes, resolvendo-os imediatamente.
Como resultado, os desenvolvedores que chegarem após o início do projeto terão mais confiança ao fazer alterações e também terão exemplos de como adicionar seus próprios testes.
4. É possível construir e implantar a aplicação com uma única linha de comando?
A sequência do build costuma ser esquecida nos novos projetos. O líder de tecnologia experimentou a dor de lidar com arquivos de configuração e scripts confusos nos projetos anteriores, então foi inflexível no que diz respeito a aplicação ser implantada em um ambiente com apenas uma única linha de comando. Isso trouxe atenção extra para a qualidade da sequência do build e fez com que os desenvolvedores da equipe percebessem que precisavam aumentar suas habilidades de script.
Isso valeu a pena, pois todos da equipe são capazes de implantar a aplicação, não apenas um ou dois especialistas. Também houve menos incidentes, uma vez que havia menos oportunidades para as pessoas cometerem erros sob o estresse de uma implantação no ambiente de produção.
5. O sistema está devidamente monitorado e é fácil desfazer alguma mudança?
Ter um modelo claro, uma base de código limpo, um conjunto de testes sólido e uma cadeia de criação fácil, são maneiras diferentes de alimentar a confiança dos desenvolvedores. Um projeto começa a ficar lento quando a equipe começa a adivinhar cada mudança, com medo de quebrar as coisas e atrapalhar os negócios. O momento de pico de ansiedade ocorre quando o sistema é implantado na produção.
A principal teoria do líder de tecnologia para este assunto era a reversibilidade, que envolve dois componentes principais:
- Ser capaz de reverter as alterações imediatamente. Isso foi possível com uma combinação de flags, versionamento do modelo de dados e backend dividido em processos diferentes, com a capacidade de um componente funcionar com várias versões dos outros sistemas;
- Ter um sistema de monitoramento sólido instalado desde o primeiro dia.
Figura 2 - Construindo a confiança do desenvolvedor.
6. O negócio está claro?
A importância dessas várias estratégias aumentam à medida que a aplicação cresce. Como consequência, uma abordagem eficaz para evitar as armadilhas do crescimento é construir software mais devagar. No caso de um MVP, isso significa manter a ênfase no "M" sendo muito claro sobre qual hipótese de negócio o MVP deve testar. Neste caso, aguçamos as expectativas do MVP. Não se tratava apenas de acompanhar as taxas de conversão e retenção: as questões mais profundas envolviam pontos específicos do comportamento do usuário que a empresa precisava esclarecer.
Concluindo
Não existe essa coisa de construir uma parte do software somente uma vez. Uma aplicação é um sistema que cresce com o tempo, à medida que o negócio em torno dele também muda. Isto tem sido o foco da discussão sobre refatoração desde o final dos anos 90, mas poucos desenvolvedores realmente seguem o que é falado.
Precisamos entender melhor como os sistemas evoluem e como podemos projetá-los para escalá-los antecipadamente. E para que isso funcione, precisamos de engenheiros que tenham curiosidade sobre o assunto e façam dele um elemento central do autodesenvolvimento, explorando e compartilhando ideias com seus pares.
Como começar? Como primeiro passo, os CTOs podem dar uma olhada em seus MVPs atuais. Quais são os próprios critérios para que um MVP seja saudável? E qual é a perspectiva de cada líder de tecnologia no assunto? E, se necessário, o que pode ser feito para colocar os projetos de volta nos trilhos antes que seja tarde demais?
Figura 3 - A verificação de integridade do MVP com base nos ideais do líder técnico.
Essas perguntas são difíceis, mas são boas. Um MVP em si é de pouca utilidade se não ajudar as empresas a colher benefícios em grande escala e em pouco tempo. Em outras palavras, um bom MVP é um MVP pronto para escalar.
Sobre os autores
Regis Medina é um coach executivo. Foi um dos pioneiros do Agile no final dos anos 90 e tem estudado Lean nos últimos dez anos, trabalhando com CEOs para construir empresas escaláveis e adaptáveis. É o autor do livro Learning to Scale.
Michael Ballé é escritor, pesquisador e coach executivo. Tem estudado Lean como um sistema de aprendizado nos últimos 25 anos. É co-autor do The Lean Strategy, The Lean Sensei e The Gold Mine Trilogy.
Benoît Charles-Lavauzelle é um empresário de tecnologia. Foi cofundador em 2009 do Theodo Group, uma empresa de consultoria digital com 350 pessoas, que ajuda grandes corporações a escalar e a se tornarem líderes em tecnologia em seus setores.
Fabrice Bernhard é o cofundador e CTO da Theodo Group, uma consultoria de software enxuta cuja missão é transformar organizações, de startups a grandes empresas, para construir melhores experiências digitais e se tornarem líderes em tecnologia no seu mercado.