AyPyCy.com

Outro dia falei sobre o que é um projeto, então nada mais justo agora falar o que é um Gerente de Projeto.

O projeto, para relembrar, é resumidamente um conjunto de atividades e recursos para gerar um produto único. O Gerente de Projetos é o que dá o ritmo da coisa, alinhando os recursos com os clientes e demais interessados no projeto.

Não vou me aprofundar, mas existem vários aspectos em que o Gerente de Projetos deve olhar, basicamente são:

• Tempo: todo projeto tem uma data para terminar, mesmo porque sem data final torna ele uma operação e não projeto. O Gerente de Projetos tem que acompanhar este cronograma e estar sempre pensando em formas de otimizar o processo e garantir a data de entrega. Naõ é tão simples, pois em muitos casos uma atividade depende de outra para acontecer (imagine a construção de uma casa, adianta fazer o acabamento interno antes das paredes e telhado?). Casos ontem você não pode nem adiantar o projeto (imagine se as obras das Olimpiadas do RIO-2016 ficassem prontas em 2014… como estariam as obras em 2016?). Enfim, não é simplesmente ficar olhando para o cronograma.
• Custo: Fato: todo projeto tem um orçamento fechado, que será consumido no decorrer do projeto. Cabe ao Gerente de Projeto decidir a melhor forma de aplicar esses recursos financeiros e garantir que o orçamento não estoure, gerando prejuízo para a empresa ou custo adicional para o cliente. Existem casos em que a empresa já sabe que o projeto dará prejuízo, mas mesmo assim ela tem a meta de, por exemplo, conquistar o cliente. Tem clientes, e passo por isso hoje, que querem gastar dinheiro! Veja bem: o cara tem um orçamento para gastar dentro do ano, se ele não gasta tudo o que pediu ele toma uma “chincha” da empresa dele, então ele me chama e fala “tenho que gastar mais R$XYZ neste ano, o que seu projeto pode absorver?”. Parece simples, mas não é. Não posso simpesmente aumentar o valor do que é produzido. Não posso simplesmente embutir coisas no projeto (veja o item escopo mais a frente)… enfim, é um grande desafio esse tipo de questão, e se um dia passar por isso garanta uma pessoa do Comercial do seu lado, senão seu projeto vai pro saco. Acredite.
• Qualidade: Conceito básico de qualidade aqui, seu projeto esta seguindo algum padrão? Esta de acordo com os processos da empresa? Nem sempre a perfeição é o esperado, qualidade é atingir o que foi proposto, por exemplo, podemos falar que é esperado que o programa tenha 30% do código errado. É ruim, mas se é o acordado no projeto é o que deve ser seguido. Não é taõ absurdo, é igual comprar roupa no Carrefour e reclamar que a costura não durou, o padrão de qualidade deles é aquele e fim.
• Recursos Humanos: Sabemos que humanos normalmente são os que dão mais trabalho. Basicamente é lidar com pessoas (contratação, evolução, etc). Tópico simples, mas que no dia-a-dia é complicado.
• Comunicação: Como vai fluir a comunicação em seu projeto? E se o estagiário mandar um mail para o diretor do cliente? Quem vai participar dos diversos tipos de reuniões? Quando ocorrerão essas reuniões? Aconteceu um determinado problema, quem deve ser acionado? Enfim, o Gerente de Projeto deve traçar esses caminhos, e garantir de que a comunicação esteja fluindo como o planejado. Já passei por problemas nisso, e é algo comum… coisa que o desenvolvedor no dia-a-dia acabou combinando algo com o cliente (que também, em muitas vezes, não tinha a alçada para tal decisão) e não comunicou ninguém. O cara normalmente nem faz esse tipo de coisa por mal, mas isso geralmente dá problema no futuro. Outra coisa que o pessoal esquece, principalmente do meio para o final do projeto: a formalização. Formalize tudo, documente, nem que seja um e-mail, mas nunca caia na armadilha de acordos verbais ou “acordo de cavalheiros”, isso nunca funciona! O que vale é o que esta escrito. Até o catolicismo e similares precisam do que está escrito na Bíblia para embasar seus argumentos, porque você faria diferente?
• Riscos: Aqui que os envolvidos sentam e tentam descobrir quais são os possíveis problemas ou oportunidades que o projeto vai ter. Pra cada risco levantado você traça um plano de ação e medidores para saber o que fazer com o risco se ele acontecer (ou se vale a pena investir em uma oportunidade). Isso tem que ser feito constantemente em um projeto e deve-se pensar nas coisas mais improváveis, pois estas que te darão a maior dor de cabeça. Quão improvável? Bom, tenho um exemplo bacana aqui: Se lembram daquele avião que caiu em Sao Paulo em 1997? Pois bem, tinha uma equipe inteira de um projeto de uma consultoria que trabalhei. Todos morreram, e com eles todos os Notebooks e dados do projeto em questão. O cliente ficou com pena? Sim, claro, e por isso deu o prazo de um mês para a consultoria repor a equipe… pois é, contrato é contrato. Depois disso a consultoria colocou como risco em todos os projetos que envolviam viagens a queda de aviões, e como plano fazer o time viajar separado. Tenho certeza que quando o outro vôo caiu em São Paulo em 2007 (ou 2008, não me lembro), a consultoria não deve ter se abalado tanto (se é que tinha gente de projetos no vôo). É muito comum as empresas terem um grupo de riscos padrão, aqueles que se repetem em todo projeto, como por exemplo o risco de um recurso chave pedir demissão.
• Aquisição: essa parte trata de contratação de serviços de terceiros. Pode ser um seguro, um especialista, um aluguel, um servidor, mesas e cadeiras de escritório… enfim, qualquer coisa. O maior cuidado aqui é não confundir com a parte de Recursos Humanos e sempre ficar de olho se o serviço contratado esta alinhado com a Qualidade do projeto. Tomar cuidado também com a compra de bens, sempre alinhando com a contabilidade da empresa (depreciação e afins…).
• Escopo: Talvez a maior armadilha de um projeto, todo o resto você consegue negociar com quem quer que seja, mas o escopo é o que é o mais sagrado em um projeto. É o que o cara pediu, nem mais nem menos. Repito, nem mais nem menos. Não pense em agradar seu cliente dando coisas a mais do que ele pediu, você vai quebrar a cara. Quer um exemplo prático? Imagine a revisão do seu carro como um projeto, você sabe exatamente o que será feito no veículo, quando começará, quando será entregue e quanto custará. Quando você vai buscar o carro o chefe da oficina diz: “Amigo, você é um cliente bacana, de cortezia trocamos os 4 pneus do seu carro, sem custo algum!” Lindo, não? Você acha que se deu bem e o chefe da oficina acha que te agradou, mas e se ao sair da oficina você andar 2 quadras e um pneu furar e você perder o controle e bater o carro, qual será sua primeira reação? Aonde você vai voltar para reclamar? Pois é, isso acontece muito, principalmente em TI, o pessoal adora enfiar coisas inúteis no projeto, pode ser um relatório a mais, um gráfico a mais, uma “telinha” a mais… Pode ser algo lindo, fantástico, surreal, mas se esta fora do escopo acordado, então é inútil para o projeto, além de poder se transformar em um Risco.
• Integração: Resumindo, nada do que você leu acima ocorre de maneira isolada, então junta tudo o que esta acima e se vira no dia-a-dia. Exemplo simples, um recurso pede demissão, gerando atraso no cronograma, com isso você acaba tendo que contratar um novo recurso ou subcontratar, esse cara novo pode por em risco a qualidade do projeto. Se ele tiver um salário maior que o anterior, pode afetar seus custos.. e por aí vai.

(isso foi muito mais do que resumido, para saber mais leia pelo menos o livro PMBoK ou o PRINCE2, além de outros menos famosos mas tão interessantes quanto)

Aqui esta bem resumido o dia-a-dia de um Gerente de Projetos, mas se eu tivesse que resumir mais ainda eu diria que o principal papel do Gerente de Projetos é “Antecipar problemas”.

Agora vou falar dos erros que as empresas normalmente cometem ao definir um Gerente de Projetos. Peceberam que a função do Gerente de Projetos é bem específica? Ele é o cara que tem o conhecimento para cuidar do projeto, esse é seu conhecimento: “Gerir Projetos”. “P-R-O-J-E-T-O-S”. O cara não é um Desenvolvedor, Pedreiro, Médico, Engenheiro, ele é um Gerente de Projetos! O que quero dizer é que o Gerente de Projetos não precisa ter conhecimento técnico sobre o projeto, o Gerente de Projeto tem que conhecer de projeto. A técnica do Gerente de Projetos é saber como gerenciar um projeto. (Acho que ficou claro, não?)

As empresas erram muito nisso… mas muito mesmo… erram demais! Elas geralmente encaram a função de Gerente de Projetos como uma promoção para, por exemplo, o Coordenador de Desenvolvimento de TI. E aí a coisa desanda… os projetos vão falhar um atrás do outro. Pois o indivíduo não possui o conhecimento em relação a projetos. Não estou dizendo que o Coordenador de Desenvolvimento não tenha capacidade intelectual para ser um Gerente de Projeto, mas a pessoa precisa ter o perfil e ter estudo sobre o assunto para exercer a função.

Eu mesmo sou um exemplo disso. Eu sou formado em Análise de Sistemas, e fui de Analista de Sistemas para Gerente de Projetos. Não foi uma promoção, e sim uma mudança de função (mesmo porque na ocasião meu salário nem mudou…). Na ocasião eu tinha terminado uma pós-graduaçao sobre o assunto e tinha decidido seguir essa carreira. A prova mais concreta de que o Gerente de Projetos cuida de projetos é que hoje eu gerencio um projeto que é 80% trabalho elétrico e 20% que envolve software, e nem é desenvolvimento. Não manjo absolutamente nada de Engenharia Elétrica, a minha maior realização no assunto foi trocar a resistência do chuveiro em casa, mas mesmo assim consigo gerenciar o projeto. Claro que eu tenho como “braço direito” um especialista em Engenharia Elétrica e outro em Software, mas é cada um na sua especialidade. Eles falam de coisas que eu sequer imagino como funciona (ok, com o tempo acabo absorvendo de qualquer maneira) assim como as vezes peço algumas informações que eles nem imaginam para que servirão.

Já vi muito isso, empresas que colocam como Gerente de Projetos pessoas que sabem de tudo, menos gerenciar projetos. E com isso a coisa afunda, e afunda bonito.

Ah, já ia me esquecendo, quem quer ser Gerente de Projetos precisa estar preparado para deixar para trás a parte técnica. Principalmente se é da área de TI, conforme-se, em menos de 3 anos você já vai ter esquecido tudo o que aprendeu e não vai conseguir acompanhar o desenvolvimento das tecnologias, conforme-se em se atualizar lendo a Info, de forma bem macro. Por isso que os RHs chama essa decisão na carreira de “Carreira em Y”, pois chega um ponto em que você decide se vai continuar como um especialista técnico ou vai para área administrativa.

Não se iluda! Conheço casos em que o especialista técnico ganha mais do que o Gerente de Projetos. Não se deixe enganar pelos titulos dos cargos, escolha o caminho que você realmente gosta. Outro dia fiquei em uma reunião das 9h da manhã até 15h com um cliente discutindo e renegociando um contrato que tinha ao todo, com seus anexos, umas 300~400 páginas… O resultado da discussão poderia terminar de forma precoce um projeto de alguns milhões de Reais (meu chefe com certeza não ficaria feliz) e colocaria na rua cerca de 80 profissionais de diversos níveis (eu incluso, afinal Gerente de Projetos sem projeto não serve pra muita coisa). Se essa cena/situação não te agrada, esqueça a gestão de projetos… Sério, nem tudo são flores, e cenas como a que descrevi acima são bem mais comuns do que você possa imaginar.

Não perca os próximos posts sobre o tema. Vou falar do Gerente de PMO (minha função hoje) e depois o mais divertido: Lições Aprendidas, onde vou falar dos absurdos que acontecem no meio de um projeto, e a solução que adotei para resolver o problema.