Muitas vezes me encontro ante a tarefa de ajudar outras pessoas a desenvolver a tarefa de desenvolver e vejo que as mesmas dificuldades se repetem de TI a TI.
Me explico: Alguns programadores (desenvolvedores) chegam a um ponto da vida em que não mais conseguem desenvolver (levar adiante) o trabalho que o resto da empresa que o contratou espera que ele realize. Isso é especialmente verídico quando se trata de empresas que não são da área de desenvolvimento. Ou seja, são empresas cujo propósito não é o desenvolvimento de software. Por consequência, elas não tem a obrigação de entender as nuances do processo de desenvolver software.
De qualquer forma, cada vez mais essa mesma dinâmica de frustração empresarial seguida de depressão no staff de desenvolvimento de software se começa a ver também nas softhouses já que cada vez mais estas últimas são geridas por pessoal que não tem a ver com TI e em muitos casos até aturam o departamento de desenvolvimento como um mal necessário.
Claro, que a solução obvia para o dilema é a de cada uma das partes entender a outra e assim juntos de forma regular podem vir a realizar mais e melhores projetos. Todavia, eu quero analisar um outro caminho esquecido que pode vir a melhorar e em muito o processo de desenvolvimento de um desenvolvedor: O caminho do serviço.
Servir o outro nada mais é do que abdicar do próprio desejo de ser servido e passar a fazer um esforço ímpar e unilateral de entender o que o outro quer. Isso se torna especialmente útil em empresas que não são soft-houses e tem um departamento de TI para resolver tudo internamente. O programador mor desse TI quase sempre é visto como uma pessoa negativa e de difícil trato; um ser quase inatingível com sérios problemas psicológicos se não psiquiátricos ao qual deve-se aturar já que ele é o único detentor dos oraculos necessários para manter sob controle o deus informação que está trancafiado metafisicamente nos porões do misterioso servidor local ou ascendeu a uma tal de nuvem na internet que não conseguem os simples humanos materializar.
Por sua vez, o ogro que habita a caverna de TI pensa do resto com medo e desconfiança já que lhe pediram na reunião retrasada para fazer uma coisa, na anterior para fazer o contrario e nesta estão lhe exigindo respostas de por que não fez a primeira, mesmo que ela mexesse com a estrutura básica da base de dados que não foi pensada para responder aos questionamentos que agora se planteiam na diretoria. Só pode ser uma forma moderna de inquisição, uma tentativa de derrubada da sua dificilmente conquistada posição, uma conspiração orquestrada por algum ex-concorrente que deve ser amigo íntimo do primo do vizinho do andar de baixo de um dos sub secretários de um dos colegas de bar de um membro quase sempre ausente da diretoria.
Bem, brincadeiras à parte, a verdade é que de ambas as partes há um medo e desconforto descomunal e que reuniões de interação lúdicas organizadas pelo RH da empresa podem fazer diminuir bastante. Porém, além disso acho que o TI luta internamente por ter a melhor opção de lógica, a última palavra em código escrito, e se possível, uma perfeição quase que divina nisso tudo e eis aqui que radica o problema.
A empresa (principalmente se não é uma softhouse) não está nem ai para teu código, meu chapa. Ela quer mais é que a empresa funcione e cumpra seu propósito. Se você conseguiu poupar 20ms no cálculo do custo médio de um produto sobre uma base com mais de 500mil produtos eles só vão se limitar a dizer “ahá.. que legal, como continua o projeto tal?” Tipo, não é o foco deles. Parabéns para você por ter conquistado 20ms * 500k em uma rotina que vai ser usada uma vez por ano mas sinceramente, isso não vai fazer a menor diferença para eles. Então o que? Isso mexe com seu ego? Pois é, é exatamente ai que está o problema de TI, ninguém está disposto a morrer. Serviço é morte. Claro, RH e companhia vão tentar te dourar a pílula e tal para te fazer sentir melhor, mas o que é, é. Simplesmente você, meu querido, é tão importante como são os outros departamentos. Nem mais nem menos. Isso doi. Porque você sabe que sim, é você quem detêm os oráculos para tornar esse monte de lixo eletrônico em coisa útil. Você sabe que o que te pediram na última reunião não tem chances de ser feito até terminares primeiro o que te pediram na outra semana que por sua vez nega o que vão te pedir na seguinte. Mas, meu, é esse o pensar humano. Vamos e voltamos. Somos assim. E se você não reparou, não somos máquinas.
Então o que fazer? Servir. Não há outra. Isto é, traduzir os desejos da empresa em pequenas e interconectáveis peças de software que se materializem em alguma tela, relatório, tabela, interface que a empresa consiga apalpar. Deverás abandonar um pouco (um pouco) o perfeccionismo (em especial aqueles que diz respeito aos outros departamento e às pessoas) e abraçar relaxadamente a humanidade que cerca o departamento de TI.
Claro, você vai argumentar, “mas Esteban, eles não entendem o tempo que leva fazer o que eles pediram, me dá medo só de ter que mostrar, pareço sempre o cara da negatividade“. Bem, nesse caso, meu amigo, vai ter que lembrar da galinha e da pata. A pata bota um único ovo vistoso e bem nutritivo que imagino comendo só um por semana, você estaria completo. Mas o faz em silêncio; ninguém sabe que ela botou um ovo. Já a galinha faz a maior farra com ovos menores e menos vistosos. Cacareje, meu filho, cacareje. O que te pediram vai levar 15 dias trabalhando em moto perpetuo?, bom, recalcule para mais e acrescente 20%. Divida o projeto em coisas “entregáveis” a cada 15 dias. Faça ou utilize um programinha besta que mostre aos outros o que está fazendo. Chame antes das reuniões os diretamente envolvidos na solicitação para ver o andamento. Aceite as correções dos simples mortais; ao final das contas, eles não são obrigados a saberem que justo aqueles casos que eles acham serem minoria ou ocorrerem “muito esporadicamente” são a maçã podre que te estraga o resto da caixa.
Caso não consiga servir os outros, caso para você seja uma carga muito pesada ter que aturar o pensar simplificado e muitas vezes simplista, vá percorrer a empresa para a qual trabalhas. Observa que tua função não é a mais importante de todas. Que coloques em forma de código a inteligência da empresa não te faz mais inteligente que ela. Que saibas como montar um servidor virtualizado ou um HBA redundante não te faz mais importante do que o departamento de contabilidade ou o de manutenção. És só mais uma peça que a empresa (que te sustenta por meio do salário) precisa para seguir enfrente e ter seus projetos realizados.
Então serve. Com amor, dedicação e inteligência, mas serve. Coloca o propósito e forma operacional da empresa acima dos teus próprios porque somente assim ela pode te enxergar como alguém de confiança e talvez (só talvez) algum dia tuas formas de trabalho possam ser apreciadas por outros mas lembra constantemente que o que fazes estará sempre no porão do código fonte da tua obra maestra.