Ries em Lean Startup descreve o conceito “Produto mínimo viável (MVP) como uma versão do produto que nos permite terminar o círculo de aprender a construir, medir com esforço mínimo e também com tempo mínimo de desenvolvimento” (RIES, 2012, p58). Ele também complementa “esta versão pode precisar de recursos e desenvolvimento adicionais posteriormente” (RIES, 2012, p58).
Atualmente, com o assunto “agile” ainda é um dos temas mais procurados principalmente no Brasil, que segundo pesquisa rápida no Google Trends nos coloca em 3º lugar de países que mais pesquisam sobre Ágil e Metodologias Ágeis. De fato as metodologias impressionam, desde pequenas empresas até grandes corporações, muita gente está tentando implementar metodologias ágeis em suas empresas.
Mas é difícil largar velhos hábitos, um deles é o famoso GoHorse.
O GoHorse é uma brincadeira criada entre os desenvolvedores, uma sátira sobre os métodos ágeis que prometem ser a salvação da produtividade, que nem diz o título do livro do Jeff Sutherland quando ele diz que o Scrum, por exemplo, é a “Scrum: Arte de Fazer o Dobro do Trabalho com Metade do Tempo”. Quando mal aplicada não só essa, mas qualquer metodologia, o que temos é o famoso Gohorse, ele se caracteriza por:
- Prazos absurdos de negócios sem levar em conta a complexidade de TI;
- Repriorizações absurdas fazendo um monte de coisas sendo priorizadas ao mesmo tempo;
- Priorizações de coisas que ninguém sabe o valor que vai agregar para o cliente, provavelmente é só porque algum chefe pediu.
- Existe uma guerra velada entre o time de produtos e de TI.
Se você vive algum desses cenários, você pode estar em uma empresa que está vivendo no GoHorse. Entretanto, para chegar a um diagnóstico mais preciso do GoHorse é necessário irmos mais a fundo até percebermos que ele é um ciclo vicioso.
O ouroboros
Já ouviu falar na lenda do Ouroboros? É um símbolo representado em diversas culturas como algo que termina para iniciar um novo ciclo. Geralmente representada por uma serpente que engole a si mesma a partir de sua cauda. Poético, né? E se eu te contasse que uma vez que caímos na cilada de trabalharmos com o GoHorse estamos fadados a voltar sempre a este ciclo?
Veja se um dia você já se viu fazendo algumas dessas etapas abaixo:
1# Etapa: Pensar como Projeto e não como Produto
Existe uma grande diferença nos dois tipos de pensamentos. Em linhas gerais, quando pensamos em um projeto, ele tem início, meio e fim. Já que um produto não acaba, ele pode evoluir, ser descontinuado, mas jamais tem um fim aparente.
Pensamos como projeto quando tratamos o produto como se fosse uma batata quente, quando subir para produção é muito mais importante de sabermos se estamos fazendo o que de fato é o correto para o produto.
2# Etapa: negligência voluntária
Apesar do conceito de MVP admitir que a primeira versão de um produto necessita de ajustes, ou até ser refeita, quando se pensa pelo GoHorse não se tem um horizonte claro de quais os problemas identificados, ou há tempo para se mapear os débitos técnicos possíveis dentro de um projeto.
3# Etapa: o excesso faz com que o processo todo seja descartado.
Você já teve a experiência de mexer em uma arquitetura extremamente complexa? Onde tudo que foi nela não parece fazer sentido? Ou pior, que te surpreende quando você abre o código com mensagens do tipo abaixo?
Pois é, quando produzimos um software correndo a tendência é criarmos algo que perde o sentido e não entendemos muito bem para que serve. O que dificulta qualquer processo de manutenção ou atualização.
4# Etapa: O ciclo recomeça
Como ninguém consegue entender o que foi parametrizado no passado, sempre alguém aparece com uma brilhante ideia “vamos refazer”. Entretanto, se estamos lidando com organizações que querem ser Ágil (pero no mucho), com gestores mais preocupados em passar para o próximo problema do que evoluir constantemente um produto, o ciclo se reinicia.
Já se viu neste cenário? Por muitas vezes já ouvi que o MVP não precisava de detalhes, de code review, de funcionalidades que todos julgavam ser vitais para as dores do cliente e entre outros. Cuidado, você pode estar caindo na cilada de trabalhar no GoHorse. As perguntas crucial que você tem que fazer para evitar trabalhar dessa forma são algumas:
- O que estou subindo em produção tem o mínimo que é necessário para que eu possa validar minha hipótese?
- Tenho plena consciência de quais débitos técnicos posso estar gerando no sistema?
- Já estou me estruturando para ajustar todos estes pontos que sei que faltam no meu MVP?
- Tenho como acompanhar minha subida para saber se os pontos que previ de erro são realmente estes, ou se são outros que não previ?
- Tenho estratégia de rollback caso precise voltar a aplicação para seu status anterior?
Escuto muito das pessoas que se você estrutura demais um plano, você não está trabalhando com Ágil. De fato, trabalhar com Ágil faz com que você consiga ganhar tempo em uma série de coisas, por trabalhar com esteiras de produção paralelas, mas Ágil não é negligente, exige planejamento e um constante equilíbrio entre as preocupações do que estamos fazendo no presente e o que vamos fazer no futuro.
