A verdade por trás das metodologias e de como elas podem arruinar seu projeto

A maior força das metodologias também é seu maior fraqueza. Elas resolvem problemas. Ou os problemas os que você tem, os que você terá.

Alguém, um dia, passou pelo mesmo processo que você está passando, enfrentou problemas, testou soluções, traçou um caminho "seguro" para seguir e colocou isso dentro do nome de uma metodologia. Isso é incrível! Por que não usar o conhecimento documentado por alguém que já percorreu os mesmos passos?

A resposta óbvia, mas muito pouco citada: é porque os caminhos quase nunca são iguais. Há sempre uma diferença de equipe, influenciadores, recursos, conhecimento, modelo mental e até mesmo de relacionamento entre as pessoas. Como um método pode ser capaz de se adaptar a todos esses cenários?

E, de fato, isso muitas vezes leva as metodologias a tentarem resolver problemas que talvez você não tenha, custando tempo, dinheiro, motivação e inspiração. A cada momento que você está trabalhando para resolver um problema que você não tem, você está perdendo seu tempo por completo. Você não está deixando de otimizá-lo para, ao contrário, perdê-lo por completo. Quem também nunca passou pela situação de estar seguindo um ritual de uma metodologia (essa é para você, SCRUM) e sentir que aquilo tinha muito pouco valor, só gerando atrito e burocracia para todos? Esse atrito pode ser determinante no sucesso de um projeto. E atrito é uma doença silenciosa, que mata aos poucos, lentamente e constantemente. Você só percebe dois anos depois, junto com uma intensa sensação de frustração. E acredite, isso pode destruir projetos e empresas por completo.

As metodologias são, então, ruins para meus projetos?

Definitivamente, não. Não sejamos maniqueístas. O que vai determinar se elas são boas ou ruins é a maneira com que nos relacionamos com elas.

O jeito mais interessante de se fazer isso é entendendo qual a proposta da metodologia. Quais são os grandes problemas que ela se propõe a resolver (e se isso não estiver claro provavelmente ela não deve ser tão boa), e depois como ela se propõe a fazer isso. Ou seja, qual o real resultado que a metodologia se propõe a trazer?

Peguemos o exemplo do Scrum. Antes de aplicar qualquer ritual da metodologia, devemos entender o que está por trás dela. No caso, o princípio de inspeção e adaptação para controlar complexidade e risco. Seu projeto precisa controlar complexidade e risco? Se sim, a maneira que a metodologia se propõe a resolver isso vai levar a esse resultado no seu caso?

A grande questão aqui é entender o grau de experiência que você e sua equipe têm para identificar, prever e resolver problemas. Um argumento inquestionável usado pelos grandes defensores de metodologias é que a maioria das pessoas não consegue identificar os problemas que tem e muito menos os problemas que virão a ter. Logo, seria mais seguro ir por um caminho pré-definido, mesmo correndo o risco de trabalhar em cima de problemas não existentes. Eu concordo com isso, para algumas equipes. Na verdade, me parece que quanto menos experiente uma equipe é, mais ela deveria se apoiar em metodologias existentes. O efeito colateral é que essas equipes raramente entendem o porquê estão fazendo isso e podem acabar desanimando do processo, pois não sabem porque eles existem e que dores estão solucionando. Além disso, o crescimento da equipe como um todo também fica prejudicado, pois nunca entrarão em contato com algumas necessidades que os criadores da metodologias vivenciaram dia-a-dia. A solução seria adotar inicialmente, mas rapidamente adaptá-la a realidade de contexto da equipe, evitando a maior parte dos efeitos colaterais.

O grande problema, contudo, está quando as equipes mais experientes cometem esse erro. Elas rodam lisas as metodologias, mas sem entender que gastar tempo e energia com processos desnecessários é um problema silencioso mas devastador. O efeito é ampliado pois essas equipes dificilmente abrem mão do processo aos quais estão acostumadas, mesmo quando os projetos tem características, objetivos e contexto diferentes dos quais estão familiarizados. É aí que você vê empresas rodando processos engessados em criações de protótipos ou processos muito soltos em produtos com baixa tolerância a risco. Se torna um problema cultural.

O efeito "metodologia pela metodologia"

É muito interessante também como algumas equipes adotam a metodologia como um fim, e não como um meio de se atingir certos resultados. Quem não conhece aquele sujeito antenado, que sempre está querendo implementar novos conceitos (AKA design thinking, holacracy, design sprint, lean, Squads, burndown, etc) mas sem exatamente refletir o contexto e sobre quais objetivos finais queremos atingir?

Essa abordagem vai provavelmente trazer resultados medianos e, em alguns casos, catastróficos. Isso porque, na média, as metodologias funcionam bem. Alguém vai lá, documenta os processos que funcionam bem na maioria dos cenários e cria a metodologia. Logo, ela funciona para um grupo relativamente grande de casos, mas com resultados consistentes apenas na média deles. O problema é que, na média, as empresas e pessoas querem resultados acima da média.

Se considerarmos ainda os extremos, em contextos muito diferentes dos quais onde a metodologia foi criada, os resultados podem ser catastróficos.

Usando metodologias como diagnóstico

Um exercício interessante e muito construtivo é olhá-las como ferramentas de diagnóstico. Uma nova metodologia quase sempre é reativa a alguma mudança de contexto. Logo, ela pode nos dar boas dicas do quanto estamos adaptados a novos paradigmas como empresa e equipes.

Vejamos o caso da Burndown, proposto pela Drift. Ela tem como objetivo ter ciclos de desenvolvimentos ainda menores (no nível de funcionalidade) e mais proximidade possível com o consumidor final. O objetivo aqui é focar um pouco mais pra fora da empresa, e utilizar a aceitação de funcionalidades como medidor final de se as decisões de produto estão corretas. Veja o que está implícito dentro dessa metodologia:

• Que montar o software corretamente e com menos risco não é mais o grande diferencial de mercado. Todo mundo já sabe construir software. Não é mais "como", e sim "o que". O diferencial é construir um produto que o consumidor final aprove.
• Que, por mais que se tente, as funcionalidades planejadas têm risco elevado de não resolver corretamente os problemas dos usuários, logo, a interação rápida é extremamente importante para correção de rumos de produto.
• Que as empresas tenham stacks de tecnologia que suportem entregas constantes e rápidas, além métricas de adoção. Leia: integração contínua, testes automatizados, analytics, escalabilidade de manutenção de código, etc.
• Que você não tem mais um roadmap. Você tem uma visão de produto e uma série de funcionalidades que se adaptam a realidade de cada momento.
• Que previsibilidade é menos importante que adequação de mercado.

Agora, analisando cada um desses pontos, você pode inferir como o contexto de mercado está mudando e diagnosticar se você entende e já está atuando nesse novo paradigma que está se formando.

Minha recomendação clara é essa: se você quer ter resultados acima da média, você deve ter uma atuação acima da média. Isso exige que você vá além de conhecer e implementar metodologias, mas saber o porque de cada decisão e julgar se a solução escolhida é a melhor para aquele cenário. Além disso, extrair o máximo do conhecimento trazido pelas metodologias. Vamos lembrar que, embora elas tragam resultados apenas medianos, elas são criadas por pessoas e equipes com uma visão muito acima da média. O grande valor está nos princípios que essas pessoas trouxeram, e não somente na sua implementação.

E quer se destacar de verdade? Crie sua própria metodologia.