Gerência de Riscos. Lidando com a desgraceira!

Tenho um conhecido que há alguns anos atrás mantinha dois carros populares. Ele dizia que “quem tem dois, tem um, quem tem um, não tem nenhum”.


Na Gerência de Projetos essa é uma maneira válida de gerenciar os riscos. É claro que tudo deve ser adaptado à natureza do projeto. E aqui cabe uma observação: quando se diz que o PMBoK é burocrático e de difícil aplicabilidade, manifesta-se aí um desconhecimento do assunto. O PMBoK, assim como a ITIL não é prescritivo, ou seja, tudo pode mas nada deve. O que se vê ali são sugestões de melhores práticas para a gestão de nossos projetos. Utilizamos os processos e áreas de conhecimento que mais necessitamos no projeto em questão. Projetos críticos, por exemplo, podem exigir uma gerência de riscos mais apurada, demandando a utilização de processos de riscos mais intensa. Quem sabe até em alguns momentos, duplicar os recursos de transporte, como fazia esse meu amigo.


Recentemente recebi a missão de dar suporte técnico a uma importante convenção de um grande cliente da empresa onde atuo. O cliente estava em fase final de avaliação de uma solução de BI, e na convenção esse software seria exibido como uma prova-conceito final da solução. Até aí tudo bem. Minha participação se resumiria em operar o sistema para o palestrante. Mas dada a infalibilidade da lei de Murphy, não custava nada aplicar uma rápida Gerência de Riscos até mesmo para exercitar essa área de conhecimento do PMBoK. Havia o agravante de o sistema ser totalmente nas nuvens, ou seja, totalmente dependente de conexão à internet, o que me motivou ainda mais.

Optei então por uma análise qualitativa, fiz um rápido plano de contingência e apresentei para o diretor da empresa.

Lembrando que ameaças são os riscos negativos, enquanto que os riscos positivos são oportunidades; e as estratégias de respostas aos riscos são: eliminar, mitigar, transferir ou aceitar.

As ameaças mais importantes detectadas foram as seguintes:

Ameaça	Tipo	Ação	Recurso necessário	Resultado
Falha no computador da apresentação	Risco técnico	Troca do computador	Outro computador	Ameaça eliminada
Falha na conexão de internet do hotel	Risco técnico	Utilização de conexão alternativa	Modem 3G	Ameaça eliminada
Falha no servidor	Risco técnico	Redirecionamento para outro servidor	Backup  dos dados em outro servidor	Ameaça eliminada
Falha no segundo servidor	Risco técnico	-	Material em pdf	Ameaça aceita

Quando relatei esses riscos ao diretor da empresa ele disse: “Mas essa desgraceira toda não vai acontecer não, né?”

Pois é, vamos aos fatos.

Primeiro risco: falha no computador da apresentação. Esse risco não era tão preocupante porque haveria uma profusão de notebooks na convenção e não seria complicado substituir um notebook na hora. Todos os palestrantes também estavam munidos de pen-drives que possibilitariam a circulação dos dados da apresentação. De qualquer forma eu também levaria o notebook da empresa (e meu velho mp3 que também uso para correr, que de vez em quando me envergonha, de feio, mas funciona! rsrs)

Segundo risco: falha na conexão do internet do hotel. Esse seria um risco de alto impacto para mim. A única solução seria obter uma conexão alternativa à internet. Dispus então, a levar meu modem 3G para o dia da convenção.

Terceiro risco: falha no servidor. O servidor (do cliente) que seria acessado durante minha apresentação poderia parar. Como o sistema é na web, não há possibilidade de instalação e acesso local. Por outro lado, como estamos em fase de avaliação, havia uma instalação alternativa no servidor da empresa onde trabalho. Eu poderia então na hora, acessar a outra instalação. Mas para isso os dados deveriam estar atualizados, o que geraria a necessidade de um backup e uma restauração na véspera.

Quarto risco: o segundo servidor poderia parar. Nesse caso optei por aceitar esse risco, e uma alternativa seria levar em formato pdf, os principais indicadores a serem apresentados na convenção.

Riscos transferidos: havia também uma sorte de riscos que optei por transferir. Por exemplo: o datashow poderia parar. Risco transferido para o hotel. Ausência de algum elemento de infra-estrutura: pontos de energia, som, etc. Todos riscos transferidos para o hotel.

Analisando a coluna de recursos necessários, eu precisaria então:

- notebook da empresa e pen-drive (mp3!);

- meu modem 3G;

- efetuar backup dos dados;

- restaurar backup dos dados;

- exportar indicadores para pdf.

O backup e a restauração deram um trabalho danado. Como não tenho acesso direto ao servidor do cliente, tive de solicitar que fizessem o backup, gravassem em um DVD e me enviassem por motoboy. Na restauração também houve problema: restaurar um banco de vários Gb pela rede se mostrou muito lento. Tive de pedir que fizessem a restauração, gerando dependência de terceiros. Isso tudo a dois dias da convenção.

Um dia antes foi marcado um ensaio geral. Na sexta-feira. A convenção seria no sábado durante o dia.

Dia do ensaio. De cara a internet do hotel não funcionou! O microfone de lapela não estava disponível! E só havia um ponto de conexão de internet por cabo no salão! Sem problema! Até aí tudo estava previsto.

Eis que o diretor da empresa cliente sugeriu a apresentação com base em dados do dia da apresentação, que seria o primeiro dia do mês, para já visualizarmos o faturamento fechado do mês! Muito natural. Natural mas eu não tinha pensado nisso!

Nota: o pessoal de banco de dados de refere a isso como (d-0) (lê-se: d menos zero). Se a base está com um dia de atraso é d-1, dois dias é d-2 e atualizada é d-0.

Ocorre que o BI estava trabalhando com d-1, atualizando todo dia 01:00 am. Logo, no sábado à 01:00 o BI seria atualizado. Mas o faturamento é feito depois da 01:00. Ou eu trocava o horário da atualização ou se antecipava o faturamento. Antecipou-se o faturamento.

No dia da apresentação o hotel disponibilizou uma conexão por cabo à internet. Uma e somente uma. Qualquer um que precisasse de outra conexão não teria. Eis que o palestrante motivacional precisou. Entrou em ação o modem 3G, funcionando redondinho.

O BI rodou redondo mostrando em tempo real que o faturamento no mês da empresa foi maior que o faturamento do mesmo mês do ano passado. Sentei para fazer a apresentação com a turma gritando: “Olha o pai do BI!”.

A Gerência de Riscos é uma área de conhecimento impressionantemente negligenciada. Gerência de Riscos é tão importante que o PMI possui a certificação PMI-RMP (Risk Management Professional) dedicada à aos riscos.

Grandes empresas estão tratando não somente os riscos, mas os desastres. Enquanto ainda há a cultura de que gerenciar riscos é fazer backup de seus dados.

Afinal, várias empresas do WTC possuíam backup na outra torre! Quantas empresas pararam nessa tragédia na serra de Petrópolis?

Um exemplo gritante, altamente comentado como ineficiência na Gerência de Riscos, foi o vazamento de petróleo da BP Deepwater Horizon, ocorrido em abril de 2010 no Golfo do México. Além de a explosão matar 11 trabalhadores, o vazamento só foi sanado em setembro custando U$11.2 bilhões de dólares. Nesses casos, é claro que um plano de contingências vale o investimento. Ao contrário da BP, a Exxon, outra empresa do mesmo ramo de negócios possui uma cultura de gerência de riscos e processos de segurança que faz com que em 20 anos tenha tido um incidente contra 3 incidentes em cinco anos da BP.

Um executivo da Exxon tem um pensamento pragmático a respeito: “deve-se atingir as pessoas no bolso, de outra forma, quando uma situação de risco ocorrer e houver considerações de orçamento e cronograma, elas irão escolher o atalho. Deve-se criar a cultura onde a tentação de correr riscos não seja compensatória.”