Qual a maior habilidade que um gerente de projetos deveria ter caso pudesse escolher um?

Debugger Membro desde: 04/10/2011 09:44:18 Mensagens: 52 Offline

Ser uma ameba petulante, que não sabe nada e manda em todos.

This message was edited 1 time. Last update was at 15/10/2011 22:38:20

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

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

oi,

Uma empresa é feita de pessoas, um projeto é feito por pessoas.

Um gerente - seja de projetos, seja de qualquer outra coisa - deveria saber motivar pessoas, gerenciar conflitos, tirar o melhor de cada um.

Mais ou menos como um técnico de um time de futebol.

Bom, essa pra mim é deveria ser a principal função de um gerente, mas infelizmente eu não tenho visto muito isso por ai..

abs

André Fonseca wrote:oi,

Uma empresa é feita de pessoas, um projeto é feito por pessoas.

Um gerente - seja de projetos, seja de qualquer outra coisa - deveria saber motivar pessoas, gerenciar conflitos, tirar o melhor de cada um.

Mais ou menos como um técnico de um time de futebol.

Bom, essa pra mim é deveria ser a principal função de um gerente, mas infelizmente eu não tenho visto muito isso por ai..

abs

Eai André, blz?

Além disso, vc tb defende q um GP deveria ser tecnico, ou ter um mínimo de conhecimento técnico?

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1617 Offline

andredecotia wrote: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...

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:

tomar decisões técnicas, ou influenciar decisões técnicas

estabelecer processos, artefatos

levantar requisitos

priorizar requisitos

estabelecer prazos (estimar é diferente)

controlar a equipe

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

andredecotia wrote:

André Fonseca wrote:oi,

Uma empresa é feita de pessoas, um projeto é feito por pessoas.

Um gerente - seja de projetos, seja de qualquer outra coisa - deveria saber motivar pessoas, gerenciar conflitos, tirar o melhor de cada um.

Mais ou menos como um técnico de um time de futebol.

Bom, essa pra mim é deveria ser a principal função de um gerente, mas infelizmente eu não tenho visto muito isso por ai..

abs

Eai André, blz?

Além disso, vc tb defende q um GP deveria ser tecnico, ou ter um mínimo de conhecimento técnico?

oi,

Então, não necessariamente

Na minha opinião a característica mais importante do GP deve ser a de lidar com pessoas

Claro que estas pessoas estão voltadas para o ambiente de TI.

Então ele deve saber: motivar a equipe, resolver conflitos, lidar com as expectativas do cliente, cobrar outras áreas da empresa, etc

Ele deve sim ser capaz de tomar decisões rápidas relativas ao projeto, mas não necessariamente ele precisa ser um técnico desde que ele conheça as pessoas certas para ajudá-lo a tomar estas decisões

abs

rmendes08 wrote:

andredecotia wrote: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...

Não acho que GP tenha que conhecer muuuito mais sobre regra de negócios do que um desenvolvedor...

Jóinha?
Vc explicar melhor isso:

analista de projeto tem que colher métricas e saber quando usar síntese/análise,

só.
?
abs,

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1617 Offline

andredecotia wrote:

rmendes08 wrote:

andredecotia wrote: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...

Não acho que GP tenha que conhecer muuuito mais sobre regra de negócios do que um desenvolvedor...

Jóinha?
Vc explicar melhor isso:

analista de projeto tem que colher métricas e saber quando usar síntese/análise,

só.
?
abs,

Explico. O objetivo da gerência de projetos é fazer com que o projeto seja entregue em um determinado prazo com um custo limite. Entregar no prazo e com o mínimo custo depende, exclusivamente, da equipe que executa o projeto, e essa equipe precisa colher métricas e obter informações para acompanhar o andamento do projeto, de forma que ela possa embasar melhor suas decisões. É esse o papel que o analista de projetos deve exercer, ele deve saber quais métricas colher, como colher e deve saber sintetizar isso para que a equipe e outros stakeholders possam avaliar o projeto. A equipe pode aproveitar-se dessa informação para concluir que existem tempo para um refactoring na arquitetura para ganhar velocidade no médio prazo, o cliente pode usar dessa informação para decidir se continua ou não investindo. Por exemplo, vamos supor que os desenvolvedores tenham que lançar horas trabalhadas em cada requisito. Não adianta o analista de projetos apresentar uma planilha dessas para o investidor e esperar que ele leia linha por linha. Ele tem que saber resumir essa informação em um gráfico por exemplo, e extrair desse gráfico a informação de custo acumulado do projeto.

JavaTeenager Membro desde: 08/10/2011 13:21:59 Mensagens: 150 Offline

Excel.

JavaTeenager Membro desde: 12/08/2011 12:07:45 Mensagens: 190 Offline

rmendes08 wrote:

andredecotia wrote: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...

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:

tomar decisões técnicas, ou influenciar decisões técnicas
estabelecer processos, artefatos
levantar requisitos
priorizar requisitos
estabelecer prazos (estimar é diferente)
controlar a equipe

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.

JavaTeenager Membro desde: 12/08/2011 12:07:45 Mensagens: 190 Offline

vargas wrote:Excel.

Não sei se foi o caso, mas acho engraçado como o pessoal trata o excel como forma pejorativa.

Acho engraçado porque se conhecessem o poder do excel e soubessem realmente utilizá-lo pensariam duas vezes antes de falar isto: quase toda a pesquisa operacional até mesmo com MCDA pode ser feita em cima do solver do excel, assim como praticamente qualquer simulação estatística, o povo normalmente utiliza ferramental para fazer análise de risco e cálculos atuariais, mas ele pode ser feito exclusivamente com o excel. E ainda dá pra juntar tudo, fazer um MCDA com uma simulação de Monte Carlo e VME a partir da análise de probabilidadeximpacto de riscos com análise financeira de VPL, TIR e payback para um problema atuarial, altíssima complexidade.

há várias habilidades importantes, uma só nao define um bom gerente de projetos....

eu diria que para cada equipe/projeto, há um melhor de gerente de projetos com suas habilidades...

pois cada projeto/equipe requer um GP com habilidades diferentes.

This message was edited 1 time. Last update was at 17/10/2011 07:28:50

felipefranz wrote:

vargas wrote:Excel.

Não sei se foi o caso, mas acho engraçado como o pessoal trata o excel como forma pejorativa.

Acho engraçado porque se conhecessem o poder do excel e soubessem realmente utilizá-lo pensariam duas vezes antes de falar isto: quase toda a pesquisa operacional até mesmo com MCDA pode ser feita em cima do solver do excel, assim como praticamente qualquer simulação estatística, o povo normalmente utiliza ferramental para fazer análise de risco e cálculos atuariais, mas ele pode ser feito exclusivamente com o excel. E ainda dá pra juntar tudo, fazer um MCDA com uma simulação de Monte Carlo e VME a partir da análise de probabilidadeximpacto de riscos com análise financeira de VPL, TIR e payback para um problema atuarial, altíssima complexidade.

Nossa! Vc falou "bonito" que nem meu professor agora rs...

abs,

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1617 Offline

felipefranz wrote:

rmendes08 wrote:

andredecotia wrote: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...

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:

tomar decisões técnicas, ou influenciar decisões técnicas
estabelecer processos, artefatos
levantar requisitos
priorizar requisitos
estabelecer prazos (estimar é diferente)
controlar a equipe

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.

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.

JavaTeenager Membro desde: 12/08/2011 12:07:45 Mensagens: 190 Offline

Estas discussões são boas rmendes08, mas estamos falando agora praticamente a mesma coisa:

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.

R: Concordo, e o gerente normalmente tem que aprovar a decisão ao apresentar o plano de projeto, se a mudança ocorrer depois, solicitação de mudança neles para evitar scope creep. Até a 3ª edição, o próprio PMBOK falava que o GP não precisava de conhecimento técnico, na 4ª ela voltou atrás, deve ter dado uma boa olhada principalmente na área de TI por questões como esta.

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.

No caso, estava falando dos artefatos que o próprio GP precisa preencher, claro que os desenvolvedores também tem que preencher artefatos e sempre deve valer o bom senso. Gerenciar as expectativas dos stakeholders é o principal processo dentro da gestão de projetos ao meu ver, e um dos stakeholders mais importantes, senão o principal é a equipe. Este é um assunto engraçado, porque muitas pessoas quando vão gerenciar projetos se decepcionam, maior parte do trabalho é comunicar-se e escrever para deixar a equipe focada no core business que é desenvolvimento/análise e facilite seu trabalho com os artefatos.

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.

Todo GP deveria ser líder, mas nem todo líder é GP e muitos GP's nem ao menos esforçam-se para liderar. Este é um problema muito sério, na maioria dos casos perde-se um excelente técnico e ganha-se um péssimo gestor. A carreira Y é bastante problemática no país, o investimento em P&D é irrisório.

No fim, eu defendo a velha máxima que deve-se fazer o que gosta, sua chance de ser bom e conquistar um salário assim é maior do que mudando-se para uma "área promissora", salvo algumas exceções. O que tem de gente se decepcionando depois sai da área técnica e vira GP não é pouco e aí o cara e a empresa perdem. Na área técnica afastar-se dois meses é quase suicídio. E voltando a questão do GP necessitar uma formação técnica na área específica, ela é especialmente forte na área de TI, porque muitas pessoas simplesmente não conseguem respeitar um cara sem qualquer formação técnica na equipe ou ainda pior, hierarquicamente superior, soma-se isto ao mito da disfunção burocrática da gestão de projetos e o monstro esta completo.

Mais odiado que GP só auditor

Notícias, artigos e o maior fórum brasileiro sobre Java