Problemas x Soluções
Um dos temas que mais chama a minha atenção, ao longo destes anos de experiência com produtos digitais, é a confusão que acontece constantemente nos times (ágeis ou não), no que diz respeito ao escopo de trabalho.
Lembro de uma vez, onde estava em um grupo para a solução de um problema não muito trivial, e parte do time envolvido com o assunto já tinha uma solução muito clara de como aquilo deveria ser construído, e quais rumos a gente deveria dar para o tema.
Na época, eu ainda estava começando a entender um pouco mais sobre a dinâmica para a construção dessas ideias, e não tinha muita noção dos passos necessários pra construir alguma coisa que fizesse – de fato – sentido para quem fosse usar aquilo. E, por conta disso, as discussões sempre orbitavam se a gente utilizaria a tecnologia A ou B para resolver o “problema”.
Ocorre, que quando a gente se referia ao “problema”, embora a gente o fizesse de forma genuína, o assunto era na verdade sobre a solução que a gente havia pensado, pois estávamos apaixonados por aquilo, esquecendo por vezes, do real propósito de tudo.
Mais tarde, quando o produto finalmente falhou, o grande aprendizado que ficou foi justamente sobre isso: A gente havia se apaixonado pela “parte errada”.
Hoje, anos depois do acontecido, duas reflexões que tenho sobre o caso são:
- Não adianta termos todo o ferramental de Design Thinking, Ágil, Lean Startup, ou qualquer outro framework da moda, usando esse grande ferramental para a construção de algo, se não tivermos de fato, o entendimento e discernimento sobre o que estamos fazendo de fato. Estamos criando uma solução, ou resolvendo um problema?
- É muito fácil as pessoas se apaixonarem por grandes e complexas soluções tecnológicas, pois é sexy trabalhar com inovação. Às vezes, contudo, a gente pode fazer grandes transformações e inovações sem usar nenhuma tecnologia. Aliás, essa é a grande sacada para a construção de produtos sem grandes perdas de tempo e dinheiro. Se você consegue validar sua hipótese a custo “zero”, você já parte de algum nível de certeza de aderência aquele produto.
Em um outro momento, um grande amigo meu mencionou uma frase que lembro até hoje, e que olhando pra trás, talvez não me pareça que foi somente essa a questão, mas que naquele contexto faz muito sentido, e consegue explicar tudo de forma sucinta e com a profundidade que todEs nós conseguíamos entender:
Talvez a gente não seja ágil o suficiente para conseguir fazer as coisas deste jeito
Lógico que não foi só isso, mas novamente, é perfeito para o nosso momento e nível de maturidade sobre aquele tema, naquela época.
Pra terminar, convido a todEs pra darem uma lida no artigo abaixo, que fala um pouco sobre roadmap de produtos, e que foi uma das minhas inspirações para escrever este texto.
https://medium.com/@jboogie/what-does-an-agile-product-roadmap-look-like-cf0dbe5be4ef
Um abraço a todEs.
