Para ser analista.

Depende ... como quase tudo em na área de T.I., trabalho como freelancer em uma empresa de consultoria na área de desenvolvimento e infra-estrutura, no meu caso só com projetos em PHP.

Eles possuem alguns programadores fixos e um analista, sendo que o analista não conhece nada de desenvolvimento mas é muito bom no entendimento do negócio e na elaboração dos requisitos, até eu me surpreendi com quando conversei com ele.

Já os programadores são feras em PHP, C#, HTML e CSS mas são horríveis nessa fase de análise e contato com o cliente.

Agora podem existir casos em que um programador evolui muito bem para um analista ....

muito interessante a situação que vc expos, gostei, e ja ouvi gente falando com uma arrogancia "para ser analista, a pessoa no minimo tem que ser um otimo programador", eu não gostei da forma que demonstrado isso.

Também estou iniciando minha carreira na área de T.I, e na empresa que trabalho, existe realmente este caso, em que o analista conhece muito do negócio e nada de programação.
Por este motivo, fiquei motivado para futuras escolhas...

que bom hein...nesse caso, posso considerar o individuo que falou tal asneira como um "cavalo batizado!!!". pq ele falou com uma arrogancia!!! acho triste isso.

wllfl e Carlos, muito legal saber que isso acontece, não sei se vc´s sabem, mas isso é raro!!!

isso depende muito, mas é interessante saber desses casos, mostram que algumas pessoas que não sabem programar, podem sim exercer uma função de analista.

O importante é que o analista e o programador estejam "alinhados" no conhecimento do que estão fazendo. Ou seja, o analista (caso não seja programador também) precisa saber o que pode e o que não pode ser feito pelo programador, da mesma forma que o programador precisa saber interpretar e contribuir com o trabalho do analista, demonstrando e sugerindo formas de atender a certas situações.

Joel, belas palavras!!! é isso mesmo!!! a equipe como um todo!!!

Por incrível que pareça, já participei da implementação de um grande ERP (como usuário) e os analistas possuiam pouco ou quase nenhum conhecimento em desenvolvimento, mas sabiam trabalhar muito bem com resquisitos funcionais e não-funcionais dos respectivos departamentos.

Alguns possuiam formação bem longe da área de T.I., mas com o salário bom acabaram mudando de área.

Mas por outro lado participei da apresentação de um módulo CRM de um grande ERP mundial, onde a empresa enviou 2 analistas para apresentação (1 - analista de negócio e 1 - analista de sistemas), que coisa horrível. Os 2 discutiam na nossa frente sobre as funcionlidades que o sistema podia ou não podia contemplar.

São casos e casos ...

entendo isso, mas o importante que isso não seja regra.

e muitas empresas isso não é. que bom!!!

quer dizer, nem todas.

A questão de se tornar regra ou não, só depende de nós mesmos. Profissionais de desenvolvimento geralmente não conseguem extrair as necessidades do cliente, mesmo em várias reuniões. Isso é comprovado que nerds em programação tem dificuldades em se expressar para outra pessoa, nessa hora que pessoas com pouco conhecimento em desenvolvimento mas, com boa didática e entendimento se dão bem.

Na faculdade presencio isso todos os dias os moleques são bons em programação (trabalham na área), mas quando tem seminário com bancada, pelo amor de deus, erros de concordância verbal e por ai a fora. Os trabalhos escritos com erros graves de português e isso acontece no dia a dia também, já li coisas do gênero em orçamentos de T.I..

Esse tipo de coisa o cliente percebe de cara e cai negativamente ....

é verdade isso, na faculdade isso é muito comum.

wllfl, por isso a importancia de ter uma equipe consistente.

Concordo !!!

A tecla que eu bato sempre é, temos que investir na parte técnica mas também na comunicação, não entre nós. Mas com pessoas leigas, temos que ser o máximo possível didáticos.

Falando em comunicação mais focado em apresentações, esse livro do Steve Jobs ajuda bem ...
[url]http://www.livrariasaraiva.com.br/produto/3003485/faca-como-steve-jobs[/url]

Li as primeiras 40 páginas, é muito bom ...

sem duvida, não é preciso falar pro cliente que "seu sistema" é feito com JAVA ou C#, isso não importa, mas tem muita gente que adora expor isso, não sei pra que? kkkkk, basta dizer o que ele faz da forma mais pratica e simples possivel.

ainda continua lendo...?

Estou com um projeto complexo e está faltando tempo para terminar de ler, mas é só passar esses dias que recomeço.

Algumas coisas já apliquei em algumas apresentações na faculdade, ficou legal a apresentação.

Acho que não é totalmente necessário saber programar BEM para ser UM BOM analista.
Mas acredito que é um diferencial e tanto alguém que saiba programar porém goste mais de trabalhar como um analista.
Sobre a comunicação, tanto o analista quanto o desenvolvedor precisam ser bons. Isso se quiserem crescer dentro de um ambiente.

O Analista precisa saber se comunicar bem, escrever estórias de usuários e testes de aceitação, diagramas UML e comunicar com o desenvolvedor.
Para isso é muito bom que ele saiba programar, arquiteturar/projetar um software.

fiquei interessada no livro.

entendo o que vc escreveu, realmente seria interessante o profissional ter esses atributos, conhecer a tecnologia bem(para se comunicar com a equipe) e ter uma boa comunicação, didatica(para os clientes).

isso mesmo Fernanda.

Ola Fernanda,
O analista não necessariamente tem de ser programador, isso vai depender do perfil de trabalho, até por que hoje, temos analista de negocio, analista de sistemas, analista de teste etc.
Agora, que dependendo de onde este vai trabalhar, ser um bom programador pode ajudar, mas não é o suficiente, pois o analista tem um perfil que necessita um maior contato com o cliente e ainda precisa conhecer de negócio, e nem sempre o programador tem este conhecimento.
Mas isso também depende muito da metodologia a ser adotada, mesmo assim, creio que um bom analista tem de ter um perfil de:
- Bom relacionamento interpessoal;
- Saber agir como ponte entre o cliente e o programador;
- Possuir capacidade analítica;
- Conhecimento de BMP e ETL pode ajudar;
- Auto-aprendizagem é necessário, mas para toda área de ti claro.
Uma pergunta, você quer se aperfeiçoar na parte de analise?

Importante, o analista é a profissão em maior destaque no Brasil.
http://br.educacao.yahoo.net/conteudo.aspx?titulo=Pesquisa+aponta+as+dez+carreiras+com+maior+expans%C3%A3o+de+vagas+no+Brasil

ainda pensando Rocha, estou ainda no começo da programação...

Bem Fernanda, bons estudos, e precisando pode perguntar...

pode deixar Rocha, mais uma vez obrigada.

Ola Boa tarde!!!

Estava garimpamdo pelo forum e achei esse topico e achei interessante.

Feliz ou infelizmente essa separacao de analista desenvolvedor e analista nao desenvolvedor talvez so aconteca em grandes empresas.

Sempre tive um perfil mais analitico e de conhecimento do negocio, sempre aprendi muito rapido do o negocio, nicho de mercado especificamente, acumulo experiencia a respeito faz um bom tempo e nas vagas de analista, nao passo nem do periodo de avaliacao do curriculo... rsrsr

Acredito que o conhecimento mesmo que basico a respeito de programacao seja importante para nao ser "ludibriado" por um programador "enrolao" e que o cara tenha como ate mesmo "defender" o software para o cliente caso necessario.

Eu outra epoca que trabalhei em uma software house, todos os programadores, lideres de testes e o escambal que tinham na empresa que consideravam os tops la nao conseguiram nem se quer passar pela fase inicial da implentacao e conhecimento da necessidade do cliente, ate que no periodo que o cliente estava desistindo me enviaram para tomar "porrada" pq ele ia desistir mesmo, e consegui reverter o quadro e o cliente terminou de fechar o negocio e dar o passo seguinte no processo.

Infelizmente nao eh bem o que acontece no mercado no nosso dia a dia, pq feliz ou infelizmente temos mais pequenas empresas como fabricantes de softwares que grandes empresas onde estes "cargos" sao separados e respeitados.

Espero que eu tenha conseguido me expressar e contribuir positivamente e de forma saudavel ao assunto.

Abraco.

Alex - Lekao

sabias palavras, é bem isso que acontece mesmo...de que adianta ser o bonzão em desenvolver se você não sabe nada do processo...

eh... eh bem isso que penso...

e infelizmente profissionais excelentes sao engavetados, pq se escolhe ter 1 de 2000 que 2 de 1500 por exemplo...

embora a analise deveria ser quando esses estao me dando de retorno? em todos os sentidos. rsrsr

é isso mesmo.

infelizmente, temos vivido uma era de "burrocratizacao" de contratacoes e gestao... =/

vc acha que isso deve a que? de quem é a culpa? hehehe

de todos nos...

ficamos querendo "inventar moda", e acabamo complicando as coisas...

queremos economizar em pequenas coisas, coando uma mosca e engolindo um camelo, queremos sempre gastar menos e termos mais, esquecendo-se que o equilibrio entre os dois eh o ideal.

deve-se ter os pes no chao e entender que mesmo que organizemos algumas coisas, podemos ter um pouco de ociosidade mas, nao teremos que apagar incendios, nem fazer as coisas "nas coxas".

acho que eh isso. rsrsr

extremamente complicado.

Como bem citado pelo membro Rocha, existem diversos tipos de analistas.
Basta saber à qual tipo de analista você está se referindo.

Se for analista de sistemas, então, fica complicado ele analisar o projeto e encontrar as melhores formas de se fazer algo, tendo visto que ele não tem capacidade técnica (se for um analista sem conhecimento técnico) para poder dizer qual tipo de tecnologia, metodologia etc utilizar.

Hoje em dia, a maioria dos programadores são os próprios analistas, em conjunto com o coordenador do projeto.
Isso tudo, na maioria das empresas está "uma bagunça".

As coisas não são hierarquizadas da forma como deveria ser.

O analista de sistemas é como uma ponte, ou um tradutor entre o negócio abstrato e o programador.

Mas minha opinião sincera:

Ser analista de sistema sem saber parte técnica é o mesmo que você dizer como fazer um bolo sem saber se a metologia usada é a mais adequada, sem saber quais ingrediente utilizar.

Enfim.

Abraços.

Atenciosamente,

Lucas Garcia Daveis

concordo Lucas, mas essa parte tecnica(programação pura) as vezes não tem a necessidade do analista saber, pq ele é a comunicação do cliente para os desenvolvedores...
mas é claro, ha casos e casos.

Ele não é SOMENTE a comunicação entre um e outro, ele não pega o chines do cliente e passa chines para os programadores.
Ele pega o chines do cliente passa para os programadores na "língua deles".

Se ele não tivesse esse papel de saber algo técnico, então ele não deveria saber nem mesmo se vai utilizar a linguagem X ou a Y.

Ou seja: se ele (analista) não sabe a diferença entre as linguagens, ele não sabe que deveria utilizar C# e não C para UM DETERMINADO PROJETO (EXEMPLO), pois C# tem uma produtividade de desenvolvimento muito maior, tem classes, objetos, herança, polimorfismo, encapsulamento de dados e tudo o que a programação OO nos trás, ao par de que a linguagem C, até mesmo algo como ultrapassar o subscrito de um array o compilador permite (É UMA CARACTERÍSTICA DA LINGUAGEM, NÃO UM PROBLEMA).

NOTE BEM ISSO: estou "dando um exemplo" de um projeto onde C# seria mais vantajosa de ser utilizada que a linguagem C. Existem MUITAS OUTRAS OCASIÕES onde linguagem C seria muito mais vantajosa de ser utilizada.


Na *minha opinião* já começa do ponto que eu duvido que existam mais de 5% de analistas de sistemas de software nas empresas do Brasil. Não estou falando isso me embasando em algum dado real coletado por uma organização confiável, apenas pela experiência que tenho e networking (caso contrário, vejam, eu não teria colocado *minha opinião* no começo da frase, ou seja, é um dado não concreto, apenas subjetivo).

Abraços.

Atenciosamente,

Lucas Garcia Daveis

Acho que cabe uma identificação de qual tipo de analista: negócios, sistema, testes...

Acho que você quis dizer como analista de sistema. Para transformar as idéias do cliente de maneira que os programadores entendam, acredito que uma vez que este analista não saiba programar e sendo assim não deve saber nem separar os requisitos em serviços do software, ele não pode componentizá-lo e nem escolher tecnologias, sendo necessário a ajuda de um arquiteto de software(pode ser o coordenador) para tal. Uma vez os serviços identificados, ele pode entrar para identificar as user stories, ou casos de uso (cenarios de teste, diagramas UML) se for o caso.

Fernanda, acredito que para ser um bom analista não é necessário ser " ótimo programador", mas ter conhecimento de programação ajuda muito na comunicação com a equipe de desenvolvimento. O papel do Analista de Requisitos é o de entender as necessidades do cliente (Foco: O que precisa ser feito?) e traduzí-las para uma linguagem técnica de forma que a equipe de desenvolvimento compreenda e construa um produto satisfatório (Foco: Como será feito?), Atua como um tradutor, então, é bom compreender bem as linguagens do cliente e dos programadores para uma boa comunicação e entendimento, através das documentações já conhecidas: Requisitos Funcionais, Nâo-Funcionais, de Domínio, e os da UML 2: Casos de Uso e os 13 Diagramas: Classe, Objeto, Atividade, etc.
Abraços, espero ter ajudado.

tem que conhecer do negocio, na minha opinião, não necessariamente o cara seja obrigado a ser durante 10 15 anos um programador para ser um analista.

entendo perfeitamente, mas vou falar uma coisa não muito agradavel, poucas pessoas(analistas. equipe) usam o UML. infelizmente. na minha opinião isso é um documento importante.

eu sei o que isso.

eu nao sei o que eh isso... rsrsr (UML) kkkk