Quem ganha mais: Analista ou Programador ?!

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: … :(
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ê?

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

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

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

Concordo.

Acho necessária.Senão vc corre o risco de ter os que trabalham,e os que assistem os outros trabalhar…

Bom,uma pessoa q tem decorado um catálogo de patterns não necessariamente será um bom programador ou analista.Quantidade de saber não revela nada,mas se possui junto a qualidade,é algo precioso e raro.Em qualquer área do conhecimento.

Bom, já que todo mundo fez um escandalo sobre o meu post dizendo que eu nao gosto de divisao de responsabilidades entre analista e programador, acho que eu preciso dar uma explicacao melhorzinha.

Seguinte: se vc tem um analista, que desenha e programa, e um programador, que as vezes desenha alguma coisinha, mas passa a maior parte do tempo programando, voce esta, essencialmente, quebrando o ciclo de desenvolvimento do software em duas “etapas”. Voce ta colocando um baita dum synchronized {} dentro do teu projeto.

Alo Mr. Shoes,

Eu devo estar parecendo uma mula, de tão teimoso (ou seria um burro?), mas eu não consigo concordar com isso, Phillip.

Continuo defendendo a idéia que desenvolvimento de software vai muito além de codificar.

Se o projeto for desenvolvido em Java, um bom analista tem que ser fera em Java? Ou tem que saber apenas sobre desenvolvimento?

Porque linguagens vém e vão. Ontem era ASP, hoje é Java, amanhã pode ser XYZ++.

Mas se você aprendeu a desenvolver software, migrar para uma nova linguagem não vai exigir tanto esforço assim.

Acho interessante quando um Analista entende de código, pode abrir uma classe e sugerir alterações. Mas não acho que isso deve ser uma regra como você está pregando.

Não vejo a atividade de Análise tão conectada a codificação.

Acredito muito mais que um bom Analista deve ser um excelente ouvinte (para entender todas loucuras do usuário) e conseguir transportar isso para o papel, escrevendo os documentos ou diagramas necessários, de acordo com a metodologia empregada.

Onde entra nessa fase de Análise a codificação?

Por que o dito cujo deveria entender de imports, for e while?

E se o projeto for em .NET ao invés de Java, o Analista tem que saber .NET também?

Pera lá. O problema dela então não é que ela não sabe codificar. O problema dela é que ela não aprendeu o básico do básico do básico da modelagem de dados!

Grande abraço,

Nada, a gente nunca corncorda em nada mesmo

Uhm… não seie xatamente se fui eu, mas vislumbro uma confusão aqui: Analista != Projetista. Sim, eu que confundi as cosias, estou falando de projetista, quase sempre. SIm, um analsita não rpecisa saber muito, o cara pode ficar com engenharia de requisitos e depois, de repente, gerenciar o projeto…

Existem duas coisas que eu exijo que as pessoas em uma equipe que eu coordeno tentem aprender: teoria e prática. Teoria te diz o que é uma classe, o que é invariânte, congeneridade, etc. Prática te diz como usar tudo isso em XYZ++.

Uma pessoa pode ser muito boa em teoria, mas se não sabe a prática… Lembra da quinta forma normal? E se seu projetista exigí-la? Afinal, ele fez dez pós, dois doutorados e sabe que é possível, só não sabe que fica lento, já que nunca pôs a mão em código.

Ok, análise não, projeto sim.

No projeto

Po, loops é o mínimo, vai, até analista ouf axineira de fábrica de software tem que saber o que é um loop

Bom, o Projetista tem que saber sim, pelo menos a diferença entre um EJB Entity e Sesion, entre uma JSP e um Servlet. Se ele não conhece o que projeta, que diabos de projeto vai sair?

Acho que confundi os conceitos nomeu post e acabei passando uma coisa diferente do quequeria, espero ter consertado

O problema neste caso específico é que disseram pra ela que tudo no mundo se resolve com uma consulta ao ADABAS. Este é um caso perdido, ams é bom pra rir um pouco…

[]s

“pcalcado”:

“mcampelo”:

Alo Mr. Shoes,
Eu devo estar parecendo uma mula, de tão teimoso (ou seria um burro?), mas eu não consigo concordar com isso, Phillip.

Nada, a gente nunca corncorda em nada mesmo

Que isso!!! Imagina!!!

Tá vendo como de vez em nunca nós concordamos!

Acho que um Analista não tem que ser um puta programador.

Mas um Projetista (costumamos chamar de Arquiteto por aqui) sim, precisa entender da tecnologia sendo utilizada, pois ele precisa projetar a melhor solução para um determinado problema levantado/especificado pelo Analista, utilizando uma tecnologia XYZ++.

E como todos nós estamos cansados de saber, a melhor solução em .NET será bem diferente da melhor solução em Java ou qualquer outra tecnologia Server Side que apareça por aí.

Concluindo: Concordo em GnG contigo. Um projetista deve ser um puta programador!

Abraços,

Analista não precisa realmente ser programador…ele tem que manjar da tecnologia…e em relação a ganhar grana…conheço muitos lugares em que se paga até duas vezes mais para analistas…analistas mesmo…que pouco contato com código tem…do que para programador.

Mas isto não é em todo lugar…com certeza!

ate mais…

Realmente é fato que Analistas costumam ganhar mais que Programadores.

Eu particularmente sou contra, pois um bom Programador é tão importante para o projeto quanto um bom Analista.

E não acho que um bom Programador deva ser transformado em um Analista, pois você pode acabar perdendo um excelente codificador e ganhando um Analista mediano.

IMHO, o que acaba acontecendo em muitos projetos é que a pessoa que coloca o chapéu de Analista, coloca também o chapéu de Líder de Projeto (Coordenador, Gerente, whatever), assumindo mais responsabilidades e recebendo mais $$$ no final do mês.

Substitua “estruturada” por “arcaica” e “burra” na frase acima, que da na mesma :D

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…

Eu não diria arcaica, mas hoje em dia é inviável ter um cara só para fazer análise, documentação e frescurinhas com processos. Uma pessoa para coordenar e dar a visão geral do sistema, um grupo de programadores razoavelmente bons (não precisam ser realmente bons, talvez nem bons; apenas razoavelmente bons, que sejam esforçados e façam testes) e um documento de requisitos bonitinho já muito melhor (do ponto de vista econômico e do ponto de vista de produtividade) do que aquela equipe com um cara que só analise e um cara que só projeta e um cara que só programa e um cara que só testa e um cara que só documenta.

Sim sim, eu conheço vários destes. Nenhum projeto deles costumava dar certo .

“richardpeder”:

Analista não precisa realmente ser programador…ele tem que manjar da tecnologia…e em relação a ganhar grana…conheço muitos lugares em que se paga até duas vezes mais para analistas…analistas mesmo…que pouco contato com código tem…do que para programador.

Mas isto não é em todo lugar…com certeza!

ate mais…

hein? voce quer dizer que 1) sendo analista, ele nao precisa mais ser programador, ou vc quer dizer que 2) para ser analista nao precisa ter sido programador alguma vez na vida ?? pq se vc disser a opcao 2, entao ha alguns problemas ai… Todos os tipos de catastrofes me vem a mente quando imagino uma pessoa sem forte experiencia em desenvolvimento dizendo como as coisas devem e nao devem serem feitas.

Rafael

“Rafael Steil”:

“richardpeder”:

Analista não precisa realmente ser programador…ele tem que manjar da tecnologia…e em relação a ganhar grana…conheço muitos lugares em que se paga até duas vezes mais para analistas…analistas mesmo…que pouco contato com código tem…do que para programador.

Mas isto não é em todo lugar…com certeza!

ate mais…

hein? voce quer dizer que 1) sendo analista, ele nao precisa mais ser programador, ou vc quer dizer que 2) para ser analista nao precisa ter sido programador alguma vez na vida ?? pq se vc disser a opcao 2, entao ha alguns problemas ai… Todos os tipos de catastrofes me vem a mente quando imagino uma pessoa sem forte experiencia em desenvolvimento dizendo como as coisas devem e nao devem serem feitas.

Rafael

Rafael…1 opção…é claro! Não vejo um analista que não tenha tido um tempo como programador…

Daniel…se o cara já foi programador em determinada linguagem…não vejo pq ele não dar certo como analista.

ate mais…

Olá

Estava me omitindo nesta discussão porque muita coisa certa está sendo dita por gente em lados opostos. É isso mesmo, o que é certo em determinadas circunstâncias em outras pode ser mesmo complemente arcaico e burro.

É claro que aquele que pensa que um sistema com separação de funções sempre redunda em fracasso está desprezando TUDO que foi desenvolvido nos últimos 25 anos antes de começar a era mais recente onde realmente está sumindo a figura do analista que só faz análise.

As funções que antes eram completamente separadas hoje se misturam principalmente nas empresas que adotam alguma coisa de XP. Mas mesmo nas empresas mais próximas dos 95% XP que são muito raras, alguém precisa fazer a análise. Como foi dito por alguém aqui, análise pressupõe reuniões com cliente ou usuário e pessoas com extrema habilidade para captar o que o cliente pensa que quer (mas que na verdade nunca sabe).

O problema do desenvolvimento sempre foi que é praticamente impossível um cara ser fera em desenvolvimento/codificação que é uma tarefa extremamente técnica (cara de exatas) e ao mesmo tempo ser capaz de ter sensibilidade para extrair do cliente/usuário o que nem o cliente/usuário sabe que precisa (cara de humanas). Não há chapéu que sirva nos dois.

Daí surgiu o tal de analista de negócio que seria o cara que manja de TI e manja do negócio. Geralmente é um desenvolvedor (ex-programador) que passou muitos anos em empresas do mesmo ramo de negócio e que conseguiram entender aquilo que estavam fazendo. Costumam ser bem valorizados, principalmente quando são suficientemente criativos para criar novos sistemas e novos negócios. Conheci poucos com esta habilidade.

Putz, falei paca sem me colocar em lado nenhum, melhor deixar a discussão seguir como dantes.

[]s
Luca

“richardpeder”:

Daniel…se o cara já foi programador em determinada linguagem…não vejo pq ele não dar certo como analista.

ate mais…

Discordo novamente. Muitas vezes você perde um ótimo programador para ganhar um péssimo analista. Há uma teoria que diz que você evolui até o seu nível de completa incompetência, ou seja, você evolui verticalmente até um cargo em que você não é competente o bastante para galgar um novo degrau na hierarquia da empresa. Às vezes é possível que um ótimo programador, um cara totalmente insano em algoritmos, seja convidado a se tornar analista e acabe se tornando um grande peso de papel na empresa. Além do mais, não acho que analista seja uma evolução de um programador. É uma tarefa completamente diferente, que evolve complexidades diferentes (não maiores, nem menores do que as de um programador). Ainda sou a favor de promoções horizontais sempre que possível (algo como: programador jr. -> programador pleno -> programador sênior -> mito de programação -> oráculo -> deus) antes de promoções verticais sem critério.

Pessoal,

É bem simples resumir o que está havendo aqui…todos aqui são programadores…correto?!

Pelo seguinte: coloquei esse post aqui com o intuito realmente de discutir a função Analista…analista em seu papel fundamental…analisar…quando falamos em analista de sistemas, meu, podemos cercar várias possibilidades…e um analista faz um papel em cada empresa…isso é muito relativo…não sei se um programador bom será essencialmente um analista…e nem sei se um cara que nunca viu codigo na vida será um analista tb…analista, acima de tudo, lida com cliente (até onde eu sei e convivo… ), geralmente o programador não tem este “tino” que o Analista tem…o que é normal…eu trabalho numa empresa em que nem todos os Analistas mexem com código…dai vcs perguntam…mas como?!

Pq eu trabalho em ambiente de fábrica…normalmente, quando o cenário é outro temos os famosos analistas/programadores…que fazem os dois papéis…e não recrimino isso…pois cada empresa sabe o que é melhor para ela…por isso que, não vejo nenhuma estrutura arcaica ou burra ou seja la o que for…simplesmente pq por tras de desenvolvedores e analistas existe administrações para saber o que é melhor para aquela empresa ou a outra…eu fui programador mais de um ano…depois mais 8 meses analista de qualidade…e meu perfil foi se adaptando até chegar a analista de sistemas…e acho que esse cargo abrange muita coisa…

Me perdoem por ter falado demais…queria explicar…não sei se consegui!

ate mais…

Quando a sua empresa descobrir o que são metodologias ágeis de desenvolvimento, aí sim você vai entender que analista é uma profissão tão perto da extinção quanto os pandas.

Daniel…

Ja disse…coloquei esse post no lugar onde só tem programadores…jamais o analista “sairia ganhando”…financeiramente seria legal ter um cara que faça analise e programação…mas nem sempre é assim…hj, os proprios cursos universitarios dividem as coisas…e se for misturar tudo…eu nao acho legal…pois acho que o legal seria ter pessoas mais focadas em programar e pessoas focadas em analisar.

Misturar tudo vira salada…

ate mais…

Yes!!! Pessoas mais focadas em cada função e não exclusivas delas.

Richard, não sei em qual empresa vc trabalha, nem o seu tamanho ou o setor de atuação, vou falar da experiência que tenho trabalhando em alguns bancos.

Já passei por 9 deles aqui em SP, de grandes a pequenos e, sem exceção, nenhum deles tem a figura do analista e programador exclusivos, ou seja, o analista que só analisa e programador que só programa. Todos eles procuram pessoas mais dinâmicas, que conseguem meter a mão no código em um momento de urgência (banco é assim mesmo, todo problema é urgente, ou pelo menos 95% deles) mesmo que o foco dele seja a análise. Não é nada raro, ao contrário disso, vc encontrar vagas para Analista Programador e que conheça bem do negócio, ou seja, seria mais um “Analista de Negócio Programador”.

Resumindo, se grandes bancos no Brasil trabalham dessa maneira, e as coisas funcionam BEM, acho que isso não é nenhum tipo de salada.

Concordo com o jc_oz, mas ainda tem um ponto importante a frisar: programador que nao conversa com o cliente, que nao sente na pele o que o cara ta passando, e nao entende do negocio, perde uma chance MUITO grande de ajudar a vida do cara (afinal, eh pra isso que os sistemas servem, nao?).

O que está prestes a acontecer aqui na minha empresa, que herdou toda a rigidez da divisão analista/programador do ambiente mainframe. Agora que estamos, lentamente e a duras penas, passando para o mundo OO/Java, já percebi que alguns analistas estão muito assustados.

Marcelo…

Acredito que eles estejam assustados…é um grande pulo sair da linguagem de mainframe para OO/Java.

ate mais…

Falando em migrar, este artigo é bem interessante.

GEnte,

O Martin Fowler tem um artigo muito bom em

Para mim, tem pessoas que realmente gostam de programar e outras que gostam de especificar os sistemas. Mas na prática eu não creio que esta separação seja boa. Ela indica níveis diferentes entre profissionais, nos quais eu não acredito. Talvez daí tenham surgidos os “Analistas Programadores” . Acho que cada um pode ter suas preferências ( técnicas ) e afinidades, mas nestas equipes, creio que um deve participar no trabalho do outro.

Vale muito ver outros artigos do Fowler

Até…

Concordo com o seu post (e, alias, valeu por citar o chefe ;)), mas é importante dizer que o trabalho eh um soh, nao “um do outro”