[RESOLVIDO] Estou iniciando como Analista, o que fazer?

Grazi,

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.

Olá Grazi,

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.

Boa indicação ViniGodoy
Esse livro é muito bom…
sobre xp, procure o livro Extreme Programming do Vinícius Manhães Teles
[]s

grazi_san:

Olá pessoal,

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

É 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:

Aqui tem um template dele

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

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.

Boa sorte para vc,

Abraço,

A todos que responderam Agradeço mesmo…

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…

Abraços

Fuja, enquanto há tempo!!!

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.

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.

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.

sergiotaborda:

Vá ser desenvolvedor durante uma decada e depois tente de novo… se ainda existir essa posição.

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.

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.

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.

mochuara:

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.

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.

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.

J-Chist:

mochuara:

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.

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.

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.

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.

Só peço para que continue seguindo em frente.

Todas deveriam. Ao menos eu gostaria que todos os profissionais de TI tivessem uma mente e fizessem bom uso dela. Infelizmente isso não ocorre.

Simplesmente:

“O que”

não é

“Como”

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.

Isso ai é o que aconteceu/funcionou comigo.

Abraço,

claudio:

Simplesmente:

“O que”

não é

“Como”

claudio, seu post explicou brilhantemente o que eu penso.

O que o pessoal esta querendo dizer é que na maioria das vezes(não todas), ou vc conhece o negocio, ou vc implementa.
A função do analistas de sistemas classico como é/era ensinado na faculdade esta desaparecendo.

Lembram da brincadeira do telefone sem fio?
O principio é o mesmo, quanto mais pessoas estiverem entre quem sabe o negocio e quem realmente vai fazer as coisas acontecerem, maior a chance de dar errado.
É isso que as metodologias ageis pregam. Proximidade entre negocio(cliente) e implementação.

[]´s

claudio:

Simplesmente:

“O que”

não é

“Como”

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

Abraço,

Achei que voce começou bem mas depois se estendeu muito pra dizer que analista de sistemas é um tipo de vendedor de segunda categoria que precisa conviver num eterno dilema entre não se preocupar com o negócio do cliente e entender ao máximo(!). Apesar de nada a ver com o problema relatado pelo autor do tópico que é sobre o processo interno de desenvolvimento eu nunca tinha conhecido um analista de sistema por esse prisma, obrigado.

Entao vai ser rapido agora ok?

Tem gente que vem aos foruns procurar ajuda, tem gente que vem ajudar, e tem os outros.

Da uma lida nos seus ultimos posts e ve onde vc se coloca

Abraço

Todas deveriam. Ao menos eu gostaria que todos os profissionais de TI tivessem uma mente e fizessem bom uso dela. Infelizmente isso não ocorre.

Uma especificação deve ocultar os detalhes de implementação é verdade, mas isso não significa que quem as escreveu estava irrelevante aos aspectos técnicos da implementação. Por isso especificações são geralmente escritas por um comite de representante das diferentes areas.

Agora se vc me pergunta se é preciso de um comite pra especificar requisitos, eu diria que esse é um aspecto da metodologia utilizada. Metodologias ageis por exemplo não criam especificações de requisitos ou analistas de sistemas.

J-Chist:

sergiotaborda:

Vá ser desenvolvedor durante uma decada e depois tente de novo… se ainda existir essa posição.

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.

O ponto é que o trabalho de analista é simplesmente : não existente.
Analise de software é feito por desenvolvedores. Por isso vc tem que ser desenvolvedor primeiro e penar muito.
Existe uma máxima para os arquitetos que só deve contratar arquitetos depois que fizeram mais de 3 projetos (aliás a definição da Sun é bem essa… arquiteto é alguem com experiencia, não com conhecimento teorico) O mesmo se pode aplicar a analista.

Analista de Negocios é feito na prática, aprendendo o negocio em causa. Trabalhando, não com software,mas com o ramo do negocio em causa.

Sendo que a colega saiu da faculdade agora é obvio que ela não pode ser analista de negocios. Donde só resta ser analisa de software, donde se conclui que tem que começar sendo desenvolvedor.

Desenvolvedor não necessáriamente é programador. Desenvolvedor é mais lato. abarca testes, documentação, etc…

Isto pode ser um choque para muitos de vcs, mas a Grazi tb está agindo absurdamente. Ela acredita que pode ocupar um cargo de analista depois de sair da faculdade. O cliente pede o que quer, mas temos que ter senso da realidade.
Se alguem pedisse a um cara que acabou de se forma em medicina que fizesse uma operação de cirurgia neural, vc acharia sensado ele aceitar ? De quem é a “culpa” , de quem pediu , ou de quem aceitou ? De ambos, mas principalmente de quem aceitou, porque tem a obrigação profissional de saber recusar propostas absurdas e desonestas ( sim, colocar um analista como citado é desonesto da parte da empresa).

Concordo com o colega ai de cima, eu sou analista de sistemas no diploma e já estou há 1 ano trabalhando como desenvolvedor, mesmo meu chefe que já trabalha na área algum tempo acaba não obtendo 100% os requisitos do cliente, ou não entende plenamente… agora imagina eu que não tenho experiência na área de análise?

Se você aceitou o cargo, tem de responder por ele, e cabe somente á você pesar suas qualidades profissionais para isto. Se fosse pra mim? Sim eu aceitaria, pois já tenho alguma experiência com desenvolvimento, sei o que é possível em determinado prazo e já posso identificar muito bem, quando o cliente viaja na maionese, mas ainda assim precisaria de alguém com mais experiência para me guiar no começo, coisa que vocẽ não tem ai na sua empresa.

Eu sinceramente prefiro muito mais a parte do desenvolvimento e pesquisa do que da parte da análise, mesmo sabendo que ganha bem melhor na segunda.

é eu concordo com o que o Claudio falou, com tudo mesmo… concordo com o que o bruno falou, em partes claro, o analista deve conhecer sim a parte tecnica, ao menos um pouco, mais assim mesmo o foco dele deve ser em aprender a regra de negocio do cliente e “arrancar” requisitos dele. Da parte tecnica fica mais com o que da/não da para fazer e custo/prazo, como não é com ele…

queria comentar também o que o jgbt falou, muita gente eu concordo que atrapalha mesmo, conforme as metodologias ageis, mais o foco do desenvolvedor é a parte mais tecnica… não a analise de requisitos…

maior_abandonado:

queria comentar também o que o jgbt falou, muita gente eu concordo que atrapalha mesmo, conforme as metodologias ageis, mais o foco do desenvolvedor é a parte mais tecnica… não a analise de requisitos…

É exatamente esse o problema. Desenvolvedor não é so tecnico. Ele deve entender do negocio, para poder implementar. Senão ele é um simples digitador de especificação. Como foi feito ate hoje. E todos nos sabemos o que acontece. O desenvolvedor deve estar em contato direto com o negocio. Não precisa de ninguem para ¨traduzir" o requisito para algo que ele entenda. Isso claro se falarem a mesma lingua.
Alguem ja implementou um caso de uso exatamente como foi levantado?
Mas como o foco do topico não é esse, deixa p/ um outro topico.

[]ś

Sinceramente, estou curioso em saber qual de vocês recusaria o cargo estando vocês na posição da grazi. Não que vocês estejam errados em suas colocações. Eu concordo com quase todas. Mas e se desistência não for a opção dela? Bom, ela pediu ajuda. Sei que não se aprende do dia para noite, mas poderiam dar algumas dicas e sugerir algumas leituras, ou é impossível ela ir a frente como analista neste momento?

Atenciosamente,
novato22

O problema todo esta no emprego do termo analista. Analista de negocios é diferente do tradicional analista de sistemas. Quem conhece o negocio nao precisa saber nada da parte tecnica. Quem faz a “especificacao” (requisitos nao é especificacao) do sistema precisa saber como implementar essa “especificacao” ou vai fazer uma besteira atras da outra.

Agora concordo com quem diz que contratar alguem que nao tenha experiencia nem no negocio e nem na parte tecnica é uma aberracao sim.

À criadora do topico eu sugiro que corra atras, porque te largaram uma bomba enorme, mas é uma enorme oportunidade pra voce aprender na pratica. Do que foi escrito aqui nesse topico voce pode apagar tudo, menos o post do vinigodoy sobre o livro do Larman.

De resto, esse é um espaco pra quem tem duvidas, pra quem quer ajudar, mas tambem pra quem quer debater.

novato22:

Sinceramente, estou curioso em saber qual de vocês recusaria o cargo estando vocês na posição da grazi. Não que vocês estejam errados em suas colocações. Eu concordo com quase todas. Mas e se desistência não for a opção dela? Bom, ela pediu ajuda. Sei que não se aprende do dia para noite, mas poderiam dar algumas dicas e sugerir algumas leituras, ou é impossível ela ir a frente como analista neste momento?

Básicamente vc está sugerindo que forneçamos gambiarras, receitas ou formas escusas de manter a pessoa no cargo que ela não deveria ocupar e nem deveria existir. É como pedir que arranjemos desculpas para perdoar a corrupção.

Profissionalmente não ha como compactuar com isso e a sugestão de procurar outro trabalho é a mais sincera , honesta e profissional que pode ser dada.

Se a pessoa decidir continuar, então não existe nenhuma outra forma de fazer frente ao problema dela senão estudar. estudar muito, com afinco e dedicação. Não apenas “fazer na prática” e ver no que dá. Experimentalismo é o caminho para a desgraça.

Desistir sempre é uma opção para um profissional que entende que está no lugar errado na hora errada fazendo coisas erradas.
Ha muito mercado por ai fora. Procure que vc acha.

Grazi,
Todos deram suas opiniões e dicas, mas acho que faltou algo, apoio moral. Menina seja forte e determinada, não existe essa de sou nova e não tenho experiência, você deve sim assumir sua posição sem medo. Seja ousada, não erre por medo de errar, erre por coragem de assumir riscos, você está em uma ótima posição para aprender, e a empresa sabe que você é recém formada, não será a falta de experiência o fator de avaliação.
Ah, estude mais também.

Abraço.

Site:http://www.jorgeluis.eti.br
Blog:http://blog.jorgeluis.eti.br
E-mail:[email removido]

tenha sangue nos olhos :twisted:

pare com esta de sou novata e tou ferrada… se pensar assim vc realmente estara ferrada…
pense: sou foda… :twisted:

sergiotaborda:

novato22:

Sinceramente, estou curioso em saber qual de vocês recusaria o cargo estando vocês na posição da grazi. Não que vocês estejam errados em suas colocações. Eu concordo com quase todas. Mas e se desistência não for a opção dela? Bom, ela pediu ajuda. Sei que não se aprende do dia para noite, mas poderiam dar algumas dicas e sugerir algumas leituras, ou é impossível ela ir a frente como analista neste momento?

Básicamente vc está sugerindo que forneçamos gambiarras, receitas ou formas escusas de manter a pessoa no cargo que ela não deveria ocupar e nem deveria existir. É como pedir que arranjemos desculpas para perdoar a corrupção.

Profissionalmente não ha como compactuar com isso e a sugestão de procurar outro trabalho é a mais sincera , honesta e profissional que pode ser dada.

Se a pessoa decidir continuar, então não existe nenhuma outra forma de fazer frente ao problema dela senão estudar. estudar muito, com afinco e dedicação. Não apenas “fazer na prática” e ver no que dá. Experimentalismo é o caminho para a desgraça.

Desistir sempre é uma opção para um profissional que entende que está no lugar errado na hora errada fazendo coisas erradas.
Ha muito mercado por ai fora. Procure que vc acha.

sergiotaborda,

se você conhecesse alguns dos analistas que conheço talvez você não visse o mundo tão cinzento assim. É certo que ela não pode dar um pulo maior que a perna, mas daí a quebrar as pernas dela sem nem ao menos saber o tamanho da empresa que ela vai trabalhar e saber da experiência dela durante o curso, como programadora mesmo(ou seja, as habilidades que ela possui)… E mais, será que ela mentiu à empresa quanto à sua experiência profissional? por que colocar toda a responsabilidade de aceitar o emprego só nela e não na empresa? É verdade que ela vai ter dificuldade no começo, vai ter que correr atrás, por falta do traquejo que o cargo exige, assim como ser programador também exige uma certa experiência. Ah, e outra coisa: talvez não tenha sido claro, mas quando eu falei em sugestões de leituras e dicas na profissão, não estava falando de “gambiarras, receitas ou formas escusas de manter a pessoa no cargo”. A garota parece interessada em aprender. Mas caso você tenha este tipo de informação, gostaria que compartilhasse, só a nível de curiosidade mesmo.

Atenciosamente,
novato22

Bom após ler todos posts pude verificar que não estou preenchendo a Vaga de Analista e sim Desenvolvedor. Se não me engano o sergio que disse que eu deveria iniciar como Desenvolvedor (não o programador mas aquele que faz testes, que cria documentos) e foi exatamente isso que a empresa exigiu para o cargo… Outra coisa que eu não mensionei é que estou como Trainee na empresa e a mesma é de pequeno porte, como eu disse nem havia esta função antes de mim…

Novato realmente na minha situação não dava pra recusar a oferta de emprego na área que escolhi para fazer minha carreira profissional… Eu deixei claro para a empresa que tudo que eu mais queria era aprender ja que eu não tinha a experiência que eles desejavam e é isso que estou fazendo… Eu penso na empresa 24hrs por dia, tentando fazer a diferença, meu problema é que não estou tendo muito espaço e os programadores também dificultam as vezes parece que fingem que eu não existo, mas não posso ser cruel pois não tenho a bagagem tecnica que eles possuem, entendo eles mais faço o possível para que eles possam recorrer a mim quando tiverem dúvidas, que hj eles recorrem ao meu chefe…estou me dedicando ao máximo no entendimento do sistema e também o negócio que a empresa atua.

Ja começei a estudar desde o dia que começei no trabalho… li vários livros… e realmente escrevi esse tópico com a intensão de conseguir novas referencias pois sabia que eu ia encontrar vários profissionais da área aki…

Mas obrigada ai pessoal … fequei decepcionada quando ouvi que minha decisão foi absurda, mas também fiquei feliz quando recebi apoio de vários de vocês e vou batalhar sim, fazer o possivel e até impossivel para permanecer no cargo e fazer um ótimo trabalho…

Muito bem, grazi. Desejo que você seja feliz no seu trabalho. Trabalhe muito e faça o seu melhor. E nunca deixe ninguém dizer que você não pode. Sucesso!!

Atenciosamente,
novato22

Orra bixo, deixar uma informação desta (trainee) de fora do tópico é sacanagem né, se fosse com Analista de Sistemas mesmo seria absurdo sim, mas se é trainee mergulha de cabeça que é isto que a empresa esta procurando, fazer você ganhar experiência.

Abraço.

Porque ela que é a profissional.
Vc está-me perguntando o mesmo que se eu acho que se o médico erra se a culpa é do hospital.

Sempre, em qualquer ocisa na vida, as pessoas tentaram procurar outro alguem para fazer o que elas não sabem ou não querem fazer. É por isso que ha profissões. Mas ha pedidos honestos e pedidos desonestos. Quem tem que saber a diferença e esolher é o profissional. Se isto fosse assim, empresas de software de meia leca iam à falencia em dois tempos e não viveriamos o cenário atual. O problema é que as pessoas que trabalham com software nem sempre são profissionais.
É uma questão de ética.

Sim, eu sei que pode parecer meio duro, mas é a realidade. As pessoas têm que começar a enxergar a realidade.
Só assim haverá respeito.

sergiotaborda:

novato22:

se você conhecesse alguns dos analistas que conheço talvez você não visse o mundo tão cinzento assim. É certo que ela não pode dar um pulo maior que a perna, mas daí a quebrar as pernas dela sem nem ao menos saber o tamanho da empresa que ela vai trabalhar e saber da experiência dela durante o curso, como programadora mesmo(ou seja, as habilidades que ela possui)… E mais, será que ela mentiu à empresa quanto à sua experiência profissional? por que colocar toda a responsabilidade de aceitar o emprego só nela e não na empresa?

Porque ela que é a profissional.
Vc está-me perguntando o mesmo que se eu acho que se o médico erra se a culpa é do hospital.

Sempre, em qualquer ocisa na vida, as pessoas tentaram procurar outro alguem para fazer o que elas não sabem ou não querem fazer. É por isso que ha profissões. Mas ha pedidos honestos e pedidos desonestos. Quem tem que saber a diferença e esolher é o profissional. Se isto fosse assim, empresas de software de meia leca iam à falencia em dois tempos e não viveriamos o cenário atual. O problema é que as pessoas que trabalham com software nem sempre são profissionais.
É uma questão de ética.

Sim, eu sei que pode parecer meio duro, mas é a realidade. As pessoas têm que começar a enxergar a realidade.
Só assim haverá respeito.

Não concordo com vc… na vida se vc não mete a cara… se vc coloca o rabo entre as pernas e fica com medo… vc e um fracassado… tem mais e que meter a cara e lutar… e verdade vc vai apanhar muito porem… é levando porrada que se aprende a bater!

luistiagos:

sergiotaborda:

novato22:

se você conhecesse alguns dos analistas que conheço talvez você não visse o mundo tão cinzento assim. É certo que ela não pode dar um pulo maior que a perna, mas daí a quebrar as pernas dela sem nem ao menos saber o tamanho da empresa que ela vai trabalhar e saber da experiência dela durante o curso, como programadora mesmo(ou seja, as habilidades que ela possui)… E mais, será que ela mentiu à empresa quanto à sua experiência profissional? por que colocar toda a responsabilidade de aceitar o emprego só nela e não na empresa?

Porque ela que é a profissional.
Vc está-me perguntando o mesmo que se eu acho que se o médico erra se a culpa é do hospital.

Sempre, em qualquer ocisa na vida, as pessoas tentaram procurar outro alguem para fazer o que elas não sabem ou não querem fazer. É por isso que ha profissões. Mas ha pedidos honestos e pedidos desonestos. Quem tem que saber a diferença e esolher é o profissional. Se isto fosse assim, empresas de software de meia leca iam à falencia em dois tempos e não viveriamos o cenário atual. O problema é que as pessoas que trabalham com software nem sempre são profissionais.
É uma questão de ética.

Sim, eu sei que pode parecer meio duro, mas é a realidade. As pessoas têm que começar a enxergar a realidade.
Só assim haverá respeito.

Não concordo com vc… na vida se vc não mete a cara… se vc coloca o rabo entre as pernas e fica com medo… vc e um fracassado… tem mais e que meter a cara e lutar… e verdade vc vai apanhar muito porem… é levando porrada que se aprende a bater!

Vc não entendeu nada. Meter a cara e lutar só faz sentido quando vc está sendo profissional. quando vc mete a cara para simplesmente estorquir dinheiro de alguem, enganar alguem a te contratar ,isso não é ser profissional. Pode funcionar,e vc pode gostar e achar que está tudo blz e que vc é um cara de sucesso, mas não é real. Se vc fizer isso, a realidade é que vc é um charlatão sem ética profissional.

Mas a questão nem é essa. A questão é ao contrário. A empresa faz uma proposta. Essa proposta é eticamente dubia. Ai vc aceita.
Vc é tão responsável quanto a empresa.

tem uma máxima do fraudadores que se aplica aqui : não é possivel enganar uma pessoa honesta.
Se a empresa apresenta algo abaixo do que seria honesto, ela está escondendo o jogo e mais cedo ou mais trade vc se ferra.

No caso em epigrafe, acabámos descobrindo que nem sequer havia problema nenhum. apenas pânico de quem se meteu numa errascada. Mas veja bem, a empresa coloca a responsabilidade de analisar/desenvolver um software nas mãos de uma pessoa sem experiecia alguma. Isto não é estranho ? É. Deveria ser obvio a todos aos que saem da faculdade.

Repare no “golpe”. Contratar uma pessoa saida da faculdade, como trainee, e colocar nela a responsabilidade de fazer um software.
Isto faz sentido para si ? Para mim não faz. Para mim é uma empresa tentando levar vantagem.
O que eu estou dizendo é que aceitar este tipo de proposta é uma fria. E não podemos culpar a empresa por tentar levar vantagem,mas podemos aconselhar os profissionais ( ou profissionais want to be) a terem cuidado com isso.

Vc pode ver na pessoa que aceita uma situação assim um cara que foi à luta. Eu vejo alguém que escolheu a batalha errada. Uma que não poderá vencer sem levar muito na cabeça. Para vc, levar na cabeça é sinal de honra, para mim é sinal de masoquismo.

Deixa eu ver se entendi: a empresa só pode contratar um analista com experiência. Logo o analista inexperiente nunca deve ser contratado, portanto ele nunca vai adquirir experiência. (E quando os analistas experientes morrerem? A TI acaba?).

Acho que tem gente xiita demais por aí, querendo limitar os outros por seus próprios limites.

Pois é, a simples ausencia da palavra trainee gerou uma grande confusao.

Discordo. Eu comecei como trainee e fui “treinada”. Pena que foi numa empresa de outsorcing e não na Johnson & Johnson (onde o programa de formação dura 3 anos e leva a um cargo gerencial, não técnico). O normal é que o trainee tenha desafios e responsabilidades sim, mas não jogado às feras. Além disso, sempre há a figura do mentor, para auxiliar em questões como essa levantada pela Grazi. Quando eu era trainee não tinha mentor, mas na empresa atual eu tenho e é muito bom.

J-Chist:

sergiotaborda:

Existe uma máxima para os arquitetos que só deve contratar arquitetos depois que fizeram mais de 3 projetos (aliás a definição da Sun é bem essa… arquiteto é alguem com experiencia, não com conhecimento teorico) O mesmo se pode aplicar a analista.

Deixa eu ver se entendi: a empresa só pode contratar um analista com experiência. Logo o analista inexperiente nunca deve ser contratado, portanto ele nunca vai adquirir experiência. (E quando os analistas experientes morrerem? A TI acaba?).

Vc não entendeu.

Existe uma coisa chamada aprender. Vc não pode ser contratada como senior sendo junior. O ponto é que não existe analista junior.
Existe analista em aprendizado (trainee). Só que para aprender é preciso aprender com alguém. (Esse é o ponto do caso, ela foi contratada como trainee sem haver ninguem para a ensinar)

A empresa só pode começar por contratar alguem que já é analisa com experiencia. Depois ela contrata pessoas que irão aprender com esse e um dia terão experiência para serem contratados como analista zero em outro lugar.

Um analista inexperiente não é um analista. Não existe isso. É uma aberração. ( É como oferta de trabalho para Analista Junior, não me façam chorar … )

Quando alguem é inexperiente ele é colocado na equipe para aprender. Os membros da equipe se são profissionais de verdade ensinam (se têm competencia para ensinar é outra historia, estou falando de vontade). É muito simples.

O problema de vocês é que acham que analista é um cargo. Analista é uma função. É um papel que alguem desempenha junto a muitos outros. Não acreditem no contrário pq vão se dar mal ( como no exemplo)

Quando os analistas experientes morrerem a TI evolui. A TI não depende dos analistas. Ela depende da equipe de desenvolvimento na qual existem pessoas com capacidade de analisar.

Às vezes eu acho que os jovens ainda acreditam no papai noel…

Siga as dicas positivas dos amigos ai e estude, se informe e logo estará inserida no contexto, opiniões pessimistas como estas que estão ai só servem pra te motivar, não desista e vá em frente e boa sorte.

Att.

Vlw ManoJava… é exatamente o que vou fazer… seguir as dicas positivas, das não muito positivas retirar o de melhor delas, e bola pra frente…

:lol:

Acredito que pensando assim vc vai se dar bem, inicie lendo tudo que puder e estudando alguns projetos, que vc verá que as coisas irão clarear e se tiver alguma duvida, fique a vontade pra postar e no que pudermos te ajudar fique tranquila pois não esta sozinha não.

Att.

Pra parte de fundamentos teóricos, sugiro começar por esta leitura. É de um prof. meu da universidade. Não está muito organizado, mas acho q ajudará.

Muitos acham que “análise” é só criar um monte d modelos da UML, e essa referência que mostrei vai um pouco contra isso. Fala da da engenharia de requisitos em três partes: elicitar, modelar e analisar. Entender essas 3 partes e suas diferenças já é um começo.

Recomendo somente não se ater a aplicar tudo que está aí, porque existem coisas mais antigas ou atuais, mas acadêmicas. Mas, de uma forma geral, as tópicos de discussão são os mesmas d hj.

Essa discussão remete a uma conhecida frase: O que veio antes? O ovo ou a galinha?

Alguém aqui aprendeu a andar de bicicleta lendo livros? Alguém aqui aprendeu a caminhar ouvindo um professor ou outra pessoa com mais experiência que você em “Caminhar”?

Chega momentos da vida que temos que peitar e ponto final.

A Grazi terá que fazer um manejo de risco da opção que ela tomar e fim de papo.
Se ela se quebrar, não quer dizer que ela tenha sido uma má profissional, quer dizer que ela terá que aprender com os erros para uma próxima e próxima e próxima e próxima e próxima e próxima… Vez!

Se pintou uma oportunidade para uma coisa que você não tem experiência, simplesmente tente adiquirir experiência. Como adquiro experiência? Tendo experiências…hehehehehhehe…

“ex.pe.ri.ên.cia
sf (lat experientia) 1 Ato ou efeito de experimentar. 2 Conhecimento adquirido graças aos dados fornecidos pela própria vida. 3 Ensaio prático para descobrir ou determinar um fenômeno, um fato ou uma teoria; experimento, prova. 4 Conhecimento das coisas pela prática ou observação. 5 Uso cauteloso e provisório. 6 Tentativa. 7 Perícia, habilidade que se adquirem pela prática. Antôn (acepções 2, 4 e 7): inexperiência. E. de vôo V ensaio de vôo.”

Grazi, faça o que teu coração manda. No fim das contas, se você fizer, haverão pessoas falando “porque você fez?” e se você não fizer haverão pessoas dizendo “porque você não fez?”…

heehehheheh

O grande problema é que os Analistas de Sistemas que vemos por ai são os famosos ECO.
Apenas repetem o que o cliente quer pros desenvolvedores, e no final das contas quem PROJETA o software mesmo é o desenvolvedor.

E pra projetar sistemas vc NECESSITA de experiencia em Desenvolvimento. E experiencia BOA.

Ja tive a infelicidade de trabalhar em projetos onde Analistas nao entendiam nem request e response, e prototipavam telas ABSURDAS como se estivessem fazendo sistemas DESKTOP.
E era WEB.

Vai morrer um dia a profissao Analista?
Creio que sim. Mas enqto esse dia nao chega melhor a gente lidar com o que tem e buscar melhorar o cenario atual.