Chefe ou Lider: Como um GP deve ser?
Acredito que nos (profissionais de TI) já trabalhamos ou ainda estamos trabalhando com "chefes". Será que a disciplina de Gestão de Projeto ainda é utilizada de maneira imprópria mesmo nos dias de hoje? Sim, de fato é. O GP (Gerente de Projetos) tem um papel crucial no sucesso de um projeto de software.
Gerente ou Dono do Projeto?
Essa questão é mais abrangente, na verdade o ponto é "Gerente ou Dono". Isso se aplica para redes de computadores também. Quem nunca ouviu alguem dizer um Administrador de redes dizendo "É na MINHA REDE ninguém instala programas que não são padrões"? Na verdade esse tipo de "coisa" nos escutamos de gerentes de projetos também.
O Gerente deve gerenciar o projeto isso significa manter o time na linha, servir como um motivador e facilitador da equipe, assim ele será um gerente não um dono. O PMI "diz" que o GP deve ouvir os "Subject Matters", ou seja, especialistas e com as informações do mesmo tomar as devidas decisões que devem ser todas.
O Anti-Pattern: Gerente é quem decide o que e como deve ser feito
Por incrível que parece, já trabalhei em projeto em que o suposto GP se "metia" com a suposta "Arquitetura" ia em reuniões, expressava sentimentos sobre UML. Não tenho nada contra um gerente que conheça mais a fundo o desenvolvimento até por que ele pode ter sido um desenvolvedor em algum dia. Porem não podemos permitir que um "suposto" GP decida o rumo das coisas.
Gerenciamento de Conflitos
Um bom gerente deve saber como lidar com conflitos tanto internos quanto externos. Quem já não trabalhou com gerentes que simplesmente ignoravam os conflitos e usavam o velho anti-pattrern "Empurrar com a Barriga"? Eu infelizmente já vi alguns. Um bom gerente deve resolver os conflitos quando eles ocorrerem, tratando o problema de maneira efetiva para que no futuro o projeto não vire uma grande bola de lodo emocional onde todos se odeiam e o software não sai.
Muitas vezes é preciso que o GP tenha aquele principio do XP a Coragem. É necessário coragem para realizar uma correção de rumo e mostrar a um colaborador que ele está errado e que ele deve refletir sobre o ocorrido para o bem dele e da equipe. Felizmente eu já trabalhei com profissionais que tinham de fato essa habilidade.
Seu GP é um Lider?
Eu já tive o privilegio de trabalhar com GPs que eram lideres, mas foram pouquíssimos, na verdade dá pra contar com metade dos dedos da mão! Um lider consegue melhorar a qualidade do trabalhos dos membros da equipe e manter o foco da equipe de forma que as pessoas respeitem ele. Isso ocorre por que esse tipo de atitude gera confiança de parte dos membros da equipe para o GP, assim as pessoas seguem os conselhos e as orientações do GP e ele consegue atingir os seus propósitos com muito mais facilidade.
Seu GP pode ser um Arquiteto?
Certamente. O processo OpenUp recomenda que em projetos pequenos o GP seja o Arquiteto. Não se engane isso é possível, o verdadeiro arquiteto é um lider nato. Infelizmente o Kent Back(autor do XP) acho desaconselhável um arquiteto exercer uma função de GP(no XP é o Coach), eu discordo da opinião dele, de fato ele não deve ter conhecido um arquiteto de verdade, eu sinceramente não conheci muitos também :)
Gerente de Projetos: Afunda Projetos
Isso é umn fato. Quanto maior o projeto e quanto mais risco o mesmo tem, mais experiencia o GP deve possuir. Infelizmente aqui no Brasil muitas vezes o GP é o Filho do Dono da empresa, ou é uma pessoa que já está a muitos anos na empresa e não tinha mais como evoluir, ai do nada o cara vira "Gerente de Projetos" tadamm! Bom ai está feita a merda.
Para ser um bom GP, o cara deve ser um Lider nato, deve ter tato com as pessoas, e se a pessoa não tem esses skills não adianta. Isso vai só adicionar mais riscos ao projeto.
E o toten do PMI: "Plan to Work, Work to Plan"?
Latímavel. Esse slogan veio nas primeiras versões do PMI, isso remete aquela velha ideia do projeto em cascata. Cascata é um exelente metodologia, mas não pra o desenvolvimento de software. Existem coisas legáis no PMI, mas mesmo assim existem coisas do estilo "Cascata", temos que dar um colher pro PMI, por que foi criado para a engenharia, exemplo: Criação de pontes. O fato é que a nossa área é muito nova, isso complica um pouco mais as coisas.
Planejar necessáriamente é ruim? Não é. O que ocorre é que existe um momento correto de se estimar, lembre-se do cone de incertezas. Como esse post é mais focado nas questões de GP, eu não posso deixar de falar disso.
Como mensurar o Progresso?
Olha pessoal acho que isso é unaneme. É algo do tipo Desenvolvimento Iterativo Incremental, mas mesmo assim tenho que falar. É de fato históricamente errado mensurar um projeto da seguinte forma:
Análise: 85%
Desenv: 49%
Testes: 25%
Implant: 5%
ou ainda pior:
Análise: 85%
Desenv: 0%
Testes: 0%
Implant: 0%
Isso me diz que estamos utilizando o modelo em Cascata. Por que é simplismente impossível ter 85% de análise e não ter nada de código e testes. De fato isso pode ser que não se reflita em uma cascata em 100% porem estamos vendo uma herança da cascata o Anti-Pattern Big Specs Up to Front.
Outro ponto chave é: Mensure apartir do que foi entregue. Bom isso está escrito no RUP e no cerno dos métodos ágeis. Infelismente eu já participei de um projeto que os caras mensuravam da forma errada que eu mostra a cima em vermelho. O que isso gerou? O projeto ficou 4 meses em 99% e esse 1% nunca chegava.
Esse é o problema desse tipo de mensuramento. Ele é falso e dá uma falsa ilusão de progresso. Essa questão está liaga com a falta de priorização e os problemas de se entregar software que não agrega valor ao negócio.
Abraços e Até a Próxima.
Gerente ou Dono do Projeto?
Essa questão é mais abrangente, na verdade o ponto é "Gerente ou Dono". Isso se aplica para redes de computadores também. Quem nunca ouviu alguem dizer um Administrador de redes dizendo "É na MINHA REDE ninguém instala programas que não são padrões"? Na verdade esse tipo de "coisa" nos escutamos de gerentes de projetos também.
O Gerente deve gerenciar o projeto isso significa manter o time na linha, servir como um motivador e facilitador da equipe, assim ele será um gerente não um dono. O PMI "diz" que o GP deve ouvir os "Subject Matters", ou seja, especialistas e com as informações do mesmo tomar as devidas decisões que devem ser todas.
O Anti-Pattern: Gerente é quem decide o que e como deve ser feito
Por incrível que parece, já trabalhei em projeto em que o suposto GP se "metia" com a suposta "Arquitetura" ia em reuniões, expressava sentimentos sobre UML. Não tenho nada contra um gerente que conheça mais a fundo o desenvolvimento até por que ele pode ter sido um desenvolvedor em algum dia. Porem não podemos permitir que um "suposto" GP decida o rumo das coisas.
Gerenciamento de Conflitos
Um bom gerente deve saber como lidar com conflitos tanto internos quanto externos. Quem já não trabalhou com gerentes que simplesmente ignoravam os conflitos e usavam o velho anti-pattrern "Empurrar com a Barriga"? Eu infelizmente já vi alguns. Um bom gerente deve resolver os conflitos quando eles ocorrerem, tratando o problema de maneira efetiva para que no futuro o projeto não vire uma grande bola de lodo emocional onde todos se odeiam e o software não sai.
Muitas vezes é preciso que o GP tenha aquele principio do XP a Coragem. É necessário coragem para realizar uma correção de rumo e mostrar a um colaborador que ele está errado e que ele deve refletir sobre o ocorrido para o bem dele e da equipe. Felizmente eu já trabalhei com profissionais que tinham de fato essa habilidade.
Seu GP é um Lider?
Eu já tive o privilegio de trabalhar com GPs que eram lideres, mas foram pouquíssimos, na verdade dá pra contar com metade dos dedos da mão! Um lider consegue melhorar a qualidade do trabalhos dos membros da equipe e manter o foco da equipe de forma que as pessoas respeitem ele. Isso ocorre por que esse tipo de atitude gera confiança de parte dos membros da equipe para o GP, assim as pessoas seguem os conselhos e as orientações do GP e ele consegue atingir os seus propósitos com muito mais facilidade.
Seu GP pode ser um Arquiteto?
Certamente. O processo OpenUp recomenda que em projetos pequenos o GP seja o Arquiteto. Não se engane isso é possível, o verdadeiro arquiteto é um lider nato. Infelizmente o Kent Back(autor do XP) acho desaconselhável um arquiteto exercer uma função de GP(no XP é o Coach), eu discordo da opinião dele, de fato ele não deve ter conhecido um arquiteto de verdade, eu sinceramente não conheci muitos também :)
Gerente de Projetos: Afunda Projetos
Isso é umn fato. Quanto maior o projeto e quanto mais risco o mesmo tem, mais experiencia o GP deve possuir. Infelizmente aqui no Brasil muitas vezes o GP é o Filho do Dono da empresa, ou é uma pessoa que já está a muitos anos na empresa e não tinha mais como evoluir, ai do nada o cara vira "Gerente de Projetos" tadamm! Bom ai está feita a merda.
Para ser um bom GP, o cara deve ser um Lider nato, deve ter tato com as pessoas, e se a pessoa não tem esses skills não adianta. Isso vai só adicionar mais riscos ao projeto.
E o toten do PMI: "Plan to Work, Work to Plan"?
Latímavel. Esse slogan veio nas primeiras versões do PMI, isso remete aquela velha ideia do projeto em cascata. Cascata é um exelente metodologia, mas não pra o desenvolvimento de software. Existem coisas legáis no PMI, mas mesmo assim existem coisas do estilo "Cascata", temos que dar um colher pro PMI, por que foi criado para a engenharia, exemplo: Criação de pontes. O fato é que a nossa área é muito nova, isso complica um pouco mais as coisas.
Planejar necessáriamente é ruim? Não é. O que ocorre é que existe um momento correto de se estimar, lembre-se do cone de incertezas. Como esse post é mais focado nas questões de GP, eu não posso deixar de falar disso.
Como mensurar o Progresso?
Olha pessoal acho que isso é unaneme. É algo do tipo Desenvolvimento Iterativo Incremental, mas mesmo assim tenho que falar. É de fato históricamente errado mensurar um projeto da seguinte forma:
Análise: 85%
Desenv: 49%
Testes: 25%
Implant: 5%
ou ainda pior:
Análise: 85%
Desenv: 0%
Testes: 0%
Implant: 0%
Isso me diz que estamos utilizando o modelo em Cascata. Por que é simplismente impossível ter 85% de análise e não ter nada de código e testes. De fato isso pode ser que não se reflita em uma cascata em 100% porem estamos vendo uma herança da cascata o Anti-Pattern Big Specs Up to Front.
Outro ponto chave é: Mensure apartir do que foi entregue. Bom isso está escrito no RUP e no cerno dos métodos ágeis. Infelismente eu já participei de um projeto que os caras mensuravam da forma errada que eu mostra a cima em vermelho. O que isso gerou? O projeto ficou 4 meses em 99% e esse 1% nunca chegava.
Esse é o problema desse tipo de mensuramento. Ele é falso e dá uma falsa ilusão de progresso. Essa questão está liaga com a falta de priorização e os problemas de se entregar software que não agrega valor ao negócio.
Abraços e Até a Próxima.
