Quais os requisitos para se tornar um analista de sistemas?

Assuntos Gerais
#41

[quote=javaflex]
Eu não gostaria de ficar trabalhando em cima do que já foi feito levantamento sem eu ter participado junto ao cliente, onde só chega especificação com prazo para já programar baseado só em terceiros. Me sentiria um robô. E o cliente muitas vezes sem saber do nível do que se contrata.[/quote]

Isso tem a ver com a natureza da relação entre empresas java/.net e seus programadores. Como são linguagens voltada para projetos grandes, fica inviável permitir que todos na equipe participem da especificação.

Aposto que isso não acontece em projetos que usam linguagens consideradas ágeis como Python, Ruby, etc.

#42

[quote=ImpossiveI]Isso tem a ver com a natureza da relação entre empresas java/.net e seus programadores. Como são linguagens voltada para projetos grandes, fica inviável permitir que todos na equipe participem da especificação.
[/quote]
Acho que não pela linguagem, propriamente dito, mas pela cultura que muitas dessas empresas têm. Talvez, não sei, a cultura “enterprise” acaba levando a isso naturalmente. Muitas consultorias (não todas, claro), são verdadeiros ratos de esgoto, onde promovem pessoas por tempo de casa, e não por competência. O desfecho disso são pouquíssimos programadores qualificados que se sentem acuados e cobrados por dezenas de “gestores/analistas/seja lá o que for” que pouco ou nada contribuem para o sucesso do projeto.

De novo, não generalizei, mas não é difícil encontrar ambientes assim nesse meio.

Vejo que é mais difícil isso acontecer, sim. Contudo isso não impede de pessoas com o pensamento enterprise entrarem nesses projetos e aplicarem suas culturas. Já vi sim projetos ágeis se comportarem da forma citada pelo javaflex, onde nem todos participavam da especificação, reuniões eram secretas e a cobrança era como fábrica de software. De projetos assim eu tento cair logo fora.

Tudo vai da cultura…que pode evoluir pra melhor assim como também pode ser deturpada.

#43

As empresas tem dificuldade de manter seus sistemas atualizados em uma plataforma nova. Isso requer pessoas com conhecimento atualizado na plataforma, que dado o ritmo e compkexidade, requer perfis exclusivamente técnicos.

É um erro achar que perfis exclusivamente técnico morreram porque uma plataforma está estagnada.

#44

[quote=ImpossiveI][quote=rmendes08]
Que seja sair da Web para plataformas Mobile, o dispositivo já está abstraído pela plataforma mesmo … como eu disse, só muda a cor do capim …

[/quote]

As empresas tem dificuldade de manter seus sistemas atualizados em uma plataforma nova. Isso requer pessoas com conhecimento atualizado na plataforma, que dado o ritmo e compkexidade, requer perfis exclusivamente técnicos.

É um erro achar que perfis exclusivamente técnico morreram porque uma plataforma está estagnada.[/quote]
Impossivel, um exemplo aqui onde trabalho: já precisaram uma época de pessoas com conhecimento de Javascript, onde teriam que mexer com backbone.js. A empresa sabia do “gap” que a pessoa teria pra aprender backbone e mais outras ferramentas da stack, mesmo não tendo tanto conhecimento. Já noutra altura precisavam de alguém com conhecimento MUITO avançado de Javascript (virar o JS do avesso…rs), mais especificamente, backbone.

O ponto é: a mesma empresa, numa época, se viu confortável em contratar alguém não tão especializado para determinada ferramenta pois tinham tempo pra isso. Já noutra época, precisa de alguém que já chega e não pode ter um gap, ou ao máximo, terá que ter um mínimo de gap pra aprendizado.

Por isso, concordo em partes com você e com o rmendes08. As empresas podem precisar de pessoas que tenham uma boa BASE apenas. Já as vezes podem realmente precisar de pessoas com conhecimento específico numa ferramenta.

#45

[quote=leandronsp][quote=ImpossiveI]Isso tem a ver com a natureza da relação entre empresas java/.net e seus programadores. Como são linguagens voltada para projetos grandes, fica inviável permitir que todos na equipe participem da especificação.
[/quote]
Acho que não pela linguagem, propriamente dito, mas pela cultura que muitas dessas empresas têm. Talvez, não sei, a cultura “enterprise” acaba levando a isso naturalmente. Muitas consultorias (não todas, claro), são verdadeiros ratos de esgoto, onde promovem pessoas por tempo de casa, e não por competência. O desfecho disso são pouquíssimos programadores qualificados que se sentem acuados e cobrados por dezenas de “gestores/analistas/seja lá o que for” que pouco ou nada contribuem para o sucesso do projeto.

De novo, não generalizei, mas não é difícil encontrar ambientes assim nesse meio.

Vejo que é mais difícil isso acontecer, sim. Contudo isso não impede de pessoas com o pensamento enterprise entrarem nesses projetos e aplicarem suas culturas. Já vi sim projetos ágeis se comportarem da forma citada pelo javaflex, onde nem todos participavam da especificação, reuniões eram secretas e a cobrança era como fábrica de software. De projetos assim eu tento cair logo fora.

Tudo vai da cultura…que pode evoluir pra melhor assim como também pode ser deturpada.[/quote]

Quantas pessoas haviam nesse projeto agil? Acho que se vc tem 10 pessoas trabalhando num projeto (comum em projetos Java/C#) é impossível que todos participem da especificação sem degenerar em caos. Projeto usando linguagens ágeis geralmente envolvem 2-3 pessoas no máximo certo?

#46

[quote=ImpossiveI][quote=leandronsp][quote=ImpossiveI]Isso tem a ver com a natureza da relação entre empresas java/.net e seus programadores. Como são linguagens voltada para projetos grandes, fica inviável permitir que todos na equipe participem da especificação.
[/quote]
Acho que não pela linguagem, propriamente dito, mas pela cultura que muitas dessas empresas têm. Talvez, não sei, a cultura “enterprise” acaba levando a isso naturalmente. Muitas consultorias (não todas, claro), são verdadeiros ratos de esgoto, onde promovem pessoas por tempo de casa, e não por competência. O desfecho disso são pouquíssimos programadores qualificados que se sentem acuados e cobrados por dezenas de “gestores/analistas/seja lá o que for” que pouco ou nada contribuem para o sucesso do projeto.

De novo, não generalizei, mas não é difícil encontrar ambientes assim nesse meio.

Vejo que é mais difícil isso acontecer, sim. Contudo isso não impede de pessoas com o pensamento enterprise entrarem nesses projetos e aplicarem suas culturas. Já vi sim projetos ágeis se comportarem da forma citada pelo javaflex, onde nem todos participavam da especificação, reuniões eram secretas e a cobrança era como fábrica de software. De projetos assim eu tento cair logo fora.

Tudo vai da cultura…que pode evoluir pra melhor assim como também pode ser deturpada.[/quote]

Quantas pessoas haviam nesse projeto agil? Acho que se vc tem 10 pessoas trabalhando num projeto (comum em projetos Java/C#) é impossível que todos participem da especificação sem degenerar em caos. Projeto usando linguagens ágeis geralmente envolvem 2-3 pessoas no máximo certo?

[/quote]

É simples. Se no projeto você tem 10 user stories é só colocar 1 programador por user story, ou 2 programadores / user story para quem usa programaçaõ pareada. Por que isso criaria caos ?

E por falar em times ágeis, eu imagino um time de Scrum com 2 pessoas apenas … tipo só o PO e o SM ? O que se encontra nas referências sobre desenvolvimento ágil são times de 7 - 20 pessoas.

#47

[quote=rmendes08]
É simples. Se no projeto você tem 10 user stories é só colocar 1 programador por user story, ou 2 programadores / user story para quem usa programaçaõ pareada. Por que isso criaria caos ?

E por falar em times ágeis, eu imagino um time de Scrum com 2 pessoas apenas … tipo só o PO e o SM ? O que se encontra nas referências sobre desenvolvimento ágil são times de 7 - 20 pessoas.[/quote]

Linguagem ágil != desenvolvimento ágil.

Linguagens ágeis eu me refiro a uma determinada classe de linguagens de programação (em geral, dinâmicas e que promovem um ambiente interativo com REPL). Essas linguagens oferecem uma boa produtividade com equipes de apenas 2-3 pessoas. Não vejo como uma equipe maior do que isso pode funcionar com todos especificando. Na medida que a equipe cresce mais do que isso, se torna mais eficaz ter uma pessoa pra fazer o meio de campo, independente da metodologia que vc esta usando.

#48

O foco não é a quantidade. Você pode muito bem ter uma equipe ágil de 10 pessoas, onde o PO faz esse papel de “meio-de-campo”, evitando assim o caos. IMHO, o PO precisa ser alguém com um bom background técnico, pois PO sem ênfase técnica não sabe filtrar as mágicas que o cliente pede e passa tudo pra equipe se virar. PO’s tecnicamente bons na minha opinião servem como uma blindagem pra equipe e também para passar confiança pro cliente, onde podem muito bem saber o que entra e oq não entra pro backlog.

Em cima do backlog, a equipe técnica (pode ser 1 pessoa, 5, 10 ou pouco mais) discute com o PO, priorizam e estimam as stories que vão entrar pro sprint. É assim que sempre tenho trabalhado em equipes ágeis, e já trabalhei com equipes desde 3 pessoas até 25 ±.

Nessas equipes de 25 pessoas, os líderes técnicos costumavam dividir em sub-projetos pra facilitar as iterações, estimativas e daily meetings. Sempre funcionou muito bem na minha experiência.
E já vi também equipes menores serem massacradas, criando alta rotatividade por conta da cultura “enterprise” (não sei se estou sendo justo e certo com esse termo, mas não encontro outro) que foi imposta na equipe, fazendo assim o projeto ser um caos.

#49

Metodologias ágeis trocam o analista de sistema pelo PO, eu sei disso. Mas se vc reparar, não mudou muita coisa além disso. Se sua equipe tem 10 pessoas no mesmo projeto, elas continuam sem qualquer participação ativa na criação da especificação, esse papel é do PO, eles apenas escolhem a ordem que querem implementar.

#50

[quote=ImpossiveI][quote=rmendes08]
É simples. Se no projeto você tem 10 user stories é só colocar 1 programador por user story, ou 2 programadores / user story para quem usa programaçaõ pareada. Por que isso criaria caos ?

E por falar em times ágeis, eu imagino um time de Scrum com 2 pessoas apenas … tipo só o PO e o SM ? O que se encontra nas referências sobre desenvolvimento ágil são times de 7 - 20 pessoas.[/quote]

Linguagem ágil != desenvolvimento ágil.

Linguagens ágeis eu me refiro a uma determinada classe de linguagens de programação (em geral, dinâmicas e que promovem um ambiente interativo com REPL). Essas linguagens oferecem uma boa produtividade com equipes de apenas 2-3 pessoas. Não vejo como uma equipe maior do que isso pode funcionar com todos especificando. Na medida que a equipe cresce mais do que isso, se torna mais eficaz ter uma pessoa pra fazer o meio de campo, independente da metodologia que vc esta usando.[/quote]

A linguagem dinâmica pode ser ágil para sua equipe e para outra equipe a linguagem estática ou estática e dinâmica como C# pode ser ágil também. Ambas apresentam vantagens e desvantagens, que só a própria equipe poderá aproveitar as vantagens e saber lidar com as desvantagens.

Linguagem é só o meio, importante é subdividir o sistema para atender bem cada gerência da empresa, nada de sistemão que misture o dia a dia de setores diferentes. Com isso consequentemente do nosso lado teremos equipes menores, menos conflito entre interesses de clientes da empresa e mais personalização, o que gera mais valor estratégico para cada cliente da empresa. Mesmo em casos que não podem ser assim, ter um sistema com vários serviços é outra saída, onde poderá ter uma equipe pequena por serviço, isso independe de ser linguagem dinâmica ou estática no lado servidor.

#51

[quote=ImpossiveI][quote=leandronsp]
O foco não é a quantidade. Você pode muito bem ter uma equipe ágil de 10 pessoas, onde o PO faz esse papel de “meio-de-campo”, evitando assim o caos. IMHO, o PO precisa ser alguém com um bom background técnico, pois PO sem ênfase técnica não sabe filtrar as mágicas que o cliente pede e passa tudo pra equipe se virar. PO’s tecnicamente bons na minha opinião servem como uma blindagem pra equipe e também para passar confiança pro cliente, onde podem muito bem saber o que entra e oq não entra pro backlog.

Em cima do backlog, a equipe técnica (pode ser 1 pessoa, 5, 10 ou pouco mais) discute com o PO, priorizam e estimam as stories que vão entrar pro sprint. É assim que sempre tenho trabalhado em equipes ágeis, e já trabalhei com equipes desde 3 pessoas até 25 ±.

Nessas equipes de 25 pessoas, os líderes técnicos costumavam dividir em sub-projetos pra facilitar as iterações, estimativas e daily meetings. Sempre funcionou muito bem na minha experiência.
E já vi também equipes menores serem massacradas, criando alta rotatividade por conta da cultura “enterprise” (não sei se estou sendo justo e certo com esse termo, mas não encontro outro) que foi imposta na equipe, fazendo assim o projeto ser um caos.

[/quote]

Metodologias ágeis trocam o analista de sistema pelo PO, eu sei disso. Mas se vc reparar, não mudou muita coisa além disso. Se sua equipe tem 10 pessoas no mesmo projeto, elas continuam sem qualquer participação ativa na criação da especificação, esse papel é do PO, eles apenas escolhem a ordem que querem implementar.[/quote]

Bom, muita calma nessa hora porque estamos falando de coisas diferentes então …

O papel do PO é muito diferente do papel do analista de sistemas “tradicional”, ao qual o artigo do Shoes se refere. Uma coisa não tem nada a ver com a outra.

Entre outras coisas, o papel do PO é ajudar o cliente a delimitar o escopo de um projeto e descobrir o valor de negócio das funcionalidades do sistema . Isso é bem diferente de criar especificações de sistema (documentos de requisitos). O analista “tradicional” a que me refiro, seria aquele que cara que faz a entrevista com o cliente, elabora um diagrama UML ou ER, gera alguma documentação adicional e passa para o programador escrever aquilo cegamente, tornando-o um “digitador de luxo”. Nessa abordagem tradicional, o programador é incentivado a seguir cegamente essas especificações e desencorajado a questionar o que quer que seja. Basicamente é esse tipo de cargo que eu acredito que não terá muito mais espaço no mercado e que eu não encorajo ninguém a seguir.

#52

Como o rmendes08 citou acima, são papeis completamente diferentes mesmo. Se a equipe tem a cultura ágil, não existem nenhum problema em se ter um PO, que não tem nada a ver com o analista de sistemas tradicional. Eu mesmo já cansei de apontar falhas na spec, propor melhorias, inclusive anular specs que não faziam sentido. Vai do PO ter capacidade de entender as motivações técnicas e aceitar as mudanças.

De novo, depende muito da cultura. Ao meu ver, essa role “PO” foi produto daquilo que o processo ágil buscava, uma pessoa altamente capacitada tecnicamente e com inclinação pro negócio, diferente da cultura antiga e enterprise que produziu a figura do “analista”. Claro que, nada impede de se terem analistas altamente capacitados tecnicamente bem como de se ter PO’s sem noção alguma…

EDIT: Lembro na faculdade que rolava aquela máxima: “começar como programador pra virar analista”. Mesmo não tendo experiência sempre questionei e achei insano isso, com vários caras ali, estudantes, que faziam estágio em dev e depois de 6 meses ou pouco mais faziam questão de mostrar na gravata o título “Analista de Sistemas I/II/III”. Não generalizando, mas alguns desses colavam na prova de algoritmo…rs
Enfim, espero que essa mentalidade tenha diminuído ou que acabe, e que também esse pensamento não atropele os conceitos ágeis, onde a máxima seria: “começar como dev pra virar P.O”. #argh

#53

[quote=leandronsp]
EDIT: Lembro na faculdade que rolava aquela máxima: “começar como programador pra virar analista”. Mesmo não tendo experiência sempre questionei e achei insano isso, com vários caras ali, estudantes, que faziam estágio em dev e depois de 6 meses ou pouco mais faziam questão de mostrar na gravata o título “Analista de Sistemas I/II/III”. Não generalizando, mas alguns desses colavam na prova de algoritmo…rs
Enfim, espero que essa mentalidade tenha diminuído ou que acabe, e que também esse pensamento não atropele os conceitos ágeis, onde a máxima seria: “começar como dev pra virar P.O”. #argh[/quote]

A mentalidade é: se quiser evoluir nos quadros na empresa, tem que fazer mais do que simplesmente escrever código. não vejo essa mentalidade mudando por causa de processos ágeis.

No máximo processos ágeis fazem elevar a autoestima dos programadores dessas empresas, que agora vêem no PO como “um dos nossos”.

#54

[quote=rmendes08]

Entre outras coisas, o papel do PO é ajudar o cliente a delimitar o escopo de um projeto e descobrir o valor de negócio das funcionalidades do sistema . Isso é bem diferente de criar especificações de sistema (documentos de requisitos). O analista “tradicional” a que me refiro, seria aquele que cara que faz a entrevista com o cliente, elabora um diagrama UML ou ER, gera alguma documentação adicional e passa para o programador escrever aquilo cegamente, tornando-o um “digitador de luxo”. Nessa abordagem tradicional, o programador é incentivado a seguir cegamente essas especificações e desencorajado a questionar o que quer que seja. Basicamente é esse tipo de cargo que eu acredito que não terá muito mais espaço no mercado e que eu não encorajo ninguém a seguir.[/quote]

Sera que numa equipe de 10 programadores vc quer mesmo encorajar cada um deles a questionar e discutir as especificações?!

#55

[quote=javaflex][quote=ImpossiveI][quote=rmendes08]
É simples. Se no projeto você tem 10 user stories é só colocar 1 programador por user story, ou 2 programadores / user story para quem usa programaçaõ pareada. Por que isso criaria caos ?

E por falar em times ágeis, eu imagino um time de Scrum com 2 pessoas apenas … tipo só o PO e o SM ? O que se encontra nas referências sobre desenvolvimento ágil são times de 7 - 20 pessoas.[/quote]

Linguagem ágil != desenvolvimento ágil.

Linguagens ágeis eu me refiro a uma determinada classe de linguagens de programação (em geral, dinâmicas e que promovem um ambiente interativo com REPL). Essas linguagens oferecem uma boa produtividade com equipes de apenas 2-3 pessoas. Não vejo como uma equipe maior do que isso pode funcionar com todos especificando. Na medida que a equipe cresce mais do que isso, se torna mais eficaz ter uma pessoa pra fazer o meio de campo, independente da metodologia que vc esta usando.[/quote]

A linguagem dinâmica pode ser ágil para sua equipe e para outra equipe a linguagem estática ou estática e dinâmica como C# pode ser ágil também. Ambas apresentam vantagens e desvantagens, que só a própria equipe poderá aproveitar as vantagens e saber lidar com as desvantagens.

Linguagem é só o meio, importante é subdividir o sistema para atender bem cada gerência da empresa, nada de sistemão que misture o dia a dia de setores diferentes. Com isso consequentemente do nosso lado teremos equipes menores, menos conflito entre interesses de clientes da empresa e mais personalização, o que gera mais valor estratégico para cada cliente da empresa. Mesmo em casos que não podem ser assim, ter um sistema com vários serviços é outra saída, onde poderá ter uma equipe pequena por serviço, isso independe de ser linguagem dinâmica ou estática no lado servidor.[/quote]

Não dá pra ser ágil com 1 equipe de 10 pessoas, independente da linguagem. Se eu entendi, vc concorda comigo. Tem que dividir em equipes menores.

Sobre a linguagem, apenas disse que empresas com grandes equipes preferem linguagens como java/c#. Mas concordo que, se você tem uma equipe de 3 profissionais competentes e proficientes nessas linguagens, nada impede que eles sejam produtivos.

#56

[quote=ImpossiveI][quote=javaflex][quote=ImpossiveI][quote=rmendes08]
É simples. Se no projeto você tem 10 user stories é só colocar 1 programador por user story, ou 2 programadores / user story para quem usa programaçaõ pareada. Por que isso criaria caos ?

E por falar em times ágeis, eu imagino um time de Scrum com 2 pessoas apenas … tipo só o PO e o SM ? O que se encontra nas referências sobre desenvolvimento ágil são times de 7 - 20 pessoas.[/quote]

Linguagem ágil != desenvolvimento ágil.

Linguagens ágeis eu me refiro a uma determinada classe de linguagens de programação (em geral, dinâmicas e que promovem um ambiente interativo com REPL). Essas linguagens oferecem uma boa produtividade com equipes de apenas 2-3 pessoas. Não vejo como uma equipe maior do que isso pode funcionar com todos especificando. Na medida que a equipe cresce mais do que isso, se torna mais eficaz ter uma pessoa pra fazer o meio de campo, independente da metodologia que vc esta usando.[/quote]

A linguagem dinâmica pode ser ágil para sua equipe e para outra equipe a linguagem estática ou estática e dinâmica como C# pode ser ágil também. Ambas apresentam vantagens e desvantagens, que só a própria equipe poderá aproveitar as vantagens e saber lidar com as desvantagens.

Linguagem é só o meio, importante é subdividir o sistema para atender bem cada gerência da empresa, nada de sistemão que misture o dia a dia de setores diferentes. Com isso consequentemente do nosso lado teremos equipes menores, menos conflito entre interesses de clientes da empresa e mais personalização, o que gera mais valor estratégico para cada cliente da empresa. Mesmo em casos que não podem ser assim, ter um sistema com vários serviços é outra saída, onde poderá ter uma equipe pequena por serviço, isso independe de ser linguagem dinâmica ou estática no lado servidor.[/quote]

Não dá pra ser ágil com 1 equipe de 10 pessoas, independente da linguagem. Se eu entendi, vc concorda comigo. Tem que dividir em equipes menores.

Sobre a linguagem, apenas disse que empresas com grandes equipes preferem linguagens como java/c#. Mas concordo que, se você tem uma equipe de 3 profissionais competentes e proficientes nessas linguagens, nada impede que eles sejam produtivos.[/quote]
Concordo sobre o numero de pessoas por time, só não concordei sobre as linguagens, mas ok voce ter explicado melhor agora, que num time pequeno e projeto ou servico bem específico também pode ser produtivo usar java/C#, claro que sem cometer excesso de engenharia, comum em projetos do legado Java.

#57

Como regra geral não é recomendado uma especialização muito cedo na carreira, os motivos: quanto mais áreas tiver possibilidade de trabalhar, mais opções terá para escolher uma área para se aprofundar.
Também, no geral, as empresas procuram um perfil misto: um certo grau generalista e outro especialista.

Uma recomendação, ao escolher as áreas que deseja atuar, precisa dosar alguns fatores: mercado, tendencias, características pessoais, obsolescência, etc. Dar um peso exagerado para mais ou menos com certeza pode influir na sua empregabilidade.

#58

[quote=A H Gusukuma] Como regra geral não é recomendado uma especialização muito cedo na carreira, os motivos: quanto mais áreas tiver possibilidade de trabalhar, mais opções terá para escolher uma área para se aprofundar.
Também, no geral, as empresas procuram um perfil misto: um certo grau generalista e outro especialista.

Uma recomendação, ao escolher as áreas que deseja atuar, precisa dosar alguns fatores: mercado, tendencias, características pessoais, obsolescência, etc. Dar um peso exagerado para mais ou menos com certeza pode influir na sua empregabilidade.

[/quote]

falta 3 meses pra me formar, trabalhei como front-end 1 ano, e 6 meses como desenvolvedor asp .net.
que cursos eu devo investir? estou pensando em fazer inglês, já que eu não tenho certificado e mais pra frente uma especialização.
gosto da área de desenvolvimento web. devo investir em cursos de UML? se sim, quais cursos e aonde posso fazer?

#59

[quote=pescadorsemvara][quote=A H Gusukuma] Como regra geral não é recomendado uma especialização muito cedo na carreira, os motivos: quanto mais áreas tiver possibilidade de trabalhar, mais opções terá para escolher uma área para se aprofundar.
Também, no geral, as empresas procuram um perfil misto: um certo grau generalista e outro especialista.

Uma recomendação, ao escolher as áreas que deseja atuar, precisa dosar alguns fatores: mercado, tendencias, características pessoais, obsolescência, etc. Dar um peso exagerado para mais ou menos com certeza pode influir na sua empregabilidade.

[/quote]

falta 3 meses pra me formar, trabalhei como front-end 1 ano, e 6 meses como desenvolvedor asp .net.
que cursos eu devo investir? estou pensando em fazer inglês, já que eu não tenho certificado e mais pra frente uma especialização.
gosto da área de desenvolvimento web. devo investir em cursos de UML? se sim, quais cursos e aonde posso fazer?
[/quote]

Inglês é fundamental, mas não estude pelo certificado. Estude pelo aprendizado pois é isso o que as empresas realmente olham. Não creio que UML seja uma boa, ao que parece tem entrado em desuso nos últimos tempos. Com qual ASP.Net você trabalhou? Web Forms? Então corra para aprender ASP.Net MVC. Se já conhece ASP.Net MVC tente melhorar suas habilidades com C#, banco de dados ou tecnologias front (HMTL, CSS, JS).

#60

[quote=pescadorsemvara][quote=A H Gusukuma] Como regra geral não é recomendado uma especialização muito cedo na carreira, os motivos: quanto mais áreas tiver possibilidade de trabalhar, mais opções terá para escolher uma área para se aprofundar.
Também, no geral, as empresas procuram um perfil misto: um certo grau generalista e outro especialista.

Uma recomendação, ao escolher as áreas que deseja atuar, precisa dosar alguns fatores: mercado, tendencias, características pessoais, obsolescência, etc. Dar um peso exagerado para mais ou menos com certeza pode influir na sua empregabilidade.

[/quote]

falta 3 meses pra me formar, trabalhei como front-end 1 ano, e 6 meses como desenvolvedor asp .net.
que cursos eu devo investir? estou pensando em fazer inglês, já que eu não tenho certificado e mais pra frente uma especialização.
gosto da área de desenvolvimento web. devo investir em cursos de UML? se sim, quais cursos e aonde posso fazer?
[/quote]

Acho que ele quer dizer: não foque em ser analista de sistemas UML, mas como criar especificações junto com o cliente e comunicar com uma equipe de programadores. Dessa forma, vc pode trabalhar como analista de sistemas ou PO, no caso de uma empresa mais “moderna”. :wink: