Escolar Documentos
Profissional Documentos
Cultura Documentos
Os 7 Passos Do Gerenciamento de Projetos: Fernando C. Barbi
Os 7 Passos Do Gerenciamento de Projetos: Fernando C. Barbi
Fernando C. Barbi
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 obter
a sua aprovao, sobre o que falaremos mais adiante.
Estas estimativas so mais precisas medida em que se avana no detalhamento do projeto. Para
estimativas iniciais, admite-se uma variao de -25% a +75%. Na fase de planejamento, o
oramento deve ter uma variao 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 situaes anteriores far diferena.
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 experincia do gerente, mas nessa hora, se a empresa tm um histrico 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 execuo tm srias dificuldades em cumprir o cronograma
e estouram o oramento. 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 francs
ilustre ? No, trata-se apenas da forma como o cliente costuma abordar o assunto: j que o
sistema faz isso, ele pode ento fazer aquilo. Agora eu quero aquilo tambm 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
prprio p, j que o prazo e oramento no sero to elsticos quanto as exigncias. Devemos
sempre contar com uma certa margem de manobra, mas nos tempos atuais, em que eficincia
a palavra que est na ordem do dia, no h muita gordura para queimar e os compromissos
assumidos pelo gerente podem se transformar num sacrifcio, muitas vezes desnecessrio, para
toda a equipe.
Em projetos de software, o scope creep uma situao to comum que no d para come-los
sem tomar algumas precaues. O primeiro cuidado negociar a forma de remunerao: fixa ou
varivel. Se for fixa, o risco das mudanas est toda com o gerente do projeto, se for varivel, 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 precauo, 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 execuo da tarefa. Gerentes financeiros no participam destas reunies e
podem alegar que no h previso de recursos para os extras, ento mantenha-os informados das
novas condies 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 caractersticas e com que recursos. Ele um quase-contrato mas no
traz as clusulas de resciso e as penalidades. Neste momento, tudo est bem e todos
concordam. S que, na cabea 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 no bem aquilo e podem comear as decepes.
A satisfao 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 relatrios. Esta tarefa
pode ser delegada para um analista, mas a responsabilidade no sai nunca das mos do gerente.
Eu costumo especificar toda a interface dos usurios com o sistema: telas e relatrios. Depois de
colocar tudo no papel, o gerente deve obter do cliente um de acordo, de preferncia assinado
no final do documento em que todas as pginas sero rubricadas com um visto para que ele
tome cincia do que ser feito. No h palavras para expressar a importncia deste planejamento
em que as expectativas sero levantadas e moldadas, de forma que, diante do produto final, o
cliente no possa se dizer decepcionado.
O terceiro cuidado definir prioridades. O gerente deve ter a sensibilidade para identificar quais
so os requisitos obrigatrios e quais os desejveis, marcando cada um segundo com a sua
prioridade. Isso evita que algum arbitre o que importante no lugar do cliente. H gerentes de
projeto que vo mais longe e pedem ao cliente para definir o que ele considera sucesso do
projeto. Por exemplo, num sistema em que havia desperdcio de 30% da matria-prima, foi
considerado sucesso reduzir esta taxa para 15%. Mas este nmero ainda alto, diria voc. Sim,
mas o cliente considerou que uma reduo de 50% dos desperdcios j representaria benefcios
suficientes que compensariam os investimentos no projeto. Alm 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.
Note que alm de saber o que deve ser feito, as tarefas tm trs propriedades importantes:
durao, inter-dependncia e responsvel. A durao importante mas se as tarefas podem ser
realizadas em paralelo, como ilustrado neste caso onde h duas figuras: o analista e o
programador, a durao total do projeto encurta. Dessa possibilidade de trade-off entre tempo e
recursos alocados, alguns gerentes acreditam que se o projeto est atrasado, ento basta colocar
mais gente que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os
problemas de comunicao 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 no
dominem. A rigor, se o planejamento foi bem-feito, j se sabe que esta mo-de-obra ser
recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para
acelerar a produo 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 explicaes para os atrasos,
afinal o projeto era mesmo muito grande.
O gerente de projetos deve trazer sua experincia para corrigir as expectativas muito otimistas de
algum colaborador mais afoito. Sim, h quem estime 50 horas e depois, com a maior
tranqilidade, cobre pelas 120 horas que foram necessrias para realizar a tarefa. Ele s errou em
140% ! Se o preo fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a
qualidade do produto final podem sofrer em decorrncia da pressa. Se a remunerao ficar
vinculada ao tempo de prestao de servio, o contratante precisa de um mecanismo de controle
minimamente confivel. Eu no uso uma frmula geral, prefiro trabalhar segundo as
caractersticas do profissional mas de todos exijo um relatrio de horas que contm o dia, data de
hora e incio, tempo de trabalho e a(s) tarefa(s) realizadas no dia.
Se no planejamento da semana h tarefas que no foram realizadas, na reunio de avaliao, eu
pergunto porque a coisa no seguiu o ritmo programado e quanto isso impacta na data final de
entrega. Procure estabelecer pontos de controle, "check-points", que so 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 verificao do progresso das atividades ("milestones") ou pode
haver entrega de produtos ou sub-produtos (deliverables) tais como desenhos, especificaes,
prottipos, modelos, etc...
Quem j reformou ou construiu uma casa sabe que esta to trivial experincia de gerenciamento
de projeto pode acabar mal. Quantas histrias existem de gente que foi pagando o pedreiro sem
atrelar os pagamentos a entregas de tarefas determinadas. Nestas histrias tristes, o dinheiro
acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo
porque ele no cuidou de atrelar entregas de tarefas a pagamentos, no 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
monitorao para saber em que momento o projeto comea a atrasar e como fazer para recuperar
o ritmo no futuro prximo.
Fonte: http://www.microsoft.com/brasil/msdn/tecnologias/carreira/gerencprojetos.mspx