[quote=felipefranz][quote=rmendes08][quote=andredecotia]Acho que um ponto que ninguém efatizou foi o conhecimento fluente do GP correlacionado à Visão de Negócios… O Negócio do Cliente… Já tive um gerente que era visível que ele
não tinha o domínio sobre o escopo, ou pior, sobre a necessidade do cliente…[/quote]
Não acho que GP tenha que conhecer muuuito mais sobre regra de negócios do que um desenvolvedor. Se reunirmos as opiniões de todos, ao invés de um GP teremos um Super-Homem, que tem que gerenciar o projeto, levantar requisitos e ainda por cima dar suporte técnico para a equipe, é por aí mesmo ?
Bom, minha opinião. Antes de mais nada, esse papel tinha que mudar de nome, e passar de Gerente de Projetos para Analista de Projetos. Veja bem, se pensarmos em um time com: desenvolvedores, testers, analistas de negócios e analistas de projeto, além de nivelar os cargos, temos uma idéia mais clara do papel de cada um.
Para mim, analista de projeto tem que colher métricas e saber quando usar síntese/análise, só. Ou seja, é uma tarefa tão técnica quanto desenvolver, é um papel como qualquer outro, portanto, não merece nenhuma elevação hierarquica. Por outro lado, liderança depende, além da experiência de uma séria de soft skills, que podem vir de uma pessoa ocupando qualquer um desses papéis.
Por fim, acho que mais fácil ainda é citar coisas que um analista/gerente de projetos NÃO deveria fazer:
:arrow: tomar decisões técnicas, ou influenciar decisões técnicas
:arrow: estabelecer processos, artefatos
:arrow: levantar requisitos
:arrow: priorizar requisitos
:arrow: estabelecer prazos (estimar é diferente)
:arrow: controlar a equipe [/quote]
Opa, mais ou menos:
1- tomar decisões técnicas, ou influenciar decisões técnicas:
Depende. Se a decisão técnica estiver de alguma forma relacionada a custos, prazo, escopo ou qualidade do projeto o que é bem provável, ele deve intervir sim, mas ele sempre deve consultar um especialista, na verdade especialistas de confiança são cruciais para o gerente de projetos.
2- Estabelecer processos, artefatos
Aí também depende. Os artefatos de projeto (principalmente um plano de projeto com plano de comunicação, escopo, risco e etc) deve ser estabelecido pelo gerente de projetos, essa é a função dele, assim como processos relacionados a projetos como metodologia e workflow de solicitação de mudança.
3, 4- Levantar/Priorizar requisitos
Em relação a requisitos, temos requisitos do produto e requisitos do projeto, é impossível fazer análise de riscos sem analisar e priorizar requisitos do projeto, então concordo parcialmente, requisitos do produto devem ser levantados e priorizados pelo analista de requisitos ou gerente de produto, mas os de projeto não.
5- Estabelecer prazos
Aí sim eu concordo totalmente, mas o gerente de projetos não tem como estabelecer prazos, quem faz isso é o cliente, seja interno ou externo. Ele pode é ter maior ou menor flexibilidade nesse quesito.
6- Controlar a equipe
Aí depende do que você entende como controlar. Pedir para que apontem horas por exemplo é fundamental para o acompanhamento do projeto. Não tem como avaliar um EVA por exemplo sem esta informação, mesmo pro burndown é importante. O controle está na própria definição de gestão (POC3) planejar, organizar, controlar, coordenar e comandar, o que deve ser visto é como este processo deve ser feito. Independente de ser gerente ou analista de projetos, ele deve assumir uma função de gestão.
[/quote]
Bom ler sua opinião felipefranz, minha tréplica:
1 - Na verdade, decisões técnicas sempre estão relacionadas a custos, escopo, qualidade etc. Claro, decisões de alto nível, ou relacionadas a arquitetura, não a cor do botão de OK. Nesse caso, vale a negociação e o bom senso. Os desenvolvedores tem que estar cientes do custo e do impacto de suas decisões e saber comunicar a importância de suas decisões para o gerente.
2 - Mais uma vez, acho que vale também a negociação. O GP pode estabelecer processos e artefatos que facilitem o acompanhamento do projeto, mas acho que a equipe tem que ter autonomia para descartar/incluir de acordo com sua percepção. Por exemplo, se os desenvolvedores apontarem que passam 30% de seu tempo preenchendo artefatos. Acho que o GP deve ter em mente que os maiores interessados no acompanhamento do projeto são os próprios stakeholders, pois as maiores decisões são deles.
6 - Nesse ponto eu falo sobre aquele controle exagerado. Colar no cara de hora em hora perguntando “Já acabou?”. Claro que o GP deve conscientizar a equipe de quais métricas ele precisa para fazer o seu trabalho.
Por fim, o que eu queria dizer é que nem sempre GP == Líder da equipe, e essa lista coisas que o GP NÃO faz serve na verdade para reforçar isso. É como um time de futebol, você não amarra a braçadeira de capitão em uma posição. O capitão pode ser o goleiro, atacante, zagueiro, volante. Mas tem que ser o cara mais experiente. Nas equipes é a mesma coisa. O líder pode ser um desenvolvedor, GP, tester, desde que ele tenha experiência e saiba “conversar” com todas as áreas. O que eu vejo acontecer muito, em razão da cultura corporativa é desenvolvedores experientes partirem para GP por falta de espaço para crescerem como técnicos.
