Pare de discutir tecnologia quando o assunto na verdade é dinheiro

Muitos programadores acham que codificar é suficiente. Que tudo além do código é papel apenas dos gestores da empresa. O que não percebem é que com este pensamento eles abrem mão do seu maior diferencial. Entenda o porquê.

0

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 e 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 sozinho 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. Foi assim que me apropriei das 03 alavancas que me levaram muito além da programação. 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 para começar este processo, foi necessário uma mudança de mentalidade. Eu precisei entender uma forma diferente e muito melhor de enxergar os projetos de software.

Foi assim que eu comecei a compartilhar essas sacadas em palestras, hacktalks, vídeos curtos no #PapoRápido, nas redes sociais e principalmente, no curso Welcome to the Django.

>>> Se você quiser conhecer melhor o Welcome to the Django e como ele funciona,  é só clicar aqui neste link! <<< 

Para ser avisado sobre  novos conteúdos, eventos ao vivo e sobre as próximas edições do WTTD é só se cadastrar no formulário abaixo:

você pode gostar também