Programação 101 - Produto vs Tecnologia - A grande batalha

Se você ainda não leu o primeiro artigo dessa série, sugiro que reserve alguns minutos - aqui - e leia para que você possa entender o real significado de Software.

Se você pensou que trabalhar como desenvolvedor de software fosse criar qualquer sistema por conta própria ou trabalhar sozinho apenas seguindo os requisitos que lhe fora pedido, sinto muito em dizer, mas o desenvolvimento de qualquer sistema não se dá por uma única mão. Aqui cabe aquele ditado que um grande amigo sempre me diz em algumas situações:

Uma andorinha só não faz verão

Ao longo da minha carreira, trabalhei com centenas de pessoas em diferentes tipos de organizações desde aquelas de montadas em uma saleta até aquelas espalhadas por vários andares em edifícios luxuosos pelo mundo e, para o meu espanto sempre tive alguma colega de trabalho que age como se estive trabalhando em um projeto particular, desenvolvendo de acordo com sua própria interpretação e não se preocupando com o time ou muito menos com o produto final e aquelas pessoas de negócios que não se importam como um sistema é desenvolvido, apenas exigindo a entrega em tal prazo. Aqui denominamos essas pessoas de solo runners, que por sinal são excelentes profissionais - no sentido de técnico, mas péssimos para entregar business value - valores, que é o que realmente importa.

Após refletir sobre esse fenômeno - sim, nós programadores temos essa tendência de analisar padrões em tudo o que vemos - cheguei a conclusão com base em experiência própria que isso dá pelo fato de sermos na maioria autodidata - solo runners de conhecimento, no qual aprendemos a programar trancados no quarto, aprendendo uma linguagem qualquer seja através da leitura clássica de alguma bíblia escrita pelo Deitel & Deitel ou de forma moderna assistindo a algum tutorial no Youtube que vai te ensinar a criar clones de Amazon, Netflix usando React.

Após horas de codificação em um ambiente isolado, é preciso sair desse casulo e enfrentar a realidade, seja em um escritório físico ou mesmo virtualmente, onde iremos ter contato com diferentes pessoas que estão ali trabalhando em conjunto para entregar um único propósito: valor. Muitos apenas cumprem a carga horária sem exatamente saberem desse propósito, mas aqui vamos nos concentrar na figura do nosso solo runner. 

Em uma equipe, você provavelmente vai se deparar com algumas figuras como o PO (Product Owner), o SM (Scrum Master), outros programadores, investidores (business stakeholders) e os temidos usuários. Nessa conjuntura de pessoas com o mesmo objetivo, mas pensando e agindo de forma diferente é que começam os conflitos e surge sempre o famoso debate Produto vs Tecnologia e vice-versa.

Como dito no primeiro artigo dessa série, um software tem que gerar valor e ao mesmo tempo ser flexível para se adaptar rapidamente e assim continuar gerando valor. Com isso, temos duas visões conflitantes, a do time de negócios (produto) que apenas consegue enxergar valor com a disponibilização desse software para o usuário final e a do time de tecnologia que procura estruturar esse software de uma maneira que seja de fácil adaptação e escala, afinal de contas, o usuário pode mudar de idéia em relação a sua necessidade, acarretando mudanças naquele programa.

Isso se dá também pelo fato de ambos os times serem formados por profissionais (em sua grande parte) solo runners, que foram ensinados no formato vertical (silos) não dominando o conhecimento multifuncional (cross-functional) de tecnologia e negócios, tão importante para a entrega de um software de qualidade que atenda os requisitos (reais necessidades) do nosso usuário final e por isso que vemos uma avalanche de sistemas que funcionam muito mal e negligenciam quem realmente precisa deles.

O meio termo

Qual seria o meio termo para essa questão: Produto vs Tecnologia? A resposta pode ser encontrada através do exercício de priorização. E para nos ajudar com esse exercício, podemos nos agarrar à matriz criada por Eisenhower em 1954 durante um discurso na Northwestern University - Eisenhower's Matrix.

Mas como o software se enquadra nessa matriz?

Segundo Bob Martin, o software classificaria de acordo com os dois propósitos que falamos no primeiro artigo dessa série (aqui):

Estrutura (Arquitetura) - Importante, mas nunca Urgente (Quadrante 2 - Important and Not Urgent)

Comportamento (Funcionalidade) - Urgente, mas nem sempre Importante (Quadrante 3 - Urgent and Not Important)

Em uma ordem de prioridade, o grande erro cometidos por ambas as partes e elevar um item classificado no quadrante 3 para o número 1, ou seja, priorizar funcionalidades que são urgentes mas nem tão importantes e isso acarreta na desconsideração do aspecto de arquitetura do sistema como um todo.

E aqui está o papel do programador, sabendo exatamente dos valores de um software e da visão da empresa, que precisará defender o ponto de vista da arquitetura e ajudar o time de negócios a entender o quão importante é o valor gerado de um sistema desenvolvido com um arquitetura flexível que irá possibilitar mudanças ou adaptações de acordo com o mercado com pouco esforço.

Acredite em mim, existem muitos sistemas que funcionam bem por aí (incluíndo aqueles que operam diretamente com o seu dinheiro 💶), mas não se atreva a perguntar como funciona e muito menos solicite uma alteração em sua estrutura/código 😱. 

Nesse artigo espero ter contribuído com um pouco de conhecimento e contexto para que você se torne um profissional de software com visão e assim não cair nessa armadilha que nos ameaça diariamente.