Mas aí é que está. Isso é o que o mercado é hoje. Não quer dizer que é o melhor meio, nem que funciona.
Será que o analista sabe mesmo “fazer o programa virar dinheiro”? Esse é o grande problema: quando se separa programação e entendimento do negócio, os programadores farão software que não está alinhado com o negócio (pois eles não receberam o conhecimento); e os analistas farão especificações que não são facilmente traduzidos para código (o que gera códigos difíceis ou lentos ou simplemente em desacordo com a especificação pois este é ambíguo).
O profissional técnico que ganha bem é o Especialista, certo. Mas em que? Em Java? Em Orientação a Objetos? Não! Especialista em Oracle, em Linux, em Mainframe… Ou seja, não são especialistas em fazer softwares excelentes, mas simplesmente em manter as coisas no ar.
Esses profissionais viram “pessoas chave” porque é fácil medir os prejuízos da indisponibilidade de uma aplicação. Por outro lado, é difícil medir a vantagem de um software bem feito por profissionais competentes em relação a um software mal feito por indianos movidos a chicotadas. Daí o pensamento pra “reduzir os custos” é um pulo.
Sinceramente, o estado atual do mercado de TI é broxante. Ele só “funciona” porque todas as empresas fazem do mesmo jeito, e todos tem igual prejuízo. No momento em que uma empresa fizer diferente e se destacar, o restante vai correr em manada.
O Thiagosc falou algo sobre o Brasil ter uma característica da época da escravidão de precisar de um gerente “capataz” pra mandar neles. Isso me fez lembrar desse vídeo (não sei se é esse ou alguma continuação desse) que o Waldez Ludwig fala sobre isso, algo que eu concordo plenamente.
Independente disso, esse cara fala muita coisa interessante sobre mercado de trabalho, vale a pena conferir.
o mercado está do jeito que está porque muitos programadores estão preocupados em aprender frameworks de moda e poucos estão realmente preocupados em atender por completo a necessidade do cliente.
Um cara que conhece a tecnologia utilizada no desenvolvimento, que consegue tornar real o que até então é somente uma abstração do Analista, não poderia ser chamado de peão em momento algum. Esse termo só pode ser utilizado por aqueles analistas que ficam frustrados em ver o quão o programador conhece da tecnologia enquanto eles ficam fadados a somente criar sistemas imaginários que não resolve nada. Os verdadeiros problemas só aparecem ali, na hora em que o peão está programando e começa a encontrar falhas e deficiências que o analista não conseguiu ver.
O cara do “negócio” quase sempre vende para o cliente o que os programadores vão ter que se desdobrar para resolver, porque o cara do negócio não conhecia a tecnologia a fundo a ponto de apontar para o cliente as limitações e implicações do que ele estava pedindo.
[quote=celsomarcos]Um cara que conhece a tecnologia utilizada no desenvolvimento, que consegue tornar real o que até então é somente uma abstração do Analista, não poderia ser chamado de peão em momento algum. Esse termo só pode ser utilizado por aqueles analistas que ficam frustrados em ver o quão o programador conhece da tecnologia enquanto eles ficam fadados a somente criar sistemas imaginários que não resolve nada. Os verdadeiros problemas só aparecem ali, na hora em que o peão está programando e começa a encontrar falhas e deficiências que o analista não conseguiu ver.
O cara do “negócio” quase sempre vende para o cliente o que os programadores vão ter que se desdobrar para resolver, porque o cara do negócio não conhecia a tecnologia a fundo a ponto de apontar para o cliente as limitações e implicações do que ele estava pedindo.
Falei…
té +[/quote]
pense também do outro lado… o “cara do negócio” como você diz, se mata para procurar ao máximo entender e refinar
a necessidade do usuário final, procurando entender tudo o que se passa no ambiente do cliente, sejam os riscos, os
impactos de cada mudança de regra, etc… chega em um acordo final com o cliente, faz aquela reunião com os “programalistas”,
explica exatamente o que precisa ser feito (do ponto de vista de negócios) e o resultado final sai aquela “beleza”,
afinal o programador de framework estava mais preocupado em aplicar o que aprendeu na revista de java do que entender o
processo e resolver o problema do cliente …
mas deixa estar, afinal estava alocado… que o empregador arque com o prejuízo como dizem por ai e sigamos caminhando
de consultoria pra consultoria.
Ok… concordo com você… mas não estou falando do “programalista”, estou falando do programador, do cara que se interessa sim, em dominar a tecnologia, mas que sabe que conhecer o negócio e entender o que se busca resolver é tão importante quanto a tecnologia, não interessa se é java ou c#… O que não pode ocorrer, e que ocorre muitas vezes, é o cara do negócio agradar o cliente e dizer amém pra tudo né…
[quote=celsomarcos]Ok… concordo com você… mas não estou falando do “programalista”, estou falando do programador, do cara que se interessa sim, em dominar a tecnologia, mas que sabe que conhecer o negócio e entender o que se busca resolver é tão importante quanto a tecnologia, não interessa se é java ou c#… O que não pode ocorrer, e que ocorre muitas vezes, é o cara do negócio agradar o cliente e dizer amém pra tudo né…
Falou…[/quote]
então não era um “cara do negócio” e sim um capacho.
Entendam:quando usei o termo “servente de pedreiro” me referi não ao conhecimento,mas á valorização do profissional dentro das empresas…
[/quote]
Mas você está certo. Independente do que nós achamos, a visão do mercado é do programador ser o servente de pedreiro mesmo. O mais valorizado sempre vai ser o analista por ser a pessoa que entende do negócio e que vai saber fazer o seu programa virar dinheiro. Daí o motivo de valer mais.
Mas para o programador/desenvolvedor (ou qualquer nomenclatura que a empresa adote para o profissional técnico) ganhar mais, o caminho é o ESPECIALISTA, o que sabe muito sobre uma área técnica e vire uma pessoa chave na empresa.
[/quote]
Isso de comparar programador com servente de pedreiro só na área de “TI” mesmo(Quando digo TI, me refiro a área da computação das empresas privadas). O área científica pensa de maneira completamente diferente. Os programadores são pesquisadores tmb, e não “serventes”.
O problema nem é o termo, servente, pedreiro, tanto faz como chamam os programadores. O problema é o falha de comunicacao que invariavelmente se cria colocando um atravessador entre a informacao que vem do cliente e vai para o programador. A possibilidade de algo dar errado é bem maior do que se for a mesma pessoa que recolhe os requisitos e os implementa.
Se um programador nao sabe fazer as duas coisas, ou ele aprende ou ele nao serve. Se um analista nao sabe fazer as duas coisas ele tambem nao serve.
Vejo muitos analistas por ai que nao gostam/sabem programar. Bem, meu irmao tambem nao gosta de programar, ele é contador.
