Estou começando agora a trabalhar como Analista, sou recém formada, e estou me sentindo ‘um peixe fora d’agua’. A empresa que eu trabalho não tinha um analista antes, e claro, eu que tenho que iniciar os trabalhos de analise dentro da empresa. Pois é, a pergunta é como, não sei por onde começar, eles me pedem pra fazer documentos mas não dizem se está correto, se está como eles querem, ou se sou eu quem determino como eles serão…Os colaboradores não tem dialogo, não interagem e eu acredito que projetos devem ser discutidos, gosto de procurar por opiniões diferentes, pois sei que nessas conversas é que surgem os possiveis problemas de um projeto e possíveis soluções também, mas como implanta isso lá é que eu não sei… Parece que eles não gostam de conversar… Quando o profissional já tem experiência, fica mais facil, ele pode impor opiniões pois sabe como funciona e qual o resultado, as pessoas querem ouvir mais… Estou completamente perdida e não sei como agir, tenho medo que pensem que não estou me esforçando, que não tenho interesse… Se alguem puder me dar umas dicas eu agradeceria…
Para os documentos você pode tomar como base os templates do RUP: http://www.wthreex.com/rup/portugues/index.htm
Acho que você poderia pegar um projeto mais simples dentre os que terá que cuidar, e assim terá uma forma de “ir pegando o jeito”. Veja se não tem um sisteminha mas simples a ser feito, mas que se fosse implementado ajudaria o trabalho do pessoal. E converse com quem realmente vai ser usuário do sistema, pois estas pessoas é que vão notar o quão fácil ficou o trabalho delas após a automatização de suas tarefas. Se estas pessoas gostarem do resultado final, com certeza você vai ganhar pontos com seu chefe.
sua situação é bastante complicada, mas sugiro que vc estude bastante, leia livros sobre analise, rup, xp. A partir do momento que vc tiver uma base teórica, vc ficará bem segura na prática, claro que teoria só não vai salvar tua vida, mas procure mostrar seu conhecimento, procure mostrar empenho e vontade.
Se quiser, poste os documentos aqui que a galera ajuda a verificar se está certo.
[]s
Se arme até os dentes contra os programadores… pois eles não costumam gostar muito de analistas.
Sacanagem…
Mas sério, isso é típico de empresa sem organização, cada um faz de uma maneira e quando entra uma pessoa
nova fica perdidaça. Pode ficar tranquila que isso infelizmente é normal, mas pela pouca descrição que colocaste,
provavelmente seja uma barca furada para um iniciante.
Procure um livro chamado Utilizando UML e Padrões, do Caig Larman. Ele exemplifica certinho como montar um projeto. Mostra que diagramas usa em 3 iterações.
Se você procurar material de UML puro, vai acabar vendo como documentar muita coisa, mas não onde usar o que.
Com o tempo, informe-se também sobre alguma metodologia de desenvolvimento, como o Extreme Programming. É difícil implantar uma metodologia de cara, principalmente você sendo nova na empresa. Então, comece documentando coisas, e conquistando a amizade dos programadores.
Estou começando agora a trabalhar como Analista, sou recém formada, e estou me sentindo ‘um peixe fora d’agua’. A empresa que eu trabalho não tinha um analista antes, e claro, eu que tenho que iniciar os trabalhos de analise dentro da empresa. Pois é, a pergunta é como, não sei por onde começar, eles me pedem pra fazer documentos mas não dizem se está correto, se está como eles querem, ou se sou eu quem determino como eles serão…Os colaboradores não tem dialogo, não interagem e eu acredito que projetos devem ser discutidos, gosto de procurar por opiniões diferentes, pois sei que nessas conversas é que surgem os possiveis problemas de um projeto e possíveis soluções também, mas como implanta isso lá é que eu não sei… Parece que eles não gostam de conversar… Quando o profissional já tem experiência, fica mais facil, ele pode impor opiniões pois sabe como funciona e qual o resultado, as pessoas querem ouvir mais… Estou completamente perdida e não sei como agir, tenho medo que pensem que não estou me esforçando, que não tenho interesse… Se alguem puder me dar umas dicas eu agradeceria…
:D[/quote]
É por isso que as coisas não evoluem, um “analista” que sequer tem experiência passando especificações para os programadores. Acho que você realmente está fora do contexto, pois este é um cargo que exige experiência anterior com programação e conhecimento do negócio.
Para falar a verdade é um cargo que já deveria ter sido extinto faz uma década, mas isso é assunto para um outro tópico.
De qualquer forma, procure seu superior e exponha os fatos, ele é a pessoa ideal para te guiar, não fique com vergonha.
Muitas respostas … muito bla bla bla … pouca ajuda pratica!
Deixa eu tentar te situar e vc tomas as suas decisoes ai.
Bom, no desenvolvimento de software, tudo comeca com um “Processo de Desenvolvimento”.
Existem diversos processos no mercado (RUP, OpenUP, Scrum, XP, Analise estruturada, etc), sua empresa precisa escolher algum antes de começar a escrever qualquer documento.
Qual escolher vai depender muito do contexto da sua empresa, da sua equipe e eu até diria da natureza do sistem que vc vai fazer. Alguns sistemas vao lhe obrigar a ser mais formal e ter mais documentos, outros nao vao se preoculpar tanto com essas coisas desde de que o sistema funcione bem.
Se vc trabalha na area militar ou aero-espacial por exemplo, acredite em mim, vc vai precisar de muito documento de requisitos e muito documento provando que testes foram feitos, já que são área extremamente nao tolerantes a erros. Uma vez minha empresa desenvolveu um sistema de mira para tanques de guerra, mesmo o processo sendo 99% Scrum, muitos artefatos precisaram ser gerados.
A profissao que nosso amigo aleck disse que deveria ter morrido, nao é analista de sistemas, e sim, o papel do antigo projetista do RUP, que era um cara que fazia uns diagramas para o programador desenvolver isso eu concordo. Agora o analista de sistemas faz todo sentido em diversas áreas, como na analise de requisitos e testes.
Analise de requisitos é uma disciplina, onde analistas de sistema trabalham, documentando o sistema que sera desenvolvido. Qualquer processo de software razoavel tem algum mecanismo de analise de requisitos. Se vc olhar o RUP vai ver um milhao de atividades que o analista de requisitos tem. Se vc olhar o Scrum ou o XP por exemplo, muitas vezes eles aparecem como “Proxy” do cliente, tirando duvidas da equipe de desenvolvimento, fazendo um meio-campo com o cliente.
Assim o analista de requisitos nao precisa ter aquela experiencia toda com desenvolvimento de sistemas, mas sim, como sistemas em si! Tem que ser um cara/mina que use muito computador, e tenha um boa ideia do que é viavel ou não, independente de tecnologia, já que isso é problema dos arquiteto de software.
O analista de requisitos vai de alguma maneira mapear as funcionalidades do sistema a ser desenvolvido. Essa maneira depende muito do processo de software, e ai agente volta ao começo desse post.
Eu sugiro a vc que estude alguns processos, comece com RUP e o Scrum. Nao entre em detalhes, mas entenda como nos dois processos uma ideia/necessidade evolui e se torna um sistema, desenvolvido e testado suprindo requisitos funcionais e nao funcionais.
Enquanto voce estuda, comece a escrever o chamado Documento de Visao, nao precisa preenche-lo 100%, mas ele serve para dar um bom contexto do sistema:
Eu particularmente gosto desse documento, independente de ser agil (Scrum, XP) ou mais formal como RUP (ja que ele pertence ao RUP) ele põe a equipe no mesmo contexto.
Acho que a sugestão é unanime ESTUDAR, e é isso que vou começar a fazer, ver RUP, Scrum e XP…
Obrigada pelos Links vão me ajudar muito…
Claudio muito obrigada pelas dicas e concordo plenamente com você em tudo sobre um Analista de Sistemas…
Nosso Amigo tem a opinião dele em dizer que a profissão de Analista deveria ser extinta, eu não concordo, e ainda vou ser uma excelente analista, mesmo não possuindo a famosa experiência…Tudo se aprende e quando se tem determinação se chega muito longe…
Mas ainda vou precisar da ajuda de vocês e espero contar com todos…
Tá, isso foi muito apocalíptico. Vamos tentar ver o lado positivo: conseguindo organizar as coisas nessa empresa, você vai estar trilhando um bom caminho pra em breve ser gerente/diretora de TI.
Mantenho minha posição, alguém que não conhece arquitetura, infraestrutura, banco de dados e programação não possui capacidade para especificar algo, independente da experiência.
[quote=aleck]Mantenho minha posição, alguém que não conhece arquitetura, infraestrutura, banco de dados e programação não possui capacidade para especificar algo, independente da experiência.
[/quote]
Faço minhas as tuas palavras.
A simples ideia de ter uma analista recém saida da faculdade é absurda.
O que fazer é simples : desista. Vá ser desenvolvedor durante uma decada e depois tente de novo… se ainda existir essa posição.
[quote=sergiotaborda]
Vá ser desenvolvedor durante uma decada e depois tente de novo… se ainda existir essa posição.[/quote]
Não é assim também. Concordo que conhecimento técnico é imprescindível a qualquer profissional de TI. Mas qualquer um que esteja no mercado de trabalho vê que essa não é a realidade. A maior parte dos meus professores na faculdade não desenvolveu (só enquanto estudaram), dos analistas de requisitos que conheço conto nos dedos da mão aqueles que sabem programar. Isso é sinônimo de ruindade? Não. Um profissional sério vai tentar aprender tudo de que necessita para fazer seu trabalho de maneira correta. Uma empresa séria vai exigir esse tipo de comportamente para produzir com qualidade.
Acho que a empresa onde a Grazi trabalha está agindo de forma absurda, querendo exigir de alguém que precisa ser formado (no sentido de experiência profissional) um comportamento condizente com um profissional de nível pelo menos pleno. Grazi, a menos que essa empresa te pague muitíssimo bem e valha muito a pena (se não for empresa de outsorcing vale muito a pena), sugiro que você procure um lugar que esteja realmente interessado em te fornecer conhecimento e não apenas em sugar suas habilidades.
Mas mantenho o que disse antes: arrumar a casa por aí vai te dar muita bagagem.
[quote=aleck]Mantenho minha posição, alguém que não conhece arquitetura, infraestrutura, banco de dados e programação não possui capacidade para especificar algo, independente da experiência.
[/quote]
Aí eu discordo. Prefiro trabalhar num projeto com analista que entende do negócio de verdade do que num projeto agil sem cliente presente.
Mas a idéia do analista recêm formado é estranho pra mim tb, porque na escola de informatica não ensina processos de negócio. Voce tem analistas de negócio e implementadores de sistemas, analista de sistema é uma aberração pra mim, aparentemente não é para o sistema de educação.
[quote=mochuara][quote=aleck]Mantenho minha posição, alguém que não conhece arquitetura, infraestrutura, banco de dados e programação não possui capacidade para especificar algo, independente da experiência.
[/quote]
Aí eu discordo. Prefiro trabalhar num projeto com analista que entende do negócio de verdade do que num projeto agil sem cliente presente.
Mas a idéia do analista recêm formado é estranho pra mim tb, porque na escola de informatica não ensina processos de negócio. Voce tem analistas de negócio e implementadores de sistemas, analista de sistema é uma aberração pra mim, aparentemente não é para o sistema de educação.[/quote]
Reza a lenda que uma boa especificação de requisitos ignora detalhes de projeto. Qual é a necessidade de o analista de requisitos conhecer profundamente infraestrutura, banco de dados, etc?? Acaba caindo na síndrome do pato.
Acho importante saber aspectos técnicos, mas é como medicina. Qualque médico aprende a suturar, mas nem todos sabem operar o cérebro.
[quote=J-Chist][quote=mochuara][quote=aleck]Mantenho minha posição, alguém que não conhece arquitetura, infraestrutura, banco de dados e programação não possui capacidade para especificar algo, independente da experiência.
[/quote]
Aí eu discordo. Prefiro trabalhar num projeto com analista que entende do negócio de verdade do que num projeto agil sem cliente presente.
Mas a idéia do analista recêm formado é estranho pra mim tb, porque na escola de informatica não ensina processos de negócio. Voce tem analistas de negócio e implementadores de sistemas, analista de sistema é uma aberração pra mim, aparentemente não é para o sistema de educação.[/quote]
Reza a lenda que uma boa especificação de requisitos ignora detalhes de projeto. Qual é a necessidade de o analista de requisitos conhecer profundamente infraestrutura, banco de dados, etc?? Acaba caindo na síndrome do pato.
Acho importante saber aspectos técnicos, mas é como medicina. Qualque médico aprende a suturar, mas nem todos sabem operar o cérebro.
[/quote]
Qual parte da lenda diz que especificação de requisitos deve ser o resultado de uma mente?
Enquanto eu concordo que analistas devem ter uma bagagem maior, e eu já sofri muito com analistas que não sabiam muito da parte técnica, não concordo que tenha que passar a vaga.
Prefiro trabalhar com alguém que corra atrás, peça a ajuda para aprender, que converse mesmo que os clientes não queiram diálogo(sim, este é o teu trabalho), que faça tudo isso, a uma pessoa que diz que sabe mas é relaxada.
Assim, entender o que deve ser feito, qual é a entrada e qual é a saida esperada não precisa ser feito por alguem que seja especialista no “como”.
Por isso eu escrevi que não é fundamental que se saiba muito nesse sentido, e sim, saber o que é possivel (o que faz sentido). Eu sempre digo para os analistas e para os clientes: “qualquer coisa é possivel” só quero que vc pense bem se quer pagar por algo que alguem não vai usar.
Na verdade experiencia tecnica até atrapalha, sistemas pensandos por engenheiros, como eu por exemplo e acredito que como vcs, normalmente sao ruins! Tem muitas funcionalidades mirabolantes, super legais de se fazer, mas que o usuario nem imagina como funciona e nunca vai usar. Agente torra a grana do cliente usando super frameworks etc que nao sao nem interessantes para o cliente.
Um bom exemplo sao esses telefones VOIP (Cisco, Nortel etc), eles tem um zilhao de funcionalidades, e os usuarios mal usam as agendas neles (provavelmente pensado por um engenheiro.
Cansei de trabalhar com analistas de requisito que nao sabiam nem o que era Java, nem que é o nome de uma ilha, mas esse pessoal entrevistava bem os clientes, entendiam o porque das coisas, e normalmente alguem que responde pela area tecnica naquele projeto, um senior, ou arquiteto, sei la quem, vai estar presente (ou estudar depois) a viabilidade tecnica (o como).
Quanto ao negocio, fala serio, isso nao eh problema do analista de sistemas, imagina se vc trabalha numa consultoria, cada dia em um cliente. O mais importante, é vc aprender a entrevistar seu cliente, e entender o maximo das regras de negocio possivel. Claro que se vc tiver experiencia no assunto sempre é melhor, mas isso é raro. Onde vi isso com frequencia é com o povo de SAP.
Mas é isso ai, cada pessoa tem sua experiencia né! Cada um passou por coisas diferentes.
que use muito computador, e tenha um boa ideia do que é viavel ou não, independente de tecnologia, já que isso é problema dos arquiteto de software.