bééééé …
Empresas de maneira geral, não só na área de desenvolvimento de software, tem reconhecido cada vez mais a importância das pessoas e o capital humano como o capital de seu maior valor. Isso acontece porque toda empresa precisa inovar sempre, sob o risco de tornar-se obsoleta. E para inovar penso que o caráter multi-disciplinar e a diversidade são fundamentais, de forma que cada pessoa passa a tornar-se única, e não mais parte de um processo.
bééééé …
Empresas de maneira geral, não só na área de desenvolvimento de software, tem reconhecido cada vez mais a importância das pessoas e o capital humano como o capital de seu maior valor. Isso acontece porque toda empresa precisa inovar sempre, sob o risco de tornar-se obsoleta. E para inovar penso que o caráter multi-disciplinar e a diversidade são fundamentais, de forma que cada pessoa passa a tornar-se única, e não mais parte de um processo.[/quote]
As empresas em geral também estão aperfeiçoado seus processos para produzir cada vez mais e com um menor custo.
Você tem um IPad, Iphone, notebook ou qualquer outro tipo de equipamento eletrônico por perto? Veja o local de fabricação e existe uma grande chance dele ter sido produzido na China… preciso dizer o motivo? O preço que pagamos pelos produtos é baixo graças ao sacrifício da renda de milhares de pessoas e da exploração irracional dos recursos de suas terras.
Por outro lado, é verdade que as empresas estão valorizando cada vez mais os “colaboradores”. As empresas começaram a perceber que o talento de cada pessoa também deve ser valorizado, mas não pq precisam inovar( não que não precisem), mas pq precisam de lucro. Uma pessoa vale para uma empresa a quantidade de lucro que ela é capaz de produzir.
Não importa o quanto queremos acreditar no contrário, mas para as empresas as pessoas são substituiveis e assim deve ser mesmo. Uma empresa não pode(ou não deve) depender de uma pessoa. Por isso algumas dão tanta importância aos seus processos.(Inclusive em alguns mercados seria impossível sobreviver sem isso -Tente ser uma empresa de logística dando ênfase à ‘criatividade’ de seus funcionários… pra estipular um prazo qualquer seria necessário uma bola de cristal, no mínimo)
Não estou dizendo que processos não são importantes. Mesmo porque eles o são. Porém eles não valem de nada se não existirem pessoas para avaliá-los e ajustá-los. Quando eu falo da valorização do capital humano não estou falando dos funcionários da empresa em si. Mas daquilo que a máquina não pode substituir. De fato, operários são considerados substituíveis, no sentido de que eles apenas reproduzem um determinado trabalho. Tanto que são substituídos por máquinas, geralmente eles não opinam sobre a organização da linha de montagem, da organização da fábrica, etc., mesmo porque seu conhecimento não o permite. Mesmo um gerente ou supervisor, aquele que simplesmente inspeciona o processo é uma pessoa substituível, pois à medida que os processos são automatizados a inspeção também passa ser automatizada, tanto quanto a operação em si. Nesse contexto, o capital humano não está nem nos operários , nem nos gerentes nem em qualquer hierarquia, mas geralmente nos engenheiros e gestores que entendem da demanda da empresa, onde está o custo de produção, etc. e a partir daí estabelecem processos. O fato de não ser um trabalho de natureza artística não significa que não façam uso da criatividade e da inovação, mesmo que essa criatividade e inovação sejam percebidas apenas internamente. Essa estrutura ainda sobrevive na indústria, mas é cada vez mais rara em empresas que dependem exclusivamente de capital intelectual. É o que acontece no desenvolvimento de software. A figura do operário é completamente desnecessária. Podemos automatizar geração de código, testes, builds, deploys, etc. Assim, o espaço que sobrou para o programador é simplesmente resolver problemas, aprender sobre o negócio do cliente, acompanhar a tecnologia, estabelecer processos de desenvolvimento, buscar ferramentas, etc. ou seja, nesse ponto, que depende de aprendizado, educação, estudo, e tudo o mais, a máquina não pode substituir o ser humano, é o espaço que sobrou para as empresas se tornarem competitivas.
Então, mas o fato da empresa tentar capturar todo tipo de conhecimento não pode ser algo ruim. Quando eu disse que “O importante para a empresa que adota um processo desses é se tornar completamente independente de uma pessoa” não quis dizer que as empresas não dão importância aos funcionários, até pq uma coisa não está diretamente relacionada com a outra. E também não estava me referindo à substituição por máquina, mas por outros humanos. Se temos o conhecimento de um sistema/negócio muito bem documentado, ou inerente ao próprio processo da empresa, é mais fácil para uma nova pessoa tomar de conta. Observando a incrível rotatividade em nossa área é preciso concordar que é algo sensato de se fazer mesmo.
Software não escala.
em grandes empresas cada programador faz uma coisa.
o programador recebe um readme com considerações gerais da tarefa, e um uml definindo algumas coisas (trabalhamos com POO, logo, é normal que outro programador vá utilizar algum método desenvolvido por você). você desenvolve a parte lógica da sua tarefa, sua classe tem de ser “fechada” sem bugs, então você desenvolve a lógica dos testes da sua classe. os debuggers trabalham com a mesma coisa, porém a principio não realizam testes unitários.
ao menos é assim que eu vejo o pessoal trabalhar por aqui.
[quote=Felagund]@ruivo
discordo da sua opnião, seria a mesma coisa que passar um texto corrido a um pedreiro e querer que ele contrua o prédio, não precisa pensar, só seguir os passos, já imaginou o tipo de predio que seria?
com Software é a mesma coisa, vc precisa conhecer o problema pra poder implementa-lo, não vai ser 2 ou 3 linhas escritas por alguem que vai te ajudar a compreender.
e acho essa divisão, de arquiteto, analista, programador, acrescente-se ao final de cara um junior, senior e pleno, uma putaria, ninguem precisa disso, é so uma desculpa pra pagar valores diferentes e so te aumentar salario por tempo de serviço, então não existe programador que não faz analise, se existe então: You are doing it wrong.
Se vc não sabe programar, analisar e arquitetar um software, vc não é programador, é não é o titulo que faz você, não é pq no teu crachá está arquiteto que você o é, vc precisa saber arquitetar um software para tal, e claro vc precisa escrever codigo, consequentemente fazer analise, são coisas que andam juntos, não tem como separar em etapas.
Quanto mais etapas, mas informação se perde e pior fica.[/quote]
Analise melhor: O pedreiro recebe o projeto e só tem que seguir o que está ali. Óbvio que o projeto não vai estar falando como assentar um tijolo ou quanto de cimento deve estar na coluna. Isso o pedreiro tem obrigação de saber.
Mesma analogia podemos fazer pro programador (naquele perfil que tinha dito: um cara sem nível superior, mas com um curso técnico de programação), ele deve ler o projeto e executar, sem se preocupar com detalhes da arquitetura. O programador se preocupar com isso, na minha opinião, é o mesmo que pedreiro dar palpite sobre o tamanho da parede, a posição das portas e/ou janelas e onde devem estar o canos e tubulações. Ele até pode saber fazer e pensar isso, mas não é o seu trabalho.
Outra coisa muito importante: O Engenheiro ou Arquiteto não entrega um projeto na mão do mestre de obras e some. O cara deve estar acompanhando a obra, para ver se o que foi projetado está sendo cumprido (Assim espera-se). Da mesma maneira, o Arquiteto de software deve estar sempre fazendo code review do que os programadores estão codificando, se a arquitetura do sistema não está sendo violada, se os padrões estão sendo seguidos, enfim, não só projetar o sistema, como também estar sempre “inspecionando a obra”.
E a sua frase
é muito infeliz. É por causa dessa visão que as empresas querem contratar um multiprofissional (Analista, Arquiteto, Programador, Designer) pelo valor do salário mais baixo. Se as funções estivessem bem definidas, e, acima de tudo, se houvesse a cobrança de cada cargo conforme conforme a responsabilidade, com certeza teríamos softwares de mais qualidade e menos profissionais frustrados com baixos salários.
[quote=ruivo]
Analise melhor: O pedreiro recebe o projeto e só tem que seguir o que está ali. Óbvio que o projeto não vai estar falando como assentar um tijolo ou quanto de cimento deve estar na coluna. Isso o pedreiro tem obrigação de saber.
Mesma analogia podemos fazer pro programador (naquele perfil que tinha dito: um cara sem nível superior, mas com um curso técnico de programação), ele deve ler o projeto e executar, sem se preocupar com detalhes da arquitetura. O programador se preocupar com isso, na minha opinião, é o mesmo que pedreiro dar palpite sobre o tamanho da parede, a posição das portas e/ou janelas e onde devem estar o canos e tubulações. Ele até pode saber fazer e pensar isso, mas não é o seu trabalho.
Outra coisa muito importante: O Engenheiro ou Arquiteto não entrega um projeto na mão do mestre de obras e some. O cara deve estar acompanhando a obra, para ver se o que foi projetado está sendo cumprido (Assim espera-se). Da mesma maneira, o Arquiteto de software deve estar sempre fazendo code review do que os programadores estão codificando, se a arquitetura do sistema não está sendo violada, se os padrões estão sendo seguidos, enfim, não só projetar o sistema, como também estar sempre “inspecionando a obra”.
E a sua frase
é muito infeliz. É por causa dessa visão que as empresas querem contratar um multiprofissional (Analista, Arquiteto, Programador, Designer) pelo valor do salário mais baixo. Se as funções estivessem bem definidas, e, acima de tudo, se houvesse a cobrança de cada cargo conforme conforme a responsabilidade, com certeza teríamos softwares de mais qualidade e menos profissionais frustrados com baixos salários.[/quote]
Cara, vc faz testes? vc pode refatorar um codigo? Como que vc partir pra uma outra abordagem se vc tem um plano a seguir? A estrutura já vem pronta? tem certeza que o cara que definiu isso sabe o que ta fazendo? ele conheçe patterns? Ou vc é so um code monkey? É ridiculo pensar que deva existir toda a hierarquia, pela sua analogia, um programador não pode questionar uma definição do seu superior, pois “pedreiro não pode dar palpite sobre o tamanho da parede”.
Conheço alguns projetos que o pedreiro corrigiu cagadas do arquiteto, deu palpite na parede. Visões como essa que geram estruturas bizarras para pagar menos aos profissionais, o que leva um programador a virar analista ou arquiteto? Quais os atributos? A vontade da empresa? Canudo?
Se vc não pode analisar seu codigo e definir outro fluxo que seja melhor pra vc trabalhar e levar o projeto pra frente, vc não é um programador (isso envolve analise e arquitetura).
Analise não é so desenhar UML e escrever um texto dizendo o que deve ser feito. Isso não funciona, é por isso que projetos atrasam, é por isso que features são entregues sem nenhuma funcionalidade, e é por isso que existe retrabalho.
o Cliente falou X, o arquiteto entendeu Z o analista modelou Y e o programador fez T
Pronto seu fluxo está ai, dai depois o que acontece
Cliente reclama com arquiteto pq a funcionalidade não esta la que fala pro analista que fala pro programador que mostra pro analista a funcionalidade, que volta até o cliente e o cliente diz que não era isso.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
Isto é a maior furada… em todas empresas que eu vi isto sendo aplicado era completamente FAIL!!! o correto e ter um desenvolvedor que tbm é arquiteto e um analista de requisitos (ou o proprio desenvolvedor ser o analista de requisitors) pois com este sistema de construção civil traduzido para software a coisa não funciona… primeiro quanto mais gente envolvida hierarquicamente a informação final sempre tende a chegar errada ou desvirtuada a parte final da hierarquia (quem aqui não já viu aquela tirinha do balanço de pneu na arvore?), segundo em muitas coisas e problemas só depois de vc meter a mão na massa vc vai saber o que vai ter que ser feito principalmente em artefatos não funcionais… ninguem tem como prever como se tal software vai realmente ter a performace adequada ou se certa regra realmente e conveniente em certa situação sem meter a mão na massa… gerar quilos de documentação e burocracia geralmente só atrasam os projetos e fazem as pessoas trabalhar horas e horas a mais… e no final não ter a satisfação do cliente… esta do programador não pensar só fazer, isto não existe… e FAIL na certa em todos os casos… o programador deve pensar elaborar diagramar e desenvolver o software a partir dos requisitos… nunca vi um sistema fora este funcionar como deveria…
Esta frase já diz tudo:
Você entendeu pouco a minha visão. Mas vamos lá. Em nenhum momento eu disse que o ‘peão de obra’ (tanto o pedreiro quanto o programador) não podem questionar as decisões das pessoas que estão acima dele na hierarquia. O que ele não pode é, tendo o arquiteto ou engenheiro projetado algo, ele ir lá e mudar por vontade própria, ou enfiar algo no projeto, “pq assim é melhor”. E isso, em TI, isso acontece muito. O programador resolve que aquele pattern é muito complicado e o retira, ou que deveria acrescentar tal framework A ou B, pq “acha” que é melhor, e ignora as decisões que o analista e o arquiteto tomaram.
Quando você diz:
Cara, isso é muito mais simples do que parece. Se os programadores fizessem o que o cliente realmente quer, projeto nenhum atrasaria. Como que projeto atrasa 1 ano? Atrasando 1 dia de cada vez. E como atrasa 1 dia? Muitas vezes, com programadores tentando reinventar a pedra, ao invés de seguir a arquitetura e executar o projeto. Claro, se um negócio estiver absurdo (ou se ele achar absurdo), deve comunicar o arquiteto e/ou analista. Estes vão verificar com o cliente como resolver e, se assim precisar, modificar a arquitetura.
Mas o que vejo muito é programador tomando decisão unilateral, pensando somente nele, sem consultar cliente e arquiteto. Decisões essas que só vão estourar na frente, quando algo não estiver funcionando ou der errado.
Mas novamente, vou enfatizar. Eu penso que o programador deveria ser uma pessoa com nível técnico, sem a necessidade de um curso superior. As decisões macro devem ser feitas por uma pessoa (ou equipe) que tenha conhecimento de padrões, arquiteturas, frameworks, da mesma maneira que decisões macro, nas outras áreas, devem ser feitas por pessoas que estudaram e têm conhecimento pra aquilo. Se o pedreiro vai usar um mangueira ou uma regua pra verificar se o nível da parede está ok, isso é decisão dele. Agora, se a parede vai ter 2 ou 3 metros, isso deve ser decisão do engenheiro ou arquiteto.
Acredito que nossa discussão está encerrada, tempos pontos de vistas diferentes, quem sabe um dia vc entenda melhor o que eu disse, ou eu compreenda melhor sua visão. Mas no momento, acho toda essa hierarquia uma merda 
Ainda vai ter que existir uma sintese entre as idéias da cultura/processo ágil e a ‘tradicional’.
As duas apresentam os problemas que consideram ponto chave e mostram a soluçoes, mas as duas são incompletas.
Existem buracos nas duas abordagens, e em vários pontos. Em alguns casos isso fica claro em alguns casos quando vemos conceito e prática indo em direção contrária.
Nos processos ageis, por exemplo, onde o foco é o ROI. Como avaliar quando passar por cima do processo vai ser de fato mais vantajoso para o cliente? Em uma visão imediata, na entrega de um projeto, pode até ser. Mas em uma visão macro, se não houver um preocupação também com o processo, a empresa terá dificuldade para estimar orçamentos futuros e etc.
Além disso, o valor de venda do produto passa a ser o tempo de desenvolvimento e não a real valor que ele agrega à empresa. Algumas vezes o sistema vai de fato valer mais do que foi pago e em outros casos vai valer menos. Economicamente falando isso é péssimo. É, literalmente, um prejuizo incalculável para quem produz o produto. Quando o valor de um produto se perde dessa forma, isso não é bom para ninguém, nem mesmo para o cliente que teve um ROI absurdo, isso pq a perda de valor do produto afeta a concorrencia, afeta a economia, afeta as empresas, afeta os empregados… afeta todo mundo. OK, isso ocorre em outros mercados também. Mas existe um problema conceitual nesse aspecto pois o tal do pensamento no ‘ROI’ parece ser unidirecional. Como eu posso estar com o foco no ROI do meu cliente e esquecendo meu próprio lucro? E se meu foco é o ROI do meu cliente, meu lucro não deveria ser proporcional ao valor que ele agrega?
Talvez seja pelo meu pouco conhecimento e falta de prática com os processos ágeis, mas esse é só um dos pontos que parecem estranhos, existem outros.
[quote=ruivo][quote=Felagund]
Cara, vc faz testes? vc pode refatorar um codigo? Como que vc partir pra uma outra abordagem se vc tem um plano a seguir? A estrutura já vem pronta? tem certeza que o cara que definiu isso sabe o que ta fazendo? ele conheçe patterns? Ou vc é so um code monkey? É ridiculo pensar que deva existir toda a hierarquia, pela sua analogia, um programador não pode questionar uma definição do seu superior, pois “pedreiro não pode dar palpite sobre o tamanho da parede”.
Conheço alguns projetos que o pedreiro corrigiu cagadas do arquiteto, deu palpite na parede. Visões como essa que geram estruturas bizarras para pagar menos aos profissionais, o que leva um programador a virar analista ou arquiteto? Quais os atributos? A vontade da empresa? Canudo?
Se vc não pode analisar seu codigo e definir outro fluxo que seja melhor pra vc trabalhar e levar o projeto pra frente, vc não é um programador (isso envolve analise e arquitetura).
Analise não é so desenhar UML e escrever um texto dizendo o que deve ser feito. Isso não funciona, é por isso que projetos atrasam, é por isso que features são entregues sem nenhuma funcionalidade, e é por isso que existe retrabalho.
o Cliente falou X, o arquiteto entendeu Z o analista modelou Y e o programador fez T
Pronto seu fluxo está ai, dai depois o que acontece
Cliente reclama com arquiteto pq a funcionalidade não esta la que fala pro analista que fala pro programador que mostra pro analista a funcionalidade, que volta até o cliente e o cliente diz que não era isso.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
http://manifesto.softwarecraftsmanship.org/
[/quote]
Você entendeu pouco a minha visão. Mas vamos lá. Em nenhum momento eu disse que o ‘peão de obra’ (tanto o pedreiro quanto o programador) não podem questionar as decisões das pessoas que estão acima dele na hierarquia. O que ele não pode é, tendo o arquiteto ou engenheiro projetado algo, ele ir lá e mudar por vontade própria, ou enfiar algo no projeto, “pq assim é melhor”. E isso, em TI, isso acontece muito. O programador resolve que aquele pattern é muito complicado e o retira, ou que deveria acrescentar tal framework A ou B, pq “acha” que é melhor, e ignora as decisões que o analista e o arquiteto tomaram.
Quando você diz:
Cara, isso é muito mais simples do que parece. Se os programadores fizessem o que o cliente realmente quer, projeto nenhum atrasaria. Como que projeto atrasa 1 ano? Atrasando 1 dia de cada vez. E como atrasa 1 dia? Muitas vezes, com programadores tentando reinventar a pedra, ao invés de seguir a arquitetura e executar o projeto. Claro, se um negócio estiver absurdo (ou se ele achar absurdo), deve comunicar o arquiteto e/ou analista. Estes vão verificar com o cliente como resolver e, se assim precisar, modificar a arquitetura.
Mas o que vejo muito é programador tomando decisão unilateral, pensando somente nele, sem consultar cliente e arquiteto. Decisões essas que só vão estourar na frente, quando algo não estiver funcionando ou der errado.
Mas novamente, vou enfatizar. Eu penso que o programador deveria ser uma pessoa com nível técnico, sem a necessidade de um curso superior. As decisões macro devem ser feitas por uma pessoa (ou equipe) que tenha conhecimento de padrões, arquiteturas, frameworks, da mesma maneira que decisões macro, nas outras áreas, devem ser feitas por pessoas que estudaram e têm conhecimento pra aquilo. Se o pedreiro vai usar um mangueira ou uma regua pra verificar se o nível da parede está ok, isso é decisão dele. Agora, se a parede vai ter 2 ou 3 metros, isso deve ser decisão do engenheiro ou arquiteto.[/quote]
E nos casos onde o programador sabe o certo mas segue a arquitetura errada do arquiteto pois assim esta a especificação… o projeto não atrasa? sendo que aquele que mete a mão na massa tem uma visão tecnica geralmente melhor daquele que não faz isto… geralmente é o contrario que acontece… o arquiteto não tem uma visão de tão baixo nivel… ele tem uma visão, mas mais de alto nivel dai então especificar bytes é mais complexo para ele, mesmo sendo muito experiente… e a chance do mesmo errar é alta…
Se as coisas funcionassem desta maneira, não iria mais ser necessário programadores ou desenvolvedores, apenas precisariam de um programa para traduzir especificação em codigo… talvez algo como o maker :twisted: , que seus problemas acabaram-se… mas quem desenvolve software sabe que a coisa não funciona assim…
Se voce quer ser estagnado na sua vida profissional trabalhe em uma fábrica de software. Ninguem verá o resultado do seu serviço e outros tomarão seu crédito.
FElizmente já pulei fora dessa. :lol: mas sempre tem empresinhas de meia tigela oferecendo soluções e oportunidades ‘ótimas’. :roll:
Bem, eu não devo estar conseguindo expressar a minha opinião. Mas vou tentar ser mais claro desta vez.
Atualmente, a função de programador exige que a pessoa tenha conhecimentos de análise, design, arquitetura… Sem esses conhecimentos, provavelmente não terá sucesso na carreira.
Mas, na minha opinião, deveria ser de outra maneira. A função de programador poderia ser desempenhada por alguém que tivesse só o conhecimento técnico, isto é, conhecesse Java, um pouco como usar o DB, lógica. Alguém que, com um curso de 1 ou 2 anos, com o básico mesmo, pudesse ler uma documentação e pôr em prática o que estiver descrito.
Alguém que termine o ensino médio, com 17 ou 18 anos, e consiga ler um UML, uma documentação de API e desenvolva seguindo um projeto, planejado por um Arquiteto ou Analista.
E essa figura do Arquiteto e Analista seria o responsável por consultar o cliente, verificar as suas necessidades e, com base nisso, se preocupar com as decisões Macro do projeto em relação à arquitetura. Essa pessoa seria a responsável por analisar cada framework a ser utilizado, fazendo os prós e contras, pensar cada parte do sistema olhando o todo e desenvolver alguns módulos mais complexos, com base no conhecimento adquirido por mais anos (e experiência) que o simples conhecimento das ferramentas.
E por que digo isso? Porque vejo muitos profissionais, que passaram 4-5 anos na faculdade, aprenderam como funcionam, em detalhes, compiladores, sistemas operacionais, computação gráfica, grafos, complexidade algorítmica e no final não passam de “code monkeys nível 3”, que, particularmente, acho um desperdício de tempo e talento.
Será que não é possível treinar alguém em Java e UML em 1 ou 2 anos, para executar essa tarefa de codificação? Será que não é possível colocar pessoas que estudaram mais, que fizeram faculdade e estudaram a fundo a teoria e tecnologias, para fazer o trabalho de arquitetos e analistas, direto?
Eu acredito que, se ao invés de inventar um curso fuleiro que enche linguiça por 4 anos, pra no final o cara mal saber programar, houvesse uma aceitação maior de profissionais de nível técnico, que não teriam um conhecimento aprofundado mas soubessem utilizar bem as ferramentas, não teríamos profissionais menos frustrados?
É essa visão que tentei mostrar. Dar mais valor àquele que estudou mais e se aprofundou, mas também dar mais chances para àqueles que conhecem bem as ferramentas, mas não tem tanto conhecimento da teoria de como as coisas funcionam (ou deveriam funcionar). E também evitar que alguém tenha que enfrentar 4-5 anos de estudos, para, no final, se frustar por estar somente programando, quando poderia estar utilizando seus conhecimentos de maneiras mais desafiadoras.
Ruivo,
eu entendi seu ponto de vista, e eu discordo dele, prefiro varios programadores que saibam o que fazem, do que ter uma hierarquia e um bobalhao que so vomita codigo, quem que vai conseguir entender se o cara não se aprofundou?? Se o cara se manteve no mesmo nivel a vidade toda, ele vai escrever codigo do mesmo jeito.
e se vc quer aprender algo de verdade não é a Faculdade seu lugar, o ensino superior é mais pra ensinar teoria que pratica, por isso existem escolas como a Caelum que ensinam muito sobre programação, é errado vc achar que a faculdade deve te ensinar a ser um Analista/Arquiteto, vc aprende uma gama de coisas, e escolhe aonde vai seguir, tenho amigos que fizeram Sistema de Informação e hoje trabalham com Redes, por que gostaram mais.
Enfim pra mim so existem programadores numa empresa, dependendo do projeto cada um assume um papel distinto 
não sei se fui claro ou se fiquei viajando aqui enquanto escrevia, mas me questione que tento ser mais claro do meu ponto de vista.
abraços
Muita gente ainda valoriza demais a programação e as linguagens e tem dificuldade em aceitar ela como um simples meio.
Falaram do Maker, mas existe ferramentas corporativas muito mais avançadas onde a necessidade de digitar código na mão é quase nula. Veja alguns ERP’s da vida, por exemplo, que muitas vezes cumprem seu papel muito bem e quase nunca exige intervenção de baixo nível no sistema. O desenvolvimento nesses ambientes é algo completamente diferente do que a maioria está acostumado. Digitar linha de código é algo que só irá acontecer em casos excepcionais. A programação em baixo nível é evitada ao máximo, apesar de não poder ser excluida completamente (Ainda assim é com base em toda estrutura e padrões do próprio sistema).
É impossível encontrar um só profissional que tenha um conhecimento tão grande nessas áreas que você citou. Por que? Porque elas são muito extensas e é preciso estudar a vida inteira para ter gabarito no assunto. É aí que se formam os Doutores, e mesmo assim em menos da metade das que você citou.
Esse modelo de “arquiteto genérico” é uma falha grotesca de algumas empresas.
Não disse em momento algum que a pessoa tem que saber TUDO de TODAS as áreas. Da mesma maneira que o médico e o engenheiro, que aprende um apanhado do todo e depois escolhe uma área e se especializa nela, assim devia com os profissionais de TI.
O cara aprende na faculdade Sistemas Operacionais, Sistemas Distribuídos, Compiladores, Computação Gráfica, termina a faculdade e depois se especializa numa área e poderia virar um Arquiteto de Compiladores, por exemplo.
Eu acredito que o generalista tende mais a perder que o especialista. Pode acontecer de aquela área sumir? Pode, mas aí vai do profissional estar atento e sempre se reciclando.
E concordo com vc no seguinte ponto:
O que é o programador atualmente senão um arquiteto genérico? Por isso defendo a idéia de que os arquitetos devem ter mais estudos e se especializar, enquanto o programador ficar naquela função que melhor lhe compete, que seria conhecer bem a ferramenta e saber usá-la para desenvolver o que foi projetado.