pmi

Contratamos um Gerente de projetos! Que conheça Java, Mainframe, PHP, SAP, CRM e que seja mestre em todas as técnicas e artes milenares de combate…

fonte imagem: http://www.cbsnews.com/news/3-reasons-multitasking-is-still-a-valuable-business-skill/

Cada vez é mais comum encontrarmos vagas que exigem que o profissional de TI tenha um portfólio de conhecimentos enorme que envolve, muitas vezes, conhecimentos não correlatos. Isso é errado? Não. Há diferentes tipos de profissionais e para estes diferentes tipos de vagas. Porém, o que não é tão correto é a conclusão de que para ser um profissional de gestão você tenha de ser, obrigatoriamente, um especialista naquilo em que você irá gerenciar e esses exemplos são cada vez mais comuns.

Imaginem um seguinte cenário: uma empresa abre uma vaga de gestão de projetos e exige que o profissional tenha conhecimento especialista e comprovado em técnicas Java.

O que provavelmente o recrutador espera: um profissional integrador, líder e comunicador que planeje, execute, controle o que foi planejado e entregue o resultado final respeitando todas as restrições e premissas estabelecidas.

O que provavelmente ele irá recrutar buscando esse perfil: um profissional técnico que atenderá muito bem todas as pendências técnicas do projeto, planejando as entregas técnicas de seus desenvolvedores e cobrando-as quando o Project avisar que a data de entrega chegou..

Resultado esperado: o profissional entregará o produto como foi especificado tecnicamente, mais as expectativas de qualidade, satisfação do cliente final, prazo e custo muitas vezes não serão as esperadas. Culpa do profissional? Não. Lembram-se da velha frase de que um bom técnico não é necessariamente um bom gestor?

Que tipos de erros foram cometidos na seleção deste profissional? Abaixo listo alguns deles:

Erro número 1

Concluir que o profissional não pode realizar a gestão de algo que ele não conhece. Errado! Isto pode ser resolvido pelo uso adequado de dois elementos importantíssimos no gerenciamento de um projeto: os ativos organizacionais e os fatores ambientais. O uso dos ativos e fatores ambientais darão o conhecimento e a opinião especializada necessários para o planejamento ou, pelo menos, para o início dele. Qual melhor entrada para um planejamento do que a própria equipe envolvida no trabalho?

Erro número 2

Contratar o profissional pela sua especialização técnica. Contratando o profissional mais do que pelo seu conhecimento técnico do que em sua experiência em gestão traz um risco a empresa. E se a estratégia não for mais pelo uso de uma tecnologia específica? Demitimos e contratamos novos recursos que sejam especialistas na nova tecnologia? Ciclo sem fim!

Erro número 3

Qualquer um pode ser gerente de projetos, basta apenas cobrar a entrega de acordo com o que foi planejado! Errado. Gestão de projetos é muito mais do que cobrar. Gestão é integrar todos os componentes de um projeto em unidade coesa. Gestão é liderar e manter sua equipe motivada. Sucesso em um projeto não se define apenas em determinar se foi ou não cumprido o prazo. Sucesso é definido em atingir todos os objetivos planejados para a qualidade, custo, escopo, satisfação do cliente e.. prazo. Gerenciar não é apenas cobrar, gerenciar é planejar, controlar os desvios guiando tudo e todos para os objetivos que estão atualmente definidos.

E erro número 4 (Pós-seleção): uma provável demissão – infelizmente – de um ótimo técnico que não atendeu as expectativas de gestão.

Bom, então você está me dizendo que um gerente não pode ter conhecimento técnico?! Não. Conhecimento técnico ajuda sim! Ele fará parte, junto com o conhecimento de todos os envolvidos/equipe, de uma entrada importante para a realização do planejamento.

A questão discutida aqui é que a exigência técnica não é ou não deva ser um critério exigido para a contratação de profissionais para gestão de projetos. Os motivos? Alguns deles foram citados acima.

Anúncios

Desafios enfrentados em um projeto

A figura ao lado representa muito bem o desespero que por vezes nos toma em algumas situações de projeto. Quando estamos gerenciando um projeto nos parece em algumas situações que o mesmo “está vivo”. Bem como diz um amigo meu: ” Quando pareço ter mapeado todas as possibilidades de caminho de um projeto surge de maneira improvável algo do “nada” que acaba causando uma terrível dor de cabeça…”. É… eu também já sofri desta terrível verdade. Um projeto é de uma maneira tão complexa e há tantos elementos nele que o PMI criou 9 áreas diferentes de conhecimento e cada uma com seus respectivos esforços para qual o gerente de projetos deve focar.  A partir de agora irei citar alguns ( 5 pelo menos) problemas e situações comuns que surgem em um projeto: (Para muitos destes até mesmo o grande padre Quevedo teria problemas no intuito de encontrar um explicação lógica)

1 – Escopo -> O escopo é uma das áreas de conhecimento do PMI e tenho ela, por experiência própria, como uma das mais difíceis para gerenciar.  Por muitas vezes, mesmo tendo fechado o escopo com o usuário  Uma, Duas, Três, Quatro vezes , seja esse entendimento documentado por ata, carta, papel de pão ou holograma, é muito comum que no andar do desenvolvimento do projeto – quando você estiver fechando o desenvolvimento ou iniciando a homologação, que o usuário questione sobre uma funcionalidade não requisitada e que não fazia parte do projeto. Pois bem isto não é um problema! É só enviar ao controle integrado de mudanças (PMBOK) para que seja avaliado se esta mudança será ou não aprovada. Dependendo do caso uma alteração ou acréscimo de uma nova funcionalidade pode até não fazer um impacto no projeto em termos de tempo e às vezes custo. Porém, rotineiras mudanças , mesmo que pequenas, podem criar um ciclo sem fim prejudicando o projeto. Por muitas vezes o gerente de projeto terá de ter “pulso firme” para controlar o escopo do projeto e seu conseqüente sucesso.

2 – Grande quantidade de stakeholders envolvidos -> A área de comunicação é fundamental e constitui umas das principais atividades do projeto. Quando o número de stakeholders de um projeto cresce ( e nisso incluo os próprios membros de equipe do projeto) a comunicação vai se tornando cada vez mais desafiante. Por muitas vezes o gerente do projeto irá ter de resolver conflitos e perceber interesses individuais.  É importante que o gerente tenha total controle sobre a sua equipe de projeto. Porém, por muitas vezes isto não será possível porque esses membros podem estar envolvidos em outras atividades as quais aplicam mais interesse ( isto acontece principalmente nas estruturas de organização matricial fraca e funcional).

3 – Riscos -> Aquela frase citada mais acima de um amigo meu mostra muito bem o que acontece quando se fala de riscos. É improvável se mapear todos os riscos que podem causar conseqüências não desejáveis a um projeto. O que faz então, por muitas vezes, é elaborar um plano de contingência a ser utilizado caso alguma coisa venha dar errado no projeto.

4 – Características do próprio projeto -> Como falamos também mais acima o projeto é quase um ser dotado de vida. E como tal, o mesmo vai sofrendo mudanças enquanto há o seu desenvolvimento. Por muitas vezes quando estamos em uma fase mais detalhada do projeto surge algo até então não pensado. E isto é muito mais comum do que possa aparecer.

5 – Priorização de projetos – Por muitas vezes você pode ter uma demanda de diversos projetos para serem atendidos para o usuário. Acontece que a partir de uma seqüência linear previamente definida pelo usuário dos projetos com mais prioridade esta “fila” segue uma constante mudança. Por muitas vezes,  podemos nos deparar em situações em que temos de “sair correndo” literalmente com um projeto porque a prioridade de um usuário mudou , seja lá pelo motivo qualquer.

Calma não se desesperem! Coloquei aqui só os problemas. Porém para todos aqui há algum tipo de solução que se não evita pode, no mínimo, minimizar as suas conseqüências. O importante é sempre não deixa-los crescer e mata-los (os problemas) tornando-se cada vez mais um analista tipo 8 hehehehe.

Certificados interessantes na área de TI

Seguem abaixo alguns dos certificados interessantes para os profissionais que trabalham na área de TI:

Umas das credenciais mais respeitadas no mundo no que se refere a gerenciamento de projetos. O livro PMBOK – Project Management Body of Knowledge – é a base para certificação além da experiência do profissional em termos de gerenciamento. Alguns requisitos mínimos são necessários para prestar a prova com o objetivo de retirar a certificação, maiores detalhes podem ser encontrados no site do PMI.

É uma certificação reconhecida internacionalmente que atesta que o professional utiliza de forma correta as regras do IFPUG  para a contagem dos pontos de função, técnica esta que permite calcular o esforço necessário para a realização de um determinado projeto.  Não há pré-requisitos mínimos exigidos, sendo a base da certificação o manual do IFPUG para realização da contagem dos pontos de função. A prova para certificação é bastante rigorosa: são 150 questões a serem realizadas em até 3 horas, exigência mínima de 90% de acerto. A prova é dividida em três partes e para cada parte é exigido também um mínimo de 80% de acerto.Maiores detalhes no site do IFPUG.

O ITIL é uma coleção de melhores práticas no que se refere ao gerenciamento de serviços de TI.  Existentes diferentes certificações que atestam o conhecimento sobre o ITIL, estas podem ser vericadas no site do orgão EXIN.

O COBIT é um framework de governança de TI que permite, entre outras coisas, o desenvolvimento de políticas claras e boas práticas para o controle de TI nas organizações. Maiores detalhes das certificações disponíveis no site ISACA.

Caso tenham outras certificações não citadas aqui e  que também são interessantes nesta área, fiquem a vontade para a citação e comentários!

Figuras extraídas de: