Frameworks são ferramentas, e não a fundação para a sua construção.
O framework deveria trabalhar para você, e não ao contrário
Esta semana, comecei a refletir sobre isso devido a um questionamento feito por um desenvolvedor da equipe.
Na minha equipe, não adotamos uma metodologia ou framework específico rigidamente. Testamos, aprendemos e combinamos o que funciona para alcançarmos nossos objetivos.
Isso me fez lembrar da frase de Kewin Moya, que sempre diz que o gerente de produtos é pago para gerar resultados, e não para aprender frameworks.
Você é pago para impactar o negócio, não para dominar frameworks.
Eu concordo com essa afirmação, com uma ressalva: se você conhece diferentes frameworks, possui muito material à sua disposição para enfrentar desafios e vencer batalhas de forma mais planejada.
Frameworks são como ferramentas disponíveis para usar na construção do seu produto. Eles ajudam a criar uma visão e um processo claro para a equipe alcançar seus objetivos, mas quando se tornam burocráticos e atrapalham mais do que ajudam, não faz sentido usá-los, na minha opinião.
Eu busco conhecimento em diversas fontes para melhorar a maneira como realizamos nossas tarefas diárias na minha equipe, e mesmo dentro da equipe, os processos podem variar. Utilizamos o que funciona para entregar resultados ao cliente e ao negócio.
Para descobrir o que funciona, é necessário conhecer essas fontes e testar, observar o que funciona e o que não funciona. E se nenhum método funcionar, tudo bem também, desde que o objetivo final seja alcançado.
No entanto, é importante lembrar que o framework deve trabalhar para você, e não o contrário. Processos são fundamentais, mas devem ser revisados e evoluídos periodicamente para se adaptarem à realidade da equipe e à estratégia de negócios.
Um exemplo bem bacana no meu time: somos um SaaS B2B e recebemos diversos feedbacks e sugestões dos nossos clientes e usamos o Impact Mapping para mapear quando precisamos ter uma visão melhor de todas as oportunidades de evolução que temos (você pode usar a Árvore de Oportunidades também, mas no nosso caso o Impact Mapping funciona melhor por termos o “ator” melhor definido).
Quando ainda não temos muita certeza também do que priorizar usamos algum framework de priorização ou até de definição de MVP, como Lean Inception combinado com a Design Sprint, Matriz CSD seguida do Método MoScow (vou deixar as referências desses frameworks no final para você conhecer melhor).
Dito isso, acredito que, principalmente para aqueles que estão começando na área de produtos, é importante conhecer frameworks, metodologias e modelos. Especialmente no início, acho que é muito útil se você está trabalhando em entregas frequentes e quer achar o seu “melhor jeito” de fazer as coisas.
