Por que antes do como

Neste último fim de semana eu estive na QCon São Paulo, uma ótima conferência feita por desenvolvedores para desenvolvedores.

Nesta conferência eu tive a oportunidade de falar sobre o Guia da Startup.

Martin Fowler (@martinfowler) da ThoughtWorks fez o primeiro keynote. Em um certo momento ele usou uma frase interessante para introduzir o tema de bom design e débito técnico.

Eu normalmente me deparo com desenvolvedores que estão frustrados porque “a gerência quer mais recursos, eles não se preocupam com qualidade”

A citação me chamou a atenção especialmente porque, como um desenvolvedor falando para desenvolvedores em uma conferência de desenvolvedores, Martin se focou na parte da frase que normalmente chama a atenção dos desenvolvedores, a parte do “como”. Ele se focou na palavra “qualidade” para explicar o quanto é importante ter um bom design para evitar o endividamento técnico para que os desenvolvedores possam adicionar mais recursos com mais facilidade. Como eu estou mais focado no lado de gestão de produto, assim que eu ouvi a frase, meu foco foi imediatamente para a parte do “porquê”. Isso me motivou a criar um novo slide na minha apresentação sobre as práticas de gerenciamento de produtos:

Quando eu ouvi a frase, meu foco foi direcionado diretamente para a palavra “funcionalidades” e minha primeira reação foi perguntar “Porque é que estas funcionalidades estão sendo solicitadas?”

Quando nos pedem para implementar uma funcionalidade em um software, a reação natural é pensar como essa funcionalidade pode ser implementada. No entanto, precisamos dar um passo atrás e entender o que estamos tentando obter com essa funcionalidade. Que valor essa funcionalidade traz para os usuários do software? Que valor essa funcionalidade traz para os proprietários de software? Cada novo recurso, não importa quão pequena e quão simples de implementar seja, cria complexidade no nosso código. Qual é o valor que esperamos dessa complexidade? Esta é uma pergunta que não apenas um gestor de produto deve fazer, mas todas as pessoas a quem for pedido para implementar uma nova funcionalidade devem tb fazer a mesma pergunta.

Assim, a minha recomendação para todos os desenvolvedores que recebem solicitações para implementar novas funcionalidades é que, antes de correr para descobrir o “como” a funcionalidades deve ser implementada, pergunte “por que” essa funcionalidade está sendo pedida. Isso ajudará você a compreender a importância da funcionalidade e ajudará quem está pedindo a funcionalidade a reafirmar a motivação por trás dessa funcionalidade.

2 thoughts on “Por que antes do como

  1. Ok, sua linha de raciocínio bem como a do Fowler são completamente válidas. Entretanto normalmente os gerentes tem razões que são suficientes na realidade deles para que aquilo seja feito, e o desenvolvedor na visão dele possui uma visão mínima de como aquilo afeta o negócio.

    Sua consideração é muito interessante, porém quando existem reais motivos para que aquilo seja feito ainda existem outras considerações as quais o Fowler tentou de forma sucinta descrever, o fato de que os profissionais de gestão tendem a enxergar tal prática como um tradeoff de qualidade por features enquanto na verdade o tradeoff é de custo por features, uma vez que cada vez que ele pedir que o desenvolvedor faça tal troca o preço a se pagar pela troca se torna ainda maior.

    Muito interessante o assunto! Parabéns pela sua palestra, pelo livro e pelo seu blog/post.

  2. Oi Jayr,

    Obrigado pelos elogios e pelo seu comentário.

    Concordo com vc, sempre que algo é pedido, existem motivos para que aquilo seja feito. Minha intenção com o post foi chamar a atenção para o fato de que às vezes a gente pula direto para a discussão sobre como implementar uma determinada funcionalidade sem antes de procurar entender os motivos por trás do pedido dessa funcionalidade.

    Abs,
    Joca.

Leave a Reply

Your email address will not be published. Required fields are marked *