Dentro do meu trabalho com consultoria em arquitetura de software e adoção de métodos ágeis em organizações, observo com frequência alarmante desenvolvedores frustrados com seus trabalhos, com seus gerentes e suas empresas. Todo dia, sem exceção. Nas mais diversas empresas, contextos e tecnologias.

A maioria destes desenvolvedores são pessoas com um notável raciocínio técnico. E, ao mesmo tempo, ainda idealizam um mundo perfeito de desenvolvimento. Neste mundo perfeito, eles tem tempo para estudar novas tecnologias no horário de trabalho, tem  clientes que concordam com suas decisões, possuem gerentes que compreendem as necessidades técnicas sem divergência e trabalham em times onde todos são dedicados e motivados.

Não sei quanto a você, mas eu nunca estive um projeto com as características acima apontadas. O mais provável é que alguma (ou todas) das características abaixo ocorram:

1. Você não terá tempo de estudar no seu trabalho.

2. O seu cliente irá discordar de você, com alguma frequência

3. O seu gerente não entenderá as suas decisões.

4. Haverá pessoas que não estarão nem um pouco motivadas a colaborar com você e com o seu projeto.

E ainda assim, você precisará entregar o seu produto.

O Desenvolvedor Passivo-Agressivo

Este universo compreende 90% dos desenvolvedores que conheço. Quando algo está errado, eles reclamam. E reclamam. E reclamam. Ad infinitum.

E quando, finalmente, o gerente pergunta “Qual a sua proposta?”, um silêncio sepulcral é ouvido na sala. E nada fazem para mudar a sua realidade.

O Desenvolvedor Pragmático

Aqui se encontram os outros 10% dos desenvolvedores que conheço. Quando algo está errado, eles verificam se eles (1) podem atacar e resolver o problema, se eles (2) podem escalar o problema ou se o (3) problema está além da sua influência.

Se o problema está na primeira categoria, eles resolvem o mesmo. Sem MiMiMi.

Se o problema está na categoria (2) eles buscam influenciar os seus gerentes no sentido da mudança que eles querem provocar.

E se o problema está na categoria (3)  eles simplesmente ignoram o problema e se adaptam para trabalhar nas condições ambientais estabelecidas.

Uma história real com um Desenvolvedor Passivo-Agressivo e um Desenvolvedor Pragmático

Tive a oportunidade de trabalhar para uma empresa de TELECOM em um certo momento do século passado. Sim, quando os dinossauros e códigos C++/CORBA habitavam a terra média.

Bom, nesta empresa havia um desenvolvedor que vivia a reclamar das suas demandas. Ele culpava o marketing de ser desorganizado, do gerente de TI ser permissivo, dos desenvolvedores serem reativos. Reclamava até do gosto do café da máquina Nescafe que havia no final do corredor.

Mas se você trabalhou ou trabalha em uma empresa de TELECOM, você sabe que a área de marketing irá trazer campanhas com datas estabelecidas em deadlines acordados com a diretoria. E sem consultar a TI, lógico. Ponto.

Em uma destas demandas, cuja campanha precisava ser operacionalizada pela TI em para a próxima semana, este desenvolvedor passivo-agressivo conseguiu desestabilizar todo o seu time. Através de uma postura diária e contínua de reclamações, ele conseguiu minar a produtividade do time onde trabalhava, o que provocou um atraso na entrega e comprometeu a qualidade do produto em produção. Posteriormente, ele saiu da empresa, levando consigo muitas reclamações e mágoas.

Em um outro time, separado por duas ilhas, havia um outro desenvolvedor que liderava tecnicamente o seu time. Ele sabia da dura realidade desta empresa de TELECOM e reconhecia o fato que as datas eram impostas por motivadores muito além das questões técnicas. Estudou o problema dado. Com profundidade. E não brigou com o fato. E assim descobriu que em projetos de prazo fechado, ele precisava trabalhar a engenharia de valor dos seus produtos. E isso abria possibilidades de tornar o escopo, antes  fechado, em algo variável. E no prazo de algumas semanas, se tornou um hábil negociador de escopo. E com isso prosperou neste cenário e se adaptou para trabalhar na realidade desta organização. Embora esta organização não trabalhasse com métodos ágeis, ele introduziu uma cultura de MVPs orientados a prazo.

A Mais Importante Habilidade de um Desenvolvedor

Desenvolvedores podem escolher viver na zona de preocupações (que estão fora do seu controle) ou viver dentro da sua zona de controle e influência. Aqueles que escolhem a segunda alternativa prosperam e são normalmente escolhidos para liderar times, por razões óbvias.

Conforme mostrado na figura acima, o círculo de preocupação é sempre maior que o círculo de controle e influência. Sim, não podemos mudar o fato que o Trump é presidente dos EUA, que a economia brasileira está ainda em recessão ou que o seu projeto tem prazos apertados. Mas podemos aceitar estes fatos e ainda assim mudar a realidade que está no seu controle e na sua influência. Sempre!

Quando a circunstância é boa, devemos desfrutá-la; quando não é favorável devemos transformá-la e quando não pode ser transformada, devemos transformar a nós mesmos, Victor Frankl.