[size=18]« Engenharia de BuildProgramação RADioativa »Quando eu crescer quero ser Analista de Sistemas[/size]
Este tópico está na minha fila de posts há meses, hora de sair algo. Eu vou me basear num e-mail que recebi de uma pessoa do GUJ (que só não vou falar o nme porque não pedi autorização):
Sobre o ?polêmico? manjado tópico de que o java pode acabar.
Você postou o seguinte (na primeira página):
Software é programar. Se você que gerenciar uma equipe de desenvolvimento você tem que estudar matérias relacionadas à gestão de pessoas. Isso não é uma evolução do programador, um desenvolvedor de software é sempre um desenvolvedor de software.
Será que alguém que se forma em Ciência da Computação (como eu, se Deus quiser) não consegue o cargo de gerência de equipe? Eu vejo isso pelo meu tio? ele é formado em Engenharia Química e hoje é gerente de um empesa aqui, mas porquê? Porque ele conhece como as coisas funcionam? todo gerente que conheço ou que já ouvi falar aconteceu o mesmo? gerentes de supermercado geralmente sabem tudo o que se passa dentro do maldito mercado! Concorda? Logo, começa-se como programador, pra depois passar pra cima. Ou não? Você já foi programador? Estou em dúvida porque parece que o salário de um programdor (caso eu seja programdor pra vida inteira, que é algo que eu não quero) é baixo e não dê pra sustentar uma família, entende? Da maneira que eu digo faz parecer que eu não quero ser programador JAMAIS, mas eu quero? putz, amo programar, tenho um tesão gigantesco por programação? mas o problema é se vai me sustentar bem e minha família pro resto da vida, entende? Acredito que se um dia eu chegar a um cargo que não envolva programação eu ainda assim vou programar, pra me divertir mesmo.
E aí, o que você acha?
Este é um problema bem grande. Vamos começar sobre um problema que não está explícito no e-mail mas que existe: aquilo que alguns chamam de analista de sistemas.
Quando eu estava na faculdade pela primeira vez (ou seja: antes de largar ela pela rimeira vez) lembro de ter aula com um professor daqueles com anos de COBOL nas costas. Ele se lamentava sobre como o mercado confundia analistas e programadores e como estava surgindo a bizarrice do ?progranalista?, alguém que combinava os dois papéis. Na comunidade em geral você vê este pensamento, eu tenho muitos conhecidos que querem ser ?analistas?, o que para eles significa desenhar UML ou fluxogramas que são passados para os programadores.
Eu acho que já escrevi sobre isso aqui mas isso não é algo justificável. Eu nunca desenvolvi em COBOL ou uma destas plataformas mais antigas e não posso te dizer se se justificava há alguns anos mas não faz mais sentido, e há muito tempo. O papel do analista seria, teoricamente, converter um modelo abstrato (de negócios) em um modelo lógico, geralmente expresso de forma gráfica. O modelo lógico então passa a um modelo físico, que é a implementação.
Agora vamos analisar o caso de uma plataforma moderna de desenvolvimento como Java, .Net ou Ruby. Um modelo abstrato é composto por conceitos de negócio, geralmente estes conceitos não possuem uma estrutura que um computador entenda. O analista vai traduzir este conceito em lógica, provavelmente usando UML. Ora, UML é apenas uma notação gráfica para classes e objetos e sua linguagem favorita já trabalha com classes e objetos. A tradução entre um modelo lógico e o modelo físico é desnecessária: o modelo lógico já é o modelo físico. A diferença é que UML não executa, por mais que os evangelistas de MDA cismem do contrário.
A solução? Modele em código. Caso você precise erar diagramas basta você utilizar uma das dezenas de ferramentas de engenharia reversa. Modelando em código você tem algo executável, testável e que pode dar feedback ao seu usuário.
?Analista de sistemas? é algo que não existe. Pode ter existido um dia, não sei, mas não faz mais sentido há muitos anos. O modelo lógico é expresso em linguagens de altíssimo nível que modela muito bem o negócio: Java, Ruby, C#? Quem converte o lógico em físico é alguém que nem cobra muito por isso: o compilador.
Alguém colocar na sua assinatura de e-mail ou ter a carteira assinada (como eu já tive!) como ?Analista Java? está se enganando e colaborando para a criação de papéis que só existem na burocracia das empresas e das pessoas.
Mas e o papel do analista de resolver problemas de negócio? Sinto informar mas se você fazia isso como analista você estava ou se enganando ou enganando seu cliente. É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema mas isso não é papel de analista de sistemas, é papel de analista de negócios. Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o ?analista de sistemas? a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e mais especializado em um mercado como bancos, marketing, telecomunicações e etc.
Mas e o gerente? Uma das piores coisas que podem fazer em uma empresa é promover um bom técnico à gerente (coordenador, o que for) apens porque ele está há mito tempo na casa. Querem estimular a pessoa? Transormem ele em um líder técnico, aumentem o salário do sujeito e o deixem em paz.
Gerência não é brincadeira. Não é porque alguém programa muito bem que vai ser um bom gerente. Se você é desenvolvedor mas sonha em dizer para a paquera no barzinho que é gerente de algo (nem que seja do McDonald?s) invista nisso. Aprenda sobre liderança, sobre mercado, plano de negócios, luxo de caixa, lean e todas as dezenas de disciplinas envolvidas. Vai levar um tempo.
Só não encare isso como uma evolução. Você está saindo da carreira de técnico, não evoluindo. Considerando que conseguir bons salários como técnico é raro pode ser uma boa escolha, mas nem sempre é. Se você é um bom técnico existem opções?