Na faculdade começamos a ter uma ideia de um bom desafio, talvez entregar um trabalho ou passar em uma prova difícil.
Mas o que acontece se você não consegue ? Talvez uma bronca dos pais ou talvez a situação chata de ter que fazer a matéria novamente.
Ok, isso é interessante para ter uma ideia, mas está longe da realidade.
Muitas vezes em um emprego aparece uma situação complicada, uma difícil barreira, que não é qualquer um que consegue passar,e o seu emprego depende disso. Pagar suas contas, manter o seu nível de vida e com dependentes a coisa piora… achar um bom emprego não é fácil então o desafio para você vira aquela missão de guerra que ou você vence ou você vence.
Isso eu chamo de maior desafio, e é uma pergunta que normalmente eu faço quando aplico um processo seletivo, pois é nesse momento que você descobre o perrengue que o candidato passou e, o melhor, qual a solução que ele encontrou para resolver esse problema.
Na minha vida profissional eu passei por alguns, mas certamente considero o maior desafio profissional o projeto que fiz para a engenharia para uma empresa de telecomunicações que oferecia serviços de rádio através da tecnologia iDEN.
Era o ano de 2007, além dos funcionários, os terceiros como eu também recebiam um desses:
O primeiro projeto, apesar de ser para a engenharia, era basicamente um controle de estoque, então a parte de negócio foi bem tranquila. Ele não foi um desafio, mas o modelo que adotamos naquela época em que só se falava em modo de desenvolvimento em cascata.
Depois de algumas reuniões com o usuário, passamos para a modelagem e começamos a codificação com as principais tecnologias da empresa:
Banco de dados: Oracle
Linguagem de programação: Java 1.4
Arquitetura: Struts 1.1 de controller, JSP/JSTL de viewer e EJB 2 de service
Enquanto começamos a codificar o projeto, passamos por uma feliz coincidência: o usuário de engenharia tinha reunião até as 11h no nosso prédio (ele trabalhava em outra unidade) e aproveitava o resto do tempo até a hora do almoço para ver com a gente como estava o projeto.
Essa reunião semanal foi essencial para nos manter no caminho certo, pois cada tela do sistema antes de ser codificada já era validada pelo usuário, e durante o desenvolvimento, algo super normal aconteceu: identificamos um erro de modelagem que naquela semana gerou algumas horas extras, mas certamente sem o alerta do usuário essa alteração se transformaria facilmente em semanas de codificação.
O que aconteceu foi tipicamente o que se diz em um treinamento de SCRUM: toda reunião com o Product Owner do projeto ele conduz a equipe para o caminho certo, para construir a aplicação do jeito que ele quer, afinal quem precisa e vai usar é ele e não o desenvolvedor. Parece uma dança de valsa.
Isso serviu de um aquecimento para o verdadeiro desafio que vinha pela frente.
Foi nessa época que, bem antes de sair no cinema, em qualquer xing-ling tinha uma TV passando e vendendo o filme mais famoso de 2007.
Antes de começarmos o projeto já enfrentamos uma barreira emocional da empresa: anos antes gastaram quase um ano tentando fazer um sistema parecido e sem sucesso, o que gerou um certo trauma aos usuários e aquela sensação de que a coisa não iria dar certo.
Para piorar, do nosso lado encontramos um sistema de engenharia que envolvia um contexto totalmente abstrato e que não era possível comparar com nada do nosso mundo real.
No sistema anterior, era um catálogo de peças de engenharia, mas não muito diferente de um catálogo de alguma coisa, com cadastro, busca, etc. Entretanto, esse sistema novo envolvia uma série de conceitos novos, onde dezenas de parâmetros de coisas distintas resultam em um cálculo maluco em uma planilha gigante.
Então basicamente funcionava assim: todo o país onde tem a cobertura de sinal de rádio tem alguns parâmetros que aumentam ou diminuem o sinal. E todo dia uma equipe de engenheiros da divisão RF (rádio frequência) revisava os eventos do próximo dia (jogos, shows, exposições), recalculavam os parâmetros e reprogramavam os novos valores para dentro do sistema. E, no final do dia, um outro engenheiro fazia a carga dos novos parâmetros para o sistema principal, que por segurança era isolado, e à meia-noite os novos valores eram transmitidos para a rede.
Antes de existir o sistema, os engenheiros usavam uma planilha Excel e preenchiam manualmente as alterações, e várias macros malucas rodavam para fazer os cálculos. A planilha era tão grande que ao usarmos a biblioteca POI estourava a memória sempre, por mais ajuste de performance que a gente fizesse. A solução foi usar o JExcelAPI.
Depois de um ano de codificação e testes, conseguimos entregar o sistema, e foi um sucesso. Na época, meses depois recebemos a visita de americanos da matriz e eles comentaram que lá o processo ainda era manual. Mesmo anos depois que deixei de trabalhar lá eu soube que parte do sistema foi reutilizado no México.
O primeiro grande desafio técnico a gente nunca esquece. =D
Fernando Boaglio, para a comunidade
