E ai pessoal tudo em cima??
Bom eu vou direto ao ponto
eu ainda num achei nada no fórum falando sobre isso
então vamos lá:
Além de ser programador minha vontade maior é ser analista
mas um amigo meu da faculdade disse que analista
mexe bastante com fluxograma, eu fiquei chocado
porque eu odeio fazer fluxograma
mas como eu sou novo na area pra mim analista
apenas analizava os programas depois de pronto
verificando erro e tals
e não ficar fazendo fluxograma
alguem por favor pode me dizer o que um analista realmente faz
ou me explicar as diferenças entre os analistas(junior, pleno, senior)
Agradecido.
obs: desculpa minha ignorância pois sou novo na área!
Hrere, primeiro para se chegar ao cargo de analista a primeira coisa eh milhas rodadas, vamos dizer e mais ou menos a mesma coisa que comandante primeiro voce começa como piloto e com um monte de horas voadas voce chega a comandante, em programação eh a mesma coisa voce começa como estagiario, programador ai voce escreve zilhoes de linhas de código faz um monte de “caca”, ler um monte de coisas, mas um aviso eu gosto realmente dessa profissão, e a principal coisa que ela exige eh atualização constante eu tenho um monte de amigos que não sei porque deixaram de se atualizar, ai meu amigo o bonde passa mesmo.
Cara… não sei se onde estás é assim… porque por aqui, não precisa ter tudo isso de Km rodados pra ser Analista não…
O cara se forma em Sistemas de informações, faz uma MBA ou Pós em GP e já é considerado Analista, Gerente de Projetos, etc…
Gente que nunca programou na vida decidindo o que o Sistema deve fazer, e pra mim, esse nem é o agravante, o pior é ver os documentos escritos como verdade absoluta e coisas realmente bizarras para serem feitas… Aff…
Analista não é uma ‘evolução’ do programador. Conheço algumas pessoas que não sabem digitar uma linha de código, mas são ótimos analistas.
Hoje em dia existe também o papel do analista desenvolvedor, mas acredito que esse papel só seja viavel em ambientes não tão complexo.
Quanto a função do analista, ele é o conhecedor das regras de negócio e como ela está representada no sistema. Ele mantém um contato direto com a área funcional ou com o cliente do sistema ( interno ou externo), principalmente na hora de levantar os requisitos. Ele também possui bastante conhecimento técnico( e isso não tem nada a ver com saber uma linguagem de programação), por isso ele é capaz de passar para o cliente as reais possibilidades na hora de adicionar uma nova funcionalidade ou adaptar uma já existente no sistema.
Enfim, ele faz a ponte entre as necessidades do usuário e o desenvolvedor( ou projetista, dependendo de como a empresa funciona).
Recomendo a leitura desse artigo
http://blog.fragmental.com.br/2008/01/15/quando-eu-crescer-quero-ser-analista-de-sistemas/
dependendo da empresa qualquer imbecil é analista só faz merda para os desenvolvedores ficarem arrumando na hora de implementar.
analista em geral tem que ser um cara que saiba programar para poder modelar as classes entre outros…
existe também o analista de negocio que deve ser um cara que tenha anos de experiência com o negocio, por exemplo fundos de investimento etc…
e o analista de requisitos que pode ser qualquer tonto que se comunique bem… mais ele deve se restringir a captura de requisitos.
[quote=Felagund]Recomendo a leitura desse artigo
http://blog.fragmental.com.br/2008/01/15/quando-eu-crescer-quero-ser-analista-de-sistemas/
[/quote]
Discordo do que foi escrito no blog. Percebi que implicitamente existiu uma defesa das ideias com base na realidade aparentemente imposta pelos metodos ageis, apesar disto não ter sido mencionada explicitamente no texto.
primeiro ponto: O ambiente de Ti nas empresas no geral ainda é muito desorganizado e esse é o principal motivo do desenvolvedor fazer o papel do analista.
(Essa frase talvez colocasse alguns de cabelo em pé e a questão é muito complexa e eu mesmo ainda não tenho experiencia o suficiente pra dar uma resposta com precisão. )
Com isso não estou dizendo que empresas que adotam metodo ágil sejam desorganizadas, porém podemos contar no dedo as que adotam. Estou dizendo que a maioria das pessoas que adotam o papel de analista e desenvolvedor fazem não de uma forma racional, mas por pura reação quase que instintiva ocasionada por fatores externo.
segundo ponto: O metodo ágil não implica na extinção do papel do analista e muito menos em um time composto somente por desenvolvedores. A ideia é um time multidisciplinar justamente para que as deficiencias individuais sejam compensadas.
terceiro ponto: O papel do analista não foi extinto e nem vai ser. Não existe uma única realidade no mercado e em alguns ambiente a complexidade é tão grande que a figura do analista-desenvolvedor é inviavel. Não existe uma realidade homogenia na área de TI e dizer que o papel do analista-desenvolvedor é mais importante que o do analista puro é tao errado quanto dizer que o papel do analista puro é mais importante do que o do analista-desenvolvedor. Quem determina o que é importante de fato é o próprio ambiente e nesse caso não é possivel partir pra uma generalização.
PS: Eu entendi o blog da forma que entendi pois ele inicia criticando a figura do Gerente de Projeto - de forma implicita- e essa é um papel que de fato deixa de existir nos métodos ágeis. O papel do gerente de projeto passa para toda equipe e não fica mais centralizado. ( Na verdade é uma resposta ao texto que fala sobre o papel do Gerenciamento de Projetos )
Não vou citar os 2 primeiros pontos, por concordar com você, hoje em dia pegasse um punhado de coisas, e diz ser agil, só para marketing.
Quanto ao 3º ponto:
Não vejo como uma empresa tenha um analista focado em requisitos e modelagens o tempo todo, alguem que não escreve codigo, não é um analista, pelo menos não analista de sistema, agora se vai me dizer que toda a empresa precisa de alguem pra ficar levantando e modelando? CLARO QUE NÃO.
O que temos é uma visão errada do que é ser analista, e o povo ainda acha bonito isso. Não existe isso de analista, somos todos desenvolvedores. Quem aqui não avalia as alterações de um sistema? Quem não modela? Não pensa? Se você não faz isso, você é um digitador de código não um desenvolvedor.
A visão de analista surgiu na época dos digitadores de código, onde um grupo ficava trancando numa sala fazendo o negocio funcionar, e o analista era o gerente que ficava businando no ouvido dos outros. Eu acho que o cargo de analista só conta pra curriculum, por que dentro da empresa, SE ele for da área, ele será também um desenvolvedor, ou analista-desenvolvedor, o que não muda bulhufas…
Aos meus olhos só existe a hierarquia, Gerente de Projetos (responsável por fechar contratos e negociações de sistema, a primeira abordagem com o cliente é dele) -> Desenvolvedor ( quem planeja e faz o negocio funciona).
[quote=Felagund][quote=immortalSoul]
…
[/quote]
…
Não vejo como uma empresa tenha um analista focado em requisitos e modelagens o tempo todo, alguem que não escreve codigo, não é um analista, pelo menos não analista de sistema, agora se vai me dizer que toda a empresa precisa de alguem pra ficar levantando e modelando? CLARO QUE NÃO.
O que temos é uma visão errada do que é ser analista, e o povo ainda acha bonito isso. Não existe isso de analista, somos todos desenvolvedores. Quem aqui não avalia as alterações de um sistema? Quem não modela? Não pensa? Se você não faz isso, você é um digitador de código não um desenvolvedor.
A visão de analista surgiu na época dos digitadores de código, onde um grupo ficava trancando numa sala fazendo o negocio funcionar, e o analista era o gerente que ficava businando no ouvido dos outros. Eu acho que o cargo de analista só conta pra curriculum, por que dentro da empresa, SE ele for da área, ele será também um desenvolvedor, ou analista-desenvolvedor, o que não muda bulhufas…
Aos meus olhos só existe a hierarquia, Gerente de Projetos (responsável por fechar contratos e negociações de sistema, a primeira abordagem com o cliente é dele) -> Desenvolvedor ( quem planeja e faz o negocio funciona).
[/quote]
Como eu disse, a questão é muito complexa e ainda tenho muito o que aprender sobre tudo.
A fabrica de software, considerado pro muitos como um modelo ultrapassado ainda é muito utilizado, principalmente em grandes empresas onde o ambiente é de fato muito complexo e o insucesso de um projeto pode ser consequencia de muitas outras coisas que não o processo de desenvolvimento adotado.
Mesmo o scrum e suas mais modernas tecnicas de gerencia não são nada se tu tem um ambiente muito conturbado, clientes que estão contra o projeto, membros pouco qualificados e etc. Infelizmente essa é a realidade em diversos locais.
Quanto ao papel do analista, ele ainda existe, mesmo no scrum. O papel do digitador pode ser até útil se tu não tem profissionais suficientemente preparado. É mais fácil aprender digitação do que aprender a fazer analise.
Claro que aqui estou falando de papeis e não de pessoas.
Uma pessoa pode assumir o papel de analista e de desenvolvedor, mas em alguns ambientes isso é simplesmente impossível. Alguns ambientes um analista devidamente treinado é essencial, caso contrário quebra todo o resto da cadeia de desenvolvimento, principalmente se a empresa trabalha em pipe-line. Não estou julgando se isso é bom ou quando isso é boim, só estou dizendo que é algo que ainda acontece no mercado. Claro que não com tanta frequencia.
A realidade comum do mercado é não ter nada de gestão, é o anarquismo completo. Porém assim como existe algumas que usam scrum, existem tmb aquelas que adotam uma forma mais pipe-line de desenvolver.
[quote=Diabo Loiro]dependendo da empresa qualquer imbecil é analista só faz merda para os desenvolvedores ficarem arrumando na hora de implementar.
analista em geral tem que ser um cara que saiba programar para poder modelar as classes entre outros…
existe também o analista de negocio que deve ser um cara que tenha anos de experiência com o negocio, por exemplo fundos de investimento etc…
e o analista de requisitos que pode ser qualquer tonto que se comunique bem… mais ele deve se restringir a captura de requisitos.
[/quote]
Assino em baixo !
Eu tenho dois analistas, um não sabe programar p… nenhum mas é o cara que se comunica bem, o outro programa POG e nem sabe direito qual a função de um Analista.
Gente obrigado pelas respostas
mas eu acho que existe sim uma diferença
significativa entre programador, analista
e principalmente gerente de projetos,
senão não existiria uma grande diferença de remuneração!!
e para ser gerente de projeto acredito que não é necessario saber
programar mesmo mas tem que conhecer muito de administração
flws!!
cara pensei que tava falando so de analistas…
tem esses ±3 tipos… cada um com uma remuneração diferente o analista de negócios é o que ganha mais por exemplo uma gerente de banco com 20 anos de experiência em operações bancarias etc.
o analista de requisitos tem o stress de lidar com o cliente e tal geralmente ganha bem tbm.
Tem o analista do sistema que modela as classes e (este tem saber Orientaçao a Objetos e saber Programar) para que especifique algo descente com base no material fornecido pelo analista de requisitos e orientado pelo analista de negocio que valida as especificações verificando se atende a logica do negocio.
o gerente de projetos é uma coisa muito diferente dos analista citados acima … que é melhor você pesquisar melhor… tem o PM book é uma boa pra quem quer estudar gerencia de projetos.
[quote=Storm]Gente obrigado pelas respostas
mas eu acho que existe sim uma diferença
significativa entre programador, analista
e principalmente gerente de projetos,
senão não existiria uma grande diferença de remuneração!!
e para ser gerente de projeto acredito que não é necessario saber
programar mesmo mas tem que conhecer muito de administração
flws!![/quote]
Storm… leste o artigo do Blog Fragmental ???
Não é que não exista a diferença, o problema é, que essa diferença é feita pelas empresas que muitas vezes não entende quem de verdade agrega valor ao teu problema e acaba pagando mais para papéis mais “gerenciais” e menos para papéis chão de fábrica… O problema é… isso está mudando aos poucos, como o immortalSoul falou, ainda não é realidade na maioria das consultorias que existem por aí… Mas em breve será uma realidade, será uma evolução lenta, mas acontecerá… Em algum ponto do tópico, foi tocado na questão de que em equipes ágeis, parte das decisões do Projeto que antes eram jogados na costa de Gerentes, hoje é dividida pela equipe técnica… Existem lugares até que a Equipe é quem contrata seus gerentes e não o contrário, todo mundo assume o pepino se a coisa der errado e portanto essa disparidade de salário já não é tão real…
Trabalhei em uma equipe, onde a equipe técnica é que fazia as coisas acontecerem… O gerente era o cara dos relacionamentos, que tirava qualquer barreira da frente e fazia o Projeto andar… Tínhamos uma equipe de uns 6 ou 7 analistas onde apenas 2 eram realmente úteis e entendiam do negócio, o resto ganhava quase o dobro do salário pra encher lingüiça e escrever merda… Resultado, quando a equipe técnica percebeu que estava fazendo todo trabalho e ganhando menos… rolou uma mini revolução e todo mundo ameaçou se demitir… Saí de lá antes dessa revolução, mas fiquei sabendo que os salários foram igualados, alguns dos encostados Analistas demitidos e as equipes reestruturadas… um dos 2 analistas que davam conta do recado, agora também desenvolve e o outro não, mas está mais como analista de negócios, todo mundo tá feliz e são a equipe que mais entregam projetos…
Claro que esse cenário não é realidade geral das empresas, mas eu vejo uma tendência… Conheci 1 e somente 1 analista que não sabia Programar na vida e nunca tinha sido técnico que era realmente um Gênio… ele só queria saber como funcionava a Arquitetura e sua percepção era perfeita sobre os UCs que escrevia e o que realmente devia ser feito e quanto tempo ia levar… acho que os Caso de Uso do cara só voltaram uma vez da revisão e mesmo assim pra consertar besteira… O resto… bando de neguinho que não queria Programar e os Requisitos eram muito mal escritos… ganhavam bem ??? ganhavam… mas até onde isso vale realmente a pena…
Abs 
Não vejo utilizade em um digitador, a não ser que seja um jovem profissional iniciando, que ainda desconheçe a maior parte do processo de desenvolvimento. Nesse ponto um programador experiente substitui o analista sem problemas.
é claro que em grandes empresas é muito dificil substituir a ideologia, a cultura, fixada a tantos anos, é muito complexo você provar que um analista e a mesma cosia que um programador, só tem um salario maior, por que antigamente não havia analise so vomitavam codigos, ai surgiu a necessidade de organização, e aos pocos os desenvolvedores estarão cada vez mais focados em escrever software de boa qualidade sem necessidade de outra pessoa fazer a analise por eles.
[quote=Felagund][quote=immortalSoul]
Como eu disse, a questão é muito complexa e ainda tenho muito o que aprender sobre tudo.
A fabrica de software, considerado pro muitos como um modelo ultrapassado ainda é muito utilizado, principalmente em grandes empresas onde o ambiente é de fato muito complexo e o insucesso de um projeto pode ser consequencia de muitas outras coisas que não o processo de desenvolvimento adotado.
Mesmo o scrum e suas mais modernas tecnicas de gerencia não são nada se tu tem um ambiente muito conturbado, clientes que estão contra o projeto, membros pouco qualificados e etc. Infelizmente essa é a realidade em diversos locais.
Quanto ao papel do analista, ele ainda existe, mesmo no scrum. O papel do digitador pode ser até útil se tu não tem profissionais suficientemente preparado. É mais fácil aprender digitação do que aprender a fazer analise.
Claro que aqui estou falando de papeis e não de pessoas.
Uma pessoa pode assumir o papel de analista e de desenvolvedor, mas em alguns ambientes isso é simplesmente impossível. Alguns ambientes um analista devidamente treinado é essencial, caso contrário quebra todo o resto da cadeia de desenvolvimento, principalmente se a empresa trabalha em pipe-line. Não estou julgando se isso é bom ou quando isso é boim, só estou dizendo que é algo que ainda acontece no mercado. Claro que não com tanta frequencia.
A realidade comum do mercado é não ter nada de gestão, é o anarquismo completo. Porém assim como existe algumas que usam scrum, existem tmb aquelas que adotam uma forma mais pipe-line de desenvolver.
[/quote]
Não vejo utilizade em um digitador, a não ser que seja um jovem profissional iniciando, que ainda desconheçe a maior parte do processo de desenvolvimento. Nesse ponto um programador experiente substitui o analista sem problemas.
é claro que em grandes empresas é muito dificil substituir a ideologia, a cultura, fixada a tantos anos, é muito complexo você provar que um analista e a mesma cosia que um programador, só tem um salario maior, por que antigamente não havia analise so vomitavam codigos, ai surgiu a necessidade de organização, e aos pocos os desenvolvedores estarão cada vez mais focados em escrever software de boa qualidade sem necessidade de outra pessoa fazer a analise por eles.
[/quote]
Como eu disse, aqui não é possível generalizar. Antes de dizer: “preciso disso ou daquilo” é preciso saber onde estamos e o que podemos conseguir . Imaginar um mundo onde todos estão capacitados pra usar scrum é ótimo pra exercitar a mente, mas não serve pra muita coisa na realidade. No mundo real temos quilos de desenvolvedores ruins e alguns que realmente se destacam, não é isso? Como reflexo temos muito mais programas dificeis de manter.
Além disso, dizer que o programador substitui o analista sem problema também não é verdade para a realidade de muitas empresas. Não estou falando que alguém no papel de programador não seria capaz de exercer de modo algum o papel de analista de sistema. Mas a menos que o programador consiga se dividr em mais de uma pessoa, ele jamais poderá assumir os dois papeis ao mesmo tempo em um projeto maior.
Não é somente questão de cultura da empresa, é questão de impossibilidade. As vezes o cliente ta em outro estado ( ou país), as vezes o desenvolvedor ta digitando código pra vários projetos, como ele teria tempo pra ir em reunião? Isso é visível principalmente nos processos que tentam usar o pipe-line no desenvolvimento. Novamente, julgar se isso é bom ou ruim não vem ao caso aqui. A questão é que essa realidade ainda existe no mercado e ao que tudo indica, não em fase de morte, mas no inicio da vida. O conceito da fabrica de software torna o papel do analista mais necessário ainda.
Vai além do escopo do tópico julgar se o modelo de fabrica é interessante ou não ( da mesma forma que não vou dizer que java é tão atrasado quanto…), mas a questão é que essa é a realidade do mercado( assim como java, infelizmente).
Felagund é personagem do Tolkien, não é?
Até hoje, as empresas que trabalhei que tinham a separação de cargos entre analista e desenvolvedor eram muito menos eficientes. Por diversas razões:
- Burocratização desnecessária do processo;
- Efeito telefone sem fio (cliente->analista de sistema->projetista->programador);
- Arrogância por parte da equipe de analistas e projetistas: Não só pela falsa noção de hierarquia (em empresas menos profissionais, existe mesmo hierarquia), mas também por se negar a mudar seu projeto sem nem sequer analisar o que o programador está falando;
- Pouca autonomia dos programadores;
- Tendência a contratação de programadores de baixo custo (como se o fato de existir analista desse a empresa a possibilidade de ter programadores de baixo custo, que simplesmente "montam" o software);
- Tendência de ciclos mais lentos. Nem vou falar de waterfall, pois isso mostra uma empresa mais antiga do que as de 1980.
Quanto a empresas grandes. Trabalhei em duas aqui em Curitiba e ambas estavam abrindo mão da profissão de analista em prol de modelos mais ágeis, com desenvolvedores em todos os papéis. O que chega mais próximo de um analista são os proxy clients (alguém que representa o cliente). Ainda assim, os modelos mais eficientes que conheci, tentam aproximar o cliente diretamente da equipe.
Compartilho da visão do Felagund. Acho que alguém pode ser mais próximo do cliente, mas sem que seja um desenvolvedor também, muito dificilmente será um bom analista.
[quote=ViniGodoy]Até hoje, as empresas que trabalhei que tinham a separação de cargos entre analista e desenvolvedor eram muito menos eficientes. Por diversas razões:
- Burocratização desnecessária do processo;
- Efeito telefone sem fio (cliente->analista de sistema->projetista->programador);
- Arrogância por parte da equipe de analistas e projetistas: Não só pela falsa noção de hierarquia (em empresas menos profissionais, existe mesmo hierarquia), mas também por se negar a mudar seu projeto sem nem sequer analisar o que o programador está falando;
- Pouca autonomia dos programadores;
- Tendência a contratação de programadores de baixo custo (como se o fato de existir analista desse a empresa a possibilidade de ter programadores de baixo custo, que simplesmente "montam" o software);
- Tendência de ciclos mais lentos. Nem vou falar de waterfall, pois isso mostra uma empresa mais antiga do que as de 1980.
Quanto a empresas grandes. Trabalhei em duas aqui em Curitiba e ambas estavam abrindo mão da profissão de analista em prol de modelos mais ágeis, com desenvolvedores em todos os papéis. O que chega mais próximo de um analista são os proxy clients (alguém que representa o cliente). Ainda assim, os modelos mais eficientes que conheci, tentam aproximar o cliente diretamente da equipe.
Compartilho da visão do Felagund. Acho que alguém pode ser mais próximo do cliente, mas sem que seja um desenvolvedor também, muito dificilmente será um bom analista.[/quote]
Da forma que voces falam, de duas uma: Ou eu vivo em um mundo paralelo onde essa realidade de fato ainda não existe, ou então fui amaldiçoado com uma visão quase constante de empresas que não adotam metodos ágeis.
Outra coisa, não adianta culpar os processos ( mesmo que seja waterfall) por falta de qualidade no desenvolvimento. As vezes uma simples falta de gestão de mudança pode ser a causa do fracasso na adoção do processo e, novamente, geralizar é praticamente impossível.
[quote=immortalSoul]Da forma que voces falam, de duas uma: Ou eu vivo em um mundo paralelo onde essa realidade de fato ainda não existe, ou então fui amaldiçoado com uma visão quase constante de empresas que não adotam metodos ágeis.
Outra coisa, não adianta culpar os processos ( mesmo que seja waterfall) por falta de qualidade no desenvolvimento. As vezes uma simples falta de gestão de mudança pode ser a causa do fracasso na adoção do processo e, novamente, geralizar é praticamente impossível.[/quote]
Em que estado vc mora?
Ao meu ver fabrica de software é uma droga, mas cada empresa tem seu universo e precisamos saber trabalhar com cada um infelizmente.
Sim, Finrod Felagund era o senhor de Nargothrond, um dos elfos do começo do mundo citado no Silmarilon 
Atualmente no DF.