O
enxugamento dos quadros de pessoal e o aumento da necessidade de especialização
técnica têm levado muitas empresas a recrutar no mercado profissionais por
período determinado apenas para a execução de projetos específicos. Neste
contexto, entender o processo de gerenciamento de projeto tem se tornado vital
para organizações a medida em que mais e mais novos negócios vão se revestindo
da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem
sempre estão disponíveis nas empresas.
Um
projeto é um empreendimento temporário, com data de início e fim, cujo objetivo
é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de
forma a atingir os objetivos propostos dentro de parâmetros de qualidade
determinados, obedecendo a um planejamento prévio de prazos (cronograma) e
custos (orçamento). Ou seja, dadas as metas e as restrições de recursos e
tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos
propostos.
Muitas empresas estão adotando a estrutura de projetos no seu
dia-a-dia. Desde a concepção de um novo software até a implantação dos
procedimentos de atendimento a clientes, desde a construção de uma ponte até a
revisão dos processos de venda com vistas a aumentar a taxa de fechamento de
negócios, muitos empreendimentos no seio das organizações se enquadram na
classe de projetos. Nos mais diversos setores, a abordagem de gerenciamento de
projetos está ganhando terreno por permitir um melhor uso dos recursos para se
atingir objetivos bem definidos pela organização. Sabendo da importância de se
gerenciar bem um projeto, vamos ver os passos que nos levam a melhorar nossas
habilidades de gerenciamento de projeto.
Tudo começa com a contratação de uma empresa para tocar o
projeto ou a definição dos colaboradores internos que integrarão a equipe de
projeto. Num dia determinado, inicia-se o projeto. Este momento deve ser
formalizado com um documento que se chama de “termo de início do projeto”. Em
projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo
gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente
envia aos patrocinadores, copiando os demais envolvidos, para notificar que
naquele momento se inicia o projeto e todos estão envolvidos com a sua
execução.
1. Escolha e adote uma metodologia
Uma
metodologia é um processo a seguir que dá maior controle sobre os recursos que
serão utilizados no projeto. Controlando melhor o processo a equipe será mais
eficiente pois entregará o projeto com maior grau de acerto em termos de prazos
e custos. O bom uso de uma metodologia é importante porque permite evitar
práticas que levam ao insucesso e com isso reproduzir o sucesso.
A opção pela metodologia deve ser
tomada a partir de alguns fatores: as exigências de cada mercado em que a
empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional
necessária para adotá-la. Para exportar software, muitas empresas nacionais têm
se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em
mercados dominados por indianos e chineses, que já possuem capacitação neste
padrão. Em última instância, uma metodologia é um conjunto de regras de como
conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é
importante que já tenha se mostrado eficiente dentro da sua empresa, de
preferência em situação similar à que você está vivendo no seu projeto atual.
Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling
Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma
forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em
geral feita com símbolos gráficos, que se usa para traduzir processos
abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como
RUP, “Rational Unified Process”.
2. Comunique-se: não é só o peixe que morre pela boca!
Quando falta comunicação, os boatos e outras formas de ruídos
tomam seu lugar. Na falta de versão oficial, ficam circulando informações que
podem minar a moral da equipe e levantar suspeitas sem fundamento. O gerente de
projeto deve evitar esse tipo de prática, conhecida por "rádio peão",
dando informações claras e confiáveis sobre o status do projeto. Certamente
esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente
de projetos pode e deve não só falar sobre ele, mas também informar que está
trabalhando na solução, e não apenas comunicar que o problema existe. Problemas
sem uma perspectiva de solução são angustiantes e causam um desconforto na
equipe que muitas vezes é desnecessário.
A
criação de relatórios de progresso do projeto ajuda no processo de comunicação,
sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito
de um e-mail onde se critica um membro da equipe pelo atraso do projeto.
Imagine a mesma informação vinda de um relatório em que a data de término real
de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo
não fez a sua parte, mas no caso do e-mail a pessoa envolvida pode se
melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que
não gera ressentimentos.
3. Defina o escopo do projeto e detalhe as atividades
O “escopo do projeto” é o trabalho que deve ser realizado para
se obter um produto ou serviço com determinadas características e recursos. Comece
por definir o que deve ser feito e o que não deve. Esse processo nos permite
entender os contornos do projeto e traçar uma linha divisória entre o que deve
ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se
perdem em discussões intermináveis sobre recursos do produto final que o
tornariam “perfeito”. Sempre me lembro de um amigo muito experiente que, ante a
minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é
inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de
algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir
atingir. Com o tempo achei uma forma elegante de contornar as exigências de
projeto sem decepcionar os clientes: não é que não faremos o que está sendo
pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc... mas não
cabe na versão 1, que é o que estamos tentando desenvolver neste momento !
Afaste o fantasma da perfeição.
Para você não se perder numa lista interminável de características
da versão 1, uma boa ideia é pedir ao cliente que liste só que o que é
“absolutamente essencial”. Claro que se você der a ele 30 minutos para
responder, tudo será “absolutamente essencial”. Não adianta, temos de ser
realistas, o tempo é curto é temos de escolher só o que realmente é importante.
Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o
escopo do projeto passa por saber o que abandonar e o que reter do universo de
necessidades do cliente.
Bom,
definido o escopo do projeto, podemos passar para a fase de detalhamento das
tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as
“unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como
regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos. Em
paralelo, deve ser elaborado um orçamento levando em conta quantas horas de
cada profissional serão necessárias. Veja um modelo simples:
Para
montar este modelo, você precisa saber o custo-hora de cada profissional e
estimar o tempo que cada um gastará no projeto. Os profissionais podem estar
envolvidos em outros projetos e quando o programador está cuidando de uma fase
do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando
ao projeto A quando for para entregar ao cliente e obtiver a sua aprovação,
sobre o que falaremos mais adiante.
Estas estimativas são mais precisas à medida que se avança no
detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de
-25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10%
a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem
realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a
+10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará
diferença. Eu, por exemplo, sei que quando lido com determinados clientes,
haverá tanto “overhead” administrativo, como dezenas de reports para cima e
para baixo antes que cada passo importante seja dado, que eu já estimo 50% a
mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da
experiência do gerente, mas nessa hora, se a empresa tem um histórico de
projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido
com outras equipes e outros gerentes de projeto.
Um dos grandes segredos do gerenciamento de projetos é proteger
o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm
sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco
mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a
medida que o cliente vai entendendo suas necessidades e reformulando seus
objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um
francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar
o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu
quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter
calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se
indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio
pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências.
Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais,
em que eficiência é a palavra que está na ordem do dia, não há muita “gordura
para queimar” e os compromissos assumidos pelo gerente podem se transformar num
sacrifício, muitas vezes desnecessário, para toda a equipe.
Em
projetos de software, o “scope creep” é uma situação tão comum que não dá para
começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma
de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda
com o gerente do projeto, se for variável, o cliente assume os custos extras.
Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja
informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo
ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a
assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes
financeiros não participam destas reuniões e podem alegar que não há previsão
de recursos para os extras, então mantenha-os informados das novas condições
para evitar dissabores na hora do recebimento.
O
segundo cuidado é documentar meticulosamente o escopo do projeto. Este
documento resume o que será feito, com que características e com que recursos.
Ele é um “quase contrato”, mas não traz as cláusulas de rescisão e as
penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça
de cada um, há uma imagem diferente do que será o produto final. Á medida que
este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que
ele imaginou “não é bem aquilo” e podem começar as decepções.
A satisfação do cliente depende em muito do que será dito e
prometido no que se chama de “pré-venda”. É neste momento que o gerente de
projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente
escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento
de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa
pode ser delegada para um analista, mas a responsabilidade não sai nunca das
mãos do gerente. Eu costumo especificar toda a interface dos usuários com o
sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve
obter do cliente um “de acordo”, de preferência assinado no final do documento
em que todas as páginas serão rubricadas com um “visto” para que ele tome
ciência do que será feito. Não há palavras para expressar a importância deste
planejamento em que as expectativas serão levantadas e moldadas, de forma que,
diante do produto final, o cliente não possa se dizer decepcionado.
O terceiro cuidado é definir prioridades. O gerente deve ter a
sensibilidade para identificar quais são os requisitos obrigatórios e quais os
desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que
alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto
que vão mais longe e pedem ao cliente para definir o que ele considera
“sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30%
da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este
número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução
de 50% dos desperdícios já representaria benefícios suficientes que
compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o
ótimo é inimigo do bom”. Em suma: definir o escopo, no fundo, é saber o que
deve ser feito para atender a necessidade do cliente.
4. Conheça os envolvidos e monte seu time
Todos
os envolvidos no projeto são os "stakeholders". Nesse grupo estão não
apenas os membros da equipe, mas também os clientes e fornecedores envolvidos.
Dentro da empresa do cliente, há uma pessoa que se destaca por ser a
patrocinadora ("sponsor") do projeto. Ela é que cria as condições
para a contratação do projeto, mesmo que não seja ela que vá usar o produto
final.
É
importante que o gerente do projeto conheça os interesses de todos os
envolvidos. Imagine como é arriscado contar com um membro da equipe que não
está disposto a colaborar. Ele pode ser um problema mais do que uma solução
dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei
por uma situação destas quando fui destacado para gerenciar um projeto onde
havia um colaborador mais antigo e que entendia que ele é quem deveria estar
gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o
projeto avançava esta pessoa se tornava um problema cada vez maior, na medida
em que, não só ele não fazia a sua parte, como minava os demais membros da
equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me
explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para
completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto
à direção para que recebesse seu próprio projeto para gerenciar. É claro que
manter um “profissional” com este tipo de atitude não é bom negócio para a
empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a
própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do
jeito dele”.
No processo de definição do escopo, as habilidades necessárias
vão ficando mais claras. Nesse momento, é importante formar uma equipe com
competência diversificada e com experiência nas áreas de atuação do projeto. Em
projetos em que há muito conhecimento técnico envolvido, surge a figura do
"líder de projeto", um profissional com grande conhecimento técnico e
com capacidade de liderança entre os técnicos. Em geral é um profissional
sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A
experiência desse especialista pode economizar muito tempo e dinheiro no
projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a
sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.
5.
Desenvolva o cronograma junto com quem põe a mão na massa
Uma vez que temos as tarefas definidas a partir do escopo, temos
de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de
execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo
tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará
se comprometendo com um prazo para a sua execução. Por outro lado, quando se
trabalha com consultores externos, o custo será função direta do tempo estimado
para a execução do projeto. Ao fixar o cronograma, o profissional está dando
por tabela um orçamento da sua parte.
Veja estas atividades que representam as linhas gerais de um
projeto de sistema:
Note que além de saber o que deve ser feito, as tarefas têm três
propriedades importantes: duração, interdependência e responsável. A duração é
importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado
neste caso onde há duas figuras: o analista e o programador, a duração total do
projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos
alocados, alguns gerentes acreditam que se o projeto está atrasado, então
“basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma
vez que com mais gente, os problemas de comunicação aumentam e o projeto que já
está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se
precisa de especialistas em temas que os membros não dominem. A rigor, se o
planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em
algum momento do projeto. A atitude de simplesmente aumentar a equipe para
acelerar a produção é que está errada e deve ser combatida. Só que alguns
gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode
imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e
temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito
grande”.
O gerente de projetos deve trazer sua experiência para corrigir
as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem
estime 50 horas e depois, com a maior tranquilidade, cobre pelas 120 horas que
foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é
fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade
do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar
vinculada ao tempo de prestação de serviço, o contratante precisa de um
mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral,
prefiro trabalhar segundo as características do profissional mas de todos exijo
um relatório de horas que contém o dia, data de hora e início, tempo de
trabalho e a(s) tarefa(s) realizadas no dia.
Se
no planejamento da semana há tarefas que não foram realizadas, na reunião de
avaliação, eu pergunto por que a coisa não seguiu o ritmo programado e quanto
isso impacta na data final de entrega. Procure estabelecer pontos de controle,
"checkpoints", que são datas onde se medirá o andamento do projeto em
face do cronograma que havia sido programado. Nestas datas, pode-se estar
apenas executando-se uma verificação do progresso das atividades
("milestones") ou pode haver entrega de produtos ou subprodutos
(“deliverables”) tais como desenhos, especificações, protótipos, modelos,
etc...
Quem já
reformou ou construiu uma casa sabe que esta tão trivial experiência de
gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente
que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas
determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o
pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque
ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de
controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está
indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender
os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma
equipe mais eficiente. É verdade que em projetos de TI nem sempre dá para
“trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por
isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que
momento o projeto começa a atrasar e como fazer para recuperar o ritmo no
futuro próximo.
6. Monitore os riscos e seja proativo
Agora que todos sabem o que devem fazer, é importante mitigar os
riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista
de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são
duas coisas
A monitoração dos riscos envolve acompanhar o status de cada
risco e as opções de ações definidas para enfrentá-los, caso eles venham a se
tornar problemas reais. A monitoração também se preocupa em avaliar a
probabilidade de ocorrência de um risco, qual o seu impacto no andamento do
projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a
contratação de dois profissionais pode parecer um exagero mas o gerente do projeto
sabe que se algo acontecer nesta área do projeto o impacto será grande no
restante. Os profissionais passam a ser um backup do outro dentro da linha de
que “quem tem um, não tem nenhum”. Voltando ao nosso projeto de exemplo, chamo
a atenção para um recurso que o MS Project tem e que deve ser usado para se
identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da
lista de tarefas que elaboramos acima:
Note que há uma sequência de tarefas que quando alinhadas
compõem o prazo de duração do projeto todo. Destaquei o início e o final só
para que você perceba que se trata de uma série de processos que devem ser
gerenciados mais de perto uma vez que o atraso em algum deles acarretará o
atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os
riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de
perto, de forma mais proativa.
O
controle dos riscos é o processo de executar o plano de ações e divulgar seus
relatórios de status. Inclui também possíveis mudanças no plano de riscos, e
eventualmente até nos planos do projeto. Essas mudanças são referentes a
recursos, funcionalidades ou cronograma.
7. Formalize o início e o encerramento do projeto
O início do
projeto é um momento solene. O patrocinador deve formalizar a todos os
envolvidos que
o
projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se
preocupar com isso, mas imagine que haja resistência de setores da empresa que
se opõem ao projeto. Sem um documento que atesta que o projeto começou, o
gerente pode não conseguir apoio algum. Além disso, este documento funciona
como um “cumpra-se” de uma autoridade da empresa: não cabe discutir a ordem, o
projeto começou e todos os “arrolados” devem participar.
Outro momento importante é o do
encerramento do projeto. É preciso formalizar o final para que fique claro para
todos os envolvidos, especialmente para o cliente, que o projeto está concluído
e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão
ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação
à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida
em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é
definir-se projetos ao longo da vida útil do sistema com o objetivo de
melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos
(“aviônicos”) de um avião para auxílio ao voo é um projeto que se distingue da
sua manutenção rotineira. Ao final faz-se também uma reunião de avaliação dos
erros e acertos da equipe.
Chamadas de reuniões "post-mortem", elas servem para
se gerar uma lista de "melhores práticas" contribuindo para a
formação de uma base de conhecimento que poderá ser muito útil em projetos
futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições
quanto às "piores práticas", atitudes e decisões que se mostraram
ruins e que devem ser evitadas em projetos futuros.
Conclusão
Acima de tudo, gerenciar projetos é planejar e acompanhar a
execução com "um olho no peixe e outro gato". O gerente do projeto
deve se manter alerta e flexível com os acontecimentos do dia-a-dia, mas deve
estar sempre se reportando ao plano inicial para não perder o controle. A
principal qualidade do gerente de projeto é saber se comunicar bem com todos.
Ele é o ponto focal das informações, nele convergem as informações que ele
depois deverá processar e divulgar para todo o restante da equipe.
O
segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se
sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho
ditado caipira, "quando todos empurram na mesma direção, ná há carroça que
não saia do atoleiro".
fonte: http://goo.gl/SNbsc
