Duvida(O que analista faz?)

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.

Felagund:

Recomendo a leitura desse artigo

http://blog.fragmental.com.br/2008/01/15/quando-eu-crescer-quero-ser-analista-de-sistemas/

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).

Felagund:

immortalSoul:

…

…

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).

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.

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.

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.

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!!

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.

Felagund:

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.

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.

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:

1. Burocratização desnecessária do processo;
2. Efeito telefone sem fio (cliente->analista de sistema->projetista->programador);
3. 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;
4. Pouca autonomia dos programadores;
5. 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);
6. 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.

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:

1. Burocratização desnecessária do processo;
2. Efeito telefone sem fio (cliente->analista de sistema->projetista->programador);
3. 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;
4. Pouca autonomia dos programadores;
5. 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);
6. 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.

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.

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.

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.

Concordo que a dificuldade em se utilizar scrum e metodologias está na capacidade dos desenvolvedores, ou melhor, na falta de vontade dos desenvolvedores de melhorar. Scrum, ou qualquer metodologia agil nao resolve problema algum se nao tiver como base codigo bem feito, baseado nos principio basicos OO. E dificilmente um desenvolvedor consegue este conhecimento só “trabalhando”, sem dedicar um bom tempo de estudo ao assunto.

Mas falta de desenvolvedor nao deve ser desculpa para código ruim mesmo assim.

Este é o problema, o entendimento do que se quer dizer quando se diz, fim da profissao de analista. Na verdade quer dizer fim do programador digitador e fim do analista que programa no word. Ao contrario do que voce diz, eu acho um absurdo pagar duas pessoas para fazerem o que uma pode fazer.

Se o desenvolvedor não pode atender o cliente porque está trabalhando em outro projeto é um sinal obvio de que precisa de outro(s) desenvolvedor, não que precisa de uma analista e um desenvolvedor. Até porque dificilmente este analista vai passar todos os dias o dia todo em reuniao, atendendo o cliente. Ele vai e depois vem “modelar” o sistema, ou seja, fazer o que o programador deveria estar fazendo.

Sim, esta realidade que voce citou existe, mas só nas empresas que nao tem competencia pra trabalhar com outro modelo.

O mercado vai acabar se adaptando as coisas que funcionam cedo ou tarde, quem ve essas coisas antes leva vantagem.

E sobre o modelo de fabrica de software é algo impossivel de funcionar porque despreza uma constante em desenvolvimento de software: mudanca de requisitos.

[/quote]

Na minha opinião um dos maiores erros dos agilistas é justamente tentar prever o futuro como se ele fosse certo quanto um calculod e matemática. Não é.
Dizer que o futuro é X ou Y é pura ilusão. Ninguém sabe ao certo como as coisas vao desenrolar devido a quantidade de variaveis envolvidas.

É muito bonito na teoria falar sobre desenvolvedores capacitados, código bem feito, facilidade de manutenção, integração entre a equipe, clientes aliados e etc.
Na pratica isso não é comum. Na pratica temos uma grande quantidade de desenvolvedores fraquissimos que não possuem a qualificação necessária para entrar em um time scrum que dê certo.

A falta de desenvolvedor não deve ser desculpa para um código ruim, por isso mesmo algumas empresas tentam contornar esse problema melhorando seus processos. Novamente, se isso é a solução, se é por aí que as empresas devem seguir, esse é outro ponto. Estou falando do que ocorre na prática. Por isso algumas empresas viram, de certa forma, na espefcialização das atividades e o foco no processo como a solução para a falta de profissional capacitado. Daí vem a idéia das fabricas, que estão diretamente relacionadas à necessidade de se ter uma pessoa adotando um ou poucos papeis especializados. Para uma empresa que tem o processo como foco, não intersesa se tu é um desenvovledor que sabe fazer analise e etc. O que interessa é que tu faça teu papel bem feito e isso é o suficiente.
O modelo de fabrica inevitavelmente coloca algumas barreiras para as mudanças nos requisitos, porém tentam contornar isso também na organização de seus processos. A ideia é que aperfeiçoando os processos, mais eficiente será o tratamento dos requisitos.

Deixo claro que eu mesmo não compartilho da idéia de que este deveria ser o caminho que as empresas deveriam seguir, mas dizer que o futuro é o scrum é pra mim tão fora da realidade quanto acreditar que só pq algo é bom irá prevalecer.

Por essa filosofia, immortalsoul, teremos também:

1. Analistas mal qualificados;
2. Projetistas mal qualificados;
3. Programadores mal qualificados;

Isso com baixo feedback, gera um projeto que não tem absolutamente nada a ver com o que foi pedido.

Mesmo no caso de má qualificação, um ciclo mais iterativo ainda permite que o cliente puxe o projeto de volta aos eixos.

ViniGodoy:

Por essa filosofia, immortalsoul, teremos também:

1. Analistas mal qualificados;
2. Projetistas mal qualificados;
3. Programadores mal qualificados;

Isso com baixo feedback, gera um projeto que não tem absolutamente nada a ver com o que foi pedido.

Mesmo no caso de má qualificação, um ciclo mais iterativo ainda permite que o cliente puxe o projeto de volta aos eixos.

Concordo em partes contigo,
porém é preciso admitir que treinar uma pessoa para fazer somente o trabalho de análise ou somente o trabalho de projeto ou de códificação é muito mais fácil e barato do que treinar um desenvolvedor completo (coisa que provavelmente levará anos). Essa é alguma das grandes vantagens (na visão de alguns gestores) da adoção das fabricas.

Veja que eu disse que o treinamento é mais fácil e mais barato, mas não que trará mais beneficios ou com maior qualidade( seja a curto ou longo prazo). Na verdade esses gestores tentam fazer um equilibrio desta qualidade com o custo e o tempo, o que de certo modo faz sentido.

A função varia de empresa para empresa, mas geralmente um Analista De Sistemas não fica codificando sistema não, para isto criou o papel de Analista de Desenvolvimento que seria um programador de nível superior, a bagunça e grande como eu disse vai de empresa para empresa, de estrutura para estrutura, mas de forma geral o Analista trabalha com Requisitos é Diagramas, fluxograma e um termo antigo que foi substituído…

Já o Gerente de Projetos cuida mais da parte de Métricas, Medições, Cronogramas, como o nome fala e a parte mais gerencial, os gerentes de projetos que eu conheço sabem programar, mas não o fazem no seu dia a dia.

quer ser analista mas não sabe o que um analista faz???

po, não leva a mal não mais… até lembrei do tiririca agora…

quanto a o que um analista faz, isso varia muuuito de empresa para empresa, de um modo geral é ele quem faz aquela analise de requisitos, conversa com o cliente para identificar o que entra no sistema e o que não… sendo assim ele tende também a fazer fluxogramas em muitas empresas, outras não, apresentações, é ele quem costuma criar as documentações de software… por ai vai…

immortalSoul:

Veja que eu disse que o treinamento é mais fácil e mais barato, mas não que trará mais beneficios ou com maior qualidade( seja a curto ou longo prazo). Na verdade esses gestores tentam fazer um equilibrio desta qualidade com o custo e o tempo, o que de certo modo faz sentido.

Nao faz o menor sentido porque o custo e o tempo de um projeto agil com uma equipe boa é invariavelmente menor do que qualquer processo burocratico, com hierarquia rigida como as que voce esta usando como exemplo.

Na verdade é que esses gestores nao conhecem outra forma de trabalhar que nao a deles, na maioria. Mas eles vao gostar de qualquer coisa que de a eles menor tempo de desenvolvimento e menor custo do produto.

Nao adotar metodologias ageis em uma empresa não é culpa dos diretores, é culpa dos desenvolvedores que, ou nao tem experiencia suficiente para conduzir um projeto agil, ou não tem iniciativa pra isso. As empresas que tem desenvolvedores com experiencia e iniciativa estao se tornando ageis.

YvGa:

immortalSoul:

Veja que eu disse que o treinamento é mais fácil e mais barato, mas não que trará mais beneficios ou com maior qualidade( seja a curto ou longo prazo). Na verdade esses gestores tentam fazer um equilibrio desta qualidade com o custo e o tempo, o que de certo modo faz sentido.

Nao faz o menor sentido porque o custo e o tempo de um projeto agil com uma equipe boa é invariavelmente menor do que qualquer processo burocratico, com hierarquia rigida como as que voce esta usando como exemplo.

Na verdade é que esses gestores nao conhecem outra forma de trabalhar que nao a deles, na maioria. Mas eles vao gostar de qualquer coisa que de a eles menor tempo de desenvolvimento e menor custo do produto.

Nao adotar metodologias ageis em uma empresa não é culpa dos diretores, é culpa dos desenvolvedores que, ou nao tem experiencia suficiente para conduzir um projeto agil, ou não tem iniciativa pra isso. As empresas que tem desenvolvedores com experiencia e iniciativa estao se tornando ageis.

Como eu disse, tudo muito bonito na teoria.
Agora imagina um mero desenvolvedor chegar em um diretor de uma grande empresa afirmando que conhece uma forma mais eficiente do que os processos que a empresa adota ( ou começou a adotar).Em outras palavras tu estaria dizendo: Joga fora esses processos que vc investiu milhoes para colocar em pratica e que levou alguns anos e começa a utilizar esse processo aqui que é bem mais interessante. Mesmo que tu tenha razão, é inevitavel que exista uma certa ( certa nao, grande mesmo) resistencia por parte deste diretor.
Tu pode ser o cara mais certo do mundo, mas se põe no lugar dele. Não estou dizendo que é impossível, mas só o fato de tu conseguir falar com um diretor de uma grande empresa já pode ser considerado um feito. Conseguir convencer de que tu ta certo e de que todo o resto da empresa está errada… Como eu disse, não é impossível, mas é algo bastante incomum.

Sem falar que qualquer mudança simples em empresas deste tipo é algo monstruoso. Quase inacreditavel. Agora multiplica essa dificuldade por 100 pois aqui a necessidade é de se alterar a cultura da empresa. Não gosto de parecer pessimista, mas essa é a realidade.

ok, isso é só um ponto.

O outro ponto é que um processo burocratico ( lembrando não devemos ver burocracia como algo necessariamente ruim) traz uma certa segurança para os gestores. Ok. Pode dizer que essa segurança é ilusória, mas aqui estamos em mundo real onde a ilusão também tem sua importancia, principalmente quando estamos tentando perceber o futuro.

A questao do futuro destes processos não é exato como uma conta matematica. Anunciar a morte do analista hoje em dia é totalmente precipitado. O tal do “rejeito a realidade e substituo pela minha” não ajuda em muita coisa também.

Mais uma coisa relacionado ao assunto incial do tópico.

Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.

É incrível como programador/desenvolvedor frequentemente tem uma visão elevada de sua função e de seu conhecimento. Grande parte é tão estrela que até esquece que tem que andar com os pés no chão. Valorizam demais o conhecimento técnico, ao ponto de limitar sua mente a achar que é só isso que importa. Já vi muita gente aqui criticando o analista por não saber programar. Ainda não perceberam que esse conhecimento técnico é uma necessidade muito especifica da situação. Hoje saber configurar o spring, hibernates e todas essas tecnologias que em teoria surgem para facilitar ( mas em java eu acho que acontece o contrário ) a vida do programador só servirá por um tempo e para determinada situações.

Nem tudo na área de informatica gira em torno de porogramação. Um bom analista não precisa saber programar, assim como um bom programador não precisa saber de redes. Claro que não estou falando de um conhecimento superficial de TI, pois esse todos devem ter, independente mesmo se for da área de TI ou não. Veja as provas de concursos públicos para entender do que estou falando.

Volto a dizer que isso não tem nenhuma relação com o processo de desenvolvimento adotado, seja fabrica ou seja agil.
As pessoas tendem a confundir e acham que por estar em uma equipe ágil ela necessáriamente deve saber de tudo. Não concordo com essa visão. Nada impede eu compor minha equipe com um analista que não sabe programar, principalmente se eu sentir uma certa deficiencia do resto da equipe nesta parte. O mesmo serve para outros papeis como do DBA e etc… tudo depende do projeto e cada caso é um caso.

Uma coisa é fato. A informatização só é realmente efetiva se a empresa em questão estiver disposta a rever seus processos.
Caso contrário, só automatizamos a burocracia. E isso não deixa com que a informática penetre com todo potencial na empresa.

Computadores existem também para simplificar o processo, não só para automatizá-lo.

immortalSoul:

Como eu disse, tudo muito bonito na teoria.
Agora imagina um mero desenvolvedor chegar em um diretor de uma grande empresa afirmando que conhece uma forma mais eficiente do que os processos que a empresa adota ( ou começou a adotar).Em outras palavras tu estaria dizendo: Joga fora esses processos que vc investiu milhoes para colocar em pratica e que levou alguns anos e começa a utilizar esse processo aqui que é bem mais interessante. Mesmo que tu tenha razão, é inevitavel que exista uma certa ( certa nao, grande mesmo) resistencia por parte deste diretor.
Tu pode ser o cara mais certo do mundo, mas se põe no lugar dele. Não estou dizendo que é impossível, mas só o fato de tu conseguir falar com um diretor de uma grande empresa já pode ser considerado um feito. Conseguir convencer de que tu ta certo e de que todo o resto da empresa está errada… Como eu disse, não é impossível, mas é algo bastante incomum.

Sem falar que qualquer mudança simples em empresas deste tipo é algo monstruoso. Quase inacreditavel. Agora multiplica essa dificuldade por 100 pois aqui a necessidade é de se alterar a cultura da empresa. Não gosto de parecer pessimista, mas essa é a realidade.

ok, isso é só um ponto.

O outro ponto é que um processo burocratico ( lembrando não devemos ver burocracia como algo necessariamente ruim) traz uma certa segurança para os gestores. Ok. Pode dizer que essa segurança é ilusória, mas aqui estamos em mundo real onde a ilusão também tem sua importancia, principalmente quando estamos tentando perceber o futuro.

A questao do futuro destes processos não é exato como uma conta matematica. Anunciar a morte do analista hoje em dia é totalmente precipitado. O tal do “rejeito a realidade e substituo pela minha” não ajuda em muita coisa também.

Se todos pensassem assim estariamos nas cavernas ainda. Essa ideia do “Ah, isso nao vai dar certo” é uma coisa que os diretores normalmente nao tem. Embora muitos erroneamente acham que tem. Em media, os diretores de empresas de TI (nao estou falando de gerentes de projeto) são mais competentes em suas profissões do que os desenvolvedores e analistas juntos.

O caso não é voce chegar com blablabla para eles supondo um mundo imaginario, voce tem que MOSTRAR COMO e porque funciona, só na teoria voce nao vai conseguir convencer ninguem. E é nesse MOSTRAR que mora o problema. Quem sabe fazer isso?

immortalSoul:

Mais uma coisa relacionado ao assunto incial do tópico.

Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.

É incrível como programador/desenvolvedor frequentemente tem uma visão elevada de sua função e de seu conhecimento. Grande parte é tão estrela que até esquece que tem que andar com os pés no chão. Valorizam demais o conhecimento técnico, ao ponto de limitar sua mente a achar que é só isso que importa. Já vi muita gente aqui criticando o analista por não saber programar. Ainda não perceberam que esse conhecimento técnico é uma necessidade muito especifica da situação. Hoje saber configurar o spring, hibernates e todas essas tecnologias que em teoria surgem para facilitar ( mas em java eu acho que acontece o contrário ) a vida do programador só servirá por um tempo e para determinada situações.

Por ferramentas pra funcionar sem saber pra que não é sinonimo de conhecimento técnico, muito pelo contrário. Spring e hibernate facilitam muito a vida do programador. Se não facilitar é porque voce nao precisa delas. E sinceramente, hoje em dia, dizer que trabalha com java e nao precisa delas já é algo que me faz torcer o nariz. O código ao qual voce se refere deve ser extremamente procedural, com muita duplicacao de código, muitos módulo extremamente acoplados entre si e etc… Sinal evidente de programadores medianos e analistas medianos. Pois não há possibilidade do Hibernate (ou algum de seus concorrentes) complicar um bom modelo orientado a objetos criado pelo grande analista. Provavelmente a coisa ja vem torta de la. E tambem nao há como o Spring complicar alguma coisa se ele foi feito pra integrar partes distintas, deixando o código mais limpo e facilitando os testes. Se ele complica é sinal evidente de programador meia-boca.

Se voce tem uma deficiencia de sua equipe na parte de analise voce vai por alguem que nao tem a menor nocao de programacao pra salvar isso?
Melhorar a sua equipe nem pensar né?

Como? voce vai me perguntar.

Esse é o problema, as empresas não conseguem avaliar candidatos, simplesmente não conseguem.

Veja bem, não estou dizendo que a pessoa deve se acomodar. Muito pelo contrário.
Estou falando exclusivamente sobre a posição do analista não programador ( ou mesmo do gerente de projeto ) hoje e no futuro. Estou também rebatendo o que foi exposto no blog, pelo menos na parte que não concordo.

aproveitando, se todos pensassem assim seria pessimo. Na verdade, se todos pensassem da mesma forma seria pessimo, independente se fosse defendendo um lado ou outro.

outro ponto, a questão da competente do diretor de TI não tem relação direta com a posição que ele adote na questão. Nem a competencia do programador, do GP, desenvolvedor ou quem quer que seja estaria diretamente relacionado com a posição que adota.

Um outro ponto improtante que deve ser considerado é que quando falamos em scrum estamos falando em mudança de cultura. A menos que tu descubra um meio de manipular a mente das pessoas, tu vai encontrar dificuldade independente do teu conhecimento ou boa vontade. As pessoas no geral parecem não se importar muito com a lei da causa-efeito, ou pelo menos não de modo previsivel.
Exemplo classico ( e adatpado): Se voce aumenta o salário por quantidade de mato cortado era de se esperar que as pessoas buscassem cortar mais mato para ganhar mais. Será? Dependendo da sociedade, da cultura e até da religião os efeitos obtidos podem ser o contrário do desejado. A solução racional no caso seria diminuir o salario destes trabalhadores. Mas mesmo isso seria impossível generalizar.
Apesar disso tem várias equipes adotando scrum e mostrando um bom resultado inicial e isso é animador. Mas é preciso não cometer o erro de generalizar esse sucesso. O scrum é possível de ser aplicado, mas para determinados ambientes, para determinadas condições e etc. Tentar generalizar e dizer que o scrum serve para qualquer situação e ambiente é ignorar completamente a realidade de alguns ambientes. Se um gestor ou diretor fizer uma escolha dessas sem fazer esse tipo de analise vai se arrepender e ainda vai sair falando que o scrum não presta. Tanto ele como todos os envolvidos no projeto.

No scrum o mais importante é a cultura que será moldada entre os integrantes da equipe e entre todos os envolvidos no projeto. Sem essa mudança cultural o scrum não vai ter resultado nenhum, ou talvez até pior do que conseguiriamos de outro modo. Com isso não estou falando de desistencia e nem que o scrum não é bom ou que é impossível de se adotar. Mas considerando todos estes aspectos é bem razoavel supor que o modelo de fabrica não vai morrer tão cedo ( e isso se morrer).

Uma coisa é falar da dificuldade de por uma metodologia agil pra funcionar, outra coisa é defender a cultura atual de grande parte das empresas.

Que não é fácil mudar a cultura eu sei, mas tem que ser mudada.

E essa historia de que “aqui isso não funciona” eu ja ouvi bastante. Se fosse de alguem que trabalha de uma forma eficiente, que entrega os projetos no prazo, e de quem o cliente está satisfeito, eu nao diria nada. Mas não era o caso de TODOS aqueles de quem ouvi o tradicional “aqui isso não funciona”. Ali nada funciona.

Se voce perguntar para um diretor de uma dessas empresas, um que não seja técnico, se ele está satisfeito com a área de desenvolvimento, eu nao tenho duvidas de que, com rarissimas exceções, eles vao dizer que não. Mas as pessoas não acreditam em metodologias porque estão fartas de ouvir que soluções mágicas vão revolucionar a área de desenvolvimento da empresa e que agora vai se tudo lindo e maravilhoso e no final das contas nada muda, só aumentam os gastos.

E por que? Resposta simples, falta de capacidade daqueles que se propoe a mudar. E nisso o Scrum não é diferente, o cara lê num blog nao sei onde que o Scrum é maravilhoso, le um artigo numa revista que fala sobre as fase do Scrum e voilá, está lá ele propondo Scrum ao seu gerente.

Mas na hora H ele nao consegue por em pratica porque ele nao tem o minimo embasamento pra isso, e o projeto volta a ser um waterfall, com um ou outro ingrediente de Scrum. Ao que se concluirá que Scrum é uma porcaria.

Se voce quer mudar, nao chegue com conversa mole. Se prepare, estude, reuna uma pequena equipe interessada para um pequeno projeto, com ou sem o aval dos superiores e mostre o resultado. O RESULTADO, não a teoria.

YvGa:

immortalSoul:

Mais uma coisa relacionado ao assunto incial do tópico.

Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.

É incrível como programador/desenvolvedor frequentemente tem uma visão elevada de sua função e de seu conhecimento. Grande parte é tão estrela que até esquece que tem que andar com os pés no chão. Valorizam demais o conhecimento técnico, ao ponto de limitar sua mente a achar que é só isso que importa. Já vi muita gente aqui criticando o analista por não saber programar. Ainda não perceberam que esse conhecimento técnico é uma necessidade muito especifica da situação. Hoje saber configurar o spring, hibernates e todas essas tecnologias que em teoria surgem para facilitar ( mas em java eu acho que acontece o contrário ) a vida do programador só servirá por um tempo e para determinada situações.

Por ferramentas pra funcionar sem saber pra que não é sinonimo de conhecimento técnico, muito pelo contrário. Spring e hibernate facilitam muito a vida do programador. Se não facilitar é porque voce nao precisa delas. E sinceramente, hoje em dia, dizer que trabalha com java e nao precisa delas já é algo que me faz torcer o nariz. O código ao qual voce se refere deve ser extremamente procedural, com muita duplicacao de código, muitos módulo extremamente acoplados entre si e etc… Sinal evidente de programadores medianos e analistas medianos. Pois não há possibilidade do Hibernate (ou algum de seus concorrentes) complicar um bom modelo orientado a objetos criado pelo grande analista. Provavelmente a coisa ja vem torta de la. E tambem nao há como o Spring complicar alguma coisa se ele foi feito pra integrar partes distintas, deixando o código mais limpo e facilitando os testes. Se ele complica é sinal evidente de programador meia-boca.

Se voce tem uma deficiencia de sua equipe na parte de analise voce vai por alguem que nao tem a menor nocao de programacao pra salvar isso?
Melhorar a sua equipe nem pensar né?

Como? voce vai me perguntar.

Esse é o problema, as empresas não conseguem avaliar candidatos, simplesmente não conseguem.

indo por partes, novamente ( e tentarei fazer minha ultima postagem aqui).

Primeiro: Hibernates. Quem acha que hibernates é uma ferramenta moderna é pq nunca ouviu falar no SQL Alchemy. Ok, sql alchemy é um ORM de outra linguagem que não tem nada a ver com JAVA, mas e daí? Conheço um cara que sabe muito de SQL alchemy, ótimo programador, mas nunca configurou um XML ( eca ) pro Hibernates ( não precisa dizer que se quiser não precisa usar XML, estou sendo sarcástico) e mal sabe dar um print ( ou melhor system.out.println ) no JAVA . Sabe o que quero dizer com isso? Que saber uma ou outra não indica o quanto o cara é capacitado como programador e muito menos como analista.

Segundo: Como eu disse, é preciso ter os pés no chão. Frequentemente programador não é o tanto quanto imagina ser. Se estou com problema em meu carro vou em um mecanico, não em um programador. Se a equipe precisa alguém para fazer o levantamento de requisitos eu devo ir atrás de um bom analista ( veja bem, a necessidade especifica desse caso teorico é a de alguem para fazer o papel do analista. Não tem pq eu ir atrás de um programador).

O problema é que a gente acaba achando que sabe fazer tudo, até contratação corretamente ( que é função RH em grande parte das empreas). O mais ironico de tudo isso é que frequentemente a área de TI é a mais mal vista de todas nas empresas. Acho que deviamos tirar uma lição disso, tentar cair um pouco na real e ver que não somos tudo isso que achamos.

Concordo plenamente que a área de TI é a mais mal vista de todas nas empresas, mas não se esqueça de que o modelo padrão que a area de TI usa atualmente para ser a mais mal vista dentro de uma empresa é justamente aquele que você esta defendendo.

E RH para contratar corretamente para um cargo técnico contribui bastante para a area de TI das empresas ser mal vista. Já participei de entrevistas em que ao final o entrevistador tinha exata noção do meu conhecimento técnico em cada um dos itens que eu apontava em meu curriculo. Alguem do RH jamais conseguiria isso.

YvGa:

immortalSoul:

O problema é que a gente acaba achando que sabe fazer tudo, até contratação corretamente ( que é função RH em grande parte das empreas). O mais ironico de tudo isso é que frequentemente a área de TI é a mais mal vista de todas nas empresas. Acho que deviamos tirar uma lição disso, tentar cair um pouco na real e ver que não somos tudo isso que achamos.

Concordo plenamente que a área de TI é a mais mal vista de todas nas empresas, mas não se esqueça de que o modelo padrão que a area de TI usa atualmente para ser a mais mal vista dentro de uma empresa é justamente aquele que você esta defendendo.

E RH para contratar corretamente para um cargo técnico contribui bastante para a area de TI das empresas ser mal vista. Já participei de entrevistas em que ao final o entrevistador tinha exata noção do meu conhecimento técnico em cada um dos itens que eu apontava em meu curriculo. Alguem do RH jamais conseguiria isso.

O modelo padrão é não adotar modelo algum. O modelo padrão é uma especie de anarquismo.
Mesmo o RUP que ainda é visto por muitos ( de forma incorreta ) como um modelo fracassado deu certo em algumas empresas que conseguiram levar a coisa da forma que deveria ser feito.Não tive vivencia com o RUP então só me limito a dizer o que li sobre o assunto.
Mas posso dizer que processos bem definidos não é sinonimo de waterfall. Burocracia não é algo necessariamente ruim. RUP não era waterfall. Foco no melhoramento do processo não é necessariamente ruim. As vezes dá até um nó na cabeça ao ter que entender isso. São muitas variaveis, muita coisa pra dar errado e culpar somente o metodo pelo fracasso é ignorar completamente as outras váriaveis. É preciso fazer uma sintese pra não corrermos o risco de cair nos mesmo erros. O modelo waterfall não é defendido por ninguém, porém algumas empresas tema necessidade de adaptar seus processos para facilitar a alteração dos requisitos enquanto outras podem se dar ao luxo passar completamente por cima dos processos. A estratégia empresarial também esta relacionada com o assunto. A estratégia também esta relacionada ao mercado e com outros pontos e cada ponto impacta no outro de forma que é quase impossível entender exatamente o que acontece. Mesmo a forma de contratação utilizada pela empresa está relacionada à sua estratégia, seu negocio, sua estrutura e etc. Nem todas as empresas possuem estrutura projetizadas e nem deveria mesmo, pois cada empresa atua em um mercado, cada uma com uma estrategia, cada uma com sua cultura. Temos somente nosso limitado ponto de vista da TI sobre como as coisas acontecem, por isso para nós é fácil criticar, pois não temos a noção real das coisas.

immortalSoul:

Mais uma coisa relacionado ao assunto incial do tópico.

Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.

As pessoas tem essa concepção porque analistas são profissionais de venda e por isso podem ser recompensados de acordo com seu desempenho. O papel do analista é fazer o corpo-a-corpo com os clientes. O bom programador por outro lado tem seu desempenho geralmente rebaixado ao nivel do pior programador existente na equipe. Mas nas empresas, tanto analistas quanto programadores estedem da classe Recurso.

Uma equipe agil deve saber tudo porque ela reune todas as disciplinas necessarias para executar o projeto, não quer dizer que cada pessoa sabe tudo, mas que a equipe é multidisciplinar e portanto analista de negócios, programadores, designers, DBAs, e todo aquele que puder contribuir para executar o projeto esta presente.

Um analista de sistema não é necessário porque neste momento o foco é executar e não vender.

ps: Já é a segunda vez que vc demonstra seu desconhecimento sobre metodos ageis nesta thread. Primeiro vc acusou agilistas de serem rigidos e inflexiveis, de acreditarem que nada vai mudar, quando são eles que pregam manter o escopo aberto enquanto é prática de todo analista de sistemas congelar a especificação do sistema em requisitos pra só então o projeto começar.

mochuara:

immortalSoul:

Mais uma coisa relacionado ao assunto incial do tópico.

Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.

As pessoas tem essa concepção porque analistas são profissionais de venda e por isso podem ser recompensados de acordo com seu desempenho. O papel do analista é fazer o corpo-a-corpo com os clientes. O bom programador por outro lado tem seu desempenho geralmente rebaixado ao nivel do pior programador existente na equipe. Mas nas empresas, tanto analistas quanto programadores estedem da classe Recurso.

Uma equipe agil deve saber tudo porque ela reune todas as disciplinas necessarias para executar o projeto, não quer dizer que cada pessoa sabe tudo, mas que a equipe é multidisciplinar e portanto analista de negócios, programadores, designers, DBAs, e todo aquele que puder contribuir para executar o projeto esta presente.

Um analista de sistema não é necessário porque neste momento o foco é executar e não vender.

ps: Já é a segunda vez que vc demonstra seu desconhecimento sobre metodos ageis nesta thread. Primeiro vc acusou agilistas de serem rigidos e inflexiveis, de acreditarem que nada vai mudar, quando são eles que pregam manter o escopo aberto enquanto é prática de todo analista de sistemas congelar a especificação do sistema em requisitos pra só então o projeto começar.

Hã???
Do que vc está falando?

Eu disse exatamente o que voce disse quanto à equipe ser multidisciplinar, não a pessoa ( Na verdade foi justamente este o enfoque que dei o dizer que a pessoa em uma equipe não precisa saber tudo).
Segundo o analista é um vendedor? Ta de brincadeira, não é?
Terceiro. ONDE EU DISSE QUE AGILISTA É RIGIDO E INFLEXIVEL COM RELAÇÃO AO ESCOPO DO PROJETO???

sério, esse comentário foi muito estranho. Eu não sei se vc existe em uma realidade paralela ou sei lá. Só não faço a minima ideia do que vc está falando.

Vender para clientes corporativos não é brincadeira. Talvez por isso vc não tenha sido evoluido até esse ponto ainda. Clientes corporativos tem processos bastante custosos e demorados devido a toda burocracia imposta pela propria empresa ara se proteger de fornecedores que prometem mas não cumprem. O analista é um recurso utilizado para empresas de software B2B para fazer o corpo-a-corpo com esse cliente corporativo, não só durante a venda, mas depois durante o projeto. Não tenha duvida que vc esta confuso sobre analista de sistemas e analistas de negócio. Este último, como havia falado, são uma coisa completamente diferente.

Terceiro. ONDE EU DISSE QUE AGILISTA É RIGIDO E INFLEXIVEL COM RELAÇÃO AO ESCOPO DO PROJETO???

[quote]Na minha opinião um dos maiores erros dos agilistas é justamente tentar prever o futuro como se ele fosse certo quanto um calculod e matemática. Não é.
Dizer que o futuro é X ou Y é pura ilusão. Ninguém sabe ao certo como as coisas vao desenrolar devido a quantidade de variaveis envolvidas.

mochuara:

immortalSoul:

Segundo o analista é um vendedor? Ta de brincadeira, não é?

Vender para clientes corporativos não é brincadeira. Talvez por isso vc não tenha sido evoluido até esse ponto ainda. Clientes corporativos tem processos bastante custosos e demorados devido a toda burocracia imposta pela propria empresa ara se proteger de fornecedores que prometem mas não cumprem. O analista é um recurso utilizado para empresas de software B2B para fazer o corpo-a-corpo com esse cliente corporativo, não só durante a venda, mas depois durante o projeto. Não tenha duvida que vc esta confuso sobre analista de sistemas e analistas de negócio. Este último, como havia falado, são uma coisa completamente diferente.

Terceiro. ONDE EU DISSE QUE AGILISTA É RIGIDO E INFLEXIVEL COM RELAÇÃO AO ESCOPO DO PROJETO???

Na minha opinião um dos maiores erros dos agilistas é justamente tentar prever o futuro como se ele fosse certo quanto um calculod e matemática. Não é.
Dizer que o futuro é X ou Y é pura ilusão. Ninguém sabe ao certo como as coisas vao desenrolar devido a quantidade de variaveis envolvidas.

Quanto ao analista como um vendedor, nem vou comentar nada. Uma coisa não tem nada a ver com a outra.
Só posso dar um conselho: antes de comentar, leia o tópico.

immortalSoul:

Quanto ao analista como um vendedor, nem vou comentar nada. Uma coisa não tem nada a ver com a outra.
Só posso dar um conselho: antes de comentar, leia o tópico.

Obrigado pelo conselho mesmo sem ter sido solicitado, mas e quanto ao assunto em questão algum argumento?

mochuara:

immortalSoul:

Quanto ao analista como um vendedor, nem vou comentar nada. Uma coisa não tem nada a ver com a outra.
Só posso dar um conselho: antes de comentar, leia o tópico.

Obrigado pelo conselho mesmo sem ter sido solicitado, mas e quanto ao assunto em questão algum argumento?

Bom, eu nunca vendi nada! O comercial vende (algo que eu nem sei se posso fazer), e ai eu discuto com o cliente como será feito e o que será feito.
Quando o analista visita um cliente, o produto já está vendido.

Posso ter entendido errado, neste caso peço desculpas.

Eu acho que o que gerou um erro referente ao nome “Analista” foi o fato de Analista de Sistema, ser alguém que desenvolve sistemas. Totalmente diferente de Analista, Analista pode ser de várias áreas. Hoje em dia está muito comum usarem o termo Analista, refere-se a: Analista de TI, Analista Contábil, Analista Financeiro, Analista de Sistemas, e assim por Diante. Analista na área de Ti, não é o cara que desenvolve e sim o cara que tem uma formação superior na área de TI ou uma vasta experiência em TI, independentemente de saber programar ou não. A informática no Brasil, não é uma profissão regulamentada, não sei se vocês sabem disso. Porem um cara para ser Analista não precisa ter uma graduação na área, mais isso varia de empresa para empresa, tem empresa que pode admitir um técnico com experiência como Analista.
O Nome Analista gera muita confusão mesmo, eu faço Tecnologia em Redes de Computadores, muitos professores nos dizem, vocês que vão ser futuros analistas, futuros por que ainda não nos formamos. Mais tem colega meu que acha que por que algumas empresas querem analista e acha que tem que fazer faculdade de analise de sistema para poder ser analista. Mais está equivocado quanto ao nome Analista. se você ver em um anuncio de emprego, Precisa de analista de sistemas, eu que sou de Redes não irei me candidatar claro, mais se o anuncio for Analista de TI, ai sim irei me candidatar, existe também Analista de Infraestrutura, pode ser infraestrutura física, ou seja redes, equipamentos, mais pode ser arquitetura de sistemas ai sim já deve ter um conhecimento desenvolvedor.

Tem muita gente na área de Ti que faz Ciências da Computação que atua somente na área de Redes de Computadores, mais existe aqueles que atuam somente em desenvolvimento = Analista de Sistemas.

Ficou mais claro agora ???

de modo geral a função do Analista de Sistemas é prover soluções informatizadas. se estas soluções são baseadas em redes, implantação de sistemas de terceiros ou programação não importa. esse “cargo” é utilizado de forma genérica para pessoas que participam de forma ativa em algum ponto da solução gerada.