Introdução

Durante os anos que tenho trabalhado como desenvolvedor ou liderando equipes de desenvolvimento, venho observando determinados padrões de comportamento nos desenvolvedores ou mesmo nas equipes.

Confesso que já pratiquei bastante esses padrões e caí nessas armadilhas. Superei alguns, outros ainda me pego fazendo e sempre tenho minhas recaídas. Não é fácil para nenhum desenvolvedor esse negócio de habilidades com pessoas.

Resolvi escrever esse post, com o objetivo de ajudar meus companheiros de profissão a superarem determinadas barreiras, seja para o crescimento profissional, seja para ter uma vida mais saudável.

Por que há tanto conflito em desenvolvimento de software?

A resposta mais correta, verdadeira e sincera é: não faço a menor idéia. Meu melhor palpite, eu compartilho.

Fazer software exige dos desenvolvedores muito esforço lógico e racional. O tempo todo lidamos com coisas abstratas (criamos coisas que a maioria das vezes não são vistas) utilizando linguagens de programação que por definição são linguagens extremamente rigorosas. A máquina não aceita erros. Se tem uma vírgula errada, não compila. Se tem uma instrução errada, compila, mas muitas vezes não funciona. Se deixamos passar um detalhezinho sequer, coisas ruins acontecem.

Dentro desse rigor, existe ainda a necessidade de criatividade. Para resolver problemas é necessário pensar em formas diferentes, caminhos diferentes para chegar na solução. Caminhos estes que precisam ser provados pelo mesmo rigor de um compilador, que não aceita vírgulas erradas.

Para tornar ainda mais complexo esse ambiente que mistura raciocínio abstrato com rigor matemático entra o ingrediente fatal: pessoas. Criar é difícil. Criar coletivamente é uma tarefa árdua. Cada um tem uma experiência diferente e opiniões diferentes sobre uma série de coisas. E o pior, você precisa conseguir sair com acordos desse ambiente para fazer qualquer coisa se movimentar em qualquer direção.

Esse acho que é o papel que mais gosto de ter nas equipes hoje. O de líder técnico. Pra mim o que esse cara faz é: ter conhecimento técnico suficiente para ser respeitado por sua equipe (desenvolvedor não se subordina a quem não respeita) e poder servir como uma espécie de bússola para orientar o time no sentido da solução, facilitar os conflitos e as decisões técnicas e propor as melhorias necessárias no ambiente para que o trabalho tenha fluidez.

Depois de tanto tempo vivendo diariamente esses conflitos, sendo a causa de alguns e a solução de outros, resolvi compartilhar algumas dicas que me ajudaram a encontrar um pouco de paz de espírito.

Muitos profissionais se questionam porque tem dificuldade de ter evolução na carreira e as razões que o impedem de participar de decisões importantes na empresa, produto ou projeto. Pode ser que esse post lhe ajude.

Distinguir perguntas com respostas objetivas de perguntas com respostas baseadas em opiniões

Para muitas coisas em tecnologia, existem respostas do tipo “certo e errado”. A maioria delas os compiladores, documentos de referência tem a resposta. Outras coisas como qual é o algoritmo mais rápido, é bem simples responder usando técnicas como análise de “Big O” ou mesmo implementando o algoritmo. Não é aqui que moram os problemas.

O problema são nas perguntas: Qual solução é melhor, qual é a pior? Pronto. Imediatamente um acha que o banco de dados resolve tudo, o outro acha que tem que por na nuvem, o outro acha que tem que desenvolver tudo do zero e começam as brigas.

As principais coisas que temos que saber é separar respostas objetivas de respostas baseadas numa recomendação ou opinião. Provavelmente no segundo caso se você perguntar para 10 pessoas diferentes, vai ter 10 respostas diferentes e provavelmente mais de uma certa.

A melhor coisa nesses casos é traçar cenários com prós e contras. Não perca tempo tentando convencer o outro que a sua solução é a melhor. O outro pode ter uma opinião diferente. Nesse caso o melhor juiz são os requisitos, as restrições de prazo, custo e recursos.

Saiba reconhecer que por mais que a sua proposta seja a melhor na sua opinião ou a mais bonita do ponto de vista técnico ela pode não ser escolhida por não atender as principais restrições ou objetivos de negócio da empresa. Isso não faz dela uma solução ou uma idéia ruim.

Viver num mundo em que duas pessoas podem ter opiniões diferentes

Esse está relacionado com o anterior. Ter uma opinião diferente ou não convencer o outro que a sua solução é melhor não faz você pior ou melhor do que ele. Apenas são opiniões diferentes sobre o mesmo assunto. Não seria um tanto quanto pretensioso achar que você está certo o tempo todo?

É importantíssimo aceitar que o outro tem uma opinião diferente, por mais que ela pareça absurda para você. Por causa dessa razão muitas discussões do tipo linguagem A é melhor que a B ou linguagem funcional é melhor que orientada a objetos e vice-versa acontecem. Discussões completamente sem fundamento sem um contexto.

Tirar bom proveito de discussões e saber o momento certo de pular fora delas

Se aprendemos a aceitar que o outro pode ter uma opinião diferente da sua, discussões passam a ter um sabor diferente. Invés de parecerem um duelo infinito que só termina quando o oponente sangra até a morte (ou simplesmente a energia esgota após ofensas intermináveis, como nas listas de discussão), a discussão passa a ser um palco para troca de experiências e aprendizado.

Quando você discute com uma pessoa com ponto de vista diferente do seu, tem uma oportunidade enorme de aprender uma nova perspectiva sobre um mesmo assunto. Invés de ficar tentando provar que o que você faz é o melhor, você passa a entender as razões por trás das ferramentas, técnicas e tecnologias utilizadas pelo outro. Logo, mesmo que no final das contas não concorde com ele, com certeza não sairá da discussão no zero a zero.

Em arquitetura esse tipo de discussão é riquíssima, pois mesmo tendo duas soluções, frameworks ou técnicas de design diferentes aplicados, conseguimos entender as motivações que fazem a pessoa escolher um caminho diferente e potencialmente as conseqüências da decisão tomada.

O melhor momento para pular fora de qualquer discussão é quando acaba a exposição de argumentos. Não tem mais o que explorar nos argumentos e ninguém mudou de opinião, muito bem. Vamos esperar entrar algum novo insumo na discussão para progredir à partir dali. Se uma decisão precisa ser feita, alguém vai ter que ceder. Então o próximo tópico pode ajudar.

Comprometer-se com aquilo que não concorda

Qualquer profissional consegue se comprometer e se engajar com aquilo que concorda. Por isso não é incomum aquelas cansativas reuniões que as pessoas empurram um compromisso goela abaixo, compromissos que são mais aceitos pelo cansaço do que pelo mérito.

Difícil mesmo é seguir adiante com aquilo que você não concorda. Ninguém quer ceder.

Se as conseqüências daquela decisão são pequenas, reveja sua posição. Será que não vale a pena abrir pequenas concessões para não levar aquela fama de inflexível na hora que precisar tomar uma decisão com impactos realmente grandes?

Se você percebe que está num impasse e vai ser impossível construir um consenso, justifique as razões que o fazem discordar daquela decisão, por exemplo, mostrando as possíveis conseqüências e mesmo assim se comprometa com ela.

O que para mim torna essa opção interessante é que mesmo muitas vezes sabendo que as coisas não estão do jeito que você gostaria, você tem a chance dos fatos ajudarem as suas idéias a ganharem mais força, enquanto ficando no impasse você tem a certeza de não ir para lugar nenhum, ou pior ainda, ser simplesmente tirado do jogo e não participar mais da decisão.

Sim, se você não tem participado mais das decisões críticas do seu projeto, pode ser porque você foi tirado do jogo por sempre se posicionar de forma dura e inflexível.

Nada como o tempo para resgatar boas idéias ou enterrar as idéias ruins.

Nunca critique sem ter uma proposta de solução

Essa é a mais clássica de todas. Todo dia ouço várias dessas: a arquitetura é uma bagunça, o projeto é um lixo, o usuário não sabe o que quer, o controle de versão é uma porcaria, e por aí afora.

Pense consigo mesmo e invés de levar as reclamações dessa forma, tente levar da seguinte forma: por que não fazemos a mudança “x” na nossa arquitetura, porque assim podemos tornar o produto melhor e mais fácil de manter? Por que não usamos a técnica “X” de escrever estórias para ajudar o usuário a definir melhor seus requisitos? Por que não instalamos o Git?

Você vai perceber que sua vida pode mudar. Quando você perceber como é difícil propor melhorias e vender os benefícios de determinadas mudanças começará não só a ponderar suas críticas como também a encorajar e apoiar as melhorias propostas por seus companheiros de time.

Vender soluções

A pior forma de fazer alguém concordar com você é impondo sua opinião. Cansei de ver desenvolvedor se descabelando para convencer outro usando abordagens do tipo: porque é certo, porque é assim que aquela empresa bacana com produtos na nuvem faz ou porque o fulano, ciclano ou beltrano falou que é o certo.

Esquece. Se você faz isso de uma forma impositiva, a pessoa vai discordar só pelo prazer de discordar e te deixar numa posição desconfortável.

Quando você pega uma pessoa dura nesse tipo de discussão, a abordagem que geralmente dá resultados é construir a solução em conjunto. Invés de simplesmente jogar a solução resolvida para
ela, jogue o problema. Ela vai apresentar uma solução. Coloque mais elementos que façam com que ela chegue a uma conclusão de que aquilo é uma má idéia. Quando aquele momento de desespero bater e ela soltar um: tá bom, se desse jeito não funciona, como funciona? Aí você coloca um pedaço da sua idéia como uma sugestão: “o que você acha de tentarmos isso?”

As vezes o que acontece também numa situação dessa é que você sai com uma solução melhor do que a que você pensou sozinho. As vezes simplesmente a pessoa tem uma idéia melhor.

O ponto central dessa idéia é que muitas vezes nós pensamos em diversas situações diferentes para chegar numa dada conclusão e como aquilo se torna óbvio para nós, esquecemos de repassar todo o processo que nos levaram a essa conclusão com nosso time, o que faz com que pareça que estamos “atropelando” toda a contribuição do outro.

Conclusão

O interessante deste processo todo é que quando você aprende a observar os seus comportamentos que o tornam uma pessoa difícil de lidar no time (por mais que sua intenção final seja fazer a coisa “certa”, de acordo com seu ponto de vista) e aprende o quão difícil é fazer isso, torna-se também uma pessoa mais tolerante com a falha do seu companheiro de time e aprende a levar a discussão de uma forma mais suave.

O que posso dizer por experiência própria é que quando você começa a encarar esses conflitos de uma forma mais natural e positiva, isso ajudará a trazer mais satisfação e felicidade para seu dia-a-dia.

Era isso!