Dev Mind - A mente do desenvolvedor - Ideias com azeite
Para muitos desenvolvedores em algum momento da carreira surge uma ideia para resolver um problema que algum amigo comenta, ou familiar, ou que observamos por nós mesmos.
A mente do Desenvolvedor
Nós desenvolvedores de software temos uma coisa excelente, muitas das vezes nós temos a capacidade de criar os sistemas para resolver possíveis problemas que possam existir. Mas ai vem um perigo, essa capacidade de criar sistemas apesar de ser uma coisa excelente, também e muitas das vezes nosso atraso. Porque?
Imagine o seguinte cenário, você ouve sua tia reclamar que ela esta velha e não tem mais paciência para ficar comparando preço de medicamentos. Você capta o que sua tia disse e raciocina: "Ela não tem como descobrir o preço mais barato dos remédios que ela procura".
Como a maioria dos desenvolvedores você pensa em como seria ter um app para resolver este problema, e como muitos também você fica com essa ideia na cabeça e decide fazer um app em que nele você possa pesquisar os remédios mais baratos.
Mas ai esta uma situação de alto risco. Quando começamos a escrever um app para um problema que alguem comentou conosco, nós estamos nos dando as respostas a outras etapas de perguntas que deveriam ser feitas. Antes sequer de começarmo a bater o código.
Ok, mas antes imagino que geralmente vem a dúvida, porque não começar a bater o código? Depois posso mudar o mesmo e ir amadurecendo o app.
O problema é que escrever código demora mais do que outras tecnicas para validar se a sua ideia vale realmente a pena investir. E para evitar este desperdicio nada melhor do que Lean Startup!
Mudando o flow do Dsenvolvedor
No livro Lean Startup, Eric Ries nos introduz ao flow: Build -> Measure -> Learn, que apesar de estar nessa ordem, a ação ocorre na ordem inversa. Você primeiro identifica o que você quer aprender (faz hipotéses a respeito), para depois saber como mensurar, e assim constroi o necessário para coletar a informação necessária para aprender sua hipótese no começo.
Dan Olsen em seu livro Lean Product Playbook, sugere o flow: Hypothesize -> Design -> Test -> Learn.
Neste, o flow segue de acordo com a ordem informada, e é explicito que a sua primeira etapa é fazer uma hipótese do que você quer aprender. Depois, construir o necessário para testar sua hipótese e assim aprender. O que sinto falta é deixar explicito que é extremamente necessário mensurar as hipóteses que você quer testar! Como ja dizia Peter Drucker "If you can't measure, you can't manage".