Não sei, ele é formado na PUC-RJ, e dá aula em faculdades do Grande ABC paulista, onde moro.[/quote]
vc sabe qual…fundação SA , imes, Uniabc e etc[/quote]
Fundação e IMES
Deve ter se referido a 30 mil pelo projeto, e não por mês. Daí o valor está coerente se for um projeto grande e complexo.
[quote=derrotado]Tem programador por aí que faz todo ciclo de vida de um projeto (o que inclui essa bosta de análise de requisitos) e não ganha mais do que 5k!
Tem professor de faculdade que não sabe o que fala mesmo… Já tive professores assim… Totalmente emaconhados…
Lixo…[/quote]
Desculpa, mas se o cara faz todo o ciclo de vida de um projeto e é programador, provavelmente ou o projeto tem uma complexidade ridiculamente baixa ou o cara não tá fazendo nenhum bem feito.
Sim, para um projeto de 6 meses já é algo factível. Embora eu sou da opinião que 5 mil reais para alguém ficar fazendo diagrama ainda é muito dinheiro.
[quote=rmendes08]Vamos fazer umas continhas, supondo que o analista seja um ultra-fodão nesse projeto:
1 an. requisitos = 30k
1 GP = 40k
10 devs. = 10 x 3k = 30k
5 testers = 4 x 3k = 12k
= 112k no mês
me diga quem investe essa montanha em um time relativamente pequeno como esse …[/quote]
A NASA para projetos de lançamento de foguetes se os caras forem uns dos melhores em suas áreas.
Aliás boa parte dos fundadores da PMI foram GP’s do projeto para mandar o homem a lua, ganhavam em valores corrigidos para época uma quantia maior do que o valor apresentado, só que neste caso o GP normalmente atua como analista de requisitos do projeto. Em relação ao produto, normalmente utiliza-se o GP e um especialista, dificilmente empresas tem analistas de requisitos propriamente ditos, quando isto acontece vejo muito no papel de gerente de produto e a analise de requisitos é apenas um de seus vários papéis.
Sim, para um projeto de 6 meses já é algo factível. Embora eu sou da opinião que 5 mil reais para alguém ficar fazendo diagrama ainda é muito dinheiro.[/quote]
Falar que analista de requisitos só faz diagrama é o mesmo que dizer que programador só digita código. Aliás é pior, porque o artefato gerado (diagrama) é muito mais simples que o código, a complexidade está em elicitar requisitos e documentá-los de uma forma que todos entendam.
Tem poucas coisas mais difíceis em TI do que elicitar requisitos e documentá-los adequadamente. Normalmente isto também envolve pesquisa de mercado, benchmarking, consulta com especialistas, conhecimento absurdo do produto e principalmente dos produtos concorrentes, ter uma visão de solução para o cliente, geralmente o que ele pede não é exatamente aquilo que ele espera.
No Brasil poucas empresas tem esta visão mas para equipes grandes analistas de requisitos é um dos caras mais importante financeiramente para a empresa, um requisito bem escrito, documentado e que de fato atenda as expectativas do cliente praticamente elimina retrabalho, os casos de teste podem ser feitos logo no início do projeto, se o cara gastar 50 horas para elicitar bons requisitos e isso faça com que o desenvolvedor leia e o entenda, não precise gerar retrabalho, o cliente não ligue para reclamar do escopo desenvolvido, isto economiza pelo menos uns 20-30% do trabalho de uma empresa que não tem um (bom) analista de requisitos, na prática financeiramente ele vale o mesmo que 20-30% da média dos programadores da empresa, em uma empresa com 50 programadores e 1 analista de requisitos ele deveria ganhar dez vezes a média dos programadores (20%), claro que isto é muito simplista, mas é mais ou menos por aí.
Cara, seu prof viajou legal R$ 30.000,00 também quero!!! 
se o cara for executivo e faxineiro, ele pode ganhar 30K
mas todo mundo vai dizer: “porra, os caras que estudam pra ser faxineiro conseguem ganhar até 30K”
qualquer semelhança é pura coincidência
[quote=Leozin]se o cara for executivo e faxineiro, ele pode ganhar 30K
mas todo mundo vai dizer: “porra, os caras que estudam pra ser faxineiro conseguem ganhar até 30K”
qualquer semelhança é pura coincidência[/quote]
Resumindo se quer grana seja capitão e não peão.
[quote=fabioEM][quote=dinho84]Estou no terceiro ano de Engenharia de Computação.
Meu professor garantiu que trabalhar com análise de requisitos, ou seja, elaborar diagramas de caso de uso, de classe, de seqüência, de estados, enfim, fazer toda a interface entre a parte técnica e o cliente, dá uma grana boa, podendo chegar a 30 mil, dependendo do projeto que vc pegar!
Vcs concordam? Discordam? Não tenho muita empatia com essa matéria na facu, mas se assim for, pq não investir?[/quote]
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Seu professor é um doido. Mas acho que ele deve estar tentando de dizer: olha programar é para burros, o negocio é modelar…
doce ilusão :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
deixa ele sair da faculdade e procurar emprego para ver o que acontece :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: [/quote]
Falou tudo!!! Ele disse mesmo que não deveríamos ficar presos a programar, pois nunca ganharíamos tanto. Saber modelar faria toda a diferença.
[quote=dinho84][quote=fabioEM][quote=dinho84]Estou no terceiro ano de Engenharia de Computação.
Meu professor garantiu que trabalhar com análise de requisitos, ou seja, elaborar diagramas de caso de uso, de classe, de seqüência, de estados, enfim, fazer toda a interface entre a parte técnica e o cliente, dá uma grana boa, podendo chegar a 30 mil, dependendo do projeto que vc pegar!
Vcs concordam? Discordam? Não tenho muita empatia com essa matéria na facu, mas se assim for, pq não investir?[/quote]
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Seu professor é um doido. Mas acho que ele deve estar tentando de dizer: olha programar é para burros, o negocio é modelar…
doce ilusão :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
deixa ele sair da faculdade e procurar emprego para ver o que acontece :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: [/quote]
Falou tudo!!! Ele disse mesmo que não deveríamos ficar presos a programar, pois nunca ganharíamos tanto. Saber modelar faria toda a diferença.[/quote]
Modelagem é documentação, não faz software que é a materia prima…
[quote=luistiagos][quote=dinho84][quote=fabioEM][quote=dinho84]Estou no terceiro ano de Engenharia de Computação.
Meu professor garantiu que trabalhar com análise de requisitos, ou seja, elaborar diagramas de caso de uso, de classe, de seqüência, de estados, enfim, fazer toda a interface entre a parte técnica e o cliente, dá uma grana boa, podendo chegar a 30 mil, dependendo do projeto que vc pegar!
Vcs concordam? Discordam? Não tenho muita empatia com essa matéria na facu, mas se assim for, pq não investir?[/quote]
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Seu professor é um doido. Mas acho que ele deve estar tentando de dizer: olha programar é para burros, o negocio é modelar…
doce ilusão :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
deixa ele sair da faculdade e procurar emprego para ver o que acontece :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: [/quote]
Falou tudo!!! Ele disse mesmo que não deveríamos ficar presos a programar, pois nunca ganharíamos tanto. Saber modelar faria toda a diferença.[/quote]
Modelagem é documentação, não faz software que é a materia prima…[/quote]
Opa! Então vou vender software lá na BM&F.
Software é produto, e documentação, artefatos de projeto, documento de tela, script de banco de dados são tão “matérias primas” do produto quanto o código.
[quote=luistiagos][quote=dinho84][quote=fabioEM][quote=dinho84]Estou no terceiro ano de Engenharia de Computação.
Meu professor garantiu que trabalhar com análise de requisitos, ou seja, elaborar diagramas de caso de uso, de classe, de seqüência, de estados, enfim, fazer toda a interface entre a parte técnica e o cliente, dá uma grana boa, podendo chegar a 30 mil, dependendo do projeto que vc pegar!
Vcs concordam? Discordam? Não tenho muita empatia com essa matéria na facu, mas se assim for, pq não investir?[/quote]
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Seu professor é um doido. Mas acho que ele deve estar tentando de dizer: olha programar é para burros, o negocio é modelar…
doce ilusão :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
deixa ele sair da faculdade e procurar emprego para ver o que acontece :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: [/quote]
Falou tudo!!! Ele disse mesmo que não deveríamos ficar presos a programar, pois nunca ganharíamos tanto. Saber modelar faria toda a diferença.[/quote]
Modelagem é documentação, não faz software que é a materia prima…[/quote]
Discordo. O código por si já um modelo. Ele pode ser um modelo bom ou um modelo ruim, mas é um modelo. Representar esse modelo em um diagrama antes de codificar não é garantia nenhuma de que a qualidade desse modelo será melhor.
[quote=rmendes08][quote=luistiagos][quote=dinho84][quote=fabioEM][quote=dinho84]Estou no terceiro ano de Engenharia de Computação.
Meu professor garantiu que trabalhar com análise de requisitos, ou seja, elaborar diagramas de caso de uso, de classe, de seqüência, de estados, enfim, fazer toda a interface entre a parte técnica e o cliente, dá uma grana boa, podendo chegar a 30 mil, dependendo do projeto que vc pegar!
Vcs concordam? Discordam? Não tenho muita empatia com essa matéria na facu, mas se assim for, pq não investir?[/quote]
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
Seu professor é um doido. Mas acho que ele deve estar tentando de dizer: olha programar é para burros, o negocio é modelar…
doce ilusão :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
deixa ele sair da faculdade e procurar emprego para ver o que acontece :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: [/quote]
Falou tudo!!! Ele disse mesmo que não deveríamos ficar presos a programar, pois nunca ganharíamos tanto. Saber modelar faria toda a diferença.[/quote]
Modelagem é documentação, não faz software que é a materia prima…[/quote]
Discordo. O código por si já um modelo. Ele pode ser um modelo bom ou um modelo ruim, mas é um modelo. Representar esse modelo em um diagrama antes de codificar não é garantia nenhuma de que a qualidade desse modelo será melhor. [/quote]
Essa é uma visão muito simplista da análise de requisitos. Vou repetir mas análise de requisitos em muitas empresas envolve a licitação de requisitos, em outra envolve o aceite de estórias (em um Scrum como exemplo) e desenvolvimento do documento de requisitos que serão base para as estimativas da equipe (no caso de estimativas por critérios e tamanho, não aquelas que levanta o dedo e chuta um valor com base na experiência), serão base para os casos de teste, tem que atuar na solicitação de mudanças, principalmente relacionadas a requisitos (se um requisito mudar durante a construção por exemplo e as baselines não estiverem sob controle da configuração, vai dar problema na hora do teste, o requisito implementado não foi o que o cliente solicitou, mas foi o que o desenvolvedor leu).
Tem muita coisa, e não sou analista de requisitos, mas acho uma das funções mais complicadas na área de TI, é muito injusta essa simplificação, assim como quando chamam um desenvolvedor de monkey code ou coisa do genêro.
Ah! Esqueci de falar sobre a matriz de rastreabilidade, só quem já passou por isso sabe como é “fácil” conseguir gerar uma rastreabilidade do requisito até o código, e é importantíssimo, como você sabe o que vai impactar uma mudança num requisito se não sabe a quais outros requisitos, artefatos e códigos ele está associado para tomar decisão de mudar ou não e como vai estimar?
R$30.000 por ano e olhe lá!
Abraços
Mas eu não estava falando dos documentos de requisitos. Quando não há a possibilidade da equipe de desenvolvimento sentar com o cliente os requisitos tem que ser transmitidos como documentação mesmo. Mas se a documentação de requisitos for composta de diagramas de classes, DER’s e etc. será um modelo de requisitos pobre, pois esses diagramas não se destinam a esse fim. Geralmente, documentos de requisitos são textuais.
O que na minha opinião não agrega em nada no desenvolvimento é elaborar diagramas de classes, sequência, DER’s detalhados, pois eles são suscetíveis a exatamente os mesmos erros do código.
[quote=rmendes08]Mas eu não estava falando dos documentos de requisitos. Quando não há a possibilidade da equipe de desenvolvimento sentar com o cliente os requisitos tem que ser transmitidos como documentação mesmo. Mas se a documentação de requisitos for composta de diagramas de classes, DER’s e etc. será um modelo de requisitos pobre, pois esses diagramas não se destinam a esse fim. Geralmente, documentos de requisitos são textuais.
O que na minha opinião não agrega em nada no desenvolvimento é elaborar diagramas de classes, sequência, DER’s detalhados, pois eles são suscetíveis a exatamente os mesmos erros do código.[/quote]
Analista de requisitos não é só diagrama, é levantar a necessidade do cliente e o que é necessário fazer pra solucionar. Nem sempre o cliente sabe exatamente o que quer, nem sempre é o seu programa propriamente dito que vai resolver, muitas vezes você vai ter de remodelar o processo.
[quote=rmendes08]Mas eu não estava falando dos documentos de requisitos. Quando não há a possibilidade da equipe de desenvolvimento sentar com o cliente os requisitos tem que ser transmitidos como documentação mesmo. Mas se a documentação de requisitos for composta de diagramas de classes, DER’s e etc. será um modelo de requisitos pobre, pois esses diagramas não se destinam a esse fim. Geralmente, documentos de requisitos são textuais.
O que na minha opinião não agrega em nada no desenvolvimento é elaborar diagramas de classes, sequência, DER’s detalhados, pois eles são suscetíveis a exatamente os mesmos erros do código.[/quote]
Mas é justamente disto que eu estou falando, o trabalho de um analista de requisitos não é (ou não deveria ser) somente ficar criando diagramas e UML’s.
Apesar de discordar quanto a utilidade, ele é útil num projeto pois pode-se discutir como as coisas serão codificadas e pode-se realizar as alterações e obter consenso antes de implementar e busca uma melhoria de qualidade pelo seguimento de padrões, lógico que tem falhas, mas acho que depende muito da cultura da empresa em como os projetos e os produtos são desenvolvidos, não podemos colocar tudo dentro da mesma cesta. Desenvolvimento cascata, iterativo, híbrido são bem diferentes assim como evolução de produto em roadmap e fábricas de software, o que não funciona em um pode funcionar muito bem pra outro e vice-versa, diagramas são muito úteis quando se trabalha em cascata. (realidade da maior parte das empresas de software, mesmo muitas das que se dizem ágeis porque tem estórias, reunião de review e restrospectiva, planning poker, mas é outra discussão).
marcosalex, não discordo do ponto de vista que você apresentou. Porém, o que eu vejo é um erro de conceito sobre a elicitação de requisitos, que erroneamente tem sido chamada de análise de requisitos (inclusive por mim). Na minha opinião, o foco do profissional de requisitos, que vai para a conversa com o cliente tem que ser a elicitação dos requisitos, ou seja, delimitar e expor de maneira clara qual é o real problema do cliente. Como você mesmo falou, muitas vezes a solução do problema não passa pelo desenvolvimento de software. Tanto é assim que é cada vez mais comum a chamada análise de negócios.
O que na minha opinião é um desperdício é ter um “profissional” só para esboçar a solução em termos de diagramas, e o pior, ter esses diagramas como planta-baixa da solução.
Na engenharia de software, elicitação de requisitos é feita pelo papel gerente de requisitos.
Este papel é comumente atribuído aos cargos gerente de produto, analista de requisitos ou mesmo um gerente de requisitos embora mais raro.
É o mesmo caso do analista de projetos, ele tem o papel de gerente de projetos mas não tem o cargo de gerente.