Pessoal,
Essa pergunta vem a tempos sem resposta pra mim…por acaso alguem ae sabe quem ganha mais…ou tipo, quem é mais valorizado no mercado…o programador mesmo ou o analista?! Podemos citar a Linguagem Java para ambos.
ate mais…
Na pratica, a diferenca entre analista e programador nao existe, pq pelo menos no mercado de sao paulo eu nao ouco falar em outra coisa senao a aberracao do cargo de “analista programador”… 
Há muito tempo também não ouvia falar dessa diferença. Pelo que sei acabou o analista, o programador, o digitador, o cara do cafezinho, a dona da faxina… juntaram isso tudo e mais um pouco no Bombril: o funcionário de mil e uma utilidades. Pior que nem é uma celebridade como o Assolan… 
Mas vende bem mais… hehehe
ou , será que um eságiário vai ocupar o lugar de ambos, só para a empresa cortar gastos?
Isso já acontece :mrgreen: … 
Aberração por quê?
Acaba sendo isso mesmo… :?
Isso já acontece :mrgreen: … :([/quote]
Pior que antes eu via isso acontecendo em empresas pequenas, mas hoje ando vendo empresas grandes colocando gente sem experiência pra cuidar de área críticas…
[]'s
Aberração por quê?[/quote]
Pq eh muito mais simples dizer “desenvolvedor”
Pessoal,
Sou analista de sistemas…não tenho contato nenhum com código…tem o cara que é o chamado “desenvolvedor”, que coloca a mao na massa…acho que empresa um pouco mais estruturada ainda separa o analista do programador…
ate mais…
Desde quando eu acrdditava no que ouvi na facudlade, os cargios já haviam se emsclado. Hoje, dificilmente alguém tem cacife para bancar alguém que não mexa no código, só projete [e nem sei se isto é assim tão ruim]. Geralmente, existem os programadores que fazer as aplicações clientes, os WAR da vida, e os que produzem a arquitetura e o núcleo do projeto. Muito diferente disso faz muito tempo que não vejo…
[]s
Substitua “estruturada” por “arcaica” e “burra” na frase acima, que da na mesma
Substitua “estruturada” por “arcaica” e “burra” na frase acima, que da na mesma :D[/quote]
Acho um pouco extremista essa sua colocação, cv. Eu acho ruim “purificar” as funções - o analista SÓ faz análise, o programador SÓ coda - mas não acho que seja ruim separar as responsabilidades.
É impossível negar que um grande número de empresas contratam apenas os famosos Analistas Programadores.
Mas não acho que isso seja correto e nem que isso aconteça 100% do tempo no mercado.
Pelo menos nas empresas por onde passei e onde trabalho atualmente, temos a figura do Analista Funcional e do Desenvolvedor.
Também já participei de uma equipe onde tínhamos uma pessoa responsável apenas por documentação e testes.
Uma divisão que também sempre encontro é a dos Desenvolvedores responsáveis por classes de Arquitetura (geram impacto em todo o projeto) e os Desenvolvedores responsáveis pelo desenvolvimento de serviços (obviamente utilizando as classes de arquitetura).
IMHO, a divisão de responsabilidades é muito importante.
Não sou muito a favor da metodologia da pelada, onde todo mundo sai correndo atrás da bola e de repente, meio sem querer, marca um gol!
Pô Cv pegou pesado. Também não vejo problema algum na divisão. Por exemplo, acho um saco essa parte de especificações, entrevistas com usuários, etc. Adoro mesmo é uma boa sopa de letrinhas cheia de código :lol:
Se na minha equipe alguém gosta mais dessa parte, não vejo problema algum que o faça. Infelizmente não podemos nos dar este luxo, pois temos de assoviar e chupar cana ao mesmo tempo.
Aqui só ta faltando a gente ter de lavar os banheiros também… :roll:
Substitua “estruturada” por “arcaica” e “burra” na frase acima, que da na mesma :D[/quote]
cv…realmente super infeliz sua colocação! Se a empresa quer um cara que analise, desenvolva roteiro de testes, melhoria de processos…enfim…do mesmo modo que “analista programador” faz até mágica o “Analista de Sistemas” pode analisar sistemas, elaborar roteiro de testes, liderar equipes, estudar melhorias em fluxos de processos…enfim…existe a empresa que tem uma estrutura em que não existe hierarquia/cargo…ou seja, o cara que analisa, desenvolve, testa, especifica…só que tem empresas em que tem cara para analisar, cara pra desenvolver, cara pra testar e cara pra coordenar…ou seja, a empresa que eu trabalho está na segunda opção e não vejo nada “arcaico” ou “burro” nisso. 
Vai de cada um…! Estou acostumado neste modelo em que eu trabalho…tenho amigos que estão no modelo de quem analisa, codifica, etc, etc…e não critico este modelo…cada empresa faz o que eh melhor pra ela…e o funcionario se adapta conforme o seu perfil e seus conhecimentos!
ate mais…
Depende… tudo eh relativo…
Do que adianta a empresa contratar um analista que nunca botou a mao no codigo direito??
Rafael
Nao adianta nada…ai está…um bom analista precisa ja ter sido programador…ou ter mexido um tempo com código…
Veja meu exemplo: programei mais de um ano…depois fui 8 meses analista de qualidade e agora sou Analista de Sistemas…mas acho que nenhum bom analista começa como analista sem nunca ter mexido em codigo…isso é meio impossivel…o analista tem que ter vivencia em projetos…codificação, prazos, os problemas em geral que um desenvolvedor passa…senão ele nunca será um bom analista…e depois da fase “desenvolvedor”, ele pode decidir por continuar ou nao…eu fui programador…não curti muito codificar e fui para a área de analise…questão de perfil.
ate mais…
IMHO, dentro de um projeto há lugar para o programador, para o analista, para o documentador e para uma pessoa que garanta a qualidade.
Acredito também que um bom Analista deve ter alguma experiência com codificação, pois se não fica bem complicado conversar com os programadores, saber filtrar as loucuras que os usuários pedem e principalmente produzir documentos em linguagem que programadores entendam.
Não vamos esquecer: desenvolvimento de software (engenharia de software ou como queiram chamar) é uma atividade complexa e possui muito mais etapas que simplesmente a codificação.
O que tenho visto com o passar dos anos é que os programadores (e eu me incluo nesse grupo) tem uma cabeça muito técnica e estão sempre pensando em bits e bytes.
Essa foi uma das boas lições que aprendi durante uma aula do MBA. Quando estamos conversando com um usuário, devemos prestar atenção e entender qual o problema a ser resolvido a um nível de negócios e não pensar em linha de código.
Geralmente, um programador, ao ouvir um usuário falando de uma necessidade X, já começa a pensar em como resolver o problema utilizando a API XYZ.
Bem, é apenas minha humilde opinião!
Bom…
É difícil pensar no “modo certo”, ele não existe, tudo depende da situação. Certa vez, a euipe da minha emrpesa resolveu aplicar uma metodologia. O primeiro passo era achar uma metodologia que coubesse no nosso ambiente, eu li de tudo, desde XP, UP, RUP, PQPUP, Catalysis e um grande e interminável ETC. Nenhum se adaptou. Começamos, então, a organizar uma reunião semanal onde colocamos algumas práticas de metodologias variadas para funcionar. Estamos com um controle de iteração próximo ao do XP, early releases, documentação como RUP…um híbrido que tem suas vantagens e desvantagens.
Não existe solução tamanho único. Eu aprendi que existem PAPEIS, e adoro como o RUP os comapra a um chapéu. Uma pessoa pode utilizar vários chapéis diferentes, e um chapéu pode ser utilizado por várias pessoas, basta uma organização.
Conheço lugares onde os todo-poderosos analistas levantam os requisitos, desenham meia dúzia de bonequinhos e mandam os programadores s e virarem com o projeto e implementação [que são coisas distintas]. Conheço lugares onde os analistas fazem todos os diagramas conceituais, os projetistas [que as vezes são os mesmos, com outro chapéu ] especificam classe por classe. Aí o cliente muda tudo e o projeto demora um ano a mais do que havia sido previsto. Conheço também lugares onde até a faxineira tem o cargo de analista-projetista-programador, não se faz um plano de desenvolvimento e você vê coisas como SQL espalhados em camada de apresentação, super-servlets, programação UM-O [um objeto manda], e anti-patterns afora.
Divisão de responsabilidades é itneressante, talvez você realmente tenha necessidade de deixar uma pessoa ser analista e somente isso, talvez ela tenha outras resposabilidades, sei lá. Mas eu não respeito um analsita que não codifica. Podem ser classes de negócio, classes de alto nível, mas O CARA TEM QUE SABER PROGRAMAR E ESTAR PROGRAMANDO!
Conheço uma “analista” que nunca escreveu uma linha de código, meia dúzia de sql e só. Fiquei uma hora explicando para ela como funcionava o processamento de um servlet, e mais uma hora explicando porque estava errado: “Se CPF não é chave, pode ter redundância!”. Tenho nojo, raiva, ânsia de vômito… Caso queiram saber, esta analista deve ganhar mais que todos nós, umas 5 vezes mais que eu ela ganha!!
Bom, voltando, a pessoa mais gabaritada que conheci até hoje te recita o catálogo de design patterns da GoF de trás pra frente, te dá um exemplo de carrinhso de f[orumla um pra explicar o que é invariância e porque não pode ser quebrada, e come C++ com CORBA no café da manhã. E ele é CIO de uma das maiores instituições federais, com alta patente militar, quase indo pra reserva.
Uma vez, Ronie Uliana disse que Programar é design em baixo nível. Eu penso o contrário: projetar [fazer design] é programar em alto nível. Aliás, MDA fala sobre isso, não?
Não acredito em coelho da páscoa, não acredito em mula-sem-cabeça, ams é aidna mais difícil acreditar em um bom analista que não programe.
[]s