Sim.. Este é mesmo o título deste desabafo.
Desabafo este vindo de uma enorme indignação. Vinda de uma situação pela qual passei nos últimos tempos e que preciso compartilhar.
Vamos lá:
- Tudo começou quando comecei a trabalhar em uma empresa(a qual não posso contar o nome) que tinha uma equipe pequena, com salário acima do mercado e com projetos simples e legados. Achei ótimo, pois pensei que poderia trabalhar num lugar sossegado, com salário bom e o melhor, ajudar a equipe a evoluir os projetos, pois eram todos desenvolvidos com tecnologias mais antigas, o que fazia a manutenção e o desenvolvimento ficar muito custosos.
Imagine um ERP feito com jdbc. Isso é terrível não é? sim, nos tempos de hoje é.. pois então:: Foi me passado a minha primeira tarefa: - Desenvolver um sistema de geração de arquivos fiscais para a receita federal. Tranquilo e fácil não é? Seria se.. Se não tivessem alguns detalhes que diferenciavam a TI da empresa. Eu não dispunha de um dump da base de produção. Apenas de uma cópia do DDL do banco e com apenas duas notas fiscais na base local.
A princípio não haviam problemas. Desenvolvi o sistema em 4 dias(1/2 dia pra gerar arquivos e montar uma arquitetura jdbc. E outros pra desenvolver e testar as regras). Pronto. Agora é só testar em produção certo? ERRADO.. Eu não podia testar em produção e nem dispôr do dump para homologar o sistema. Mas aí vc vai dizer: Mas nem todo mundo tem acesso ao banco de dados de produção. CORRETO. Eu pedi um DUMP.. E a resposta que tive: Me enviaram papéis impressos com as tabelas e alguns dados.
Quando perguntei prq não tínhamos um dump me disseram que não era possível porque o banco possuia muitas foreign keys. AHAHAH.. que piada.. Contei a alguns especialistas em banco e rimos muito juntos. Foi quando comecei a desistir de trabalhar. Pois o processo para terminar o tal sistema, que já estava pronto, era: GERAR UM JAR E MANDAR POR E-MAIL PRO "RESPONSÁVEL" TESTAR. E ele me mandava de volta os logs de erros pois ele testava na base de produção com milhares de notas fiscais. E achava que não dariam erros. Que incrível!!! Que idiota.
Quando falei pro resto do pessoal a minha indignação com esta situação o pessoal me disse que infelizmente era assim. O cara que tinha acesso, mais chamado pelos outros de "MICKEY", pois foi apelidado por se tratar de um "FILINHO DE PAPAI", que provavelmente foi o que deixou essa "PESSOA" com a arrogância que ele tinha. E que fazia ela pensar que era melhor que os outros profissionais da equipe.. O pessoal me contou que o "MICKEY", também um PUXA SACO, já tinha feito a cabeça dos chefes e convencido eles de que o processo deveria ser assim. Que somente ele teria acesso a tudo.
De início não acreditei, mas depois do que estava acontecendo comecei a acreditar..
Ai, ficamos nesse vai e vem de e-mails com os jars da aplicação e logs pra eu "TENTAR DESCOBRIR OS ERROS SEM VER OS DADOS" por TRES SEMANAS. Acreditam? Prq eu ainda não acredito. Pensei em pedir demissão no início, mas não queria fazer um ato de rebeldia e me controlei.
OBS.: PRESTE ATENÇAO NISSO: Quando finalizei o sistema, na primeira semana, e os arquivos passaram na validação do sistema validador da receita-federal, Tive que repassar algumas vezes as regras no código porque ele funcionava comigo, mas quando o MICKEY executava na máquina dele os arquivos não passavam na validação. Após ter certeza de que estava tudo ok, resolvi enviar os arquivos para o suporte da própria receita-federal verificar o que era o problema. Após dois dias tive a confirmação de que OS ARQUIVOS ESTAVAM CORRETOS. E que o PROBLEMA ESTAVA NO COMPUTADOR QUE ESTAVA GERANDO OS ARQUIVOS QUE ESTAVA COM UMA CONFIGURÇAO DE CARACTERES QUE FERRAVA OS ARQUIVOS.
Ou seja, se tivesse simplesmente executado o sistema no meu computador conectando na base de produção, provavelmente os arquivos tivessem sido gerados ok e validados pelo sistema da receita-federal logo de início.
O MICKEY era conhecido por "QUEIMAR AS PESSOAS" e resolvi esperar pra ver no que ia dar.
OUTRA COISA.. o MICKEY era pra ser o responsável por passar as tarefas para todos da equipe, pois também não tinha-se um sistema de gerenciamento para isto.
"ELE NUNCA ME DIRIGIU A PALAVRA". A não ser quando os chefes ligaram pra ele pra cobrar sobre o sistema que EU ESTAVA FAZENDO, mas ele dizia aos chefes que ELE QUE ESTAVA FAZENDO.
MAIS OUTRA COISA.. o MICKEY perguntou quando ficava pronto o outro sistema? que sistema? Ele não passou a informação sobre outro sistema e estava cobrando..
MAIS OUTRA COISA.. O MICKEY não gostava do hibernate. Ora ora. Como a maioria dos caras de banco de dados ele também não gostava do hibernate. Mas tem um detalhe interessante. Ele só sabia trabalhar com banco de dados enquanto que verdadeiros administradores de banco e DBA's, sabem pra que serve o hibernate.
PS.: HIBERNATE NAO SERVE PARA FICAR MONTANDO UM MODELO DE DADOS ER CRIADO NUM BANCO DE DADOS. ISSO EH TRABALHO DOBRADO. MESMO QUE SEJA COM PLUGINS, POIS OS PLUGINS(NAO CONFUNDIR COM HIBERNATE OU JPA). NAO FAZEM UMA ENGENHARIA REVERSA PERFEITA. ESSE TRABALHO EH ARDUO E DEMORADO.
HIBERNATE SERVE PARA ADMINISTRAR E CRIAR UM MODELO DE DADOS ORIENTADO A OBJETOS DE UM SISTEMA E ASSIM, USAR O BANCO APENAS COMO REPOSITORIO DE DADOS.
AGORA vcs estão começando a concordar comigo.. hein?!?
Enfim, eu não tinha mais motivação, pois eu não conseguia ser produtivo, não tinha autonomia, não tinha confiança da empresa e nem tinha pra quem reclamar, pois os chefes, que deveriam estar a par disso ficavam em SP. Bem distante de nós. Mesmo assim eles já estavam nas mãos do MICKEY.
Pra aqueles que leram isto e devem estar se perguntando, mas você não fez nada?
- Sim. Eu tentei propôr soluções, reuniões, mandei e-mails que sequer foram respondidos.
Só me restou desanimar e ser "executado", pois tinha resolvido não pedir demissão. Fui "QUEIMADO PELO MICKEY".
30 MINUTOS DEPOIS EU COMECEI A TRABALHAR EM OUTRA EMPRESA COM OUTRA MENTALIDADE: PRODUTIVIDADE E INOVACAO.
E PRINCIPALMENTE: SEM NENHUM DESENHO ANIMADO E CENTRALIZADOR NA EQUIPE.
Hoje trabalho com arquitetura, desenvolvimento, orquestração, GESTAO DE CONHECIMENTO e inovação de sistemas.
FICA A DICA.. SE TIVEREM UM MICKEY NA EQUIPE. SAIA DELA. ATÉ FAÇA O POSSÍVEL, MAS SE NÃO ADIANTAR, ABANDONE. ESTA EMPRESA NÃO VAI EVOLUIR.
