Uma vez, eu estava num 1:1 com um PM discutindo se deveríamos começar ou não um projeto novo. Eu disse que “para muitas empresas, software é um mal necessário”. E o PM, sendo generoso, respondeu “é a primeira vez que eu vejo um desenvolvedor falando isso”.
Noto que nós desenvolvedores costumamos pensar em espectros de tempo e dinheiro. “…precisamos de um CRM”, “contrate um, tendendo a pouco tempo e muito dinheiro”. “…precisamos atacar um débito técnico”, “postergue, tendendo a muito tempo e pouco dinheiro”.
O problema é que essa forma de pensar é subjetiva e sujeita a conflitos de interesse. Por que contratar o CRM? Porque leva tempo ou é complicado fazer um? Por que resolver um débito técnico? Porque hoje vai dar menos trabalho que amanhã? Por que começar um projeto? Porque é desafiador?
O que guia decisões como essa? A resposta em vasta literatura é o negócio. Se o negócio precisa de um software, mas que não gera valor para o cliente, tende-se a contratar. Caso contrário, desenvolver. O que gera valor para o cliente, em geral, paga de volta com diferencial competitivo. E diferencial competitivo, na maioria das vezes, precisa ficar em casa, muito bem guardado.
Profissionais de produto têm esse entendimento como formação, diferente de nós de tecnologia. Não sei você, mas eu já participei daquela reunião de “desalinhamento” de expectativa de duração, tamanho ou qualidade do projeto. O time de produto está visivelmente desconfortável e preocupado com prazos e escopo, enquanto os desenvolvedores estão animados em discussões sobre tecnologia e boas práticas. No pior cenário o caldo entorna. Se conclui que conversar com tecnologia é difícil de um lado, e que se obriga a fazer as coisas de qualquer jeito do outro.
Para nós desenvolvedores, é muito fácil cair na ideia de que tudo orbita escrever código. Mas vamos por o pé no freio. Primeiro, quanto o projeto em discussão agrega ao negócio? Se pouco, quais técnicas conheço que me permitem criá-lo com qualidade adequada para então estar disponível para os assuntos principais do negócio? Porque até o feijão com arroz mais simples tem técnica pra fazer. Se agrega muito, aí é outra conversa.
É uma discussão muito rica por negócio e tecnologia na mesma frequência.
Caso você seja Head de Desenvolvimento como eu, como você distribui as atividades entre os membros do time? Grau de complexidade e diferencial competitivo costumam contar nessa hora?