Você deve adotar uma metodologia ou focar na resolução de problemas? Essas abordagens estão em desacordo ou pode haver um terreno comum?
A história do debate humano sobre o valor da tradição versus o progresso é tão antiga quanto a própria civilização ocidental. Todos os campos da actividade humana, da filosofia à ciência, têm visto o choque entre puristas e pragmáticos que lutam para decidir qual abordagem é mais fiável.
Ironicamente, nem mesmo o mundo empresarial, um ambiente social conhecido pela sua cosmovisão bastante pragmática, está imune a este debate. Desenvolvedores de software, gerentes e cientistas de dados experimentaram, em um momento ou outro, a tensão entre aqueles que promovem uma metodologia ou estilo e aqueles que tendem a preferir uma abordagem eclética.
Compreendendo o debate
Decidi usar os termos Purista e Pragmático para me referir a cada lado deste debate. Não há nenhuma tendência filosófica para esses conceitos, decidi usá-los com base no fato de que são bastante autoexplicativos.
Por puristas, queremos dizer tradicionalistas ou pessoas que têm uma visão de mundo bem definida e cujos valores e comportamentos refletem esse mundo o mais fielmente possível. Imagine um desenvolvedor de software que é um defensor ferrenho de uma metodologia ágil ou em cascata, não disposto a comprometer seus princípios.
Os pragmáticos, por outro lado, são pessoas que têm uma visão de mundo flexível. Eles estão menos interessados em seguir um método e mais focados no resultado. Se tivéssemos que descrever suas crenças fundamentais em uma frase, seria “tudo o que funciona”.
Mas a realidade raramente é tão clara e facilmente definida, em vez de pensar nesta divisão como os dois lados de uma moeda, é mais provável pensar nela em termos de um continuum. A maioria de nós não somos puristas ou pragmáticos radicais, temos um pouco de ambos.
Alguns de nós gostam da estrutura das metodologias, enquanto outros gostam da liberdade e da criatividade de uma abordagem mais livre. Seja qual for o caso, a maioria de nós está mais do que disposta a fazer concessões no contexto certo. Infelizmente, nem sempre é esse o caso, e é aí que às vezes podemos nos encontrar diante de um beco sem saída.
Quando os métodos são importantes
Quando um amigo meu dá aula em seu workshop, ele sempre conta uma história bastante engraçada. Quando ele começou como desenvolvedor de software, o primeiro emprego que conseguiu foi em uma empresa que orgulhosamente anunciava que era uma empresa de desenvolvimento 100% orientada a objetos.
No primeiro projeto do meu amigo, a equipe ficou perplexa porque tinha um problema que não era fácil de modelar com uma abordagem orientada a objetos. Meu amigo pensou em algumas soluções, ambas exigindo um pouco de programação imperativa, mas suas ideias foram encerradas porque isso não fazia parte do estilo da empresa.
Por mais engraçado que possa parecer, essa é uma história verdadeira, e você ficaria surpreso com o quão comum ela é. Nem precisa ser um paradigma de programação. Os proponentes da cascata ou do ágil podem ser tão rígidos em suas posições quanto esta empresa foi com sua abordagem ao desenvolvimento de software.
Há uma infinidade de razões pelas quais isso acontece. Uma explicação é a falácia dos custos irrecuperáveis: algumas empresas investiram tanto tempo e esforço para dominar uma determinada abordagem, que acabam por aplicá-la a tudo, mesmo que a abordagem não tenha sido originalmente concebida com essa intenção.
Tenho tendência a optar por uma explicação menos cínica. Os seres humanos são criaturas de tradição e hábitos, as sociedades são construídas com base em rituais. E por sociedade quero dizer desde civilizações até unidades familiares, incluindo empresas.
A identidade de uma empresa é definida em parte pelas suas práticas e tradições. Estruturas e metodologias fornecem uma linguagem comum que é compartilhada entre todos os membros, pense nelas como atalhos semânticos. Maneiras de compartilharmos informações rapidamente com pessoas que compartilham nosso quadro de referência.
Quando agimos fora dessa visão de mundo, a comunicação torna-se mais difícil, é mais difícil transmitir a ideia e corremos o risco de quebrar padrões ou de nos desligarmos completamente da comunidade.
Por exemplo, imagine uma empresa que busca o seis sigma, com exceção de um departamento cujo gerente se apegou obstinadamente a outras formas de melhoria de processos.
Se você, como consultor, verificasse a produtividade de cada departamento, teria mais dificuldade com este departamento, pois sua abordagem é diferente dos demais, é mais difícil avaliar seu desempenho em comparação com os outros.
Voltando ao meu amigo, ele pode estar certo, mas e se eles implementassem a solução e, alguns anos depois, outra equipe herdasse o projeto, apenas para encontrar esse estranho trecho de código imperativo em um software orientado a objetos? Para eles, pode ser mais difícil entender como o código deve funcionar.
A inovação é, por natureza, disruptiva, por isso não é incomum que encontre resistência, especialmente se essa inovação for contra os valores fundamentais ou as normas sociais do grupo.
O desenvolvedor pragmático
Agora imagine o oposto absoluto, um desenvolvedor de software que constrói seu projeto na base do puro pragmatismo, se funcionar, vai. Eu seria o primeiro a admitir que, para a maioria de nós, seria incrível poder escrever código da maneira que quiséssemos.
Infelizmente, isso simplesmente não é viável. Quando escrevemos código, especialmente para outros, temos que entender que talvez não existamos para sempre. Como tal, o nosso trabalho não pode ser idiossincrático, tem de ser capaz de comunicar a intenção, precisa de uma estrutura que outros possam seguir.
É claro que, mais uma vez, esse é um exemplo extremo. Os pragmáticos não são mestres do caos, apenas acreditam que encontrar a solução para um problema é mais importante do que respeitar um conjunto de normas ou tradições definidas que podem ser restritivas.
Talvez o maior exemplo de desenvolvedores pragmáticos sejam aqueles que praticam metodologias híbridas, misturando a estrutura da abordagem em cascata com a entrega rápida e o envolvimento do usuário das tradições ágeis.
Um traço comum entre os pragmáticos tende a ser o seu nível de experiência. Os desenvolvedores seniores são mais propensos à experimentação e menos dependentes de abordagens tradicionais.
Veja por exemplo como a esmagadora maioria das pessoas que trabalham com Clojure (uma linguagem de programação funcional baseada em Java) são desenvolvedores seniores que estão cansados de trabalhar com programação orientada a objetos.
Isso não é incomum. Como Khun postula no seu livro sobre revoluções científicas, cada paradigma tem um limite, um ponto onde se desintegra. É aí que o especialista percebe que precisa de um novo paradigma para resolver o seu problema.
Se a estrutura fornece um quadro comum, então a inovação é o que leva esse quadro aos seus limites. A alternativa é bastante deprimente, o tradicionalismo promove a estagnação. Se nos mantivermos fiéis aos nossos métodos seguros e fiáveis, chegaremos a um ponto em que simplesmente não conseguiremos adaptar-nos.
E essa é a última coisa que queremos num negócio que acelera a cada minuto.
Os opostos se complementam
O psicanalista Carl Gustav Jung compreendeu perfeitamente que forças opostas não são contraproducentes, mas sim que, quando encontram o equilíbrio certo, potencializam-se mutuamente.
Pragmatismo e Purismo não são opostos, no sentido de que uma abordagem não exclui ou invalida a outra. Seguir seus métodos cria estrutura, tentar novas soluções ultrapassa seus limites.
Compreender o valor de cada abordagem e promover uma cultura que valorize ambas é, na minha opinião pessoal, a melhor forma possível de promover uma empresa flexível com um núcleo forte que se adapta mas mantém a sua essência.
