prova superada

Chegou ao fim o projecto que captou toda a minha atenção durante os meses de Dezembro e Janeiro.

Tive o prazer de ser um dos gestores de projecto que esteve envolvido na mudança da marca Clix para Optimus Clix, e como diz o novo slogan, o Clix agora é Optimus.

Foi um projecto que durou cerca de 2 meses onde tive o prazer de coordenar uma equipa de cerca de 11 profissionais.

Era um projecto de alto risco com datas completamente inadiáveis que termina com sucesso. E porquê? Porque conseguimos terminar on-time, on-budget e com a qualidade desejada. Por incrível que pareça sempre que um projecto cumpre estas 3 directrizes pode-se dizer que é um projecto de se lhe tirar o chapéu pois (infelizmente) grande parte dos projectos em Portugal falham redondamente em pelo menos um destes três pontos.

Se a memória não me falha e não querendo ser injusto para com os restantes projectos que tive oportunidade  de gerir arrisco dizer que este foi o projecto que mais gozo me deu ver o resultado final.

É por projectos intensos como este que dá vontade de ser gestor de projectos.

Por fim não poderia deixar de referir a equipa que tive o prazer de gerir constituída por excelentes profissionais que fez com que este projecto tivesse um final feliz.

A todos os envolvidos, um “muito obrigado” e um “foi um prazer enorme trabalhar com vocês”.

Agora é a altura de festejar e de consolidar as “lessons learned”.

Até para a semana.

Anúncios

gestão da qualidade

A qualidade num projecto é fundamental. E inexplicavelmente é onde grande parte dos projectos facilita de forma a cumprir com prazos, custos. O que acaba por ser o maior contra-senso porque efectivamente se um produto não tiver qualidade qual é o objectivo do projecto? Gastar budget por gastar? Então não é preferível redefinir o âmbito e ter um produto menos ambicioso mas com qualidade do que um “elefante branco” sem qualidade, por vezes inferior ao produto que vai ser “reformado”, que vai ser mal recebido pelos utilizadores finais e por consequência sem utilidade nenhuma?

Cabe ao gestor do projecto defender intransigentemente a qualidade do seu projecto, até porque ninguém gosta de “criar” um produto “coxo”, sem utilidade. O gestor de projecto deve apelar sempre ao bom senso do sponsor e convence-lo de que cortar na qualidade nunca deve ser, mesmo como último recurso. Uma das partes fundamentais de um projecto é sem dúvida a bateria de testes. A equipa de projecto deve ser cuidadosa a testar o código desenvolvido, apesar de por vezes não ter a paciência ideal para o fazer. Eu sei que custa (também já passei por isso) mas se a equipa não é competente e testar, inclusivamente o gestor de projecto também o deve fazer, todo o trabalho desenvolvido caí por terra. É um autentico morrer na praia que vai trazer efeitos negativos à equipa de projecto, pois ficará mal vista perante sponsors e restantes stakeholders.

Por isso lembrem-se, os testes fazem parte do projecto e o seu objectivo é garantir a qualidade do que foi feito. Se não garantirmos a qualidade então não fizemos nada e todo o projecto está pronto para ir para o lixo e engrossar o capitulo das “lessons-learned“.

Até para a semana.

atrasos

Sem dúvida que o bicho papão de qualquer projecto é o  “atraso”.

E afinal o que são os “atrasos”?

Os atrasos são deslizes no tempo, ou seja, é o resultado da decisão dos stakeholders em abdicar do Tempo em favor da Qualidade e do Custo (de forma a cumprirem com determinadas expectativas).

Esta decisão é um clássico na gestão de projecto e por norma das mais erradas. Isto porque é mais vantajoso cumprir os tempos do projecto e refazer o âmbito (menos funcionalidades, menos relatórios, menos detalhe) mantendo a qualidade e o custo do que pura e simplesmente abdicar do tempo na expectativa de manter o âmbito intacto e que os novos tempos se cumpram sem mais percalços.

Tendo em conta que os “atrasos” acontecem sempre nos projectos, os stakeholders deveriam encarar este fenómeno de outra forma. Não pelo lado negativo mas sim como um acontecimento natural que exige uma reflexão sobre todo o projecto.

E a que se devem os “atrasos”?

Basicamente os atrasos devem-se a todos os stakeholders no geral:

– programadores (atrasarem-se nos desenvolvimentos);

– líder técnico (estimativas erradas);

– gestor de projecto (má orquestração de todas as partes envolvidas no projecto e/ou estimativas erradas);

– outras equipas (é sempre difícil coordenar um projecto em que envolva mais do que 1 equipa, onde cada uma tem o seu objectivo e o seu respectivo calendário);

– decisores (redefinição de requisitos a meio dos desenvolvimentos quer por alterações da realidade quer por omissão de requisitos durante a fase de análise ou até por alteração dos decisores em si);

– sponsor (alteração da prioridade/importância do projecto);

Resumindo, os “atrasos” podem acontecer por culpa de qualquer pessoa ligada ao projecto.

Mas não é só por causa das pessoas que um projecto pode atrasar. Existem outros fenómenos que originam atrasos:

– fenómenos externos à organização (situação actual da economia e decisões políticas);

– tecnologia (tecnologia desadequada ao projecto);

– indisponibilidade dos stakeholders (férias, despedimentos, gravidez);

ou seja, os atrasos podem ser motivados por imensos factores o que faz com que os atrasos em si sejam perfeitamente naturais dentro dos projectos. E sendo uma realidade intrínseca em qualquer projecto, a principal função do gestor de projecto é não só evitar os atrasos mas essencialmente fazer com que qualquer atraso prejudique o menos possível o projecto.

Para me explicar melhor vou dar um exemplo: Imaginem um capitão num barco em alto mar. Apesar de poder optar sempre pelas rotas mais favoráveis, a verdade é que eventualmente vai-se cruzar com uma tempestade. E aí sim é que se vê quem é bom capitão. Bom capitão é aquele que atravessa a tempestade e leva a sua tripulação para um porto seguro. E deve-se dar tanto ou mais valor a quem consegue atravessar uma tempestade do que a quem, por sorte ou mérito, a consegue evitar (a sorte não dura para sempre e nem todos os dias somos brilhantes).

Creio que o assunto “atrasos” está por agora encerrado.

Estamos agora a começar a entrar na gestão da mudança (em atravessar tempestades). Mas sobre esse tema iremos falar no próximo post.

Até para a semana.

custo qualidade tempo

Custo, qualidade e tempo são sem dúvida as 3 grandes preocupações de um gestor de projecto no decorrer de qualquer projecto.

Todos os projectos giram em torno destas 3 variáveis.

Mesmo num projecto que tenha o custo fechado, a qualidade pretendida bem definida e o tempo bem dimensionado estas 3 variáveis têm de estar em constante vigilância. Isto porque os imprevistos acontecem (obrigado Murphy!) e ao mínimo deslize estas variáveis terão de ser equacionadas.

Isto porque a partir do momento em que temos um “atraso” (fenómeno perfeitamente normal no mundo da gestão de projecto) temos de confrontar os stakeholders e tomar decisões. Sacrificamos a qualidade? Aumentamos o tempo? Aumentamos o custo? São as 3 questões que têm de ser respondidas sempre que um projecto começa a desviar-se do seu plano original.

A verdade é que se sacrificarmos a qualidade o projecto poderá não corresponder às expectativas dos utilizadores finais, poderá não haver tempo suficiente para recuperar o “atraso” e até poderemos não ter budget necessário para inverter o rumo do projecto.

Tantas questões para tão poucas respostas!

Tomar decisões nunca é fácil e quando são relativas a um projecto ainda mais difíceis serão, pois um projecto por norma impacta várias áreas de uma organização, ou tem visibilidade para o cliente final ou é vital para o core business da empresa. Depende basicamente da sua criticidade, mas por norma não existem projectos “fáceis” e pouco “críticos” em que não seja necessário ponderar bem antes de decidir.

E não pensem que é sempre culpa do gestor de projecto se um projecto começar a desviar-se do seu plano original. Desde problemas de ordem técnica, fenómenos externos à equipa de projecto ou mesmo à organização, problemas na equipa de projecto, mudança de sponsor ou de stakeholders, existem imensos motivos para que um projecto se desvie da sua rota original e que leve por conseguinte à tomada de decisão sobre o custo, qualidade e tempo.

Mas sobre “atrasos” falarei no próximo post.

Até para a semana.