Dev Mind - A mente do desenvolvedor

  • Rafael Miceli
  • 31 Jan 2017

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.

BML

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”.

HDTL

comentarios com Disqus Disqus