Algumas lições que eu aprendi quando mudei a minha forma de pensar em software…

Sempre que eu falo sobre a importância de deixar de ser um executor de demandas para ser um solucionador de problemas, eu percebo que algumas pessoas confundem “focar na solução” com “fazer de qualquer jeito”.

Nessa confusão, elas vêem quem se posiciona como “solucionador de problemas” como uma pessoa que faz qualquer coisa, de qualquer jeito pra se livrar do pepino, sem considerar o dia de amanhã, na esperança de que no dia seguinte vai aparecer um aspira para assumir o fardo.

Pra mim esse comportamento inconsequente é mais do que ruim, é irresponsável.

No desafio diário do trabalho de programação, tanto a escolha de fazer de qualquer jeito, quanto a busca pela forma ideal são extremos que colocam o projeto em risco. No 1º o projeto explode com caos generalizado, no 2º o projeto implode nunca indo ao ar.

Mais do que programar, o nosso trabalho de programador exige a gestão de riscos, o que não implica a transferência deles para outras pessoas.

É claro que sempre haverão trade-offs. Não se pode ter tudo, sempre que fazemos uma escolha, abrimos mão de outra. Toda decisão terá um preço, e isso não é um problema.

Mas como fazer a melhor escolha?

Na minha experiência, apenas o conhecimento técnico não é suficiente para fazer a escolha certa. Veja, não estou dizendo que conhecimento técnico seja supérfluo. Muito pelo contrário. Quanto mais conhecimento técnico melhor. O ponto em questão é que ele não é suficiente e nem um fim em si, porque os projetos de software envolvem mais do que desafios técnicos.

Eu já achei que entender os desafios não-técnicos, os desafios que vão além da programação, era papel do gerente ou de outra pessoa na hierarquia da empresa. Que eu como programador eu deveria focar em ser o melhor técnico possível, o que já é um trabalho enorme. Talvez esse até seja o papel dos gerentes, mas pra mim isso nunca funcionou. Sempre sobrava uma pica para o aspira aqui.

Foi quando eu comecei a questionar sobre as restrições do projeto e principalmente sobre os pontos econômicos e financeiros que eu comecei a conseguir enxugar escopo e eliminar um monte de delírio em forma de demandas.

Lembro como se fosse hoje quando em uma reunião de projeto, demonstrei que a demanda de uma funcionalidade traria prejuízos financeiros para a nossa empresa. Na sequência ficou claro para todos, inclusive para o diretor, que o analista de negócios tinha medo de dizer não para o cliente e transferia o risco para a equipe desenvolvimento.

Ali eu tive o estalo!

Parei de discutir tecnologia com quem não sabia tecnologia, para subir o nível da conversa e discutir dinheiro. Só desta forma que eu consegui transmitir para as pessoas o valor do meu trabalho e me posicionar melhor no mercado.

Eu deixei de ser um mero executor de demandas para me posicionar como um verdadeiro solucionador de problemas, alguém que conversa de igual para igual com os clientes e gestores.

Mas eu não vou dizer aqui que isso foi um processo fácil. Eu precisei me aproximar de pessoas que faziam o que eu queria fazer, precisei de uma mudança de mentalidade que me fizesse enxergar os meus projetos de software de uma forma completamente diferente.