Gestão na advocacia

Método Go Horse na advocacia

O método go horse é muito conhecido por pessoas de negócios e que gerenciam empresas. Apesar de ser uma metodologia, ela é extremamente questionada. Inclusive, grande parte dos administradores e conselheiros de companhias não aconselham a sua utilização.

Embora criado para ser aplicado em uma área totalmente diferente, ele pode também ser utilizado na advocacia. De certo modo, o go horse é usado como exemplo do que não se deve fazer em uma empresa.

O que é a metodologia go horse?

O go horse, também conhecido como extreme go horse ou pelas siglas XGH, significa, em uma tradução literal, “vai cavalo”.

Dessa forma, trata-se de uma metodologia inventada por programadores. Ela iniciou como uma brincadeira com as piores práticas de desenvolvimento de software. Contudo, acabou se tornando um método conhecido.

A ideia consiste em trabalhar sem nenhum planejamento, análise ou reflexão sobre o que está sendo desenvolvido. Desse modo, assim que os problemas forem aparecendo, eles devem ser “empurrados”, o que pode ocasionar mais prejuízos.

Ou seja, o go horse é basicamente um método que consiste em começar a realizar um projeto ou trabalho sem pensar antes sobre ele. É uma maneira simples de fazer qualquer coisa, envolvendo mais improviso e ação do que pensamento estratégico.

Como funciona o método go horse?

O go horse possui 22 mandamentos que explicam como essa metodologia funciona. Abaixo, veja todos eles na íntegra para ter noção do que se trata.

1 – Pensou, não é XGH.

O método XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2 – Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3 – Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas, todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4 – XGH é totalmente reativo.

Os erros só existem quando aparecem.

5 – XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6 – Commit sempre antes de update.

Se der confusão, a sua parte estará sempre correta.. e seus colegas que levam a culpa.

7 – XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8 – Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9 – Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10 – Não existe refactoring, apenas rework.

Se der confusão, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11 – XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12 – Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13 – XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14 – XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é frescura. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15 – XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16 – Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17 – O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18 – O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de funcionalidades entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19 – Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20 – Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21 – Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22 – O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Conforme a leitura dos 22 mandamentos, é possível perceber que se trata de uma maneira bastante estranha para trabalhar e realizar qualquer projeto.

Na prática, quando uma pessoa atua dessa forma, ela não planeja algo efetivo, não prevê problemas e faz tudo sem análise. Desse modo, podem ocorrer equívocos, demora na finalização e entrega, retrabalho e, principalmente, grandes possibilidades de fracasso.

Por que o go horse é ruim?

O go horse é considerado ruim por diversos motivos.

Por isso, imagine fazer tudo em uma empresa sem pensar e analisar antes? Seria caótico, não acha? Tudo exige planejamento e estudo para poder ser iniciado. Caso contrário, as chances da organização ir à falência é grande. 

Veja abaixo alguns motivos que tornam o go horse muito ruim.

1. Não respeita prazos

Conforme visto, o go horse não possui planejamento. Logo, as consequências disso são justamente ter dificuldades no cumprimento de prazos. Adaptando a ideia para um escritório de advocacia, que trabalha a todo instante com prazos processuais e compromissos, é claro o problema que isso pode causar.

2. Prejudica o relacionamento entre os colaboradores

O go horse, além de implementar a ideia de que tudo deve ser feito sem pensar, diz que, em caso de erros, o ideal é culpar algum colaborador. Isso é injusto, visto que apontar culpados não resolve o problema.

Ademais, além de atrasar todo o trabalho e causar conflitos, gera insatisfação e desconfiança entre os membros da equipe, tornando o ambiente negativo.

3. Torna o trabalho improdutivo

Fazer qualquer serviço, por menor que ele possa ser, sem analisar e pensar antes na solução, torna o processo mais lento e o trabalho mais improdutivo. Ademais, realizar qualquer coisa sem pensar ocasiona retrabalho e acumulação de erros que devem ser corrigidos. 

A produtividade é fundamental para qualquer empresa que deseja lucrar e ter uma boa performance. Sendo assim, o go horse deve ser considerado o inimigo de quem almeja bons resultados. 

4. Prejudica o relacionamento com o cliente

O go horse também prejudica o relacionamento com o cliente. Em empresas que prestam serviços, como os escritórios de advocacia, os atendidos poderão perceber o improviso dos colaboradores, o que poderá ser interpretado como despreparo. 

Além disso, eles irão sentir que o trabalho é mais lento e feito sem qualquer análise, fazendo com que o cliente procure outro escritório e não indique o seu para conhecidos. 

5. Prejudica a reputação da empresa

Aplicar o método go horse em qualquer escritório pode prejudicar a reputação do negócio e de toda a equipe.

Sendo assim, isso significa que, além de gerar insatisfação nos clientes, seus colaboradores podem ser vistos como maus profissionais, podendo ter dificuldades de se recolocarem em outras bancas caso precisem.

Como o go horse é adaptado para a advocacia?

Você deve pensar “mas nenhuma empresa utiliza o extreme go horse”. Por incrível que pareça, muitas pessoas acabam adotando as práticas do XGH, mesmo que as não conheça diretamente.

É fato que existem escritórios que realizam diversos trabalhos no improviso, apenas agindo e não pensando. Não é incomum ver negócios que não estruturam seus processos, deixando os seus colaboradores agirem da maneira que desejarem.

Infelizmente, é possível encontrar bancas que não estruturam e realizam o controle de processos, não idealizam um planejamento adequado da empresa e não utilizam programas para analisar dados antes de tomarem decisões ou implementarem melhorias. Além disso, a falta de controle dos prazos também é um fator comum neste tipo de escritório.

Questione-se por alguns minutos: o seu escritório possui processos e diretrizes para realizar as tarefas ou deixa que todos realizem da forma como bem entender, principalmente sem análise e planejamento? Se sim, está na hora de mudar isso.

O go horse é um excelente exemplo do que não se deve fazer em um escritório, principalmente pelo fato de lidar diretamente com o direito das pessoas.

Imagine iniciar uma ação sem estudar o direito material, analisar o caso e verificar as provas que possui. Além de despender mais tempo que o necessário, as possibilidades de retrabalho serão enormes. Ademais, você pode lotar o poder judiciário com ações desnecessárias e prejudicar seu cliente. 

Sendo assim, não seja um advogado que utiliza o método go horse, nem tenha um escritório de advocacia com uma equipe que age dessa maneira.

Método extreme go horse

O extreme go horse é um método que pode ensinar muitas empresas dos mais variados setores a entender o que não deve ser feito. Isso porque, mesmo quem queira utilizá-lo, precisará realizar análises, mesmo que seja de forma macro e rápida. 

Logo, ele não é aconselhável. Portanto, evite adotar qualquer um dos mandamentos, pois os prejuízos podem ser grandes.

Se você gostou desse artigo, aproveite e entenda como alguns processos podem trazer prejuízos para o escritório!

Autor
Foto - Eduardo Koetz
Eduardo Koetz

Eduardo Koetz é advogado, escritor, sócio e fundador da Koetz Advocacia e CEO da empresa de software jurídico Advbox.

Possui bacharel em Direito pela Universidade do Vale do Rio dos Sinos (Unisinos). Possui tanto registros na Ordem dos Advogados do Brasil - OAB (OAB/SC 42.934, OAB/RS 73.409, OAB/PR 72.951, OAB/SP 435.266, OAB/MG 204.531, OAB/MG 204.531), como na Ordem dos Advogados de Portugal - OA ( OA/Portugal 69.512L).
É pós-graduado em Direito do Trabalho pela Universidade Federal do Rio Grande do Sul (2011- 2012) e em Direito Tributário pela Escola Superior da Magistratura Federal ESMAFE (2013 - 2014).

Atua como um dos principais gestores da Koetz Advocacia realizando a supervisão e liderança em todos os setores do escritório. Em 2021, Eduardo publicou o livro intitulado: Otimizado - O escritório como empresa escalável pela editora Viseu.

Postagens Relacionadas