Arquivo

Archive for the ‘Na prática’ Category

5 objetivos pra não esquecer

março 29, 2010 Deixe um comentário

Ron Holohan resumiu de forma prática em seu post “The 5 goals of a Project Manager” o que ele pensa serem as principais metas a serem alcançadas pelos GPs em seus projetos.

Como tem muita coisa escrita sobre gerenciamento de projetos atualmente e pouco tempo para a maioria das pessoas lê-las, gosto de textos focados assim que de forma suscinta nos direcionam para o que realmente é importante. Categorizo os 5 pontos de Holohan em 2 grupos principais. O primeiro grupo, com os três primeiros pontos, trata do básico:

Objetivo 1: Terminar no prazo

Objetivo 2: Terminar dentro do custo

Objetivo 3: Atender aos requisitos

A boa e velha tríade escopo / tempo / custo (com boa vontade de quem quer simplicidade, daria pra incluir a variável qualidade no objetivo 3).

O segundo grupo, com os dois últimos pontos, já aborda uma questão muitas vezes esquecida pelos GPs: a REAL satisfação de todas as partes interessadas com o projeto. Veja:

Objetivo 4: Mantenha os clientes felizes

Objetivo 5: Assegure-se que seu time está feliz

Nesse grupo aparece o que está além do contrato, da mera formalidade.  Aquilo que é importante, menos para garantir o pagamento pelo projeto corrente, mas fundamentalmente para aumentar as chances de sucesso em novos projetos (no caso dos clientes até mesmo para viabilizar a existência de um novo projeto).

De que adianta atender aos requisitos escritos se as reais expectativas dos clientes não estão devidamente expressas e resolvidas? Será que vale a pena esconder alguns problemas dos clientes só pra parecer que tudo está bem (felicidade vai passar longe quando ele descobrir)? E o seu time: será que finalizar em dia, dentro do custo, com tudo atendido mas com a equipe em farrapos é algo realmente bom? Estas pessoas vão querer trabalhar com você no futuro?

São dois pontos simples, mas esquecidos pelo fato de não se traduzirem na letra fria dos contratos, das especificações. Ou melhor: eram esquecidos. Já gravou na memória, né?

Anúncios
Categorias:Na prática, Soft skills

Turbine o gerenciamento de seus projetos com novas tecnologias

março 26, 2010 5 comentários

Passeando pela web durante a madrugada encontrei um guest post excelente de Andrew Filev no blog “A girls guide to Project Management”. Nest post, Andrew mostra a importância das mídias sociais em GP por meio de duas histórias de gerentes de projeto com rotinas bem diferentes. Ambos trabalham nos EUA e gerenciam projetos para clientes na Europa. Veja abaixo como é a vida destes caras.

Jake

Jake, um dos gerentes de projetos, está sempre muito ocupado. Sua rotina diária é composta das seguintes atividades:

  • Checar e-mails logo no início da manhã para obter as atualizações do projeto pelos diversos membros da equipe;
  • Ligar, enviar e-mails ou encontrar-se pessoalmente para coletar novas informações do projeto e garantir que tudo vai bem;
  • Atualizar o plano de projeto com todas as informações obtidas;
  • Gerar relatórios de status para os diversos executivos da empresa;
  • Comunicar-se por e-mail ou telefone com o cliente que está em Londres;
  • Resolver uma série de problemas que aparecem no projeto por meio do telefone, reuniões e e-mails;
  • Lidar com a confusão de se ter várias versões de documentos do Word e do Excel.

As pessoas do time de Jake também são bastante ocupadas e enfrentam alguns problemas.Veja:

  • Eles recebem entre 50 a 100 e-mails por dia que precisam ser checados necessariamente;
  • Eles não têm acesso direto ao plano de projeto. Assim, se eles precisam reportar progresso em suas atividades eles precisam enviar um e-mail para Jake.

Às vezes eles perdem ou se esquecem de itens importantes, mas isto não é um grande problema já que Jake sempre pode ligar para eles para lembrá-los. 🙂

Jake é um excelente GP e adora seu trabalho. Ele trabalha arduamente para manter tudo em ordem, mas raramente tem tempo para pensar em sua estratégia de gerenciamento de projetos ou sobre a motivação de seu time e normalmente depende de horas extras para completar se trabalho. Mas, fazer o que? Vida de GP não é fácil, não é mesmo?

Simon

Simon, o outro gerente de projetos, tem uma rotina diferente. Veja as características do seu trabalho e de sua equipe:

  • Simon checa o e-mail pela manhã, mas a quantidade de mensagens recebidas não passa de 10 a 15;
  • Sua equipe também não precisa trocar dezenas de e-mails já que eles utilizam um sistema de gerenciamento de projetos baseado na WEB, em que todos podem observar o progresso dos projetos on-line (inclusive os representantes do cliente em Barcelona e os executivos da empresa). Além disto, os próprios membros da equipe do projeto podem atualizar suas tarefas diretamente, garantindo uma maior aderência do plano de projeto com a realidade.
  • Logo no início do trabalho, Simon criou um blog do projeto e compartilhou por meio dele a sua visão sobre o desenvolvimento do projeto com sua equipe. Os membros da equipe se sentiram encorajados, e além dos feedbacks aos posts de Simon passaram também a contribuir com sugestões para melhorar o andamento do projeto. Todos recebem as atualizações por meio de feeds RSS e podem usar recursos de tags e buscas para encontrar rapidamente qualquer tópico de interesse que eventuamente tenha sido discutido;
  • Simon não costuma usar o telefone. Ele prefere o Skype, já que além de voz a ferramenta integra também funções de chat e video-conferência. Reuniões diárias de 15 minutos são executadas envolvendo pessoas da equipe em 3 cidades distintas dos EUA e o cliente em Barcelona;
  • Simon gosta de ferramentas de instant messaging, mas acredita que elas não são ideais para sua equipe. Uma aplicação de microblogging mostrou-se mais adequada. Membros da equipe a utilizam para dizer no que estão trabalhando, fazer perguntas, compartilhar links e solicitar ajuda em algum problema específico. A possibilidade de fazer tudo isso pela Internet tem sido algo muito útil para um time distribuído em 4 fusos horários diferentes;
  • Simon náo tem problemas com versões de documentos, já que toda a documentação é gerada em um Wiki.

Simon também é um profissional muito ocupado. Ele está sempre pensando nas próximas etapas do projeto e em como motivar sua equipe. Ele investe também boa parte de seu tempo nos relacionamentos com todos os envolvidos em seus projetos e até fez bons amigos entre clientes e colegas de time. Alguns deles são seus amigos ou contatos em redes como Facebook e Linkedin. Sua equipe é menos estressada que a de Jake, já que tem menos problemas de comunicação e como consequencia comete menos erros. Todos se sentem parte de uma grande comunidade, a despeito de estarem tão distantes fisicamente uns dos outros. O resultado: expectativas do cliente sempre superadas!

Simon não liga muito para buzz words tais como WEB 2.0 ou “mídias sociais” e não se preocupa em sempre seguir a última tendência. Apenas não tem medo de experiementar o novo. Alguns destes experimentos invariavelmente têm se mostrado extremamente úteis para a execução de sua função como gerente de projetos.

E VOCÊ?

Agora pense (30 segundos apenas): Que tipo de profissional tem mais valor? Jake ou Simon? Que tipo de profissional VOCÊ quer ser?

Aprenda estes conceitos e pare de brigar com seu chefe!

março 24, 2010 2 comentários

Em termos bem simples, uma estimativa é uma previsão referente ao esforço gasto,  custo ou duração de uma atividade ou projeto.

Uma meta é uma definição de um objetivo de negócios desejável.

Um plano é uma forma  de se atender às metas.

Perceba então: são coisas completamente diferentes, apesar de correlatas!

O processo de estimar é analítico e não viesado e busca acurácia, correção dos números. Baseado em experiência e dados históricos eu tento prever com a mínima margem de erro, o quanto eu gastaria ou quanto demoraria um projeto.

Já o processo de planejar é viesado por natureiza. O objetivo de um planejamento é criar uma rota para se atingir metas, levando em consideração as minhas estimativas.

Estas diferenças são  motivo de desentendimentos terríveis entre gerentes de projeto e executivos. Imaginem o seguinte diálogo:

Executivo: Quanto tempo você acha que o projeto demorará? Precisamos do software em 3 meses.

Gerente de Projetos: Vou avaliar e te dou a resposta em algumas horas…

Depois de analisar seus números…

Gerente de Projetos: Estimamos que o projeto levará 5 meses.

Executivo: 5 meses? Você é surdo? Eu disse que preciso do software em 3 meses.

Agora repare: o executivo solicitou uma estimativa mas na realidade queria um plano para atender à sua meta de negócios (ter o software em 3 meses). O gerente de projetos fez o que lhe foi mandado, mas acabou ouvindo poucas e boas de graça porque não soube como lidar com um executivo.

Da próxima vez em que isso lhe acontecer não faça apenas o que lhe foi solicitado. Entenda que seu executivo quer algo mais. E faça o possível para ter um plano factível. Tente negociar o escopo, entenda a real necessidade de se cumprir a meta, e negocie condições mínimas para que seja possível se atingi-la. É claro que, se a diferença entre sua estimativa e a meta for muito grande, o plano tende a ser de altíssimo risco e talvez não valha a pena ir adiante. O melhor seria flexibilizar a meta. Mas você só vai conseguir negociar se mostrar capacidade e conhecimento de causa.

As definições e o diálogo hipotético foram retirados do excelente livro Software Estimation de Steve McConnell. Pra quem se interessa pelo assunto “estimativas”, recomendo fortemente a leitura.

Categorias:Na prática

Tão simples quanto possível. Gerenciar projetos é…

março 12, 2010 2 comentários

…transformar idéias, objetivos, desejos e necessidades, organizacionais ou pessoais, em resultados concretos.

É uma definição pessoal. Deliberadamente simples, assim como este post. Pra que você nunca mais se esqueça da ESSÊNCIA do Gerenciamento de Projetos. E não se afogue no mar de informações que existe sobre o tema atualmente.

Deus pode estar nos detalhes. Mas o diabo também está.

“A simplicidade é o último grau de sofisticação” – Leonardo da Vinci
Categorias:Na prática

Dois passos para começar com o Gerenciamento de Projetos em sua Empresa. Já!

março 11, 2010 4 comentários

“Geralmente há um acordo substancial quanto ao que deve ser feito, mas sempre há desacordo quanto ao que deve ser feito em primeiro lugar.”

Por onde começar? Tantos livros, blogs, modelos, metodologias, normas,  níveis,  áreas de conhecimento, grupos de processos…… Pode ser difícil decidir.

Mas vamos lá: vou responder à pergunta original de forma muito direta. Se você quer começar a obter os benefícios do gerenciamento de projetos em sua empresa faça duas coisas. Defina como:

  1. Identificar e selecionar os projetos a serem executados;
  2. Medir o desempenho de custo e prazo, destes projetos.

O ponto 1 ajuda a você fazer as coisas certas e a encapsular as milhões de coisas a serem realizadas em sua empresa em pacotes relativamente bem definidos chamados projetos.

O ponto 2 permite que você cheque periodicamente se está conseguindo fazer o que foi proposto, dentro do tempo certo e gastando o que foi previsto. E mais: permite que você corrija os erros e resolva os problemas que aparecerem pelo caminho de modo a colocar o projeto nos eixos quando ele teimar em deslizar (e pode ter certeza, ele vai teimar).

Mas e o resto, é irrelevante? Não, não é. Mas vem a reboque. Pra conseguir medidas consistentes de desempenho você vai ter que necessariamente gerenciar bem escopo, qualidade, riscos e algumas outras variáveis que provavelmente  já estava sentido falta neste texto.

Isso não é simplificar demais as coisas? Não,  também não é. Este humilde post não se propõe a mostrar detalhadamente tudo o que deve ser feito e a ensinar como remover todos os obstáculos do caminho. Ele só quer fazer você começar. É importante saber o que fazer PRIMEIRO.

PS1: Se você não tem a menor idéia de como começar a executar os dois passos propostos, fale comigo. Nos comentários deste post, por e-mail/gtalk(andriele@gmail.com), ou por skype (andriele.ferreira.ribeiro).

PS2: 24/03 começa meu Curso Preparatório para PMP em BH. Se você tem interesse veja maiores informações aqui.

PS3: tem mais sobre Gerenciamento de Projetos no Twitter. Basta seguir andrielefr.  Assine também o feed deste blog ou se inscreva para receber os posts por e-mail na na faixa direita desta página.

Categorias:Na prática

Quão único é um projeto?

novembro 11, 2008 8 comentários

Um projeto, por definição, cria um produto, serviço ou resultado único, exclusivo. Mas quão único é este resultado? Já parou pra pensar a respeito?

Se nunca fez isso, aproveitemos o momento pra refletir um pouco.

Situação A: Suponha que você trabalhe em uma instituição de alta tecnologia e receba a incumbência de gerenciar um projeto de criação de um sistema imunológico artificial, que será posteriormente utilizado em chips tolerantes a falhas (antes de me chamar de louco saiba que tem gente por aí tentando produzir algo nesta linha). Inovação da pesada hein? Provavelmente ninguém nunca fez isso antes e quem teve a idéia de levar a iniciativa adiante provavelmente não sabe exatamente como chegar lá. O processo de criação de um produto desta natureza está longe de ser prescritivo. Ao contrário é provavelmente altamente empírico, o que quer dizer que algumas tentativas e erros podem e devem acontecer pelo caminho.

Situação B: Você agora é um gerente de projetos de uma empresa de infra-estrutura de TI convencional. Já implementou dezenas de redes de computadores em escritórios deste “Brasilzão” afora e acaba de ser nomeado GP para um nova inciativa do gênero. O passo a passo pra resolver a demanda do cliente é bem conhecido. Você tem documentado um processo de implementação de redes que, tirando algumas coisas que sempre variam caso a caso, funciona bastante bem de modo geral.

Situação A e Situação B podem ser tratadas como projetos, certo? No caso da Situação A creio não haver muita dúvida. Em B, é bom lembrar àqueles que ainda não estão muito seguros que “algumas coisas sempre variam caso a caso” e que “Deus está nos detalhes” – esta última frase não sei exatamente de quem é mas sempre gostei dela e acho que se encaixa bem aqui.

Dado que consegui convencê-los que ambas as demandas podem ser consideradas projetos (se alguém ainda não se convenceu comente o post logo abaixo dizendo porque :-)), podemos afirmar também que as duas devem ser planejadas, monitoradas e controladas. Mas será que devemos planejá-las, monitorá-las e controlá-las da mesma forma? Veja a figura abaixo. Ela nos ajuda a clarear um pouco a situação:

desenho4

Veja que a demanda B pode ser classificada como projeto, mas situa-se próximo ao que costumamos chamar de “Operações Continuadas”, para classificar aquilo que é repetitivo. Já a demanda A está muito próxima do outro extremo do desenho. Denominei esta outra extremidade de “Mundo Completamente Desconhecido”, mostrando que, quando mais para direita, mais nebuloso e indefinido é o resultado que se espera do projeto. O ponto “Marco zero de projetos” é conceitual e serve apenas para mostrar que a partir de algum momento, algo deixa de ser repetível e contínuo para se tornar temporário e exclusivo.

Algumas conclusões interessantes podem ser tiradas deste desenho:

  • A primeira é que a distinção entre operações continuadas e projetos não é discreta, mas contínua. Existem operações continuadas muito padronizadas (ex: produção de tijolos), operações continuada menos padronizadas (ex: manutenções de software não projetizadas), projetos com produtos finais pouco exclusivos (situação B) e projetos com produtos finais muito exclusivos (situação A);
  • E a segunda, retornando à nossa dúvida que ficou em aberto é: apesar de A e B serem considerados projetos, tratam-se de duas demandas com perfis bastante diferentes. Assim a abordagem gerencial para conduzir as duas iniciativas será, naturalmente diferente.

Em B as entregas, tanto finais como intermediárias, podem ser delineadas com boa precisão. Afinal de contas isso já foi feito dezenas de outras vezes. É possível definir, seqüenciar e estimar recursos e durações com boa taxa de acerto para uma quantidade razoável de atividades, até mesmo para algumas próximas do final do ciclo de vida do projeto. Ou seja, enxergamos com clareza todo o fluxo de atividades a ser desenvolvido, do início ao fim do projeto.

Em A as coisas já são mais complicadas. Tem-se uma idéia do que se quer ao fim do projeto, mas é impossível definir-se logo no primeiro ciclo de planejamento, de forma prescritiva, a seqüência de todas atividades a serem executadas para chegar-se ao produto final. Produtos intermediários são gerados e seus resultados são analisados para se definir etapas posteriores e em alguns casos para se decidir se o projeto segue ou não adiante. É possível planejar, monitorar e controlar mas a filosofia é outra. O produto final é mais ou menos conhecido. Há objetivos traçados. Mas o caminho que é percorrido é definido ao longo do projeto. Planejado sim, mas com antecedência menor.

De forma bem pragmática, executar um projeto como o descrito em B é parecido com viajarmos para o Nordeste comprando um pacote turístico. Sabemos que vamos conhecer 5 cidades, os hotéis em que vamos nos hospedar, os passeios que vamos fazer (inclusive com os horários). Sempre tem algum imprevisto, mas de modo geral a coisa não muda muito. Executar A é mais ou menos como viajar para o Nordeste por conta própria com o hotel para o primeiro destino reservado e um objetivo de conhecer outras 4 cidades. Que outras 4? Ainda não sabemos, mas quando estivermos prestes a sair da primeira já teremos reservado o hotel para a segunda, tendo inclusive uma boa idéia de quando iremos para a terceira. Alguém poderia me dizer: o bom mesmo é pegar o carro e ir viajando sem destino certo… Parando quando der vontade, conhecendo praias nunca antes visitadas, decidindo tudo na última hora, sem plano algum. Eu diria que um comportamento assim pode até funcionar… pra sua próxima viagem para o Nordeste. Mas nunca para a criação de um sistema imunológico artificial. Entendeu a diferença?

Categorias:Na prática

Você conhece a força das restrições do seu projeto?

agosto 26, 2008 7 comentários

Uma restrição é algo que limita a liberdade de ação de um gerente na condução de um projeto. Limitações normalmente não são coisas muito agradáveis e podem afetar o desempenho de uma iniciativa. Seria interessante, portanto, que sempre conhecêssemos a fundo as restrições que nos são impostas, certo?

Imagine por exemplo o projeto que tem como entrega a realização da cerimônia de abertura dos Jogos Olímpicos. Será que alguém cogitaria a possibilidade da ocorrência de um atraso neste caso? Certamente não. Isto significa que há para este projeto uma restrição de tempo fortíssima.

Agora pense na seguinte situação: uma empresa do setor automobilístico contrata uma empresa de tecnologia para desenvolver um software para controle de alguma operação industrial. Além de esperar um software que atenda às suas necessidades, a contratante exige que a contratada siga um processo de desenvolvimento de software específico definido por ela. Em princípio esta é uma restrição do projeto. Mas seria esta uma restrição forte? Tudo depende do contexto e do motivo pelo qual ela foi imposta. Pode ser que a contratante tenha tido boas experiências com esse processo proposto e queira por algum motivo padronizar a forma como seus fornecedores produzem seus softwares. Mas pode ser também que alguém na empresa automobilística tenha ouvido falar que tal processo é bom e sem nenhum conhecimento de causa tenha estabelecido a restrição. Pra piorar, vamos assumir que a contratada dispõe de um processo de desenvolvimento muito melhor do que o imposto pela restrição. Será que é certo simplesmente aceitar a situação? Ou seria melhor tentar mostrar ao cliente que o caminho a priori escolhido por ele não é o melhor. Na segunda possíbilidade, (situação em que a escolha pelo processo imposto foi baseada em opiniões vagas) a restrição não tem bases “fortes” e poderia com um pouco de empenho ser eliminada para o bem do projeto.

Já vi também algumas restrições de tempo criadas de forma equivocada. Em um determinado projeto o sponsor, que era um cliente externo à organização, havia definido que o projeto deveria ser finalizado em 4 meses. A equipe fez o planejamento e chegou à conclusão de que o tempo mais adequado para o atendimento de todas as necessidades seria em torno de 6 meses. O sponsor não aceitou e o cronograma foi comprimido para se adequar à restrição de 4 meses. O problema é que a compressão pode gerar riscos para o projeto, que se materializados podem ter o efeito inverso: uma data fim ainda mais distante que a original. E foi o que acabou ocorrendo neste caso específico. Tempo final de execução: 9 meses. Mais tarde descobriu-se que a finalização do projeto em 4 meses não era uma restrição de fato. O sponsor queria apenas dar uma pressionada no fornecedor, porque achava que de outra forma o produto esperado demoraria demais para ser finalizado.

O grande problema é que normalmente informações sobre a verdadeira força das restrições não estão disponíveis facilmente. Não caem em nosso colo de graça. Para conseguí-las, é preciso que o gerente de projetos se dedique a entender a fundo o contexto que cerca o projeto. E que seja corajoso o suficiente para questionar e negociar aquilo que parece não fazer muito sentido, independentemente de quem tenha imposto.

Conhecer a força das restrições é bastante útil também para que decisões importantes possam ser tomadas no decorrer do projeto. Em uma situação extrema, em que custo, qualidade ou prazo terão que ser sacrificados, qual deles escolher? O ideal seria nenhum, mas em alguns casos sabemos que as coisas não são tão perfeitas assim.

Portanto, ao assumir um projeto, antes de aceitar tudo aquilo que lhe é imposto, analise, questione, argumente. Pode estar aí a diferença entre seu sucesso ou fracasso.

Categorias:Na prática