Não sei se posto esta mensagem meio rancorosa porque meus últimos exames de saúde não foram aquilo que eu esperava, ou se é devido aquilo que o J. me passou pelo MSN há pouco.Enfim, o fato é que posições como os - famosos - arquitetos de software despertam o âmago do ego humano.
Sim, arquitetos de software, e principalmente aqueles que trabalham com a plataforma Java EE se acham deuses, como tal, esperam merecerem contratações astronômicas.
Que piada.
Tenho certos pré-conceitos (no bom sentido, e ainda sem saber se vai ou não hífen nisso com esta nova - e maluca - gramática portuguesa) a respeito de vagas para arquitetos, que são (vou falar do mundo Java, que é o que conheco):
Para mim (ou seria eu?), um arquiteto precisaria, no mínimo:
ALGUNS (MINIMOS) REQUISITOS PARA ARQUITETOS
Ter dez anos de experiência em Java, visto que ele precisa ter passado pelas dores das plataformas 1.1, 1.2, 1.3, 1.4, 1.5 e, claro, a 1.6 e 1.7; caso contrário, que referências um cara desse teria?
Conhecer pelo menos 2 servidores de aplicação Java EE, e isso não significa apenas instalar e configurar (o que qualquer tutorial na web mostra), mas sim realizar slimming e tunning das mais diversas categorias de componentes e protocolos que existem lá dentro (jms, ejb, ws, jaas, scritps, conectores http/s, jca, jndi, iiop, jmx...)
Ter nível superior completo, e isso é o mínimo que eu espero. Pessoas contra vão dizer que pouco adianta, mas isso é como certificacação, mostra caráter, força de vontade, dedicação, persuação e visão de alto nível sobre os bits e bytes que norteiam a vida dos informatas. A Alegoria da Caverna de Sócrates é um tema filosófico mas, não pasmem, ela é aplicada em qualquer empresa da atualidade, seja ou não seja de TI.
Um mestrado ou doutorado vai bem, obrigado. E aqueles que não o tem, que não levantem a mão para questionar, pois só quem já pesquisou (e muito) vai saber que aquela sua idéia mirabolante e maluca já teve, com certeza quase absoluta, dezenas ou mais de pessoas que já a exauriram em alternativas e implementações. Que o diga minha idéia do Merlin, com seus mais de 46 projetos similares ao longo dos últimos 25 anos de história!
Inglês para leitura, escrita, conversação e - claro - oratória. Ler e escrever nem se fala, isso deveria ser a nossa base desde o primário. Conversar, bem, isso deveria ser o básico na adolecência nossa e, falar ao público, bem, isso todo arquiteto que se preze tem que saber. É fato que a oratória está para o mundo da TI assim como para o do marketing. Não basta termos projetos arquietônicos maravilhosos se nossa equipe de TI não souber vendê-los. Então, duas coisas: Primeira, em um mundo globalizado, o que vale é a língua padrão de fato. E, segundo, quem melhor do que o arquiteto do projeto que vendê-lo ao cliente, patrocinador e usuário (I'm the architect. I created the Matrix.)?
Ter certificações, pode não provar nada. Que me diga o Corcel Negro daquela vez que fiz curso de MSSQL... Mas mostram, novamente, o item persuação e o famoso índice "C", culhão mesmo! Uma SCJP é básica, e qualquer programador precisa tê-la. Uma SCEA é o foco aqui, e ela, bem, ela mostra o "C" do cara.
Conhecer pelo menos 2 outras plataformas são o básico para qualquer arquiteto que se preze. De que adianta conhecer Java de cabo a rabo se o cara não manja nada de C, VB, PHP, Clipper, Cobol, Delphi, Ruby ou outra coisa do gênero. Isso me remonta ao caso do I. que era vendedor de carros, e em uma entrevista ganhou a vaga de seus concorrentes porque... simplesmente viu que para o cliente em questão o melhor não era um corsinha básico e barato, mas sim uma grande, possante e cara wagon. Não entendeu? Bom, é porque você não merece a vaga mesmo...
Saber muito de SQL, obrigado. Eu sou um daqueles que ama OQL, JPA, Hibernate, OCL e outras coisas do gênero, e acredito piamente que, quando tivermos mídia óptica de baixo custo e alta velocidade para leitura e escrita isso vai ser o boom do negócio. Mas por enquanto, os antigos preceitos de Projeção, Junção e Produto Cartesiano são inerentes à qualquer arquitetura de dados (claro, fora o BigTable do branquelo) e, portanto, conhecer como fazer bons SQL é essencial para qualquer arquiteto.
"Entender" SOA, do início ao fim. Parece outra piada, né? Mas é incrível como pessoas que mal aprenderam a fazer um HelloWorld com Webservices já se acham "o cara" e querem pleitear vagas de arquiteto. Se você já usou (e abusou muito, mas muito mesmo) de recursos como Pipes, Mashups, GData, JSon, JQuery, RSS, Shale, ESB, BPMN, alguma engine de regras de inferência (como Jess, Drools, ILog...), Apps e outros, bem, você está no começo e vai bem como um arquiteto júnior. Agora, se você quer ser pleno, vai ter que manjar de muitas outras coisas ainda - do nível de um OFBiz, por exemplo. E para sênior, bem, plajeio (existe isso?) aqui meu professor no PMP: É o Sei; É o Sei que Não Sei e É o Não Sei que Não Sei. Ave!
Manjar de Versionadores como CVS e Subversion são (e sempre foram) pouco. Ao arquiteto que se preze não basta saber usar, configurar e manutenir ambientes de versionadores tradicionais como VSS (hic!), CVS ou SVN. Manjar de Git pode ser algo para uma galera mais restrita, mas Mercurial e outros dessa cepa são coisas que deveriam constar no CV com, no mínimo, "experiência profissional em uso, administração e tunning"...
Pacotes xOffice são o mínimo. Outra coisa que passa despercebida entre os candidatos. Conhecer famílias como MsOffice, Notes, OpenOffice e análogos não é coisa da "guria do marketing", não. Ao arquiteto que se preze, saber fazer mala direta, indexação, índices analíticos, campos customizados e fórmulas exotéricas numa planilha eletrônica são coisas básicas. E por quê? Bem, essa eu deixo para vocês responderem...
UML é básico; U.M.L. é outro nível. Mais uma das coisas que o pessoal acha bonito colocar no CV e gritar, "Sim, eu conheço". Conhecer os 13 diagramas dela em suas 2 nuances é barbada. Agora, saber como usá-los, quando usá-los, como interligá-los, como não poluí-los, como passá-los para a equipe e cliente - sim, cliente e, claro, como mantê-los em sincronia com a Gerência de Configuração ao longo dos diversos baselines e marcos de projeto, bem, aí entra novamente o feeling de um bom arquiteto. PS. Última palavra: Projetistas fazem diagramas; Arquitetos, os definem!)
Dicção e Boa Aparência: Ainda esta semana questionei a E. sobre o que seria Boa Aparência quando estávamos vendo uma vaga para postar na consultoria de RH. Ela não soube responder. Nem eu! Mas o fato é que um arquiteto que não sabe falar em público, ou que fala como uma voz de caixa de abelha ou radinho de pilhas, que encolhe os ombros, que olha para baixo quando fala, que não responde (e não se cala) quando deve, que não assume a liderança, que não se expresse corretamente (de forma gestual, escrita ou oral), que não "puxe" sua equipe (de projetistas, designers, desenvolvedores, analistas, testadores, estagiários, comercial, diretoria, etc, etc, etc) bem, este cara está fadado a *não ser arquiteto*.
Processos nunca são demais. Outra coisa que acho engraçada. Todos conhecem o Waterfall. Legal, muito bom. Alguns conheçem o RUP. Uau, estamos bem ainda. Outros conhecem XP, Crystal, REUP e esses caras. Mais gente, talvez os mais novos, são fãs do Scrum, FDD e outros. Nossa, como somos bons! Mas, ao arquiteto, não basta conhecê-los; é preciso vivenciá-los. E isso faz toda a diferença. Particularmente, adoro FDD. E também aplico Scrum. E XP, às vezes. E RUP, em alguns casos. E o REUP, esse eu ainda não tive oportunidade. Até um pouco do 4+1 já usei. Enfim, não existe nada como a prática. Longe de mim ser expert em qualquer um deles. E ainda mais quando tento aplicar os preceitos do PMBOK sobre eles. É uma loucura, pura e simples. Assim, arquitetos, não digam "conheço", digam "usei, e minhas dores foram...". É mais realista, e sim, isso sim aumenta seu cachê.
JSRs, eu quase esqueci delas. Nem todos gostam de lê-las. Quem dirá, entendê-las. Mas para os Javeiros, elas são nosso porto seguro, e é por elas que devemos nos guiar. Tenho algumas delas no meu note, e frequentemente as leio para entender o porquê das coisas - embora muitas vezes seja difícil de aceitar porque uma mesma interface não pode ser Remota e Local ao mesmo tempo, ou porque os Jobs dos Timers não podiam ser inicializados já no deployment do artefato... Enfim, JSRs como a do WebBeans (que nome feio - e errado!) ou da JPA são colossais, mas necessárias. É conhecendo elas que damos os primeiros passos para, depois, corrermos para o abraço. Arquitetos, vocês, diferentes de mim, não as esqueçam, please!
Maven, Ant, Integração contínua e desenvolvimento por branches não são bixos de sete cabeças. São mais do que isso; são o Santo Graal dos ambientes de desenvolvimento. Cabe aos arquitetos montá-los, gerenciá-los, intercambiá-los e, óbvio, mantê-los ao longo do tempo - muitas vezes por vários e vários anos a fio. Maven para mim é um ótima ferramenta de download e, talvez, por isso, não ouso pleitear uma vaga de alto escalão.
Utilitários, Bibliotecas e Frameworks não devem ser feitos. Pelo menos, não por você, arquiteto comercial. Você vai bem montando um utilitário para ajudar em algum projeto aqui ou acolá. Uma biblioteca? Bem, quantos de vocês podem colocar em um CV algo como um, hum, deixe-me ver...hum, um Javassist? Ou um MicroKernel JMX? Bem, são poucos. E frameworks então? Não é questão de mérito, mas de foco. Cada uma dessas coisas tem complexidade logarítmica para criação. Assim, quando estamos desenvolvendo um projeto, é notória a tendência de sair do foco do PROJETO DO CLIENTE e cair no MEU FOCO MEGALOMANÍACO de criar um novo framework da hora para o mercado, que vai derrubar aquele lixo do Hibernate ou Spring... É óbvio que são arquitetos visionários que criam coisas desse gênero, mas isso tem hora e lugar. Projetos Open Source são um cultivaris show de bola para isso. Então você colocar no seu CV que criou um "framework de persistência de alta performance no projeto X", bem, é mais fácil você conseguir uma oportunidade em um projeto de pesquisa do que em uma empresa de mercado que visa lucro com projetos comerciais.
Hierarquias e prioridades e precisam serem seguidas. Lembro de quando eu trabalhava mais forte nesse lance de projeto e arquitetura de sistemas - que diga-se de passagem eu adoro - e era constantemente "podado" pelos meus GPs. Eu ficava P da vida. Pô, eu vou demorar um pouquinho agora, mas daqui 3 semanas a galera vai estar 2 vezes mais rápida com isso... Maravilhoso, não? Pois é, nem sempre. Já ouvi por isso coisas como "ou vai você, ou vai a equipe". Fui eu. Hoje sei o que é isso, e embora eu adore perfis visionários - sim, confirmo, também o sou - eles tem hora e lugar para serem explorados. Quando falo como o J. ou mesmo com o P., sempre digo "pessoal, precisamos dos nossos lists e filtros genéricos" e, em conjunto, nos cobramos para fazê-los. Sentimos na carne não ainda os tê-los. Porém, a prioridade nos manda realizar a entrega do cliente, e não a nossa. Assim, hoje entendo aquilo que me cobravam há 10 anos atrás...
FINALMENTE
Não sei se falei tudo aquilo que nossa lista de itens pede para um arquiteto master f.cker, mas falei o mais importante.
Difícil é chegar pessoas com 3 ou 4 anos de experiência e quererem R$ 50,00/hora. Isso sim é difícil de entender.
Termino o post aqui com aquela do médico que vai ao mecânico e pergunta quanto deu o serviço de retífica do motor do seu carro:
_ Foi 3.000 real, chefia.
_ Hum, você não acha caro, não?
_ Pois é, né chefia, eu tive que abrí todo o motor e trocá umas parte. Mas tá tudo novinho di novo. Um relógio, basta ligá pra ver.
_ É, mas mesmo assim, é caro.
_ Chora não, chefia. O sinhô não cobra caro também só pra trocá umas pecinhas na genti, não?
_ Sim, mas as eu troco com o motor em funcionamento!
T+
