Gerente e gerente projeto

Jr R$ 2000,00 + ou -

Nossa! Pouco…

Abraço

PMP Júnior me parece uma contradição de termos

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

PMP Júnior me parece uma contradição de termos

Se o sujeito acaba de tirar a certificação ou acaba de se formar e não tem experiência…
É jr…

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

PMP Júnior me parece uma contradição de termos

Se o sujeito acaba de tirar a certificação ou acaba de se formar e não tem experiência…
É jr…

E como é alguem tira uma PMP sem ter experiência em gerência?

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

O PMI não diz respeito sobre a metodologia de desenvolvimento, e sim sobre a metodologia de gestão. Você pode aplicar o PMI em projetos totalmente ágeis, pois como o próprio PMBook diz, ele é um guia de boas práticas. Logo você pode utilizar somente os métodos que condizem com o seu tipo de projeto.

Pra você ser elegível a fazer a prova de PMP, você deve ter 4500 horas de gestão de projetodos nos 5 “Process Groups” caso seja Graduado, caso tenha apenas o ensino médio, o total de horas sobe para 7500. Em ambos os casos você deve ter no mínimo 35 horas de cursos/treinamento em gestão de projetos.
Ou seja, gerente júnior, só se for na competência.

deniswsrosa:

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

O PMI não diz respeito sobre a metodologia de desenvolvimento, e sim sobre a metodologia de gestão. Você pode aplicar o PMI em projetos totalmente ágeis, pois como o próprio PMBook diz, ele é um guia de boas práticas. Logo você pode utilizar somente os métodos que condizem com o seu tipo de projeto.

Pra você ser elegível a fazer a prova de PMP, você deve ter 4500 horas de gestão de projetodos nos 5 “Process Groups” caso seja Graduado, caso tenha apenas o ensino médio, o total de horas sobe para 7500. Em ambos os casos você deve ter no mínimo 35 horas de cursos/treinamento em gestão de projetos.
Ou seja, gerente júnior, só se for na competência.

E apesar de tantas horas de “experiência” tem MUITA gente incompetente exibindo essa certificação.

Jovem,

Isso vai depender muito da empresa e o nivel de conhecimento do Gestor. Mas a faixa salarial está entre R$ 7.500,00 á R$ 12.000,00.

Abs,

Uma área promissora…

Kanin Dragon:

Jovem,

Isso vai depender muito da empresa e o nivel de conhecimento do Gestor. Mas a faixa salarial está entre R$ 7.500,00 á R$ 12.000,00.

Abs,

Exatamente a média de salário de um desenvolvedor sênior / arquiteto. Acho que vale mais a pena desenvolver…

drsmachado:

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

Isso é coisa de maus gerentes de projeto.
Um bom gerente de projeto (que usa o PMI) está envolvido em todo processo. Pode até perguntar se está pronto, mas tem ciência da capacidade e da dificuldade de cada recurso.
Ele tem conhecimento de todos os envolvidos (stackholders), dos prazos, dos riscos e de tudo que envolve o projeto.

x2

E digo mais: isso de falar que um gerente de projeto só sabe perguntar se está pronto ou não é típico de quem nunca trabalhou com um gerente de projetos decente. Sem contar que ter ou não ter um gerente de projeto e usar metodologias ágeis não são fatos mutuamente excludentes.

[]'s

asaudate:

drsmachado:

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

Isso é coisa de maus gerentes de projeto.
Um bom gerente de projeto (que usa o PMI) está envolvido em todo processo. Pode até perguntar se está pronto, mas tem ciência da capacidade e da dificuldade de cada recurso.
Ele tem conhecimento de todos os envolvidos (stackholders), dos prazos, dos riscos e de tudo que envolve o projeto.

x2

E digo mais: isso de falar que um gerente de projeto só sabe perguntar se está pronto ou não é típico de quem nunca trabalhou com um gerente de projetos decente. Sem contar que ter ou não ter um gerente de projeto e usar metodologias ágeis não são fatos mutuamente excludentes.

[]'s

Assino em baixo, e ainda carimbo.

Sem falar que deve-se sempre levar em conta os processos da empresa. Ninguém usa todos os (se não me engano 42) processos do PMI. É um guia de boas práticas, você usa aquilo que é aderente aos seus processos e aquilo que trará melhorias.

Agora o que eu acho incrível é como estão vendendo “Agile” como se fosse bala de prata, uma classe salvadora de problemas com modificador final :roll:

EDIT: Pra quem não sabe, o PMI irá lançar uma certificação para gerenciamento de projetos ágeis, com práticas e processos diretamente voltados pra esse tipo de metodologia.

Falaram tudo, muita gente não entende que PMBok não é tecnologia, fico feliz que hoje em dia esteja mais desmistificado.

so respondendo ao pessoal que tava falando…

eu ja trabalhei com mais de 5 gerentes certificados em empresas diferentes e nenhum deles usava os ensinamentos do pmbook para nada… nenhuma empresa que tem cmmi 5 e talz segue qualquer coisa… é quase impossivel 90% das vezes é FAKE so para as empresas ganharem licitações … e infelizmente trato com hoje lido com uma equipe de clientes com mais de 5 pmp e pmi, todos so sabem olhar para o project e perguntar se esta pronto?.. ou se quantos % tal tarefa esta pronta sendo que não se tem preocupação nenhuma em entender os problemas de verdade que existem nos projetos… falta vontade de entregar o produto e tal, praticamente cegos.

e para o pessoal que considera as pessoas como “recursos” e não como pessoas tem que estudar o pmp e pmi mesmo , pois e assim que se trata as pessoas nessas filosofias…

com relação a certificação um gerente falou pra mim que é quase como diploma de faculdade pra entra em consultorias, que tem essas certificações tipo cmmi quase como pré requisito,e ele me falou que ele tirou em 1 mes estudando 4 horas por dia… é so seguir o guia de estudo que por acaso é bem menor do que as certificações tecnicas, eles so verificam a experiencia de 1 a cada 10 candidatos… e o pior ele falou que na pratica ele não usava nada do que aprendeu… isso foram as coisas que o único gerente certificado BOM que conheci me contou com sinceridade…

so para fixar é uma opinião pessoal.

Diabo Loiro:

so respondendo ao pessoal que tava falando…

eu ja trabalhei com mais de 5 gerentes certificados em empresas diferentes e nenhum deles usava os ensinamentos do pmbook para nada…

Quantos são os programadores OCJP e quantos utilizam 100% do que aprenderam para a certificação?
E quantos utilizam qualquer coisa?

É bem mais complexo que isto, vai de pessoa para pessoa.

E, respondendo a pergunta, com certeza, bem mais que eu.

Hum legal ver os pontos de vista… Muito bacana…

Estou pensando seriamente nessa carreira gosto…

Diabo Loiro:

so respondendo ao pessoal que tava falando…

eu ja trabalhei com mais de 5 gerentes certificados em empresas diferentes e nenhum deles usava os ensinamentos do pmbook para nada… nenhuma empresa que tem cmmi 5 e talz segue qualquer coisa… é quase impossivel 90% das vezes é FAKE so para as empresas ganharem licitações … e infelizmente trato com hoje lido com uma equipe de clientes com mais de 5 pmp e pmi, todos so sabem olhar para o project e perguntar se esta pronto?.. ou se quantos % tal tarefa esta pronta sendo que não se tem preocupação nenhuma em entender os problemas de verdade que existem nos projetos… falta vontade de entregar o produto e tal, praticamente cegos.

e para o pessoal que considera as pessoas como “recursos” e não como pessoas tem que estudar o pmp e pmi mesmo , pois e assim que se trata as pessoas nessas filosofias…

com relação a certificação um gerente falou pra mim que é quase como diploma de faculdade pra entra em consultorias, que tem essas certificações tipo cmmi quase como pré requisito,e ele me falou que ele tirou em 1 mes estudando 4 horas por dia… é so seguir o guia de estudo que por acaso é bem menor do que as certificações tecnicas, eles so verificam a experiencia de 1 a cada 10 candidatos… e o pior ele falou que na pratica ele não usava nada do que aprendeu… isso foram as coisas que o único gerente certificado BOM que conheci me contou com sinceridade…

so para fixar é uma opinião pessoal.

Falou tudo. Pra não falar que todos gerentes que eu trabalhei eram péssimos profissionais, teve uma gerente que achei ela fantástica - ela também era certificada. Mas a grande maioria, é exatamente o que vc falou e, infelizmente, as consultorias ( BRQ, Dedic GPTI, CPM, Stefanini e afins ) tratam os funcionários como meros recursos.

Diabo Loiro:

e infelizmente trato com hoje lido com uma equipe de clientes com mais de 5 pmp e pmi, todos so sabem olhar para o project e perguntar se esta pronto?.. ou se quantos % tal tarefa esta pronta sendo que não se tem preocupação nenhuma em entender os problemas de verdade que existem nos projetos… falta vontade de entregar o produto e tal, praticamente cegos.

Mas isso não eh culpa do PMP/PMI/PMBOK

Não se esqueçam de que o PMBOK não é um livro de gerenciamento de projetos de TI.

Tudo que está sendo falado aqui se refere a gerentes de projetos de TI, e no nosso universo sabemos que tem uma palavrinha mágica que todos gerentes evitam ao máximo mas ela sempre vence: Mudança.

Por isso tudo que é muito engessado via de regra não dá muito certo em TI, mas acredito que as práticas do PMBOK devem ser aplicadas com sucesso em outras áreas de atuação.

Vejam que não estou falando que não são aplicadas com sucesso também em TI, mas eu até hoje não vi. Mas concordo que boa parte dos problemas tem origem nos gerentes e não no livro.

Maracuja:

andredecotia:

Hum legal ver os pontos de vista… Muito bacana…

Estou pensando seriamente nessa carreira gosto…

Minha opiniao:

Entao use pelo menos uns 10 anos desenvolvendo sistemas, depois tente focar em gerencia (e sempre estude mto) se e o que vc quer. Vi poucos gerentes com mta experiencia em desenvolvimento serem ruins, mas vi muitos gerentes sem essa experiencia serem ruins.

[]`s

Concordo plenamente!

A menos que queira ser um gerente ruim (ou seja O padrão do mercado).

Uma das coisas que discordo em muito do PMBook é que no geral, um gestor de projetos seria teoricamente capaz de coordenar qualquer tipo de projeto, desde desenvolvimento de software à construção civil, o que na prática sabemos que é totalmente desaconcelhável.

Na verdade boa parte dos maus gerentes são em geral pessoas com pouca vivência ma área de TI, entenda “pouca vivência” como poucas diversidades de situações, de nada adianta um cara ter 15 anos na área de TI se sempre trabalhou em uma mesma empresa no ritmo de empresas públicas.

Nada contra quem faz isso, mas o que se espera de um bom gerente é que ele tenha vivido dezenas de situações semelhantes e saiba exatamente as consequencias de cada decisão. Posso falar com autoridade de que os projetos em que mais aprendi sobre gestão foram justamente os piores projetos que trabalhei, pois eu na minha posição de desenvolvedor pago na pele o preço de decisões erradas de gestão.

E o mercado dá muito valor a sua “experiência”, não importa o quanto você conheça sobre gestão de projetos e etc, nesse caso a idade pesa bastante. Dificilmente vi empresas contratando gestores com menos de 28… 29 anos.

Mesmo que o “jovem” seja muito capaz, acabam por escolher alguns Baby Boomers que pararam no tempo das primeiras versões do Fortran e Cobol.

Independente de certificações creio que isso seja uma realidade bem constante em vários segmentos. Eu mesmo já tive o desprazer de conviver com uma gerente de projetos certificada em PMP da qual só fazia perguntar: “está pronto?”, mas também já conheci bons gerentes que realmente controlavam o projeto e não apenas o seu prazo.

Também sou descrente no que tange as certificações de empresas como ISO 20000, cmmi, etc. Não necessariamente pelo cumprimento de suas normas, mas até mesmo, na elaboração e na proposta de tais certificações que engessam os trabalhos.

Também acho que metodologias ágeis podem ser uma boa, pelo a proposta é mais interessante.

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Cara ai é o ponto amigo… voce ganha estudando para a certificação aprendendo e não pegando colecionando como se fosse medalhas de honra da guerra. …

É muito legal ter um objetivo estudar por meses ser testado e receber um certificado por se especializar em uma área ?ESPECIFICA? por exemplo sintaxe do java,web services, etc…

geralmente pelo menos em sp as empresas colocam nas vagas “desejável certificações” pois geralmente o pessoal é mais esforçado e da um destaque,visto que java é uma das linguagens mais complexas e completa que se tem no mercado.

Pega um cara que sai da faculdade e poe ele em um projeto com codigo legado? Saber pelo menos a api do java, conhecer a linguagem, já é um grande adianto…

Outro ponto é que por exemplo uma certificação técnica como por exemplo SCJP so significa que o programador conhece a api do java… e se o cara for trabalhar com php ou ruby não vai valer nada… então você conclui que SCJP é uma certificação especifica para uma tecnologia… e no dia a dia de um programador java voce geralmente usa as coisas que aprendeu estudando.

o Fato é que o PMP é genericasso como nosso amigo falou pela teoria dos caras podia ser usado pra construção civil etc… o que é totalmente diferente de um projeto de software, por tanto a probabilidade de você não usar nada do que “aprendeu” estudando para PMP é alta… é melhor você estudar um guia especifico para software ou especifico para construção civil considerando as diferenças técnicas, do que ficar decorando textos do study guide do pmp sendo que provavelmente n vai usar.

Hoje qualquer um tem PMP é praticamente pre requisito de empresas grandes.

E outra a gerencia é um assunto que depende de cada empresa… diferente da sintaxe JAVA scjp que não vai mudar ou ficar variando.

e só reforçando… não vão colocar qualquer novato só por que tem pmp em um projeto de risco sem no minimo ter anos de experiencia…

por isso pensa bem cara… pessoal novo tem que ser bom tecnicamente para no futuro ser um bom gerente ou arquiteto.

andredecotia:

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Você teria que demonstrar as milhares de horas experiência gerenciando projetos para tirar essa certificação, então te aconselho a focar na carreira técnica por mais um (bom) tempo.

não nescessariamente, é simples burlar isso e muita gente faz.

não nescessariamente, é simples burlar isso e muita gente faz.

Pouts… por favor, não comente como burlar, pois se já tem gerente ruim “com experiência”, sem então…

andredecotia:

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Uma emprresa é formada por pessoas, não por robôs. Se você quer ganhar mais, tem que merecer isso. E “merecer” independe de quantos certificados você tem.

[]'s

Conheci alguns PMPs e única constante que notei em todos é a seguinte frase de efeito:

“ESTÁ PRONTO ?” Passasse 15 minutos e novamente o tal PMP certificado chega na nossa mesa e diz as palavras
mágicas: “ESTÁ PRONTO ?” Passasse mais 20 minutos e adivinha quem voltou ? Sim sim, novamente o PMP
perguntando: “ESTÁ PRONTO ?”

Fico imaginando porque as empresas não contratam de uma vez um PAPAGAIO, porque um papagaio
pode repetir ESTÁ PRONTO N vezes seguidas, e o melhor, a empresa não precisaria pagar mais de 7K para
um cara que só sabe repetir ESTÁ PRONTO ?

não nescessariamente, é simples burlar isso e muita gente faz.

Já foi mais simples, cada dia tem mais gente caindo na auditoria, daí a coisa fica feia.

Não é isso que ele diz, o PMBok (um único “o”) lista as práticas comuns a todos os projetos, mas deixa claro que conhecer as práticas é um requisito, mas saber usá-las é mais importante e isso o PMBok deixa claro que não cobre.

Gerente do tipo “está pronto?” tem em todos os lugares, independente de certificação. Bons gerentes são difícies de encontrar, independente de serem de TI ou não. PMI não faz milagre, mas pelo menos na minha experiência é mais fácil encontrar profissionais melhores entre os PMPs do que fora deles.

johnny quest:

Conheci alguns PMPs e única constante que notei em todos é a seguinte frase de efeito:

“ESTÁ PRONTO ?” Passasse 15 minutos e novamente o tal PMP certificado chega na nossa mesa e diz as palavras
mágicas: “ESTÁ PRONTO ?” Passasse mais 20 minutos e adivinha quem voltou ? Sim sim, novamente o PMP
perguntando: “ESTÁ PRONTO ?”

Fico imaginando porque as empresas não contratam de uma vez um PAPAGAIO, porque um papagaio
pode repetir ESTÁ PRONTO N vezes seguidas, e o melhor, a empresa não precisaria pagar mais de 7K para
um cara que só sabe repetir ESTÁ PRONTO ?

Uma coisa que fico impressionado, e o nivel dos gerentes no geral, pois para contratar um desenvolvedor existem centenas de procedimentos e provas, e para gerentes, a contratação e no papo.

Chueguei a conhecer gerentes que não sabem mexer no project!!! E como se nos nao soubéssemos mexer no eclipse/netbeans.

andredecotia:

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Serei extremamente sincero no que direi adiante:

Manifesto um nojo profundo dessa linha de pensamento.
Certificação e carreira simplesmente por progressão salarial faz com que pessoas sem o menor tino/feeling/talento para o negócio ingressem nessas áreas e façam cagadas.
Não digo isso só para a área de gerência não, já trabalhei com muito desenvolvedor/arquiteto incompetente e burro (prontofalei), que não deveriam jamais ter entrado na área de TI.

E digo mais, uma frase muito boa que ouvi/li esses dias (só não me recordo de onde):
_para identificar o erro de um desenvolvedor você o faz no próximo deploy, o erro de um gerente/diretor só daqui a 6 meses pelo menos.

Lembrando também que existe uma diferença abismal entre chefe(gerente, coordenador, diretor) e líder.
Tive muitos chefes e pouquíssimo líderes, conto apenas dois na verdade (é um número muito grande na realidade atual) pelos quais eu cumpria qualquer missão.

Resumindo, discussões salariais por certificações e divagações de ingresso na área puro e simplesmente por dinheiro é patético.

Tchello:

Lembrando também que existe uma diferença abismal entre chefe(gerente, coordenador, diretor) e líder.
Tive muitos chefes e pouquíssimo líderes, conto apenas dois na verdade (é um número muito grande na realidade atual) pelos quais eu cumpria qualquer missão.

Um dos fatores, aliás, que eu considero causa do péssimo estado em que o desenvolvimento de software está.

[]'s

Tchello:

andredecotia:

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Serei extremamente sincero no que direi adiante:

Manifesto um nojo profundo dessa linha de pensamento.
Certificação e carreira simplesmente por progressão salarial faz com que pessoas sem o menor tino/feeling/talento para o negócio ingressem nessas áreas e façam cagadas.
Não digo isso só para a área de gerência não, já trabalhei com muito desenvolvedor/arquiteto incompetente e burro (prontofalei), que não deveriam jamais ter entrado na área de TI.

E digo mais, uma frase muito boa que ouvi/li esses dias (só não me recordo de onde):
_para identificar o erro de um desenvolvedor você o faz no próximo deploy, o erro de um gerente/diretor só daqui a 6 meses pelo menos.

Lembrando também que existe uma diferença abismal entre chefe(gerente, coordenador, diretor) e líder.
Tive muitos chefes e pouquíssimo líderes, conto apenas dois na verdade (é um número muito grande na realidade atual) pelos quais eu cumpria qualquer missão.

Resumindo, discussões salariais por certificações e divagações de ingresso na área puro e simplesmente por dinheiro é patético.

Sim, fato.

Há Analistas de Sistemas que tem habilidades tecnicas que sobressem à programação, estes, teriam o potencial de cargos de gerência, este é o tipo de profissional base à questão
levantada:

andredecotia wrote:
Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

É a velha discussão do “como é” contra o “como eu gostaria que fosse”.

rs Adoro tais discussões, n opiniões…

Só para apimentar mais a questão: Alguém aqui caso recebe tal proposta, promoção à PMP, aceitaria?! E pq?

andredecotia:

rs Adoro tais discussões, n opiniões…

Só para apimentar mais a questão: Alguém aqui caso recebe tal proposta, promoção à PMP, aceitaria?! E pq?

Não entendi a pergunta. Não tem como ser promovido à PMP. PMP é uma certificação pra gerentes de projetos, você faz uma prova e os projetos que você coordenou são avaliados. E a cada 2 anos eles revisam e atualizam as práticas, ou você precisa fazer outra prova, ou precisa participar de eventos pra manter-se atualizado sob o risco de perder o título.

O que acontece é que tem empresas que condicionam a vaga de serviço à certificação. Ou condicionam o aumento de salário a ela. É opção da empresa, algumas trabalham assim outras ignoram. Concordando ou não é direito delas. Se a pergunta é caso alguém certificado tivesse uma proposta de salário melhor devido à certificação, por que não?

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

Não julgo dessa forma. Existem profissionais e profissionais. Pode ser que vc conheça um PMP que não acrescente nada ao projeto, mas a certificação é muito legal de tirar.
Outra coisa: é possível aplicar “algo ágil” no PMP… Se vc der uma olhada, muitas empresas atualmente tentam juntar os 2, melhorando seus processos e práticas. É possível realizar adaptações!!!

Maracuja:

So para que conste aqui, ja que estamos falando de PMP e salario e etc. Vou dar um exemplo, no momento estou trabalhando em um projeto em que tem um colega que tem PMP mas esta trabalhando como tecnico e nao como gerente, ele tem pelo menos uns 15 anos de XP e falou que no geral, paga-se melhor para um bom tecnico do que para um gerente por aqui. (Canada) E por isso ele tem optado por trabalhar como tecnico.

[]`s

Mas, qual é o “gramour” de ser um técnico?
Quando se é gerente, se tem subordinados e se tem a (as vezes falsa) impressão de poder, e é isso que a maioria da molecada que entra na carreira de TI por dinheiro quer…
É triste, mas é real.
Conheci um sem número de pessoas que me falaram isso.

E eu também entro no time de “tive muitos gerentes mas só 1 foi bom”
Agora, líderes eu já tive o prazer de trabalhar com alguns muito bons. Você até esquece que tem gerente nessas horas.

clone_zealot:

E eu também entro no time de “tive muitos gerentes mas só 1 foi bom”
Agora, líderes eu já tive o prazer de trabalhar com alguns muito bons. Você até esquece que tem gerente nessas horas.

Esses são difíceis de encontrar, os poucos com essas qualidades são caros e já estão empregados. Então sobra o tipo que são comuns e que todo mundo já falou. Outro agravante é que formar líderes é bem mais difícil que formar um técnico, então as empresas tem de se virar com o que tem mesmo, não tem muita saída.

clone_zealot:

Maracuja:

So para que conste aqui, ja que estamos falando de PMP e salario e etc. Vou dar um exemplo, no momento estou trabalhando em um projeto em que tem um colega que tem PMP mas esta trabalhando como tecnico e nao como gerente, ele tem pelo menos uns 15 anos de XP e falou que no geral, paga-se melhor para um bom tecnico do que para um gerente por aqui. (Canada) E por isso ele tem optado por trabalhar como tecnico.

[]`s

Mas, qual é o “gramour” de ser um técnico?
Quando se é gerente, se tem subordinados e se tem a (as vezes falsa) impressão de poder, e é isso que a maioria da molecada que entra na carreira de TI por dinheiro quer…
É triste, mas é real.
Conheci um sem número de pessoas que me falaram isso.

Exatamente, cai na linha de pensamento idiota que o brasileiro tem de que vencer na vida é virar chefe e ficar mandando.
Já disse que tenho nojo disso?

Tchello:

andredecotia:

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Serei extremamente sincero no que direi adiante:

Manifesto um nojo profundo dessa linha de pensamento.
Certificação e carreira simplesmente por progressão salarial faz com que pessoas sem o menor tino/feeling/talento para o negócio ingressem nessas áreas e façam cagadas.
Não digo isso só para a área de gerência não, já trabalhei com muito desenvolvedor/arquiteto incompetente e burro (prontofalei), que não deveriam jamais ter entrado na área de TI.

E digo mais, uma frase muito boa que ouvi/li esses dias (só não me recordo de onde):
_para identificar o erro de um desenvolvedor você o faz no próximo deploy, o erro de um gerente/diretor só daqui a 6 meses pelo menos.

Lembrando também que existe uma diferença abismal entre chefe(gerente, coordenador, diretor) e líder.
Tive muitos chefes e pouquíssimo líderes, conto apenas dois na verdade (é um número muito grande na realidade atual) pelos quais eu cumpria qualquer missão.

Resumindo, discussões salariais por certificações e divagações de ingresso na área puro e simplesmente por dinheiro é patético.

x__________________________

Eu discordo um pouco da linha de pensamento de vocês.

O cara para ser um bom gerente não tem que necessariamente ter sido um bom técnico, as habilidades interpessoais são muito mais importantes para um gerente de projetos que as habilidades técnicas, ele tem que ter uma boa noção, mas não conhecimento específico e das legislações pertinentes a sua área de atuação.

O que mais acontece é a empresa perder um bom técnico e arrumar um péssimo gestor. O problema é que dificilmente gerentes de projeto tem formação em gestão, só tiram a certificação PMBOK que não dá formação alguma, para ser um bom gerente de projetos é imprescindível conhecer as áreas de psicologia motivacional/RH, finanças, marketing, gestão da qualidade e aplicá-las de fato.

Aliás, a maior parte do trabalho de um gerente de projetos está em gerenciar a expectativa dos stakeholders, isso é puramente comunicação. E é bastante difícil encontrar um bom técnico que se comunique bem, questão de perfil mesmo.

felipefranz:

Eu discordo um pouco da linha de pensamento de vocês.

O cara para ser um bom gerente não tem que necessariamente ter sido um bom técnico, as habilidades interpessoais são muito mais importantes para um gerente de projetos que as habilidades técnicas, ele tem que ter uma boa noção, mas não conhecimento específico e das legislações pertinentes a sua área de atuação.

O que mais acontece é a empresa perder um bom técnico e arrumar um péssimo gestor. O problema é que dificilmente gerentes de projeto tem formação em gestão, só tiram a certificação PMBOK que não dá formação alguma, para ser um bom gerente de projetos é imprescindível conhecer as áreas de psicologia motivacional/RH, finanças, marketing, gestão da qualidade e aplicá-las de fato.

Destaquei a parte vital do seu comentário.
Note que ele deve sim ter boa noção, não exigimos que eles saibam cada detalhe de implementação do produto ou de uma linguagem/framework.
Ter uma noção é essencial.

Mas acima disso tudo, de qualquer coisa, é ter humildade de bom senso.

Com isso temos a base para construir a confiança recíproca do time com o gerente/whatever. Note na reciprocidade.

A grande maioria (senão todos) dos gerentes dizem confiar na sua equipe mas exigem uma centenas de documentos e processos burocráticos.
Esses processos e exigências exageradas nada mais são como uma manifestação de insegurança.
Insegurança essa gerada justamente pela falta de confiança.

Perceberam como tudo se encaixa?

Um bom time, além de conter bons desenvolvedores ( o que não inclui somente skills técnicas, mas easygoing person e principalmente bom senso), possui uma equipe que trabalhe efetivamente como equipe. Um bom time tem consciência de unidade, do que o define como um time, uma equipe, uma empresa.

Note que não restrinjo as observações para o time, mas para a empresa. O comprometimento não deve se restringir a esse sub-domínio, mas deve ser recíproco (de novo).
Mesmo que o cliente seja um pé no saco, das portas pra dentro da empresa somos um só, de novo, uma unidade.

Caraca, empolguei nessa resposta.

Tchello:

felipefranz:

Eu discordo um pouco da linha de pensamento de vocês.

O cara para ser um bom gerente não tem que necessariamente ter sido um bom técnico, as habilidades interpessoais são muito mais importantes para um gerente de projetos que as habilidades técnicas, ele tem que ter uma boa noção, mas não conhecimento específico e das legislações pertinentes a sua área de atuação.

O que mais acontece é a empresa perder um bom técnico e arrumar um péssimo gestor. O problema é que dificilmente gerentes de projeto tem formação em gestão, só tiram a certificação PMBOK que não dá formação alguma, para ser um bom gerente de projetos é imprescindível conhecer as áreas de psicologia motivacional/RH, finanças, marketing, gestão da qualidade e aplicá-las de fato.

Destaquei a parte vital do seu comentário.
Note que ele deve sim ter boa noção, não exigimos que eles saibam cada detalhe de implementação do produto ou de uma linguagem/framework.
Ter uma noção é essencial.

Mas acima disso tudo, de qualquer coisa, é ter humildade de bom senso.

Com isso temos a base para construir a confiança recíproca do time com o gerente/whatever. Note na reciprocidade.

A grande maioria (senão todos) dos gerentes dizem confiar na sua equipe mas exigem uma centenas de documentos e processos burocráticos.
[b]Esses processos e exigências exageradas nada mais são como uma manifestação de insegurança.
Insegurança essa gerada justamente pela falta de confiança.
[/b]
Perceberam como tudo se encaixa?

Um bom time, além de conter bons desenvolvedores ( o que não inclui somente skills técnicas, mas easygoing person e principalmente bom senso), possui uma equipe que trabalhe efetivamente como equipe. Um bom time tem consciência de unidade, do que o define como um time, uma equipe, uma empresa.

Note que não restrinjo as observações para o time, mas para a empresa. O comprometimento não deve se restringir a esse sub-domínio, mas deve ser recíproco (de novo).
Mesmo que o cliente seja um pé no saco, das portas pra dentro da empresa somos um só, de novo, uma unidade.

Caraca, empolguei nessa resposta.

Nada a haver essa frase: [i]Esses processos e exigências exageradas nada mais são como uma manifestação de insegurança.
Insegurança essa gerada justamente pela falta de confiança[/i].

Isso faz parte da governança corporativa, o gerente do projeto não te pede documentos porque quer ter um overhead de controle, normalmente ele precisa prestar conta para o dono do negócio. Se a empresa fosse sua, você gostaria de saber exatamente o que está acontecendo, para isso ele tem que alimentar o EVA, Tir, Payback e precisa de informações de controle, não quer dizer que não confia na sua equipe, nem tudo são prazos.

Claro que um bom gerente de projetos não vai colocar todos os processos do PMBOK, mais tudo que leu no PRINCE2 e tentar colocar isso de forma ágil, ele precisa saber adaptar e verificar o que é mais crítico para a empresa, com a colaboração dos desenvolvedores e gerentes.

felipefranz:

Nada a haver essa frase: [b]Esses processos e exigências exageradas nada mais são como uma manifestação de insegurança.
Insegurança essa gerada justamente pela falta de confiança..

Isso faz parte da governança corporativa, o gerente do projeto não te pede documentos porque quer ter um overhead de controle, normalmente ele precisa prestar conta para o dono do negócio. Se a empresa fosse sua, você gostaria de saber exatamente o que está acontecendo, para isso ele tem que alimentar o EVA, Tir, Payback e precisa de informações de controle, não quer dizer que não confia na sua equipe, nem tudo são prazos.

Claro que um bom gerente de projetos não vai colocar todos os processos do PMBOK, mais tudo que leu no PRINCE2 e tentar colocar isso de forma ágil, ele precisa saber adaptar e verificar o que é mais crítico para a empresa, com a colaboração dos desenvolvedores e gerentes.

Primeiro que Agile e PMI são contraditórios. Uma piada aquela certificação PMI Agile.

Minha opinião continua sendo que o excesso de controle é sim uma manifestação de insegurança.
Mas isso não passa de uma opinião, sinta-se a vontade para discordar. Não quero evangelizar ninguém.

Tchello:

felipefranz:

Nada a haver essa frase: [b]Esses processos e exigências exageradas nada mais são como uma manifestação de insegurança.
Insegurança essa gerada justamente pela falta de confiança..

Isso faz parte da governança corporativa, o gerente do projeto não te pede documentos porque quer ter um overhead de controle, normalmente ele precisa prestar conta para o dono do negócio. Se a empresa fosse sua, você gostaria de saber exatamente o que está acontecendo, para isso ele tem que alimentar o EVA, Tir, Payback e precisa de informações de controle, não quer dizer que não confia na sua equipe, nem tudo são prazos.

Claro que um bom gerente de projetos não vai colocar todos os processos do PMBOK, mais tudo que leu no PRINCE2 e tentar colocar isso de forma ágil, ele precisa saber adaptar e verificar o que é mais crítico para a empresa, com a colaboração dos desenvolvedores e gerentes.

Primeiro que Agile e PMI são contraditórios. Uma piada aquela certificação PMI Agile.

Minha opinião continua sendo que o excesso de controle é sim uma manifestação de insegurança.
Mas isso não passa de uma opinião, sinta-se a vontade para discordar. Não quero evangelizar ninguém.

Agile e PMI não são contraditórios, você provavelmente não leu o PMBOK inteiro se diz isso.

Primeiro que o PMBOK não é uma metodologia e sim um guia de melhores práticas que inclui entre os modelos o desenvolvimento iterativo, por si só isso não tem como ser contraditório com nenhuma prática de gestão de projetos, ainda mais metodologias que não tem nem como comparar. Eles são modelos complementares, isso sempre foi implícito desde a criação do Agile e desenvolvimento de metodologias como XP e SCRUM, mas é algo que muita gente confunde, o problema é que é mal utilizado pela grande maioria das pessoas.

PRINCE2 sim é contraditório a metodologias Agile como SCRUM e XP, embora há como utilizar de forma híbrida.

O PMI-Agile não vejo como uma piada, é um nicho de mercado diante da má utilização do Agile no mundo todo. A pessoa se achava preparada para gerenciar projetos com Scrum depois de dois dias de curso sem realizar uma única prova e comprovar qualquer experiência, se intitulava Scrum Master e colocava SMC no curriculum.

felipefranz:

Agile e PMI não são contraditórios, você provavelmente não leu o PMBOK inteiro se diz isso.

Primeiro que o PMBOK não é uma metodologia e sim um guia de melhores práticas que inclui entre os modelos o desenvolvimento iterativo, por si só isso não tem como ser contraditório com nenhuma prática de gestão de projetos, ainda mais metodologias que não tem nem como comparar. Eles são modelos complementares, isso sempre foi implícito desde a criação do Agile e desenvolvimento de metodologias como XP e SCRUM, mas é algo que muita gente confunde, o problema é que é mal utilizado pela grande maioria das pessoas.

PRINCE2 sim é contraditório a metodologias Agile como SCRUM e XP, embora há como utilizar de forma híbrida.

O PMI-Agile não vejo como uma piada, é um nicho de mercado diante da má utilização do Agile no mundo todo. A pessoa se achava preparada para gerenciar projetos com Scrum depois de dois dias de curso sem realizar uma única prova e comprovar qualquer experiência, se intitulava Scrum Master e colocava SMC no curriculum.

Certamente falamos de pontos de vista e interpretações completamente distintos.
Não falei que PMBOK é metodologia.

De qualquer modo, como diz que Agile tem sido deturpado e falaciosamente utilizado, o mesmo se aplica a qualquer outra metodologia/filosofia ou seja lá como queira chamar.
E digo mais, dai pra dizer que uma certificação é válida para garantir esse compliance é outra falácia. Certificação não prova absolutamente nada.

Digo que é contraditório por que PMI por princípio tem o hábito de centralizar o comando em uma espécie de GP e Agile em sua essência e objetivo supremo não existe GP.
De novo entramos na discussão do controle, da insegurança, etc.

Mas como eu disse anteriormente, isso é uma interpretação pessoal.
Quando me refiro a Agile não estou focando na molecada que se entitula Agile, mas em agile em sí, se me entende.
Argumentar que não funciona pela má utilização é inválido, uma vez que isso se aplica a qualquer metodologia, processo, filosofia, etc…

Tchello:

felipefranz:

Agile e PMI não são contraditórios, você provavelmente não leu o PMBOK inteiro se diz isso.

Primeiro que o PMBOK não é uma metodologia e sim um guia de melhores práticas que inclui entre os modelos o desenvolvimento iterativo, por si só isso não tem como ser contraditório com nenhuma prática de gestão de projetos, ainda mais metodologias que não tem nem como comparar. Eles são modelos complementares, isso sempre foi implícito desde a criação do Agile e desenvolvimento de metodologias como XP e SCRUM, mas é algo que muita gente confunde, o problema é que é mal utilizado pela grande maioria das pessoas.

PRINCE2 sim é contraditório a metodologias Agile como SCRUM e XP, embora há como utilizar de forma híbrida.

O PMI-Agile não vejo como uma piada, é um nicho de mercado diante da má utilização do Agile no mundo todo. A pessoa se achava preparada para gerenciar projetos com Scrum depois de dois dias de curso sem realizar uma única prova e comprovar qualquer experiência, se intitulava Scrum Master e colocava SMC no curriculum.

Certamente falamos de pontos de vista e interpretações completamente distintos.
Não falei que PMBOK é metodologia.

De qualquer modo, como diz que Agile tem sido deturpado e falaciosamente utilizado, o mesmo se aplica a qualquer outra metodologia/filosofia ou seja lá como queira chamar.
E digo mais, dai pra dizer que uma certificação é válida para garantir esse compliance é outra falácia. Certificação não prova absolutamente nada.

Digo que é contraditório por que PMI por princípio tem o hábito de centralizar o comando em uma espécie de GP e Agile em sua essência e objetivo supremo não existe GP.
De novo entramos na discussão do controle, da insegurança, etc.

Mas como eu disse anteriormente, isso é uma interpretação pessoal.
Quando me refiro a Agile não estou focando na molecada que se entitula Agile, mas em agile em sí, se me entende.
Argumentar que não funciona pela má utilização é inválido, uma vez que isso se aplica a qualquer metodologia, processo, filosofia, etc…

Agora entendi seu ponto de vista. Concordo em partes, do meu ponto de vista, gerenciar um projeto é mais que simplesmente o proposto pelas metodologias advindas do Agile, não tem um foco muito grande em vender seu projeto para os stakeholders a iteração é Equipe>Scrum Master>Product Owner>Cliente, nem em prestar contas financeiramente do projeto para o dono do negócio (até daria para implementar um EVA a partir do Burndown Chart, mas tenho visto pouco esta prática), gerenciar contrato e expectativas e egos a todo momento. Não estou falando que Agile não funciona, mas eu particularmente acho que ela faz parte de um contexto maior dentro de um gerenciamento de projetos, não é autosuficiente no paradigma das empresas hoje, talvez um dia seja.

Na verdade, o PMBOK nunca colocou o Gerente de Projeto como centralizador de toda informação, ele é apenas uma pessoa dentro da equipe que tenta evitar o overhead enquanto monitora as expectativas dos stakeholders, boa parte das vezes por falta de estrutura organizacional ele é sim obrigado a tomar conta das nove áreas dentro desta perspectiva, mas o foco vem mudando a cada dia. A parte de comunicação por exemplo é algo que eu sempre criticava por ser top down, da linha gerencial para a equipe, hoje em dia muitas empresas já utilizam o gerenciamento da comunicação bottom up através do uso de mídias sociais como o Enterprise 2.0.

Quanto a certificação, concordo que não é garantia de nada, mas todo recrutador vai procurar garantir ao máximo que o profissional contratado tenha competência para assumir a função e neste contexto é normal escolher alguém que passou por uma certificação um pouco mais rígida, com exigência de prova e experiência comprovada (neste quesito, que sempre foi tão criticado pela falta de pessoal do PMI para controlar já está mudando, a cada ano mais pessoas são pegas pela “malha fina”).

A questão que pega é realmente o que você colocou, insegurança x controle. Eu sou gerente de projetos e gosto de ter um bom controle sobre os processos, sempre gostei de modelos como Cobit, CMMI. Eu confio na equipe e não fico em cima dela para prazos, na verdade uma das primeiras perguntas que eu faço para a equipe é como eles preferem ser gerenciados. Há pessoas que gostam que alguém lembre de forma periódica o que deve ser feito, outros já preferem que ninguém fique em cima e assumem a responsabilidade, e a maior parte do meu trabalho com os controles é além de trazer informações para o gestor do negócio, salvaguardar a equipe contra pressões de clientes e mudanças de requisito, tenho números para provar que não vai dar para entregar na release X a funcionalidade, que a equipe não tem condições de assumir e que deve ser feito por outsourcing e etc.

Nunca tive péssimos gerentes, a maioria foram bons, salvo alguns casos um pouco mais dificeis, mas nada assutador.

Estou trabalhando em um projeto sob a gerência de uma pessoa voltada pra negócios e com pouco conhecimento técnico. Tivemos um pouco de conflito no começo e começamos a se perder no cronograma que foi estipulado pela própria gerência sem um aval técnico. Parecia que as coisas iriam ficar feias, junto com um colega convencemos a gerente a adotar algumas estratégias para agilizar o trabalho, nossa gerente comprou a idéia.

Cortamos a reunião mensal e implantamos Daily-Meeting, também conseguimos um quadro e aproveitamos para representar nossas atividades em postit’s. Cada atividade ficou rotulada com módulo para ajudar a identificar e marcamos o rótulo projeto para identificar aquilo que envolvia o projeto. Nossa comunicação com a gerência cresceu, estou fazendo uma amizade muito bacana até peço conselhos para pessoa de vez em quando.

Estamos vendo padrões mais enxutos e objetivos para os artefatos de metodologia que ficou a nossa livre escolha, também conseguimos adotar um conceito de small-realease ficou bem mais fácil controlar as implantações e mostrar a evolução no sistema ao usuário diminuindo a cobrança por resultado.

Enfim, conseguimos ganhar a confiança e respeito da gerência, graças a alguns fundamentos de metodologias ageis. Uma coisa que demorei pra perceber é que essa metologias promovem a comunicação, uma das coisas que mais falta em projetos convencionais.

Hoje temos uma ótima gerente, ela alivia a pressão das cobranças por parte do usuário e direciona as atividades conforme afinidade.

Se é tão simples tirar a certificação como esse Diabo Loiro falou, como q no Brasil só temos 11.000 certificados com a demanda que o mercado exige ???
Não é uma prova fácil. (Estuda um mês só que nem seu colega falou, e vai fazer a prova e me fala se é fácil.)
Valoriza, e muito o profissional.
Aumenta e muito, os recursos, habilidades e conhecimento de um profissional que esteja gerenciando um projeto e engajado com a ‘causa’.
Agrega conhecimento em áreas que muitas vezes o GP não tem domínio.
Não é um lixo para estudar. Lixo é ficar na internet cornetando o que você não sabe.

Agora claro que temos casos de pessoas que estudaram, passaram e não tem a minima vocação para o cargo, e essa parte de gestão de projetos, acreditem, é muito do perfil de cada um. Mas o que encontramos por aí é o chamado efeito ‘halo’, transferência de pessoas boas tecnicamente para a área de gerência. Mas enfim, isso não tem nada a ver com a certificação PMP , o PMBOK ou o PMI. São pessoas que gerenciam , cada um é cada um , ou vocês acham que todas as pessoas que foram aprovadas na certificação de programador Java, de fato são programadores ??? Ou então aquelas que não passaram, não são programadores ? Cada caso é um caso, generalizar é a forma mais simples de tapar o sol com a peneira.

Falar que é um lixo, demonstra muita falta de conhecimento. Falar que não é compatível com desenvolvimento ágil, pior ainda. As técnicas, ferramentas e metodologias apresentadas no PMBOK são utilizadas no mundo INTEIRO. Cuidado ao filtrar o que usuários desse tipo colocam, porque a maioria são opiniões desem basadas. O que um amigo falou, para o primo da tia da minha mãe não serve para nada, são apenas palavras jogadas ao vento. O GERENTE DE PROJETO, certificado PMP, é muito mais respeitado no mundo do que um Java Baby que acha que um Web Service é uma coisa incrível.

Vale também salientar que este fórum é voltado principalmente para programadores Java. Logo você não vai encontrar as melhores opinões aqui, procure outros sites, sugiro o pmtech, tem muitas informações sobre a carreira de GP. Apenas para constar de quem é essa opinião toda, fui programador Java durante 6 anos, conquistei nesse tempo algumas cerficações SCJP , SCWCD e SCBCD. Recentemente fui aprovado na prova do PMP e estou muito feliz com conhecimento obtive do .
Espero ter ajudado.
Att.

fred.diniz:

Se é tão simples tirar a certificação como esse Diabo Loiro falou, como q no Brasil só temos 11.000 certificados com a demanda que o mercado exige ???
Não é uma prova fácil. (Estuda um mês só que nem seu colega falou, e vai fazer a prova e me fala se é fácil.)
Valoriza, e muito o profissional.
Aumenta e muito, os recursos, habilidades e conhecimento de um profissional que esteja gerenciando um projeto e engajado com a ‘causa’.
Agrega conhecimento em áreas que muitas vezes o GP não tem domínio.
Não é um lixo para estudar. Lixo é ficar na internet cornetando o que você não sabe.

Agora claro que temos casos de pessoas que estudaram, passaram e não tem a minima vocação para o cargo, e essa parte de gestão de projetos, acreditem, é muito do perfil de cada um. Mas o que encontramos por aí é o chamado efeito ‘halo’, transferência de pessoas boas tecnicamente para a área de gerência. Mas enfim, isso não tem nada a ver com a certificação PMP , o PMBOK ou o PMI. São pessoas que gerenciam , cada um é cada um , ou vocês acham que todas as pessoas que foram aprovadas na certificação de programador Java, de fato são programadores ??? Ou então aquelas que não passaram, não são programadores ? Cada caso é um caso, generalizar é a forma mais simples de tapar o sol com a peneira.

Falar que é um lixo, demonstra muita falta de conhecimento. Falar que não é compatível com desenvolvimento ágil, pior ainda. As técnicas, ferramentas e metodologias apresentadas no PMBOK são utilizadas no mundo INTEIRO. Cuidado ao filtrar o que usuários desse tipo colocam, porque a maioria são opiniões desem basadas. O que um amigo falou, para o primo da tia da minha mãe não serve para nada, são apenas palavras jogadas ao vento. O GERENTE DE PROJETO, certificado PMP, é muito mais respeitado no mundo do que um Java Baby que acha que um Web Service é uma coisa incrível.

Vale também salientar que este fórum é voltado principalmente para programadores Java. Logo você não vai encontrar as melhores opinões aqui, procure outros sites, sugiro o pmtech, tem muitas informações sobre a carreira de GP. Apenas para constar de quem é essa opinião toda, fui programador Java durante 6 anos, conquistei nesse tempo algumas cerficações SCJP , SCWCD e SCBCD. Recentemente fui aprovado na prova do PMP e estou muito feliz com conhecimento obtive do .
Espero ter ajudado.
Att.

Palavras sábias… Concordo 100%…

Não conhecia o PMTech, putz tem vários artigos lokos… Gostei…

Parabéns por ter passado na prova, tenho certeza de q o esforço valeu a pena…

Vc pode falar um pouco à respeito de salários em SP?

Eu gostaria de levantar aqui a seguinte questão: Vocês realmente acham que um gerente é necessário em uma equipe que desenvolve software? Para um time ágil, creio que não haja lugar para essa figura. Quem acompanha no twitter pessoas do meio ágil, já as deve ter visto falando sobre não haver necessidade do gerente (às vezes, até mesmo fora do contexto de software). Acho que faz todo o sentido, já que um time ágil deve ser auto-gerenciável.

O que vocês acham?

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

+1

fiquem espertos se decidirem gastar tempo com isso, e tbm estiverem de olho no exterior, na europa o uso do PMI eh baixissimo em comparacao com os EUA, quer chegar aqui se achando o gostosao com PMI / PMP no curriculo – vai quebrar a cara

claro que: existem excessoes e empresas que adotam, estou aqui a 8 anos e ja passei por dezenas de projetos e ateh hoje to pra achar um cara que toma conta da TI de uma empresa que gosta dessas praticas

von.juliano:

Eu gostaria de levantar aqui a seguinte questão: Vocês realmente acham que um gerente é necessário em uma equipe que desenvolve software? Para um time ágil, creio que não haja lugar para essa figura. Quem acompanha no twitter pessoas do meio ágil, já as deve ter visto falando sobre não haver necessidade do gerente (às vezes, até mesmo fora do contexto de software). Acho que faz todo o sentido, já que um time ágil deve ser auto-gerenciável.

O que vocês acham?

Quem fala isso é quem tem a mentalidade de que gerente é aquele cara que só fica cobrando, assume a glória dos sucessos e penaliza o funcionário que fracassa. Fora que o espírito aventureiro do brasileiro tem aversão ao método.

Esse tipo de profissional não é necessário em nenhuma área. Mas gerência é muito mais que isso e não necessariamente é uma hierarquia, mas um papel e se for um bom profissional, ajuda e facilita em muito o trabalho da equipe.

Fora que da mesma forma que existe gerentes e gerentes, existem também pessoas e pessoas. Tá cheio de profissional que abomina gerente ou qualquer hierarquia pra poder navegar no Orkut e companhia e aproveita a onda pra se entitular ‘agil’.

Já houve diversas tentativas de empresas e equipes auto-gerenciáveis, até mesmo países com a anarquia.

Fato é que nunca deu muito certo, e a psicologia tem uma explicação muito lógica disto em relação ao desenvolvimento de maturidade no grupo. Toda vez que um novo membro entra ou sai do grupo, o grupo volta ao ciclo que sempre enfrenta em quaisquer relações, seja pessoal ou profissional: conhecimento com base nas identificações, disputas de poder, afastamento, exlusão e consolidação.

Entretanto assim como existe ciclo de vida de produto e até da pessoa, existe do grupo, e tende ao declínio, equipes auto gerenciáveis podem até funcionar, embora muito raro, somente por um tempo.

O gerente de projetos deveria ser uma pessoa da equipe que entende de gestão e se preocupa em remover os obstáculos da equipe, este que só cobra não é gerente é o que eu chamo de schedule whore. O gerente tem que ter uma formação mais gerencial e menos técnica, a pior coisa que tem é o cara que programou a vida inteira e faz a certificação, virar gerente de projetos, com certeza ele vai ficar só cobrando, porque de gestão não entende bulhufas.

E quanto ao salário, se fosse 30.000 eu já tava feito na vida

balrog:

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

+1

fiquem espertos se decidirem gastar tempo com isso, e tbm estiverem de olho no exterior, na europa o uso do PMI eh baixissimo em comparacao com os EUA, quer chegar aqui se achando o gostosao com PMI / PMP no curriculo – vai quebrar a cara

claro que: existem excessoes e empresas que adotam, estou aqui a 8 anos e ja passei por dezenas de projetos e ateh hoje to pra achar um cara que toma conta da TI de uma empresa que gosta dessas praticas

Aí usa-se muito o Prince2 que diferentemente do PMBOK é uma metodologia, mas os princípios são os mesmos. É a mesma coisa que você dizer que na Europa eles rejeitam eclipse porque usam net beans.

E na verdade eles não rejeitam de forma alguma, até tem estudado muito o PMBOK, um dos maiores entusiastas do PMBOK é a Inglaterra, curiosamente o país de onde surgiu o Prince2 a partir da OGC, é só olhar os artigos de um dos principais orgãos de estudo lá e verificar a importância que eles dão: http://www.projectsmart.co.uk/articles.html

Dezenas de empresa e experiência pessoal tá longe de ser uma amostra estatística relevante para afirmar qualquer coisa, faz melhor, entra no site do PMI e procura pelo número de PMP’s da europa. E curiosamente, os dois países com melhor estatística de sucesso em projetos são os dois países que tem maior número de PMP’s, Canadá e EUA

von.juliano:

Eu gostaria de levantar aqui a seguinte questão: Vocês realmente acham que um gerente é necessário em uma equipe que desenvolve software? Para um time ágil, creio que não haja lugar para essa figura. Quem acompanha no twitter pessoas do meio ágil, já as deve ter visto falando sobre não haver necessidade do gerente (às vezes, até mesmo fora do contexto de software). Acho que faz todo o sentido, já que um time ágil deve ser auto-gerenciável.

O que vocês acham?

No Scrum, o Scrum Master nada mais é que um gerente de projetos que não documenta quase nada.

As pessoas da nossa área tem dificuldades de entender a burocracia, para todo processo deve-se verificar o custo/benefício para a empresa, não para você. Se o número de horas reduzidas ou valor monetário adquirido for maior que o gasto para realizá-lo o processo é válido, quem disse que programador só precisa programar?

Quem não gosta do processo ou política da empresa, que procure outra, simples assim, a adequação dos seus valores com os da empresa é um dos pilares do sucesso profissional.

Certo. Na sua opinião, o que deve fazer um bom gerente de projetos? Que valor você acha que ele traz para a criação de um software?

Não leve a mal, mas está completamente enganado. O papel de Scrum Master em nada se assemelha ao de um gerente de projetos. O papel do SM nada mais é do que o de um “facilitador”. No Scrum, o que chega mais perto do gerente de projetos seria o Product Owner.

Deve ser porque burocracia só atrapalha, não só na nossa área, mas em qualquer lugar. O manifesto ágil está aí justamente para mostrar que o caminho “tradicional” é falho, mostrando que há formas melhores. Não é melhor apenas para os desenvolvedores, já que visa fortemente acabar com o comando-controle que é tanto usado hoje (os já citados péssimos gerentes), mas para a empresa, focando em obter retorno o quanto antes. E não é isso que a empresa quer?

Sobre os métodos “tradicionais”, acho interessante apontar aqui um post do Rodrigo Yoshima, entitulado Só agilidade funciona, uma visão bem interessante, de alguém que já está a bastante tempo na área.

Certo. Na sua opinião, o que deve fazer um bom gerente de projetos? Que valor você acha que ele traz para a criação de um software?

Não leve a mal, mas está completamente enganado. O papel de Scrum Master em nada se assemelha ao de um gerente de projetos. O papel do SM nada mais é do que o de um “facilitador”. No Scrum, o que chega mais perto do gerente de projetos seria o Product Owner.

Deve ser porque burocracia só atrapalha, não só na nossa área, mas em qualquer lugar. O manifesto ágil está aí justamente para mostrar que o caminho “tradicional” é falho, mostrando que há formas melhores. Não é melhor apenas para os desenvolvedores, já que visa fortemente acabar com o comando-controle que é tanto usado hoje (os já citados péssimos gerentes), mas para a empresa, focando em obter retorno o quanto antes. E não é isso que a empresa quer?

Sobre os métodos “tradicionais”, acho interessante apontar aqui um post do Rodrigo Yoshima, entitulado Só agilidade funciona, uma visão bem interessante, de alguém que já está a bastante tempo na área.

Uma visão unilateral. Burocracia não atrapalha, senão não faria sentido, é a mesma coisa que dizer que lei não serve pra nada e só atrapalha, a burocracia se assemelha muito às leis, burocracia burra, ou seja, disfunção burocrática sim é ruim.

E você que está enganado se acha que a função do gerente de projetos não deveria ser “facilitador” da equipe para que o projeto seja entregue no prazo, custo e escopo prometidos, você só confirmou o que eu constatei.

Cara, PMBOK não tem NADA a haver com tradicional, ele não tem estrutura em waterfall nem nada, é só um guia de conhecimentos, isto é puro desconhecimento seu e leitura de material que fala besteira, o modelo iterativo já era contemplado pelo PMBOK bem antes do Scrum ou XP, o PMBOK simplesmente não fala COMO as coisas devem ser feitas, só fala quais são as melhores práticas.

O que tem a haver falta de comando-controle com retorno antes? Isto é o alicerce da administração com Fayol e funciona desde antes de 1800, talvez ainda não na computação por falta de padrões.

Eu acho engraçado como todo cara da área técnica quer dizer como deve funcionar a gestão ou a empresa sem ter qualquer formação ou experiência nisto, é a mesma coisa que a sua vizinha falando como você deve programar. O que eu falo é baseado na minha formação em administração com anos de experiência, e baseado em autores no assunto. A própria gestão científica tem anos a mais do que a própria área de tecnologia, desde a revolução industrial. O Scrum funciona de certa forma porque tem o alicerce na comunicação e porque a área de TI é um caos por ser muito recente e não ter qualquer padrão bem definido ou estrutura, diferente da maior parte das outras áreas.

Só para constar, também fiz computação, sou da área, mas acho absurdo esta pretensão de querer dizer para a empresa e profissionais de anos de experiência em gestão como as coisas devem ser gerenciadas e dizer que um padrão que é adotado no mundo inteiro baseado nas práticas das melhores empresas não funciona. Queria ver se fosse o contrário.

Pra falar mal tem que conhecer.

Aliás, qualquer material PRESCRITIVO, falando que só X funciona já é burro por definição e por ignorância da diferença entre culturas e contextos empresariais, nada funciona em todo lugar e nada é melhor ou pior, depende sempre do contexto, PMBOK são 42 processos que são consideradas boas práticas e SCRUM é uma metodologia focada no ágil, elas são muito complementares e a utilização separada ou customizada sempre depende do contexto.

O problema é que forçam burocracia onde não é necessário, o que acontece sempre. Um exemplo é a forma como “administram” bugs. O bug é informado, cadastrado, ae escolhem alguém para resolver, a pessoa vai e resolve e depois anida tem que provar que resolveu, quando o importante aqui é resolver, e garantir que não aconteça de novo. Cadastrar o bug é realmente necessário? Toda essa administração é?

Acho que não fui claro, mas o SM tem que cuidar para que o scrum flua bem, lidando com o que dificulta a vida do time. Ele é o cara que pára pra resolver os problemas do time. Ele NÃO tem que GARANTIR a entrega no prazo (já que pode surgir algo que impeça isso, e problema acontecem), ele não lida com custo, e trabalha com escopo aberto como os demais. Além do que, um membro do time não É SM, ele ESTÁ SM, é um papel, não um cargo.

Falei para exemplificar que os ganhos dessa abordagem são para todos, não só para um dos lados.

Por ser nova, a gestão na área de ti não tem nenhum padrão definido, então são experimentados os mais variados modelos pré-existentes, como modelo de fábrica, que não serve pra software. Como esse, muitos modelos falham, mas ainda sim continuam sendo adotados - a fábrica de software tá aí - o que não quer dizer que seja uma boa opção. Qualquer um que estudou um mínimo sobre projetos de software já viu os gráficos que indicam a grande quantidade de projetos de software que falham fazendo uso de tais métodos - e que continuam em uso. Quando diz melhores práticas, não são melhores práticas pra um projeto de software, já que elas não existiam, então como pode assumir que práticas de tantos anos, as quais não foram feitas para lidar com esse tipo de projeto, são “as melhores práticas”? Por experimentação, o que não trouxe um resultado tão bom assim.

Falando de Software, agile é o melhor que temos hoje, o que também foi experimentado, trouxe resultados melhores e está constantemente evoluindo. O ponto é que muitas vezes é escolhido manter um modelo pobre com resultados medíocres, ao arriscar um que pode trazer resultados melhores. É claro que agile não é modelo para tudo, mas tem se mostrado a melhor opção para desenvolvimento de software - vide o destaque que empresas que o adotam conseguem - comparado à outros modelos.

[edit]

Isto é a disfunção burocrática, mas você tem que garantir a integridade do produto, isto só é feito com gerencia de configuração. Por exemplo você tem 10 testes para fazer, se não tem um processo bem definido de baselines como vai garantir que ao corrigir o 8º bug, não teve alterações no 1º que tinha sido resolvido antes? Toda esta administração é necessária sim, sem ela você não tem como garantir a integridade do produto, o problema é quando ela é mal feita, que talvez tenha sido o caso nas suas experiências.

Na verdade, você também está no cargo, a grande diferença do cargo e papel é o número de horas associadas a função. Se você tem 8 horas de trabalho diário de gerencia de projetos, seu papel acaba tornando-se um cargo. O papel é uma forma que a empresa cria de colocar atividades não especificadas no plano de cargos e salários sem ter que pagar por elas. SM em essência nada mais é que um gerente de projetos que lida com o projeto de forma mais informal, o prazo é o prazo definido pelo cliente, qualquer gerenciamento de projeto tem que prever problemas, mas aí você precisa replanejar o projeto e criar linhas de base. Se o escopo é aberto não é um projeto, o escopo é o que diferencia um projeto de uma operação, por exemplo. Tanto que no CMMI normalmente em empresas que adotam SCRUM quem adota a função de gerente de projetos para as práticas de PP (Planejamento do projeto) e PMC (Monitoramento e Controle do projeto) é justamente o Scrum Master.

von.juliano:

Falei para exemplificar que os ganhos dessa abordagem são para todos, não só para um dos lados.

Por ser nova, a gestão na área de ti não tem nenhum padrão definido, então são experimentados os mais variados modelos pré-existentes, como modelo de fábrica, que não serve pra software. Como esse, muitos modelos falham, mas ainda sim continuam sendo adotados - a fábrica de software tá aí - o que não quer dizer que seja uma boa opção. Qualquer um que estudou um mínimo sobre projetos de software já viu os gráficos que indicam a grande quantidade de projetos de software que falham fazendo uso de tais métodos - e que continuam em uso. Quando diz melhores práticas, não são melhores práticas pra um projeto de software, já que elas não existiam, então como pode assumir que práticas de tantos anos, as quais não foram feitas para lidar com esse tipo de projeto, são “as melhores práticas”? Por experimentação, o que não trouxe um resultado tão bom assim.

Falando de Software, agile é o melhor que temos hoje, o que também foi experimentado, trouxe resultados melhores e está constantemente evoluindo. O ponto é que muitas vezes é escolhido manter um modelo pobre com resultados medíocres, ao arriscar um que pode trazer resultados melhores. É claro que agile não é modelo para tudo, mas tem se mostrado a melhor opção para desenvolvimento de software - vide o destaque que empresas que o adotam conseguem - comparado à outros modelos.

Engraçado você falar em modelo de fábrica não funcionar, porque o scrum vem justamente do lean que é modelo de fábrica pré existente que veio de Deming. Os projetos não falham por causa do método aplicado, faltam pela falta de utilização, veja as pesquisa do Chaos Report em relação a empresas que tem uma metodologia de projetos baseada nas melhores práticas e as que não tem. Resultado não foi tão bom? Onde que você viu isto? Se você conseguir me provar que utilizando uma metodologia baseada nas melhores práticas o sucesso em projetos não foi bastante superior a quem não tem um processo definido ou que não é baseado eu me convenço. Mostrar estatísticas gerais não prova nada, aliás é muito difícil fazer estatísticas deste tipo, as melhores práticas são baseadas justamente no inverso do que você falou, nos padrões de projetos que ocorrem nas mais variadas áreas.

Se na empresa de software não está funcionando, é mais provável que o problema esteja na empresa e na forma como utiliza que nas melhores práticas em si. Elas são totalmente integradas a visão ágil, as pessoas normalmente falam por falta de conhecimento, se você não vivencia o gerenciamento de projetos diariamente normalmente tem uma tendência a falar muita besteira em relação a isto, assim como eu falaria se hoje fosse querer falar sobre desenvolvimento, bd e etc, apesar de ter um certo conhecimento e estudado, não é o que vivencio.

na minha opinião é o emprego mais inutil da area de informatica.

PMO = picaretagem

o discurso da parada é lindo mas quem realmente tem experiencia em TI e em projetos com orçamento acima de 10 milhões de reais sabe o quanto é imbecil esta função de ficar controlando cronogramas e planilhas.

issso na prática nao auxilia em nada o andamento das coisas e pior faz com que o orçamento dos projetos aumente muito desnecessariamente em documentos que ninguém irá ler.

voces podem acreditar nessa falácia se quiser pois cada um acredita no que quer mas eu nunca vi vantagem prática e já trabalhei em muitos projetos pelo país pra saber do que estou falando.

PMO é como mula sem cabeça ou saci perere.

balrog:

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

+1

fiquem espertos se decidirem gastar tempo com isso, e tbm estiverem de olho no exterior, na europa o uso do PMI eh baixissimo em comparacao com os EUA, quer chegar aqui se achando o gostosao com PMI / PMP no curriculo – vai quebrar a cara

claro que: existem excessoes e empresas que adotam, estou aqui a 8 anos e ja passei por dezenas de projetos e ateh hoje to pra achar um cara que toma conta da TI de uma empresa que gosta dessas praticas

Desculpa a franqueza, mas você falou besteira.
Aqui na Europa valorizam e muito uma pessoa certificada em pmp/pmi.

O problema é o seguinte: qualquer pessoa consegue provar que teve [telefone removido] horas gerindo projetos para poder tirar um pmp/pmi. Daí o resultado é o que temos hoje, um monte de gente que tem o pmi/pmp e em termos de tecnologia só conhece CRUD… então temos muitos chefes de projetos que andam de terno e gravata aparentando firmeza no que falam, mas no fundo dependem 100% da equipe de programação porque não entende porra nenhuma de tecnologia, e acaba por desempenhar uma tarefa de cobrança a tempo inteiro ( “já está pronto?”, “Já funciona?” )

É exatamente por isso que escrevi acima que os caras do pmp/pmi tentaram travar isso colocando como requisito para tirar a certificação, X horas como chefe de projetos. Mas não conseguiram travar muito não…

Mas como disse no inicio, um cara que tira um pmp/pmi, e que saiba minimamente de tecnologia, tem tudo para ser um ótimo chefe de projetos e ganhar 2, 3 ou 4 vezes mais que um mero programador…

Sparcx86:

na minha opinião é o emprego mais inutil da area de informatica.

PMO = picaretagem

o discurso da parada é lindo mas quem realmente tem experiencia em TI e em projetos com orçamento acima de 10 milhões de reais sabe o quanto é imbecil esta função de ficar controlando cronogramas e planilhas.

issso na prática nao auxilia em nada o andamento das coisas e pior faz com que o orçamento dos projetos aumente muito desnecessariamente em documentos que ninguém irá ler.

voces podem acreditar nessa falácia se quiser pois cada um acredita no que quer mas eu nunca vi vantagem prática e já trabalhei em muitos projetos pelo país pra saber do que estou falando.

PMO é como mula sem cabeça ou saci perere.

Eu tenho experiencia em TI, trabalhei com varios projetos acima do orçamento e discordo de você, portanto sua sentença é uma falácia.

Primeiro por afirmar que gerenciar projeto é ficar controlando cronogramas e planilhas, ainda colocando isto de forma pejorativa, o principal trabalho do gerenciamento do projeto está na gestão dos riscos e na comunicação. Isto que você falou agora que é uma falácia clássica de discurso de autoridade, na verdade dois com a falsa atribuição de causa. São duas das falácias mais praticadas no país por políticos.

Eu também já trabalhei várias vezes e sempre vi resultados muito positivos quando bem aplicados, então não generalize.

E PMO é escritório de projetos, não gerente de projetos. PMO não necessariamente gerencia projetos, quando faz é exceção. Normalmente ele é o “guardião” do gerenciamento de projetos na empresa, estabelecendo metodologia, treinamento e outros.

“A má utilização de um ideal, não invalida o mesmo”

Nao é porque a maioria esmagadora de Gerentes PMI são “mais marketing do que eficientes”, que as pratica de gerencia sao inuteis e desnecessárias.
O mesmo raciocínio poderia ser aplicado a programadores, diríamos que sao “macacos” tendo em vista o monte de código ctrl+c / ctrl+v que vemos por ae.
Generalizado assim estariamos ofendendo os varios programadores excelentes que estao sempre em busca das melhores praticas e tornam programar uma ARTE.

Generalizar é a arte dos TOLOS.

E papel do GP é isso também.

Esse é o sponsor.

Já houve diversas tentativas de empresas e equipes auto-gerenciáveis, até mesmo países com a anarquia.

Fato é que nunca deu muito certo, e a psicologia tem uma explicação muito lógica disto em relação ao desenvolvimento de maturidade no grupo. Toda vez que um novo membro entra ou sai do grupo, o grupo volta ao ciclo que sempre enfrenta em quaisquer relações, seja pessoal ou profissional: conhecimento com base nas identificações, disputas de poder, afastamento, exlusão e consolidação.

Entretanto assim como existe ciclo de vida de produto e até da pessoa, existe do grupo, e tende ao declínio, equipes auto gerenciáveis podem até funcionar, embora muito raro, somente por um tempo.

O gerente de projetos deveria ser uma pessoa da equipe que entende de gestão e se preocupa em remover os obstáculos da equipe, este que só cobra não é gerente é o que eu chamo de schedule whore. O gerente tem que ter uma formação mais gerencial e menos técnica, a pior coisa que tem é o cara que programou a vida inteira e faz a certificação, virar gerente de projetos, com certeza ele vai ficar só cobrando, porque de gestão não entende bulhufas.

E quanto ao salário, se fosse 30.000 eu já tava feito na vida

Equipes auto-gerenciaveis sao uma necessidade atualmente, as empresas que nao conseguem instituir isso estao tendo muitas dificuldades em seus projetos, porque se voce nao tem uma equipe auto-gerenciavel, voce precisa de uma pessoa centralizando as decisoes e micro-gerenciando tudo. Nao precisa ser nenhum genio pra saber que as decisoes sao mais demoradas e mais propensas a erro nesses casos, quando estao centralizadas.

O problema é que as pessoas pensam que equipe auto-gerenciavel é esbornia e que cada um faz o que quer, na hora que quer e fica tudo certo. Vai ter sempre alguem (seja la que titulo lhe seja dado) responsavel por manter o foco no produto que esta sendo desenvolvido, por fazer com que toda a equipe tenha o mesmo ponto comum.

Se um gerente precisa ficar designando tarefa para uma equipe o tempo todo é porque tem algo errado. Ou a equipe ou o gerente (ou as duas coisas) sao fracos.

Tal coisa precisa ser feita. Quanto tempo, quem vai fazer o que e como? Isso é uma decisao tecnica, so uma equipe tecnica pode responder a essas perguntas. Se a sua equipe nao eh capaz de decidir isso ela eh uma equipe fraca.

YvGa:

Já houve diversas tentativas de empresas e equipes auto-gerenciáveis, até mesmo países com a anarquia.

Fato é que nunca deu muito certo, e a psicologia tem uma explicação muito lógica disto em relação ao desenvolvimento de maturidade no grupo. Toda vez que um novo membro entra ou sai do grupo, o grupo volta ao ciclo que sempre enfrenta em quaisquer relações, seja pessoal ou profissional: conhecimento com base nas identificações, disputas de poder, afastamento, exlusão e consolidação.

Entretanto assim como existe ciclo de vida de produto e até da pessoa, existe do grupo, e tende ao declínio, equipes auto gerenciáveis podem até funcionar, embora muito raro, somente por um tempo.

O gerente de projetos deveria ser uma pessoa da equipe que entende de gestão e se preocupa em remover os obstáculos da equipe, este que só cobra não é gerente é o que eu chamo de schedule whore. O gerente tem que ter uma formação mais gerencial e menos técnica, a pior coisa que tem é o cara que programou a vida inteira e faz a certificação, virar gerente de projetos, com certeza ele vai ficar só cobrando, porque de gestão não entende bulhufas.

E quanto ao salário, se fosse 30.000 eu já tava feito na vida

E gostaria que voce desse mais exemplos desse “equipes auto-gerenciaveis nao deu muito certo”.

Equipes auto-gerenciaveis sao uma necessidade atualmente, as empresas que nao conseguem instituir isso estao tendo muitas dificuldades em seus projetos, porque se voce nao tem uma equipe auto-gerenciavel, voce precisa de uma pessoa centralizando as decisoes e micro-gerenciando tudo. Nao precisa ser nenhum genio pra saber que as decisoes sao mais demoradas e mais propensas a erro nesses casos, quando estao centralizadas.

O problema é que as pessoas pensam que equipe auto-gerenciavel é esbornia e que cada um faz o que quer, na hora que quer e fica tudo certo. Vai ter sempre alguem (seja la que titulo lhe seja dado) responsavel por manter o foco no produto que esta sendo desenvolvido, por fazer com que toda a equipe tenha o mesmo ponto comum.

Se um gerente precisa ficar designando tarefa para uma equipe o tempo todo é porque tem algo errado. Ou a equipe ou o gerente (ou as duas coisas) sao fracos.

Tal coisa precisa ser feita. Quanto tempo, quem vai fazer o que e como? Isso é uma decisao tecnica, so uma equipe tecnica pode responder a essas perguntas. Se a sua equipe nao eh capaz de decidir isso ela eh uma equipe fraca.

Vou pesquisar caso de empresas conforme já estudei e fico te devendo, tenho que buscar nos livros de ADM, até sexta feira te trago, mas o conceito de equipes auto gerenciáveis é muito antigo, há pelo menos uns 30 anos a idéia e nunca conseguiu ser implantada de fato, há pouco tempo tentaram reviver sob o nome de enpowerment e várias empresas já tentaram implementar, as maiores críticas são a própria teoria X, Y de Mc Gregor que mostra que a diferença entre as pessoas em relação ao trabalho, embora há muitas pessoas que tomam a iniciativa e não desejam ser cobradas (perfil normalmente dos entusiastas do autogerenciamento) há uma infinidade de pessoas que não fazem nada a não ser que sejam cobradas e digam o que necessita ser feito, e corresponde a uma boa parcela da população, é questão de perfil. Mesmo que você tentasse formar equipes com pessoas somente do perfil X, há alguns complicadores, o primeiro é em relação a dificuldade em identificar este tipo de pessoa, não é algo que você normalmente consiga filtrar numa entrevista, pode aparecer quando você mais esperar, e há muitas pessoas tecnicamente excelentes neste perfil, você teria dificuldade em encontrar uma equipe somente com o primeiro perfil.

Outro problema foi o que eu citei da psicologia, a estruturação das pessoas em grupo, normalmente acaba em ciclos, e níveis de maturidades cíclicos e imprevisíveis são ruim para uma empresa, nenhuma equipe auto gerenciável consegue se manter sem uma disputa de poder, mesmo que informal, isto faz parte das relações humanas. Toda vez que houver rotatividade na equipe, haverá problemas com a inclusão de um novo membro, vai acontecer a desconfiança, reequilíbrio, novas disputas de poder e nova consolidação (ou não). A teoria de equipes autogerenciáveis é bonita e muita gente gosta, mas na prática é insustentável. O que pode ter é uma liderança mais democrática que centralize menos o poder ou mesmo um laisse faire.

Agora em relação ao que você falou em velocidade de decisão, o normal é o contrário, quando a decisão é centralizada ela tende a ser mais rápida porque não depende de um consenso, o que pode demorar é a estrutura funcional da empresa, em uma estrutura mais matricial ou projetizada este problema tende a diminuir bastante.

Esta questão de liderança, trabalho em equipe e motivação envolve muito mais psicologia do que qualquer outro fator, o ser humano é altamente complexo, não tem a haver com equipes ou gerentes fracos, tem a haver com a natureza do ser humano e suas motivações enquanto indivíduo pertencente a um grupo. E aí que entra o que se conhece atualmente na Administração científica e é aceito como por exemplo Maslow, Hezberg e McGregor. Todas estas idéias que parecem inovadoras já foram tentadas e ciclicamente voltam sob outros nomes como um novo modismo empresarial. O Scrum por exemplo nada mais é que Deming simplificado, ciclos PDCA e Kanban, com uma tendência Lean, isto já foi testado e deu certo desde a reestruturação do Japão depois de Hiroshima e Nagazaki com o foco na qualidade.

A grande verdade é que a área de TI é uma área muito intelectualizada, então as pessoas tem dificuldade em aceitar uma hierarquia, ainda mais quando é baseada em cobrança, meio behaviorista. Normalmente em outras áreas quem tem mestrado/pós está acima na hierarquia e na TI isto nem sempre é verdade, tem muito programador com mestrado/doutorado.

E há uma confusão de competência em relação a posição hierárquica, normalmente quem acaba mandando é uma pessoa que geralmente tem um conhecimento técnico menor, e quem é da área tem uma dificuldade imensa em aceitar isto, então querem desenvolver um método para que possam se auto gerir.

O fato é, as pessoas nao gostam de receber ordens, principalmente quando elas tem um alto nivel de capacitacao e menos ainda quando estas ordens vem de alguem com menos conhecimento tecnico que elas sobre o assunto.

O papel de um gerente em desenvolvimento de software tem que estar bem mais perto do de um tecnico de futebol, ou de um diretor de teatro do que o de um gerente tradicional. É prciso manter o foco, deixar sempre claro qual o objetivo do que esta sendo feito, mas só os jogadores ou atores saberao o que e quando fazer.

Quando voce toma as decisoes sozinho, ou precisa dar a ultima palavra sobre elas, mas nao esta plenamente envolvido tecnicamente, voce esta bem mais propenso ao erro do que quando isso é dividido por uma equipe com alta capacidade tecnica. E sim, as decisoes centralizadas sao mais lentas, porque o problema, quando surge, ao inves de ser resolvido de pronto, por alguem com capacidade pra fazer, precisa subir todas as camadas gerenciais, pelas quais pedaços de informações que podem ser cruciais vao ficando. E depois as ordens tem que novamente descer as camadas ate chegar a quem ira executa-la. É obvio que isto é mais demorado.

Alem de que, quando as decisoes sao centralizadas, sao mais propensas a erro, ja que sao tomadas por uma só pessoa, nao por um grupo.

E tambem assinalar tarefas é mais lento do que deixar com que os membros decidam qual devem fazer, porque a mesma pessoa precisa avaliar uma a uma e enviar a alguem, que muitas vezes pode nao ser a pessoa indicada a faze-lo.

O modelo auto-gerencial é bem mais dificil de ser alcançado, até pelos motivos que voce citou, problemas interpessoais, perfis, disputa de poder. Mas isso tudo pode e deve ser bem gerenciado.

Mas logico, eh bem mais facil simplesmente dar ordens e quem tiver juizo que obedeça, do que ficar se preocupando em gerenciar conflitos.

Eu mando, voces obedecem, porque eu sei o que estou fazendo. Isso tambem funciona e é bem mais facil de implementar, mas quando voce consegue compor equipes auto-gerenciaveis o resultado é muito melhor.

felipefranz:

A grande verdade é que a área de TI é uma área muito intelectualizada, então as pessoas tem dificuldade em aceitar uma hierarquia, ainda mais quando é baseada em cobrança, meio behaviorista. Normalmente em outras áreas quem tem mestrado/pós está acima na hierarquia e na TI isto nem sempre é verdade, tem muito programador com mestrado/doutorado.

E há uma confusão de competência em relação a posição hierárquica, normalmente quem acaba mandando é uma pessoa que geralmente tem um conhecimento técnico menor, e quem é da área tem uma dificuldade imensa em aceitar isto, então querem desenvolver um método para que possam se auto gerir.

++

felipefranz :

A grande verdade é que a área de TI é uma área muito intelectualizada, então as pessoas tem dificuldade em aceitar uma hierarquia, ainda mais quando é baseada em cobrança, meio behaviorista. Normalmente em outras áreas quem tem mestrado/pós está acima na hierarquia e na TI isto nem sempre é verdade, tem muito programador com mestrado/doutorado.

E há uma confusão de competência em relação a posição hierárquica, normalmente quem acaba mandando é uma pessoa que geralmente tem um conhecimento técnico menor, e quem é da área tem uma dificuldade imensa em aceitar isto, então querem desenvolver um método para que possam se auto gerir.

Verdade…perceba que, até onde entendo, mestrado / doutorado na realidade irá possibilitar o cidadão a MINISTRAR AULAS em uma universidade. Portanto acreditar que o titulo de mestrado / doutorado irá proporcionar um cargo melhor pode ser frustrante. Claro que pode acontecer porem não é tão comum e simples como alguns acreditam. Dependendo da situação pode até dificultar na contratação, muitos podem ficar com receio de contratar alguem com mestrado / doutorado temendo uma forte competição pelo poder ou até mesmo um valor muito elevado na pretensão salarial.

flws

Já ouvi dizer muitas vezes que Scrum é uma idéia nova rsrsrsrsr.

flws

gerente = campeão

Você percebe que tenta defender um extremo argumentando com outro extremo? Quem aqui falou que a alternatia a uma equipe teoricamente auto-gerenciável é microgerenciar tudo? E por que você acha que todos os projetos são iguais e precisam da mesma fórmula, independente da equipe, negócio e necessidade?

Sua visão é meio preto e branco, não acha?

marcosalex:

YvGa:

Equipes auto-gerenciaveis sao uma necessidade atualmente, as empresas que nao conseguem instituir isso estao tendo muitas dificuldades em seus projetos, porque se voce nao tem uma equipe auto-gerenciavel, voce precisa de uma pessoa centralizando as decisoes e micro-gerenciando tudo.

Você percebe que tenta defender um extremo argumentando com outro extremo? Quem aqui falou que a alternatia a uma equipe teoricamente auto-gerenciável é microgerenciar tudo? E por que você acha que todos os projetos são iguais e precisam da mesma fórmula, independente da equipe, negócio e necessidade?

Sua visão é meio preto e branco, não acha?

Pensei o mesmo, é a questão da validação.

Micro gerenciamento é uma falha de gestão, não uma boa prática e não é defendida por nenhuma metodologia/guia de melhores práticas.

Você não precisa nem centralizar as decisões e nem microgerenciar, você está usando experiência pessoal como forma de invalidar algo que desconhece. Como o marcosalex falou e já tinha colocado antes, tudo depende de um contexto, nada é prescritivo.

É a mesma diferença entre uma revista científica indexada e uma exame por exemplo tratando uma mesma questão, por exemplo: finanças.

Numa revista científica estarão as melhores práticas estudadas, estatísticas sem viés, teoria sobre o comportamento e tomada de decisões frente ao dinheiro, estudos sobre probabilidades em investimentos, deixa no contexto certos padrões que funcionaram em certas situações. Ela pode indicar o que deve ser feito com base nos estudos, nunca como deve ser feito, que é o grande problema das metodologias e é aí que as pessoas metem os pés pelas mãos.

Na revista comercial estará “30 passos para ficar rico em 6 meses” justamente porque tem um caráter puramente comercial e o intuito é vender o máximo possível, vai te dizer como você deve proceder para ficar rico, o que geralmente tem uma probabilidade ínfima de acontecer.

Minha conclusão é: quando as pessoas me perguntam sobre metodologias minha resposta sempre é para que a empresa desenvolva a sua própria metodologia, testando e errando, mantendo o que deu certo utilizando as melhores práticas e práticas que deram certo de outras metodologias (famoso benchmarking). Ninguém quer saber (ou deveria se preocupar) se o nome não vai ser Scrum, XP, PMBOK, XYZ, vocês seguem a metodologia da empresa X, que sempre deve ser revisada, porque a empresa também muda.

felipefranz:

marcosalex:

YvGa:

Equipes auto-gerenciaveis sao uma necessidade atualmente, as empresas que nao conseguem instituir isso estao tendo muitas dificuldades em seus projetos, porque se voce nao tem uma equipe auto-gerenciavel, voce precisa de uma pessoa centralizando as decisoes e micro-gerenciando tudo.

Você percebe que tenta defender um extremo argumentando com outro extremo? Quem aqui falou que a alternatia a uma equipe teoricamente auto-gerenciável é microgerenciar tudo? E por que você acha que todos os projetos são iguais e precisam da mesma fórmula, independente da equipe, negócio e necessidade?

Sua visão é meio preto e branco, não acha?

Pensei o mesmo, é a questão da validação.

Micro gerenciamento é uma falha de gestão, não uma boa prática e não é defendida por nenhuma metodologia/guia de melhores práticas.

Você não precisa nem centralizar as decisões e nem microgerenciar, você está usando experiência pessoal como forma de invalidar algo que desconhece. Como o marcosalex falou e já tinha colocado antes, tudo depende de um contexto, nada é prescritivo.

É a mesma diferença entre uma revista científica indexada e uma exame por exemplo tratando uma mesma questão, por exemplo: finanças.

Numa revista científica estarão as melhores práticas estudadas, estatísticas sem viés, teoria sobre o comportamento e tomada de decisões frente ao dinheiro, estudos sobre probabilidades em investimentos, deixa no contexto certos padrões que funcionaram em certas situações. Ela pode indicar o que deve ser feito com base nos estudos, nunca como deve ser feito, que é o grande problema das metodologias e é aí que as pessoas metem os pés pelas mãos.

Na revista comercial estará “30 passos para ficar rico em 6 meses” justamente porque tem um caráter puramente comercial e o intuito é vender o máximo possível, vai te dizer como você deve proceder para ficar rico, o que geralmente tem uma probabilidade ínfima de acontecer.

Minha conclusão é: quando as pessoas me perguntam sobre metodologias minha resposta sempre é para que a empresa desenvolva a sua própria metodologia, testando e errando, mantendo o que deu certo utilizando as melhores práticas e práticas que deram certo de outras metodologias (famoso benchmarking). Ninguém quer saber (ou deveria se preocupar) se o nome não vai ser Scrum, XP, PMBOK, XYZ, vocês seguem a metodologia da empresa X, que sempre deve ser revisada, porque a empresa também muda.

Nao, Marco, nao acho a minha visao “meio” preto e branco. Eu mesmo disse que o modelo de gestao tradicional funciona em muitos casos, e é inclusive mais facil.

O problema é que provavelmente o Felipe esta usando a experiencia pessoal pra argumentar. É claro que se voce chegar na maioria dos lugares, olhar para as equipes e tentar imaginar elas se auto-gerenciando, voce vai achar que isso nao eh possivel ou eh muito dificil. Mas o problema eh que a equipe é tecnicamente fraca, e provavelmente incapaz de tomar a maioria das decisoes que precisam ser tomadas.

E sim, ou a equipe se auto-gerencia, ou voce micro-gerencia, nao ha meio termo. O que pode haver sao determinados assuntos voce deixa por conta da equipe, outros voce assume para si. Quanto mais voce assume para si, maior a necessidade de micro-gerenciar. Quanto mais voce deixa para a equipe, mais capacitada a equipe deve ser para saber tomar as decisoes e em que momentos toma-las.

O grande problema é que muitas vezes as empresas estao tao amarradas em processos e fluxos e charts e tasks, que perdem completamente a capacidade de inspecionar, de validar e medir o que esta sendo feito. Por isso, aliado ao historico de falhas da equipe (montada por elas mesmas), nao confiam no time.

Mais uma vez eu insisto em dizer que a maioria dos que nao gostam do auto-gerenciamento, nao gostam por assumir prematuramente que auto-gerenciamento é esbornia onde cada um faz o que quer.

Auto-gerenciamento é aplicavel em qualquer caso e em qualquer lugar? Nao, logico que nao. Mas sempre onde eu vi instaurado com sucesso, os resultados foram melhores do que o gerenciamento tradicional poderia alcancar. Ja vi ilhas de alta performance dentro de uma empresa comum e um dos pilares desta alta performance era o auto-gerenciamento. “Me diga o que voce precisa que eu faço. Só nao me diga como eu devo fazer, pois isso eu sei. Apenas confie. Ah, e esteja livre para inspecionar, medir, verificar, acompanhar e reclamar na hora em que voce quiser.”

Em relação a dificuldade maior, este sim eu concordo, o maior desafio além de implantar é manter a empresa não consegue ter nenhuma garantia a longo prazo, os riscos são grandes. Em relação ao micro gerenciamento, as práticas do PMBOK deixam bem claro que isto é prejudicial ao projeto, tipicamente, de acordo com os autores mais reconhecidos na área, você deve gerenciar pacotes de trabalho entre 8 e 80 horas (embora na área de TI recomenda-se 4/40), não por tarefas ou micro atividades, normalmente quem tenta microgerenciar acaba não gerenciando nada.

Em relação aos processos, isto acontece quando o processo é mal feito. Em uma área (não empresa) que tenha implantado o CMMI 3 por exemplo, é muito difícil ver inconsistências nas medições e análises, normalmente há números reais para a tomada de decisão.

Se por experiência pessoal, você contar a minha formação e não somente deduções com base em senso comum, aí sim, estou usando.

Em relação a equipe “tecnicamente fraca” o problema maior é quando a equipe é fraca em relacionamento interpessoal e comunicação, justamente por ser uma equipe. Ela tem que ser muito coesa para funcionar, além também de “tecnicamente forte”, e mesmo assim é difícil mantê-la a longo prazo, por isto digo que é bastante utópico, a empresa tem que ter uma maturidade absurda e saber gerenciar muito bem seus riscos, ter plena confiança em todos os funcionários e as pessoas tem que ser boas tanto em soft quanto em hard skill sem contar que não funciona em estrutura funcional que é a realidade da maior parte das empresas do país e não funciona em todas as situações.

Sem contar que para o dono do negócio, é uma idéia muito difícil de vender, dependendo do perfil. Normalmente quem tem o seu dinheiro no negócio não está disposto a assumir um risco grande. Se ele o fizer, vai querer saber qual o VPL, TIR e Payback da mudança, talvez alguns tomadores de risco o fizessem, mas de forma geral seria bastante difícil justificar.

Agora, se a empresa já no seu startup trabalha desta forma começando com equipes pequenas e evoluindo e consegue implantar uma cultura voltada a este lado, acho louvável e uma boa iniciativa, o risco da empresa vai aumentar, provavelmente também acontecerá com o retorno. Esta discussão me deu até uma idéia para um artigo.

Sobre quem associa Scrum Master ao gerente de projeto, me abstenho de explicar a diferença, pois falta muito conhecimento para afirmar que é o mesmo papel.

Voltando ao tópico, encontrei um post muito interessante sobre o que está em discussão, denominado Fire all the managers, escrito pelo Giovanni Bassi, uma conhecida figura do meio ágil, o qual recomendo a leitura inclusive dos comentários, que está gerando uma discussão muito semelhante ao desse tópico.

von.juliano:

Sobre quem associa Scrum Master ao gerente de projeto, me abstenho de explicar a diferença, pois falta muito conhecimento para afirmar que é o mesmo papel.

Voltando ao tópico, encontrei um post muito interessante sobre o que está em discussão, denominado Fire all the managers, escrito pelo Giovanni Bassi, uma conhecida figura do meio ágil, o qual recomendo a leitura inclusive dos comentários, que está gerando uma discussão muito semelhante ao desse tópico.

Bom, talvez falte é discernimento para você perceber que fundamentalmente, fazem a mesma coisa, mas de forma diferentes devido a questões relacionadas a tempo, estrutura e autoridade.

Qual é fundamentalmente o papel do SM? Basicamente, remover os obstáculos, ou impedimentos que atrapalhem a equipe e zelar pela prática dos processos do Scrum. Porque ele faz isto? Para garantir que a equipe entregue o projeto dentro dos requisitos, prazo e custo (no sentido de esforço) necessários.

Qual é a função do gerente de projetos? Utilizar conhecimentos, habilidades, ferramentas e técnicas (normamente seguindo um processo) para que o projeto seja entregue dentro dos requisitos (ou escopo), prazo e custos especificados. Nada mais é fundamentalmente que remover os obstáculos da equipe, seguir um processo e zelar para que a equipe também siga, apontando hora, issues.

Em relação ao texto, ele não abre aqui, mas só pelo título percebe-se que é aquilo que me referi anteriormente, prescritivo e altamente sensacionalista/comercial, típico de fanboys.

@felipefranz, creio que você seja gerente de projeto, o que me leva a crer que tenha maior resistência para considerar a possibilidade de uma equipe sem um gerente.

Basicamente, o SM não está hierarquicamente acima do time, como é um gerente tradicional, e quem já passou por um ambiente assim sabe que é uma situação completamente diferente, já que a hierarquia leva ao comando-controle. Vou deixar para o Alexandre Magno explicar.

O texto é uma visão de quem já está há um bom tempo na area, e que já foi gerente de projetos por muitos anos e hoje não é mais. Sugiro que quando poder abri-lo aproveite a oportunidade de entrar na discussão, e dizer ao próprio criador do post que é a visão de um fanboy, ele tem muita disposição pra defender seu ponto de vista.

Ah sim, algumas equipes ágeis, após um certo tempo chegam a abolir o Scrum Master, quando a equipe chega a um ponto que leva os valores do scrum com grande facilidade. No cenário que você citou, em que o gerente “é” o SM, ele poderia ter seu cargo removido? Se é a mesma coisa, não vejo pra que mantê-lo nesse caso.

von.juliano:

@felipefranz, creio que você seja gerente de projeto, o que me leva a crer que tenha maior resistência para considerar a possibilidade de uma equipe sem um gerente.

Basicamente, o SM não está hierarquicamente acima do time, como é um gerente tradicional, e quem já passou por um ambiente assim sabe que é uma situação completamente diferente, já que a hierarquia leva ao comando-controle. Vou deixar para o Alexandre Magno explicar.

O texto é uma visão de quem já está há um bom tempo na area, e que já foi gerente de projetos por muitos anos e hoje não é mais. Sugiro que quando poder abri-lo aproveite a oportunidade de entrar na discussão, e dizer ao próprio criador do post que é a visão de um fanboy, ele tem muita disposição pra defender seu ponto de vista.

Sim, sou gerente de projetos, como já coloquei aqui e já . Eu nunca achei que um gerente de projetos devesse estar acima do time e sim junto com ele, já falei sobre isto em outros tópicos. Para mim, este é um erro que as empresas cometem, colocar o gerente de projetos em uma posição hierarquicamente superior e longe da equipe. Ele deve conhecer no dia a dia os problemas da equipe e ser uma referência, um líder, não um símbolo de autoridade subscrito por determinação burocrática. Agora, acho que o cara que está com a equipe deva ser um cara com formação voltada para a gestão, com conhecimentos técnicos básicos, porque vai conseguir dar parecer em questões como contratação de funcionários para a equipe, formas e canais de comunicação, viabilidade economico-financeira do projeto, fornecer subsídios para tomada de decisão do(s) dono(s) do negócio, estar em contato com o cliente e saber reportar para a equipe e tomar decisão em conjunto, levando para o patrocinador.

Mas para isto funcionar a estrutura tem que ser propícia, preferencialmente projetizada. No fundo, você deve seguir o processo estabelecido para a empresa, e é muito difícil um empreendedor deixar a “estrutura comando/controle”, porque é a que menos oferece risco para o negócio, ele só precisa ter uma pessoa de confiança. Funciona desde a revolução industrial e muito bem em áreas que tem padrões estabelecidos, como tínhamos discutido anteriormente.

Ficarei feliz em falar para o criador do post o que penso, pelo menos do título já vou reclamar, visto que ainda não li o texto

Mas pode ser que no fim acabe concordando com o ponto de vista dele, vai saber? Eu sou teimoso, mas quando algo faz sentido no meu ponto de vista eu costumo mudar de opinião sobre certas coisas, ou ao menos considerá-las em um contexto, afinal não sou dono da verdade. Mas tenho uns bons anos de experiência e essencialmente em gestão, já estudei a parte técnica, mas sempre foi uma questão de vocação, então modéstia a parte, o cara tem que ser bom para me convencer, porque passei boa parte da vida estudando isto.

E assim como eu tenho uma resistência para aceitar uma equipe sem “gerente”, mas dentro da estrutura que eu lhe falei, muitos dos programadores normalmente são bastante intelectualizados e tem dificuldade em receber ordens, por isto querem mudar a estrutura, como também já falei anteriormente.

É ´tudo a mesma merdaaaaaaaa

lol

Não digo que esta estrutura não possa acontecer, mas é uma estrutura bastante arriscada pela própria formação e mudança do grupo em relação ao tempo. O que vai acontecer quando saírem algumas pessoas e entrarem outras que não tem os valores do SCRUM? Sem contar em tudo aquilo que já coloquei anteriormente sobre mudança de um grupo e etc.

O Scrum ainda é muito novo para se colocar como uma consolidação de mercado para a área de TI, embora o ágil, em essência, faça bastante sentido e seja aplicável em muitas empresas do segmento e até de outros, não se pode abolir ou descartar algo que já é consolidado há muitos anos, por isto que eu digo, sempre depende do contexto, não tem melhor ou pior em relação a processos, principalmente empresariais, sempre vai depender da cultura, da própria vontade do empreendedor, da disposição em assumir riscos, do número de funcionários e tantos outros fatores que se possam imaginar, quem diz isto é porque ou tem más intenções ou quer aproveitar da ignorância alheia em benefício próprio.

@felipefranz, então você tem uma visão semelhante a minha quanto ao gerente, mas concorda que falando de “gerentes tradicionais” essa é uma raridade? A própria estrutura hierárquica não permite que o gerente esteja lado a lado da equipe 100% do tempo. Repare que o problema é o controle, não um líder. E isso leva à uma indicação clara da diferença entre o SM e o gerente: você conhece algum gerente que foi “eleito” para o papel de líder pela própria equipe?

Sobre os demais afazeres do gerente que você citou, não há porque a comunicação com o cliente não ser feita pelo próprio time, incluindo os assuntos financeiros (trabalho do Product Owner, que também é parte do time), então o time não precisa do gerente fazendo o papel de intermediário.

Entendo que nossa discussão aqui não vai fazer as empresas mudarem sua estrutura da noite para o dia, mas podemos levantar: esse modelo hierárquico baseado em comando controle é uma boa opção? Pra quem? Como você disse, ele vem de muitos anos atrás, mas será esse o melhor modelo? Até quando? É complicado conceber um modelo muito diferente ao qual estamos acostumados, mas quando ele começa a incomodar, levantamos possibilidades que ontem eram inconcebíveis, e hoje são malucas, mas o que serão amanhã?

Essa resistência por parte dos programadores acontece porque muitas vezes quem dá a ordem nem ao menos considera a opinião do programador. O caso é que há muitas formas de lidar com a pessoas, e pessoas que trabalham com conhecimento são diferenciadas. Um bom desenvolvedor não faz por fazer (o famoso “code monkey”), ele quer aprender sobre o negócio, e então cruzar o conhecimento adquirido com o técnico e daí propor a melhor solução. Uma ordem vinda de uma pessoa que não tem todo esse conhecimento bate de frente com essa visão, o que pode gerar muitos conflitos e insatisfação. Nesse caso, deixar a equipe coordenar o próprio trabalho não pode ser a melhor opção?

E GP não precisa estar também. O fato de não estar ‘acima’, não faz ele deixar de ser gerente de projeto.

@felipefranz, então você tem uma visão semelhante a minha quanto ao gerente, mas concorda que falando de “gerentes tradicionais” essa é uma raridade?

Concordo, especialmente porque isto normalmente significa redução de salário, o que também não faz o menor sentido, você continua desempenhando o mesmo papel e com a mesma responsabilidade.

A própria estrutura hierárquica não permite que o gerente esteja lado a lado da equipe 100% do tempo. Repare que o problema é o controle, não um líder. E isso leva à uma indicação clara da diferença entre o SM e o gerente: você conhece algum gerente que foi “eleito” para o papel de líder pela própria equipe?

Eleito não, aceito sim. Mas aí também entra a questão: a equipe também vai fazer parte do rh selecionando as pessoas que vão trabalhar nela? Se não, elas também não foram eleitas para fazer parte daquela equipe. Esta estrutura vai dar o controle da própria administração da área para a equipe, dificilmente um empreendedor vai ver isto com bons olhos. Também tem a questão de capacitação, a equipe tem que focar no core, na parte técnica, ela não tem competência para tomar decisões relacionadas a gestão, assim como um profissional de rh não sabe dizer qual é a melhor tecnologia para satisfazer a necessidade x.

Sobre os demais afazeres do gerente que você citou, não há porque a comunicação com o cliente não ser feita pelo próprio time, incluindo os assuntos financeiros (trabalho do Product Owner, que também é parte do time), então o time não precisa do gerente fazendo o papel de intermediário.

Aí entra uma questão interessante. No gerenciamento de projetos está sendo levado cada vez mais em consideração a comunicação bottom up ao invés de top down, tecnicamente é a descentralização da comunicação sobre o projeto. Isto diminui, mas na minha visão não elimina a necessidade de alguém que esteja no dia a dia do projeto e consiga fornecer análises e informações importantes para o PO, patrocinador ou seja lá quem for tomar decisão, como por exemplo EVA do projeto, os indicadores financeiros: Tir, VPL, Payback, análise de CAPM, VME dos riscos, são informações importantísssimas para um projeto e dificilmente um PO vai saber dar, ele está mais alto nível, na parte estratégica do projeto, atuando como stakeholder para o SM e a equipe, ao meu ver, ele normalmente é um usuário das informações.

Agora, questões que exigem certos conhecimentos e habilidades específicas acho por enquanto um pouco complicado a própria equipe assumir porque não é o foco dela. Isto exige estudo e experiência, assim como qualquer área e pode fazer com que a equipe acabe deixando um pouco de desenvolver para ter que resolver as questões gerenciais, acho que o modelo em que cada um se preocupa com seu core business mais eficaz, embora a visão generalista seja bastante importante. A questão é ter um certo controle sobre o projeto e conseguir prover informações para que o tomador de decisão tenha embasamento, normalmente esta é uma tarefa um pouco complicada.

Também depende muito da complexidade do projeto em si, um projeto aeroespacial por exemplo, tem uma complexidade tamanha que normalmente há vários “gerentes de projeto” cada um focado em uma área do conhecimento, um cara que trabalha só com riscos, outro para tratar de aquisições, outro para escopo e etc. Isto também é importante para saber quem é responsável pelo quê, em uma equipe sem uma figura que distribua responsabilidades isto pode ficar um pouco perdido, embora possa funcionar com muita organização.

Entendo que nossa discussão aqui não vai fazer as empresas mudarem sua estrutura da noite para o dia, mas podemos levantar: esse modelo hierárquico baseado em comando controle é uma boa opção? Pra quem? Como você disse, ele vem de muitos anos atrás, mas será esse o melhor modelo? Até quando? É complicado conceber um modelo muito diferente ao qual estamos acostumados, mas quando ele começa a incomodar, levantamos possibilidades que ontem eram inconcebíveis, e hoje são malucas, mas o que serão amanhã?

Claro, todo este estudo é válido e com certeza tem demanda para aplicação de um novo modelo, agora o difícil é responder as suas perguntas

Essa resistência por parte dos programadores acontece porque muitas vezes quem dá a ordem nem ao menos considera a opinião do programador. O caso é que há muitas formas de lidar com a pessoas, e pessoas que trabalham com conhecimento são diferenciadas. Um bom desenvolvedor não faz por fazer (o famoso “code monkey”), ele quer aprender sobre o negócio, e então cruzar o conhecimento adquirido com o técnico e daí propor a melhor solução. Uma ordem vinda de uma pessoa que não tem todo esse conhecimento bate de frente com essa visão, o que pode gerar muitos conflitos e insatisfação. Nesse caso, deixar a equipe coordenar o próprio trabalho não pode ser a melhor opção?

Se ela tiver conhecimentos e habilidades suficientes para lidar com questões de gestão e atender as expectativas da empresa e seus stakeholders, não vejo problema nenhum e pode ser sim a melhor opção, o difícil é chegar lá, normalmente a pessoa tem um foco muito especialista ou generalista, reunir os dois é bem difícil, embora não seja impossível.

von.juliano:

@felipefranz, então você tem uma visão semelhante a minha quanto ao gerente, mas concorda que falando de “gerentes tradicionais” essa é uma raridade? A própria estrutura hierárquica não permite que o gerente esteja lado a lado da equipe 100% do tempo. Repare que o problema é o controle, não um líder. E isso leva à uma indicação clara da diferença entre o SM e o gerente: você conhece algum gerente que foi “eleito” para o papel de líder pela própria equipe?

Sobre os demais afazeres do gerente que você citou, não há porque a comunicação com o cliente não ser feita pelo próprio time, incluindo os assuntos financeiros (trabalho do Product Owner, que também é parte do time), então o time não precisa do gerente fazendo o papel de intermediário.

Entendo que nossa discussão aqui não vai fazer as empresas mudarem sua estrutura da noite para o dia, mas podemos levantar: esse modelo hierárquico baseado em comando controle é uma boa opção? Pra quem? Como você disse, ele vem de muitos anos atrás, mas será esse o melhor modelo? Até quando? É complicado conceber um modelo muito diferente ao qual estamos acostumados, mas quando ele começa a incomodar, levantamos possibilidades que ontem eram inconcebíveis, e hoje são malucas, mas o que serão amanhã?

Essa resistência por parte dos programadores acontece porque muitas vezes quem dá a ordem nem ao menos considera a opinião do programador. O caso é que há muitas formas de lidar com a pessoas, e pessoas que trabalham com conhecimento são diferenciadas. Um bom desenvolvedor não faz por fazer (o famoso “code monkey”), ele quer aprender sobre o negócio, e então cruzar o conhecimento adquirido com o técnico e daí propor a melhor solução. Uma ordem vinda de uma pessoa que não tem todo esse conhecimento bate de frente com essa visão, o que pode gerar muitos conflitos e insatisfação. Nesse caso, deixar a equipe coordenar o próprio trabalho não pode ser a melhor opção?

Isso é uma discussão de ‘como é’ e ‘como eu gostaria que fosse’. Você está olhando o mundo perfeito, onde toda a equipe consegue ser auto gerenciada, jamais vai existir conflito, os clientes vão saber o que querem e serem objetivos, o product owner (ou sponsor) vai sempre ter tempo de recebê-los e compreender suas necessidades, o cliente vai aceitar escopo variável e preço e prazo variável, todo mundo vai se dar as mãos e cantar ‘we are the world’, etc.

No mundo real você vai encontrar vários casos que não caem nessas regras e a equipe vai ter de usar suas habilidades de comunicação e liderança pra conseguir fazer do projeto o sucesso.

marcosalex:

von.juliano:

@felipefranz, então você tem uma visão semelhante a minha quanto ao gerente, mas concorda que falando de “gerentes tradicionais” essa é uma raridade? A própria estrutura hierárquica não permite que o gerente esteja lado a lado da equipe 100% do tempo. Repare que o problema é o controle, não um líder. E isso leva à uma indicação clara da diferença entre o SM e o gerente: você conhece algum gerente que foi “eleito” para o papel de líder pela própria equipe?

Sobre os demais afazeres do gerente que você citou, não há porque a comunicação com o cliente não ser feita pelo próprio time, incluindo os assuntos financeiros (trabalho do Product Owner, que também é parte do time), então o time não precisa do gerente fazendo o papel de intermediário.

Entendo que nossa discussão aqui não vai fazer as empresas mudarem sua estrutura da noite para o dia, mas podemos levantar: esse modelo hierárquico baseado em comando controle é uma boa opção? Pra quem? Como você disse, ele vem de muitos anos atrás, mas será esse o melhor modelo? Até quando? É complicado conceber um modelo muito diferente ao qual estamos acostumados, mas quando ele começa a incomodar, levantamos possibilidades que ontem eram inconcebíveis, e hoje são malucas, mas o que serão amanhã?

Essa resistência por parte dos programadores acontece porque muitas vezes quem dá a ordem nem ao menos considera a opinião do programador. O caso é que há muitas formas de lidar com a pessoas, e pessoas que trabalham com conhecimento são diferenciadas. Um bom desenvolvedor não faz por fazer (o famoso “code monkey”), ele quer aprender sobre o negócio, e então cruzar o conhecimento adquirido com o técnico e daí propor a melhor solução. Uma ordem vinda de uma pessoa que não tem todo esse conhecimento bate de frente com essa visão, o que pode gerar muitos conflitos e insatisfação. Nesse caso, deixar a equipe coordenar o próprio trabalho não pode ser a melhor opção?

Isso é uma discussão de ‘como é’ e ‘como eu gostaria que fosse’. Você está olhando o mundo perfeito, onde toda a equipe consegue ser auto gerenciada, jamais vai existir conflito, os clientes vão saber o que querem e serem objetivos, o product owner (ou sponsor) vai sempre ter tempo de recebê-los e compreender suas necessidades, o cliente vai aceitar escopo variável e preço e prazo variável, todo mundo vai se dar as mãos e cantar ‘we are the world’, etc.

No mundo real você vai encontrar vários casos que não caem nessas regras e a equipe vai ter de usar suas habilidades de comunicação e liderança pra conseguir fazer do projeto o sucesso.

Isto me lembra aquela velha máxima de que toda metodologia é composta por processos, pessoas e tecnologia, quanto pior uma estiver as outras terão mais trabalho para garantir a entrega do projeto. Se você não tem processos bem definidos, você está colocando tudo na mão das pessoas e da tecnologia. Aí vem aquela velha história da dependência dos heróis que sustentam a empresa nos ombros.

O processo serve justamente para salvaguardar a pessoa em momentos de tensão e pressão do cliente, se a empresa cede o processo em virtude da pressão, ou a metodolgia não está funcionando por disfunção burocrática e neste caso devem ser feitos ajustes ou a empresa não tem maturidade para seguir uma metodologia.

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

++

Ano passado estava estudando para tirar o ITL v3, então pensei: “Se eu tiver uma certificação dessa na cartela, terei vergonha de dizer que tenho”, então, desisti dela.

@felipefranz … especialmente porque isto normalmente significa redução de salário …

Essa é outra grande diferença entre o gerente e o SM - e que de mais uma forma, afasta o gerente do time. E se torna um problema sério quando o gerente não ajuda e só cobra, por ganhar mais e não fazer nada.

Entendo que seja preciso alguem que faça alguns serviços mais burocráticos, mas usando um dos exemplos que você deu, eu creio que a equipe deve ser responsável por selecionar novos membros (selecionar, não fazer os trâmites da contratação). Não faz sentido o gerente selecionar é mais adequado para trabalhar com aquela equipe, quando a própria sabe melhor do que ele que tipo de talento eles precisam.

Quando você diz questões gerenciais, quais você acha que uma equipe ágil não daria conta sem um gerente? As que você disse que precisam de conhecimentos e habilidades específicas?

@marcosalex a discussão é sobre uma possível forma de trabalho e se é possível alcançá-la. Todos sabemos como são as coisas hoje, e tudo o que você levantou são os pontos que o Agile foi concebido para combater. Claro que não funciona para todos, e mesmo métodos ageis falham, mas se ninguém tentar mudar, tudo o que está errado permanece.

@felipefranz[i] Isto me lembra aquela velha máxima de que toda metodologia é composta por processos, pessoas e tecnologia, quanto pior uma estiver as outras terão mais trabalho para garantir a entrega do projeto. Se você não tem processos bem definidos, você está colocando tudo na mão das pessoas e da tecnologia. Aí vem aquela velha história da dependência dos heróis que sustentam a empresa nos ombros.

O processo serve justamente para salvaguardar a pessoa em momentos de tensão e pressão do cliente, se a empresa cede o processo em virtude da pressão, ou a metodolgia não está funcionando por disfunção burocrática e neste caso devem ser feitos ajustes ou a empresa não tem maturidade para seguir uma metodologia. [/i]

Acho que temos visões completamente opostas sobre esse ponto. A primeira “lei” de Agile diz que pessoas são mais importantes do que processos, e repare que desde que começamos a discussão eu defendo esse lado. Esse seu ultimo post, me leva a crer que a empresa onde você trabalha é bastante conservadora e deve seguir métodos bastante rígidos, e se for isso mesmo, entendo como e porque defende esse lado. Eu levaria muito tempo escrevendo sobre o que penso sobre isso, então te convido a conversarmos sobre isso por email, acho que temos muito a aprender um com o outro.

Campe?2011:

É ´tudo a mesma merdaaaaaaaa

lol

lol ++

Campe?2011:

Campe?2011:

É ´tudo a mesma merdaaaaaaaa

lol

lol ++

E eu que ainda sou obrigado a ouvir em entrevistas: “eu sou ativo na comunidade, tenho muitos posts no GUJ”

Para quem está discutindo o assunto em questão, ignore-nos. A discussão está agregando bastante

Desculpe, nao tenho a intencao de ser ofensivo, so serei mais enfatico.

Esta frase me faz acreditar que, ou voce so possui conhecimento teorico, baseado no modelo de gestao tradicional, ou, pior ainda, voce gerencia baseando-se em relatorios de inputs falsos.

Eu ja trabalhei em empresas que possuem CMMI 3, com projetos seguindo rigorosamente o CMMI 3, que foram auditados e participaram da avaliacao da certificacao. E te digo de cadeira, o simples fato de possuir CMMI 3 ou 4 ou 5 nao garante NADA.

A unica coisa que o CMMI garante eh que voce tem um processo, segue aquele processo a risca, consegue comprovar que segue a risca, e para os projetos que voce diz que segue a risca. Se o processo eh bom, ruim, mais ou menos, pessimo ou excelente pouco importa ao CMMI, desde que voce siga sempre o processo que voce determinou.

Voce pode usar Kanban, Scrum, RUP, Cascata ou seja la o que for, desde que siga aquele processo.

Entao, voce pode ver e pode ver MUITA inconsistencia em areas que utilizam CMMI. Pode ver porque os dados podem ser maquiados pela equipe tecnica, digo porque eu mesmo ja maquiei dados. Nao de forma desonesta, digo maquiar quando a metrica “automatizada” dos pontos de caso de uso me dizem que determinada funcionalidade vai levar 5 dias pra ficar pronta e a minha experiencia me diz que nao leva mais do que dois. Entao eu “minto” para os pontos de caso de uso ate que eles cheguem a 2 dias.

Ah, mas entao os pontos de caso de uso estao errados. Voce vai dizer. Sim, estao errados e precisaria de uma complexidade absurda, quase inalcancavel para que eles estivessem certos. Usar da experiencia da equipe é bem mais simples e eficaz, mas o processo nao permitia isso. Eu tinha que ter uma forma “automatizada” de estimar.

Ah, mas entao o processo adotado pela empresa estava errado, voce vai dizer. Nao, nao estava. Pelo menos nao para o CMMI nivel 3 que voce citou como exemplo de processos bem definidos.

E muitos dos processos fantasticos, supostamente consistentes com as medicoes, nao refletiam a realidade.

E sobre as metricas? Estavam todas la, repletas de maquiagem, com dados desvirtuados e irreais. E nao pense que nós nao diziamos isso aos diretores. Mas como a velocidade do desenvolvimento, nem a qualidade do produto final eram prioridade na empresa, embora o discurso sempre dissesse que eram, as coisas iam seguindo assim. Certificados e ineficientes.

Entao, por favor, CMMI nao garante processo bem feito, garante que tem processo.

So existe uma metrica boa em desenvolvimento de software. Software funcionando, validade pelo usuario. O resto é papagaiada. Se voce me vem com um grafico todo coloridinho indicando 40% do projeto pronto eu rasgo e jogo no lixo, eu quero ver os 40% funcionando. Ah nao tem 40%? Entao eu quero ver o que voce pode me demonstrar. Ah, nao pode demonstrar nada ainda? Entao tem 0% pronto.

RH selecionando pessoas para area tecnica? Isso pra mim é inconcebivel. Por isso que voce ve tanta provinha besta, cheia de pegadinhas de certificacao em processsos de selecao das empresas. O que isso mede? nada, absolutamente nada.

Meia hora de conversa com um desenvolvedor e qualquer um com conhecimento tecnico suficiente vai saber avaliar uma pessoa melhor do que qualquer prova. Se eu perguntar para o sujeito algo especifico sobre determinada metodologia, nao tem blablabla que ele possa armar pra enrolar ninguem. Pergunto A ele tem que responder A ou dizer que nao sabe, se ele tentar responder B eu descubro na hora que é lorota.

Ninguem de RH nenhum, nem gerente nenhum (sem conhecimento tecnico) tem essa capacidade que nos desenvolvedores temos.

Se depois vai passar por uma conversa com o GP ou com o RH é outra historia, mas a entrevista tecnica tem que acontecer e acontecer cara a cara, com quem conhece do assunto.

Não, isso é um papel, o fato de fazer ou não isso, não faz uma pessoa deixar de ser gerente.

A primeira “lei” de Agile diz que pessoas são mais importantes do que processos, por isso são importantes

Errado, pessoas são parte do processo. Querer separar os dois é uma distorção que você está fazendo, e que agile ou não-agile não defendem isso.

Desculpe, nao tenho a intencao de ser ofensivo, so serei mais enfatico.

Esta frase me faz acreditar que, ou voce so possui conhecimento teorico, baseado no modelo de gestao tradicional, ou, pior ainda, voce gerencia baseando-se em relatorios de inputs falsos.

Eu ja trabalhei em empresas que possuem CMMI 3, com projetos seguindo rigorosamente o CMMI 3, que foram auditados e participaram da avaliacao da certificacao. E te digo de cadeira, o simples fato de possuir CMMI 3 ou 4 ou 5 nao garante NADA.

A unica coisa que o CMMI garante eh que voce tem um processo, segue aquele processo a risca, consegue comprovar que segue a risca, e para os projetos que voce diz que segue a risca. Se o processo eh bom, ruim, mais ou menos, pessimo ou excelente pouco importa ao CMMI, desde que voce siga sempre o processo que voce determinou.

Voce pode usar Kanban, Scrum, RUP, Cascata ou seja la o que for, desde que siga aquele processo.

Entao, voce pode ver e pode ver MUITA inconsistencia em areas que utilizam CMMI. Pode ver porque os dados podem ser maquiados pela equipe tecnica, digo porque eu mesmo ja maquiei dados. Nao de forma desonesta, digo maquiar quando a metrica “automatizada” dos pontos de caso de uso me dizem que determinada funcionalidade vai levar 5 dias pra ficar pronta e a minha experiencia me diz que nao leva mais do que dois. Entao eu “minto” para os pontos de caso de uso ate que eles cheguem a 2 dias.

Ah, mas entao os pontos de caso de uso estao errados. Voce vai dizer. Sim, estao errados e precisaria de uma complexidade absurda, quase inalcancavel para que eles estivessem certos. Usar da experiencia da equipe é bem mais simples e eficaz, mas o processo nao permitia isso. Eu tinha que ter uma forma “automatizada” de estimar.

Ah, mas entao o processo adotado pela empresa estava errado, voce vai dizer. Nao, nao estava. Pelo menos nao para o CMMI nivel 3 que voce citou como exemplo de processos bem definidos.

E muitos dos processos fantasticos, supostamente consistentes com as medicoes, nao refletiam a realidade.

E sobre as metricas? Estavam todas la, repletas de maquiagem, com dados desvirtuados e irreais. E nao pense que nós nao diziamos isso aos diretores. Mas como a velocidade do desenvolvimento, nem a qualidade do produto final eram prioridade na empresa, embora o discurso sempre dissesse que eram, as coisas iam seguindo assim. Certificados e ineficientes.

Entao, por favor, CMMI nao garante processo bem feito, garante que tem processo.

So existe uma metrica boa em desenvolvimento de software. Software funcionando, validade pelo usuario. O resto é papagaiada. Se voce me vem com um grafico todo coloridinho indicando 40% do projeto pronto eu rasgo e jogo no lixo, eu quero ver os 40% funcionando. Ah nao tem 40%? Entao eu quero ver o que voce pode me demonstrar. Ah, nao pode demonstrar nada ainda? Entao tem 0% pronto.

RH selecionando pessoas para area tecnica? Isso pra mim é inconcebivel. Por isso que voce ve tanta provinha besta, cheia de pegadinhas de certificacao em processsos de selecao das empresas. O que isso mede? nada, absolutamente nada.

Meia hora de conversa com um desenvolvedor e qualquer um com conhecimento tecnico suficiente vai saber avaliar uma pessoa melhor do que qualquer prova. Se eu perguntar para o sujeito algo especifico sobre determinada metodologia, nao tem blablabla que ele possa armar pra enrolar ninguem. Pergunto A ele tem que responder A ou dizer que nao sabe, se ele tentar responder B eu descubro na hora que é lorota.

Ninguem de RH nenhum, nem gerente nenhum (sem conhecimento tecnico) tem essa capacidade que nos desenvolvedores temos.

Se depois vai passar por uma conversa com o GP ou com o RH é outra historia, mas a entrevista tecnica tem que acontecer e acontecer cara a cara, com quem conhece do assunto.

Na minha visão, isto foi de certa forma incompetência do avaliador do CMMI. Porque ele tem a liberdade de reprovar a empresa, mesmo que esteja seguindo um processo mais ou menos a risca, mas ele vê que é insustentável para a empresa, o esforço é grande para manter, além disto tem a recertificação a cada 3 anos, se a empresa está atrasando os projetos para seguir o processo ou fazendo muita hora extra, o avaliador deveria verificar isto, afinal ele fica 40 horas a cada 3 anos focado somente em olhar dados históricos.

A empresa pode maquiar tudo? Pode, mas se o cara é experiente, ele pega nas entrevistas com as pessoas, depois de anos de experiência em avaliações, o cara tem faro para isto. Sem contar que a empresa está dando um tiro no pé, está fazendo um “pró forma” só para poder participar de editais internacionais ou ter um pouco mais de credibilidade no mercado, mas a longo prazo, esta farsa tende a matar a competitividade.

A métrica não é feita para você, é feita para quem toma decisão, para ele é importante saber se o projeto está só 40% pronto quando deveria estar 70% para poder tomar alguma ação, não tem a haver com as funcionalidades, tem mais a haver com a gestão de portfólio, que está diretamente ligada a mercado e dinheiro, e é fonte de informação para o dono do negócio.

von.juliano:

@felipefranz … especialmente porque isto normalmente significa redução de salário …

Essa é outra grande diferença entre o gerente e o SM - e que de mais uma forma, afasta o gerente do time. E se torna um problema sério quando o gerente não ajuda e só cobra, por ganhar mais e não fazer nada.

Entendo que seja preciso alguem que faça alguns serviços mais burocráticos, mas usando um dos exemplos que você deu, eu creio que a equipe deve ser responsável por selecionar novos membros (selecionar, não fazer os trâmites da contratação). Não faz sentido o gerente selecionar é mais adequado para trabalhar com aquela equipe, quando a própria sabe melhor do que ele que tipo de talento eles precisam.

Quando você diz questões gerenciais, quais você acha que uma equipe ágil não daria conta sem um gerente? As que você disse que precisam de conhecimentos e habilidades específicas?

@marcosalex a discussão é sobre uma possível forma de trabalho e se é possível alcançá-la. Todos sabemos como são as coisas hoje, e tudo o que você levantou são os pontos que o Agile foi concebido para combater. Claro que não funciona para todos, e mesmo métodos ageis falham, mas se ninguém tentar mudar, tudo o que está errado permanece.

@felipefranz[i] Isto me lembra aquela velha máxima de que toda metodologia é composta por processos, pessoas e tecnologia, quanto pior uma estiver as outras terão mais trabalho para garantir a entrega do projeto. Se você não tem processos bem definidos, você está colocando tudo na mão das pessoas e da tecnologia. Aí vem aquela velha história da dependência dos heróis que sustentam a empresa nos ombros.

O processo serve justamente para salvaguardar a pessoa em momentos de tensão e pressão do cliente, se a empresa cede o processo em virtude da pressão, ou a metodolgia não está funcionando por disfunção burocrática e neste caso devem ser feitos ajustes ou a empresa não tem maturidade para seguir uma metodologia. [/i]

Acho que temos visões completamente opostas sobre esse ponto. A primeira “lei” de Agile diz que pessoas são mais importantes do que processos, e repare que desde que começamos a discussão eu defendo esse lado. Esse seu ultimo post, me leva a crer que a empresa onde você trabalha é bastante conservadora e deve seguir métodos bastante rígidos, e se for isso mesmo, entendo como e porque defende esse lado. Eu levaria muito tempo escrevendo sobre o que penso sobre isso, então te convido a conversarmos sobre isso por email, acho que temos muito a aprender um com o outro.

Com certeza, sempre bom poder conversar com quem tenha uma visão diferente. Vou mandar e-mail por mensagem privada.

E o meu conhecimento é com gerenciamento de projeto da implantação do CMMI, aqui tem funcionado muito bem, porque nós envolvemos a equipe no desenho do processo e toda a “burocracia” foi montada para garantir que coisas necessárias, como desenho de tela por exemplo, fossem entregues para a equipe no momento correto. Sempre foi visto o custo/benefício de tudo que foi implementado.

Tem coisas que dão trabalho, como rastreabilidade e configuração no nível 2, code review e requisitos no nível 3, mas o custo/benefício quando bem implementado é bastante positivo. Para saber isto você mede a redução de retrabalho (bugs, correção de estórias e etc) em relação ao trabalho adicional.

Dá uma olhada no http://agilemanifesto.org/ e você vai ver como primeiro valor: Individuals and interactions over processes and tools, o que quer dizer que as pessoas e as interações entre elas são mais importantes do que processos e ferramentas. Se não estiver claro o suficiente, é só falar.

Entao, voce pode ver e pode ver MUITA inconsistencia em areas que utilizam CMMI. Pode ver porque os dados podem ser maquiados pela equipe tecnica, digo porque eu mesmo ja maquiei dados. Nao de forma desonesta, digo maquiar quando a metrica “automatizada” dos pontos de caso de uso me dizem que determinada funcionalidade vai levar 5 dias pra ficar pronta e a minha experiencia me diz que nao leva mais do que dois. Entao eu “minto” para os pontos de caso de uso ate que eles cheguem a 2 dias.

Isto é uma forma desonesta, na verdade é a pior delas para a empresa. Em vez de usar sua experiência para melhorar o processo de estimativa, você está burlando para que chegue no tempo que você quer baseado na sua experiência.

A vantagem de fazer um processo de estimativa é justamente ter um resultado mais preciso que somente com a experiência, tem inúmeros casos onde um cara sênior pega uma histórias do legado, faz pelo processo de estimativas que foi montado pela empresa e pela experiência dele e depois vê o realizado e o processo de estimativa acertou melhor do que ele, e o melhor que o número será o mesmo (em tamanho) para um júnior, o que vai mudar é a produtividade.

Para isto, são necessários vários ajustes pelo feedback das pessoas que estão estimando o processo até que ele se chegue a um número mais preciso, no nível 4 é feito controle estatístico do processo para delimitar o desvio padrão da estimativa. Quando você burla algo, você está matando o processo, quando teria uma informação útil para melhorá-lo.

Se você não concorda com o processo, não deveria trabalhar na empresa que adotou o processo. Projeto não é questão de gosto, você tem que se adaptar as políticas da empresa.

Fico aguardando!

Dá uma olhada no http://agilemanifesto.org/ e você vai ver como primeiro valor: Individuals and interactions over processes and tools, o que quer dizer que as pessoas e as interações entre elas são mais importantes do que processos e ferramentas. Se não estiver claro o suficiente, é só falar.

Mas isto é bastante óbvio, já que são as pessoas que usam as ferramentas e os processos. Mas uma empresa deveria se preocupar em ter bons processos e tecnologia também, quando eu digo que o pilar é formado pelos três é o cenário ideal, na maior parte das empresas são as pessoas que tem que cobrir tudo.

johnny quest:

Conheci alguns PMPs e única constante que notei em todos é a seguinte frase de efeito:

“ESTÁ PRONTO ?” Passasse 15 minutos e novamente o tal PMP certificado chega na nossa mesa e diz as palavras
mágicas: “ESTÁ PRONTO ?” Passasse mais 20 minutos e adivinha quem voltou ? Sim sim, novamente o PMP
perguntando: “ESTÁ PRONTO ?”

Fico imaginando porque as empresas não contratam de uma vez um PAPAGAIO, porque um papagaio
pode repetir ESTÁ PRONTO N vezes seguidas, e o melhor, a empresa não precisaria pagar mais de 7K para
um cara que só sabe repetir ESTÁ PRONTO ?

Ao menos para um papagaio ração e água já são suficientes…

O problema nao esta no avaliador, a empresa cumpriu exatamente aquilo que se propos a cumprir. O problema esta no modelo de avaliacao que nao gatante nada.

A métrica não é feita para você, é feita para quem toma decisão, para ele é importante saber se o projeto está só 40% pronto quando deveria estar 70% para poder tomar alguma ação, não tem a haver com as funcionalidades, tem mais a haver com a gestão de portfólio, que está diretamente ligada a mercado e dinheiro, e é fonte de informação para o dono do negócio.

Eu nao disse nada contra a metrica, eu nao sou contra a metrica. Em nenhum momento eu disse que ninguem precisa saber o quanto do projeto esta pronto. O que eu disse foi que a unica metrica confiavel que existe em desenvolvimento de software é software funcionando. Se voce nao ve software funcionando, aquele monte de papel dizendo que tem 40 ou 90% prontos nao serve pra nada.

Se voce acredita quando um desenvolvedor te fala que o projeto esta 50% pronto e toma decisoes baseadas nisso (seja la de que forma ele te disser, falando, por email, ou por um milhao de fontes de dados de origens diferentes todas convergindo num relatorio maravilhoso), voce muito provavelmente vai tomar decisoes erradas.

So software funcionando te da nocao do que esta pronto e do que nao esta. Qualquer outra forma de medir cedo ou tarde vai cobrar seu preco.

Mas o problema é que na maioria das vezes é estabelecido um processo rígido que deve ser seguido à risca, e isso por si só se torna problemático, pois acaba que as pessoas tem de se encaixar nos papéis do processo, quando ele deveria ser uma ferramenta para ajudar as pessoas. Sem contar que um processo engessado não é “alterável” (e quando é, demora eras), o que impede sugestões para melhorias, tentativas e experimentações, já que essas estão fora do processo.

Talvez você me diga que onde trabalha o processo seja possivelmente alterado, mas quando é o caso, quanto tempo demora para isso acontecer? Um processo assim geralmente leva muito tempo para ser estabelecido, e não sei se as pessoas que o conceberam o vêem como um filho ou como “a solução perfeita” que custou uma fortuna, pq muitas delas não querem que ele seja mudado. Eu vejo um processo assim como um elefante branco.

O problema nao esta no avaliador, a empresa cumpriu exatamente aquilo que se propos a cumprir. O problema esta no modelo de avaliacao que nao gatante nada.

Nenhum modelo garante nada na prática, visto que todos são passíveis de pró forma. Se a empresa quer ter a certificação somente por edital ela vai perder uma boa oportunidade de organizar a gestão e dar um tiro no pé a longo prazo por competitividade, embora como eu já tenha colocado, o avaliador tem a liberdade de reprovar a empresa se não sentir confiança que o processo está sendo seguido, seja útil para a empresa e é mantido sem “fraudes”.

Ops, um leve indicio do velho conceito “peao nao sabe de nada” aqui?

Nenhum, em nenhum momento eu falei em peao e nem em falta de conhecimento. É uma questão de papéis e responsabilidades, se a empresa tem uma política e não está na sua descrição de cargos alterá-la sem consultar os outros ou fazer as coisas ao seu gosto, você não pode fazê-las, simples assim. O programador pode sim ter um bom conhecimento em métricas, processos, regras de negócio, mas ele deve consultar a pessoa responsável para alterar os processos.

Mais ou menos como as leis em um país, você pode ser a favor da legalização das drogas, mas não pode usá-las enquanto estiver descrito.

Eu nao disse nada contra a metrica, eu nao sou contra a metrica. Em nenhum momento eu disse que ninguem precisa saber o quanto do projeto esta pronto. O que eu disse foi que a unica metrica confiavel que existe em desenvolvimento de software é software funcionando. Se voce nao ve software funcionando, aquele monte de papel dizendo que tem 40 ou 90% prontos nao serve pra nada.

Mas esta é a sua opinião. Eu discordo totalmente de você, o software funcionando tem ligação direta com um monte de métricas como densidade de defeitos, satisfação da equipe, próprias métricas de requisitos funcionais e não funcionais implementados, no fim todas as métricas dão suporte para que o software esteja funcionando. Até porque software funcionando é bem subjetivo. Quem garante que os requisitos implementados são de fato aqueles que o cliente queria? Quais são os usuários do sistema, é o cliente que especificou os requisitos? Será que o software não tem bugs desconhecidos?

Se voce acredita quando um desenvolvedor te fala que o projeto esta 50% pronto e toma decisoes baseadas nisso (seja la de que forma ele te disser, falando, por email, ou por um milhao de fontes de dados de origens diferentes todas convergindo num relatorio maravilhoso), voce muito provavelmente vai tomar decisoes erradas.

O que pode acontecer é as estimativas terem sido mal feitas ou a pessoa burlar o apontamento de horas, mas se estiverem corretas a tomada de decisão tende a ser correta, ou ao menos melhor que se fosse feita sem estas medidas. E isto não é mutuamente excludente com questões como entregas parciais, por exemplo.

So software funcionando te da nocao do que esta pronto e do que nao esta. Qualquer outra forma de medir cedo ou tarde vai cobrar seu preco.

Esta também é sua opinião, discordo totalmente. Todas as outras medidas com medidas em relação a software (defeitos, requisitos implementados, satisfação do cliente) formam um conjunto para tomar decisões, inclusive a satisfação e motivação da equipe. De que adianta um software funcionando se ao final do projeto tá todo mundo insatisfeito, desmotivado e cansado?

Eu concordo. Trabalhei em uma empresa que tinha certificação iso, mas nunca vi nenhuma melhoria vinda daí. Só duas coisas mudaram: passamos a preencher mais documentos, e passaram a “disseminar o conhecimento” usando um sistema colocando uns documentos que ninguém lia.

@felipefranz aqui aponto novamente o tópico pessoas mais que processos, pois esse processo de “disseminação do conhecimento” não funciona, não é assim que as pessoas aprendem.

Discutimos isso antes, então aproveito pra te perguntar: uma equipe precisa de alguém não poderia tomar essa ação? Ela tem conhecimento do andamento melhor do que qualquer um, não poderia então ser ela a passar essas informações para o dono do negócio?

[quote=YvGa:

]Ops, um leve indicio do velho conceito “peao nao sabe de nada” aqui?

Eu nao disse nada contra a metrica, eu nao sou contra a metrica. Em nenhum momento eu disse que ninguem precisa saber o quanto do projeto esta pronto. O que eu disse foi que a unica metrica confiavel que existe em desenvolvimento de software é software funcionando. Se voce nao ve software funcionando, aquele monte de papel dizendo que tem 40 ou 90% prontos nao serve pra nada.

Se voce acredita quando um desenvolvedor te fala que o projeto esta 50% pronto e toma decisoes baseadas nisso (seja la de que forma ele te disser, falando, por email, ou por um milhao de fontes de dados de origens diferentes todas convergindo num relatorio maravilhoso), voce muito provavelmente vai tomar decisoes erradas.

So software funcionando te da nocao do que esta pronto e do que nao esta. Qualquer outra forma de medir cedo ou tarde vai cobrar seu preco.

von.juliano:

Mas o problema é que na maioria das vezes é estabelecido um processo rígido que deve ser seguido à risca, e isso por si só se torna problemático, pois acaba que as pessoas tem de se encaixar nos papéis do processo, quando ele deveria ser uma ferramenta para ajudar as pessoas. Sem contar que um processo engessado não é “alterável” (e quando é, demora eras), o que impede sugestões para melhorias, tentativas e experimentações, já que essas estão fora do processo.

Mas isso não é por culpa do cargo de gerente, mas de um gerente específico em um contexto errado.

Colocar ideologia em uma metodologia ou em um processo, querer polarizar o mundo em processos x pessoas ou em software livre x proprietário, java x .net é um mal que o pessoal comete.

Daí fica com a ideia fixa ‘gerentes tradicionais são malvados, tomam prejuízo na empresa e maltratam os funcionarios e não deixam as empresas boazinhas e ageis ganhar dinheiro e dominar o mundo’.

@marcosalex você conhece alguma empresa que segue um modelo de hierarquia tradicional que estabeleceu seus processos, e que permite mudanças constantes neles?

Várias. Praticamente

‘Tradicional’ é um termo meio generalista, não acha? Como eu disse antes, o mundo é dinâmico e ninguém quebrou por causa disso.

“Várias” é dificil de acreditar, ou você se refere à empresas sem cmmi, iso, etc. Já trabalhou para algum banco? Nada nunca muda.

O modelo hierárquico é baseado no medo, pois se você contraria um superior pode ser mandado pra rua. Quem lida muito com o medo, acaba sofrendo muito com ele, de forma que os processos burocráticos se tornam uma “proteção” para essas pessoas.

Modelo “tradicional” nem existe na literatura, mas ficou difundido dessa forma. Acaba sendo usado para se referir ao comando-controle.

Mas foi voce quem disse que areas que possuem o CMMI nivel 3 tem processos maduros, nao eu. O meu argumento foi justamente pra dizer que nao tem e agora voce discorda de mim dizendo que nao tem.

E, naturalmente, como todos os que colocam o processo acima das pessoas, voce diz que a culpa é de alguem que nao soube avaliar o processo e nao do processo em si que permite falhas. Tipico. Ah mas voce nao poe o processo acima das pessoas. Poe sim, seu discurso eh obvio, favorecendo os processos pre-estabelecidos.

Nao disse explicitamente, mas disse nas entrelinhas. E disse de novo agora. “É uma questao de papeis e responsabilidades, se a empresa tem uma política e não está na sua descrição de cargos alterá-la sem consultar os outros …”. Isso nao pode ser lido como: “Faca a tua parte e cale a boca!”?

Veja o micro-gerenciamente sendo evidenciado mais uma vez “consultar a pessoa responsavel”. So a pessoa responsavel pode alterar o processo e ela toda-poderosa que é dificilmente vai sequer ouvir os reles programadores reclamando de ter que preencher um documento que para eles meros peoes nao servem pra nada, mas pra mim servem, ah se servem. Ah minhas planilhas coloridas.

Densidade de defeitos? Satisfacao da equipe? Entao me mostre exemplos destas metricas? Me diga como voce mede satisfacao da equipe, quais metricas usa?
E como voce mede requisitos funcionais e nao funcionais implementados? Num relatorio no Word? No Project? Sei.

Mais uma vez a conversa de equipe motivada. Como voce motiva a equipe? Com palminhas? Bexiguinas? Nao existe nada mais motivador do que liberdade para tomar as decisoes e ver o resultado do seu trabalho. Mais uma vez com software funcionando.

O resto eh conversa pra boi dormir.

Me desculpe, mas não vou mais discutir com você, e improdutivo e você fica zombando o trabalho de gestão e ironizando com planilhas coloridas, medições em planilhas, falando que não serve pra nada e eh coisa pra boi dormir, colocando entrelinhas que eu não escrevi.

Eu quis dizer que existe uma hierarquia e deve ser respeitada, isso não significa que o principal usuário do processo não possa dizer como ele deve ser melhorado, mas na minha opinião tem que ter uma centralizacao e ser respeitada, se você não concorda tudo bem, agora respeite a opinião alheia, tenha um mínimo de educação e respeito.

Eu afirmo que não coloco o processo acima das pessoas ate porque não faz sentido, são as pessoas que usam os processos, e quanto a motivação, isto e objeto de estudo da administração não e feito com base no senso comum.

Em relação a satisfação a varias formas de medir, depende da cultura da empresa, uma bastante conhecida e o painel com smiles representando humor com diferentes níveis, quando ha um padrão o gestor verifica o que esta acontecendo, esta técnica veio da general eletrica que e considerada uma das melhores empresas para se trabalhar no mundo.

Encerro aqui minha participação no tópico devido a falta de respeito e tentativa de interpretar e distorcer tudo que eu digo.

felipefranz:

Me desculpe, mas não vou mais discutir com você, e improdutivo e você fica zombando o trabalho de gestão e ironizando com planilhas coloridas, medições em planilhas, falando que não serve pra nada e eh coisa pra boi dormir, colocando entrelinhas que eu não escrevi.

Eu quis dizer que existe uma hierarquia e deve ser respeitada, isso não significa que o principal usuário do processo não possa dizer como ele deve ser melhorado, mas na minha opinião tem que ter uma centralizacao e ser respeitada, se você não concorda tudo bem, agora respeite a opinião alheia, tenha um mínimo de educação e respeito.

Eu afirmo que não coloco o processo acima das pessoas ate porque não faz sentido, são as pessoas que usam os processos, e quanto a motivação, isto e objeto de estudo da administração não e feito com base no senso comum.

Em relação a satisfação a varias formas de medir, depende da cultura da empresa, uma bastante conhecida e o painel com smiles representando humor com diferentes níveis, quando ha um padrão o gestor verifica o que esta acontecendo, esta técnica veio da general eletrica que e considerada uma das melhores empresas para se trabalhar no mundo.

Encerro aqui minha participação no tópico devido a falta de respeito e tentativa de interpretar e distorcer tudo que eu digo.

Repare que eu nao tenho a intencao de te convencer de nada, nem duvido que voce acredita piamente no que escreve. Qualquer discussao aqui tem como foco quem esta lendo, quem nao conhece ainda as grandes empresas, os grandes processos, os grandes projetos. Esses que leem, ao ler textos como o seu podem acreditar que esta sua visao é a unica possivel, é a unica viavel e nao eh.

O grande ponto eh que voce valoriza sim os processos mais que as pessoas, embora insista em dizer que nao. Valoriza porque valoriza um carimbo que de nada vale, apontando este carimbo como exemplo de empresas com processos maduros. E quando eu falo sobre a minha experiencia com ele, voce imediatamente encontra algum culpado para o processo ser falho. Jamais voce cogitaria a hipotese do problema estar no processo.

Valoriza demais os processos quando fala da importancia da burocratizacao. Burocracia so serve para se proteger, eu ja trabalhei em lugares que havia necessidade de alguma burocracia. Boa parte dos usuarios do sistema nao tinha o menor pudor em dar o tapa e esconder a mao, em pedir alguma coisa e depois dizer que nao pediu. Isso estava alem do nosso alcance, nos nao podiamos educar os usuarios, que nao se importavam com isso, nem nos livrar deles obviamente. Nesse caso a burocracia era necessaria, qualquer conversa era documentada, qualquer solicitacao tinha que ser assinada.

Agora, burocracia interna? Eu me lembro uma vez, no comeco da minha carreira quando eu tinha muitos problemas com a tramitacao dos processos entre os setores da empresa. Um dia eu sugeri ao meu chefe, que era o dono da empresa, que fosse feito um sistema de protocolos, assim a cada erro que houvesse ficaria facil descobrir onde ele havia sido cometido. O velho me olhou e disse: “Otima, ideia, assim voce resolve o seu problema de nao ser acusado de erros que nao cometeu. Mas quem resolve o meu? Eu nao quero saber quem cometeu o erro, eu quero que eles nao acontecam.”

Burocracia é a politica do cover your ass, eh normalmente empregada por administradores amadores que precisam da ilusao do controle e nao percebem que com isso eles atrapalham o fluxo de trabalho. É obvio que processos sao necessarios, mas o maior erro que eu vejo por ai sao os gerentes tentarem automatizar os processos antes de saber se eles funcionam ou nao. Quando voce automatiza voce congela o prcesso e cria resistencia a mudanca, porque para altera-lo voce precisa mudar toda a automatizacao, nao so o processo em si.

Quer melhorar o processo? Remova toda automatizacao dele, controle tudo com papel e caneta ou planilhas simples, depois adapte, arrume, pergunte as pessoas o que as esta atrapalhando. Meça onde as coisas estao demorando e tente de fato descobrir porque. Leia o processo, pense sobre ele. Nao assuma que voce sozinho sabe como resolve-lo, voce nao sabe, nem nunca vai saber, porque voce so ve as coisas do seu angulo e nao tem como voce conseguir ver pelo angulo de outro por mais que tente. Entao nao tente adivinhar, meça. Mas medir nao eh pedir para equipe preencher documentos, medir eh ler o fluxo, ver o que esta acontecendo de fato, nao o que as pessoas dizem ou acham que esta acontecendo. Aí, depois disso voce automatiza.

Mas o que os amadores gostam de fazer? Tentam resolver um problema com a primeira coisa que lhes vem a cabeca, normalmente colocando alguma burocracia. Resolve? Num primeiro momento sim, mas podem trazer consequencias pessimas. Geralmente ha solucoes melhores. Normalmente nao investigam as causas do problema, basta mais um pedaco de papel que fica tudo certo. Nao percebem que na verdade estao atrapalhando porque estao tornando o processo aos poucos cada vez mais moroso. E depois quando a morosidade fica notoria, nao se pode mais esconder, tentam encontrar o problema pondo mais burocracia ainda. Inventam entao milhares de coisas. Graficos, inputs, outputs, nomenclaturas para medir e ainda assim nao conseguem porque colocaram um parafernalha de coisas no meio do caminho que chegaram num ponto em que nao so nao se consegue bons resultados como tambem ja nao se consegue medir mais nada.

Sim, voce, Felipe, valoriza mais os processos que as pessoas. Valoriza quando diz que se deve automatizar a forma de estimativa de um projeto de software. E ouco muito isso e normalmente a desculpa eh: “Eu nao posso ter um processo de estimativas baseado no Feelling de um desenvolvedor”. O que voces chamam de Feeling eu chamo de experiencia, nao dar credito a isso eh o mesmo que achar que voce pode jogar o PMBok nas maos de um administrador recem-formado e achar que ele pode gerir uma equipe. Ao dizer que isto deve ser automatizado voce desconsidera praticamente toda a literatura tecnica de desenvolvimento de software, que diz que so os desenvolvedores, analisando caso a caso, serao capazes de te dar uma estimativa, e ainda assim sera apenas uma estimativa.

Ha um numero tao grande de variaveis que podem influenciar no desenvolvimento de uma funcionalidade que voce ficaria espantado de descobrir. Alem da experiencia do desenvolvedor, a experiencia dele com o codigo que esta mexendo, com a linguagem. A qualidade do codigo, a ferramenta escolhida para o trabalho, as bibliotecas externas que vai precisar, se ela ja as conhece ou nao, se alguem da equipe ja conhece ou nao, se vai usar a A, a B, ou a C e por ai vai… Essa eh so a ponta do iceberg das variaveis.

Se voce acha simples, crie voce entao um bom algoritmo para estimativa e traga para nos, vamos usa-lo e ver se funciona. Porque todos os outros que inventaram ate hoje nao funcionaram.

Entao nao queira ficar irritado achando que eu nao te respeito, isso aqui eh so um forum, sua opiniao pra mim pouco importa, mas pode importar para quem le, entao nao vou deixar que voce fique propagando aos quatro ventos um monte de coisas que eu ja vi na pratica que nao funcionam.

Qualquer semelhanca…
http://www.observadorpolitico.org.br/grupos/educacao/forum/topic/a-fabula-dos-porcos-assados-autor-desconhecido/

Olha, a verdade foi dita aqui acima.

Diabo Loiro:

cara pmp e pmi = lixo… não faça isso da sua vida… so sabem perguntar está pronto? está pronto? nao resolve nada.

estude algo agil.

Alguem ser ou nao um PMP nao tem nada haver com isso. Em todas as profissoes e lugares sempre existem profissionais bons e ruins.

Costumo classificar esse tipo de gerente como “Gerente Mendingo”, so sabe perguntas se “esta pronto” ou “como esta indo”, geralmente nem sabe do que se trata o projeto, ou o que o sistema que esta sendo desenvolvido deve fazer; costuma trabalhar em consultorias 3 letrinhas na grande maioria das vezes, mas esta presente em todos os lugares em menor ou maior grau. Seu maior aliado e uma planilha do excel ou um gantt chart, e acredita que se sua planilha ou gannt chart estiver cheia de rostinhos felizes como esse entao esta tudo bem. Entende tanto de projetos de IT que se vc falar: “Precisamos de CS para concluir o projeto.” (CS de Counter Strike msm). Ele vai tentar conseguir para voce CS sem nem mesmo questionar. Nunca desenvolveu em sua vida nem sequer um simples cadastro para um sistema de uma padaria por exemplo.

[]`s

andredecotia:

Hum legal ver os pontos de vista… Muito bacana…

Estou pensando seriamente nessa carreira gosto…

Minha opiniao:

Entao use pelo menos uns 10 anos desenvolvendo sistemas, depois tente focar em gerencia (e sempre estude mto) se e o que vc quer. Vi poucos gerentes com mta experiencia em desenvolvimento serem ruins, mas vi muitos gerentes sem essa experiencia serem ruins.

[]`s

andredecotia:

Um ponto a citar:

Ouço muito falarem que a certificação PMP é certeza de progressão salarial… Fato, que isso não
acontece com certificações Java, pelo menos não com a principal/mais conhecida, a de programador…

Vocês tem opiniões formadas a este respeito?

Nenhum certificado e ctza de progressao salarial, nem PMP.

So para que conste aqui, ja que estamos falando de PMP e salario e etc. Vou dar um exemplo, no momento estou trabalhando em um projeto em que tem um colega que tem PMP mas esta trabalhando como tecnico e nao como gerente, ele tem pelo menos uns 15 anos de XP e falou que no geral, paga-se melhor para um bom tecnico do que para um gerente por aqui. (Canada) E por isso ele tem optado por trabalhar como tecnico.

[]`s