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.

Livro sobre gestão de produtos

Vc gosta do tema gestão de produtos de software? Quer se aprofundar mais no assunto? Escrevi um livro sobre o assunto, dividido em 5 grandes áreas:

  • Definições e requisitos
  • Ciclo de vida de um produto de software
  • Relacionamento com as outras funções
  • Gestão de portfólio de produtos
  • Onde usar gestão de produtos de software
Capa do Livro Gestão de Produtos

Esse livro é indicado não só para quem tem software como seu core business, como tb para empresas que desenvolvem software sob demanda e empresas que não tem software como seu core business mas usam software para se comunicar com seus clientes como, por exemplo, escolas, bancos e laboratórios clínicos.

Interessou? Então adquira sua cópia hoje mesmo!

Newsletter

Se você quiser receber artigos por email sobre startup, gestão de produtos e gestão de TI, digite seu endereço abaixo e aperte enter:


2 ideias sobre “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.

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

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>