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.

gestão do risco

risco | s. m.
1ª pess. sing. pres. ind. de riscar
risco

s. m.
1. Risca.
2. Delineamento; traçado; debuxo.
3. Perigo; inconveniente.
4. Gír. Golpe com instrumento cortante.
A risco de: expondo-se a.
Correr o risco: estar exposto a perigo.

Olhando para a definição no ponto 3 conseguimos logo perceber que não é fácil gerir perigos ou algo que seja inconveniente.

O risco é mesmo isso, algo perigoso, que pode fugir muito rapidamente de controlo e que para ser “contrariado” apenas dispomos de 2 ferramentas:

– evitar;
– mitigar;

Claro que o cenário ideal é evitar os riscos. E como? Através de um planeamento cuidado onde uma boa margem de segurança (aka margem de “caganço”) é de todo recomendável.

Mas infelizmente por vezes os piores cenários efectivamente ocorrem. E então quando algo corre realmente mal devemos ter o chamado “plano B”, ou seja, como é que posso mitigar, minimizar o impacto no projecto. Sem cair em exercícios de futurologia, o gestor de projecto deve estar sempre aware do worst case scenario e como actuar perante este:

– os stakeholders estavam ao corrente deste risco?
– o risco pode ser partilhado por vários stakeholders?
– que impactos tem no projecto?
– como é que o minimizamos?
– o risco pode ser convertido numa oportunidade?

Basicamente o fundamental é o gestor de projecto não se deixar apanhar com “as calças na mão”, ou seja, não se deixe apanhar de surpresa de forma a saber exactamente como actuar e sempre de forma eficaz e eficiente.

Evitar o pânico, o stress, o levantamento de suspeitas, o apontar do dedo, culpabilizar um elemento da equipa são atitudes que o gestor de projecto deve ter. Acima de tudo deve-se transmitir a mensagem: “ok, aconteceu. não vamos lamentar ter acontecido mas sim pensar e agir de forma a ultrapassarmos o problema.”. Não vale a pena chorar por leite derramado e quanto mais depressa a equipa de projecto se focar no problema e na sua solução melhor.

O gestor de projecto nunca deve mostrar falta de confiança numa situação deste género, pois é nos piores momentos que a equipa de projecto e mesmo restantes stakeholders necessitam do nosso apoio e optimismo.

Até para a semana.

gestão das expectativas

Desde o primeiro dia do projecto até ao último, o gestor de projecto tem sempre de lidar com as expectativas de quem o rodeiam.

E existem 2 principais tipos de expectativas:

– dentro da equipa: gerindo as expectativas dos elementos da equipa garantindo que o trabalho desta é reconhecido e que o projecto vai ao encontro dela. A motivação também pode ser uma ferramenta poderosa na gestão das expectativas “criando” inclusivamente uma equipa de alto rendimento.

– fora da equipa: trabalhando os desejos e vontades dos sponsors e utilizadores finais de forma a garantir que o produto final vai exactamente ao encontro das suas expectativas e num cenário ideal até as superar.

A gestão das expectativas torna-se fácil ou difícil consoante o poder de argumentação, credibilidade e “senioridade”/experiência do gestor de projecto. Serve essencialmente para manter uma sintonia entre as características do produto final e o idealizado pelos clientes finais e sponsors do projecto, tornando-se assim das tarefas mais fulcrais para a boa aceitação do projecto e evitando assim a resistência à mudança.

Sem uma gestão correcta de expectativas é perfeitamente normal que os utilizadores finais e os sponsors estejam à espera de um ferrari quando na realidade apenas temos um fiat para lhes entregar. Com as expectativas bem controladas temos a certeza que o projecto não irá defraudar as expectativas de quem tanto anseia o seu fim de forma a tirar partido do seu investimento e partir em busca do retorno do investimento (ROI – Return of Investement).

E como se faz esta gestão das expectativas? Através da comunicação e da sinceridade. Não adianta de nada omitir factos que depois irão ser “descobertos” no final do projecto. O cliente não ficará satisfeito e a reputação da equipa não sairá intacta. Por isso é que nunca se deve omitir factos que irão saltar à vista dos utilizadores finais e dos sponsors, evitando o popular “gato escondido com o rabo de fora”. Os sponsors irão ter muito menos compreensão em terem as suas expectativas defraudadas no final do projecto do que se tivessem sido alertados durante o seu ciclo de vida.

Esta tarefa (gestão das expectativas) é uma das minhas tarefas preferidas na medida em que temos de usar toda a nossa capacidade de comunicação e persuasão para “levarmos” a água ao nosso moinho. Basicamente é ter a certeza que os sponsors e a equipa de projecto se encontram a meio do caminho das características de um projecto e não sejam irredutíveis nas suas posições.

Com esta tarefa bem sucedida é meio caminho andado para termos um final feliz num projecto por muitos percalços que enfrentemos.

Até para a semana.

gestão da comunicação

A comunicação é dos bens mais preciosos na vida.

O poder de comunicar é uma das maiores armas que temos na nossa sociedade.

E tal como na sociedade, num projecto a comunicação é de extrema importância.

À primeira vista até podem achar que é algo pouco pertinente, mas não podiam estar mais longe da verdade. A comunicação é o que permite o gestor de projecto gerir todos os stakeholders e garantir um bom “clima” dentro do projecto.

A comunicação permite gerir as expectativas do sponsor, dos stakeholders e dos utilizadores finais. Permite também gerir a motivação do líder técnico e por conseguinte dos programadores. Facilita a tolerância à falha e cria um sentimento de compreensão perante imprevistos.

Ao comunicarmos de forma atempada e assertiva conseguimos garantir o “bom humor” de todas as partes envolvidas no projecto fazendo com que todas as partes se sintam envolvidas e “importantes”, pois de facto são.

Mas tanto a comunicação atempada e assertiva é um trunfo para qualquer gestor de projecto como a comunicação desajeitada e fora de tempo é um penalti decisivo falhado.

O gestor de projecto deve usar a comunicação sempre a favor do projecto e nunca permitir que a comunicação se torna numa faca de 2 gumes, pois muito facilmente conseguimos comprometer um projecto à conta da comunicação.

A comunicação, tal como já foi dito, é o veículo para a gestão das expectativas e da motivação dos elementos do projecto.

Uma dica do PMBoK é o gestor de projecto ter claramente identificados os stakeholders de um projecto, os seus contactos e a forma preferencial de contacto de cada elemento. Só por isto podem ver como o PMBoK assume que a comunicação é algo bastante delicado num projecto e que requer prudência durante a sua utilização.

Espero que não fiquem com medo de comunicar, pois pior do que comunicar mal é a ausência de comunicação. Isso sim é a morte do artista, ou neste caso, do projecto. A ausência de comunicação permite e alimenta a especulação e cria enorme resistência dentro do projecto. Fragiliza a posição do gestor do projecto e destrói a confiança que tanto a equipa de projecto como restantes stakeholders depositam nele.

Por isso já sabem. A palavra de ordem é comunicar, comunicar e comunicar. Mas de forma correcta, atempada e acima de tudo assertiva.

Para a semana espero falar-vos da gestão das expectativas. Uma das minhas tarefas preferidas.

Até para a semana.

gestão da mudança

Durante um projecto é praticamente inevitável a mudança.

E mudança de quê?

Das mais variadas coisas:
– dos requisitos;
– da equipa de projecto:
– da tecnologia;
– dos stakeholders;
– do sponsor;
– do tempo, custo e/ou qualidade
– do âmbito;
– entre outros;
– importância do projecto;
– entre outras.

A mudança é uma realidade num projecto. Quem é que nunca perdeu um recurso durante o decorrer de um projecto? Ou assistiu à mudança de um stakeholder? Ou assistiu a alterações do triângulo custo, tempo e qualidade?

A verdade é que a mudança está sempre a ocorrer, umas vezes com maior impacto do que outras. E infelizmente como as pessoas têm uma grande resistência à mudança, a tarefa de gerir essa mesma mudança não é propriamente fácil.

A mudança pode ter várias origens:
– a equipa de projecto;
– factores externos;
– sponsor;
– restantes stakeholders;
– gestor de projecto.

Qualquer pessoa ou circunstância ligada directa ou indirectamente ao projecto pode ser originadora de uma mudança.

O papel do gestor de projecto na gestão da mudança é fulcral. Cabe-lhe a ele manter sempre a calma, ser receptivo e acima de tudo encarar sempre de forma positiva e transmiti-lo a todos os stakeholders. Basicamente é o chamado “Always look on the bright side of life!”. O dever do gestor de projecto não é evitar a mudança, mas sim fazer com que tenha o menor impacto possível no projecto e que seja encarada de forma positiva por todos os stakeholders. Desta forma a mudança será um aspecto positivo do projecto e não um aspecto negativo. Tudo depende como esta (a mudança) é introduzida no projecto.

Se o gestor de projecto fizer um drama de uma mudança, a equipa de projecto não a irá aceitar bem, os stakeholders irão torcer o nariz e pode-se transformar uma bela relação num autêntico pesadelo.

E a partir deste momento, se as pessoas começam a ficar resistentes à mudança todo o resto do projecto sairá prejudicado e terão de se redobrar esforços na comunicação.

Já que estamos a falar de comunicação, poderemos abordar este tema no próximo post.

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.