Riscos!? Que riscos?

Riscos é um assunto que deixa muitos incomodados, afinal muitas vezes, principalmente em projetos de software, ele é visto como algo negativo, um empecilho que pode ocorrer e diminuir as chances de sucesso do projeto.

E o perigo maior está quando não identificamos o risco, e o impacto dele pode comprometer todo o projeto. Fazendo uma analogia, seria como você descobrir que o botijão de gás está vazando ao ligar a lâmpada, ou seja, tarde demais… BOOMM!!!

Assustador não é?

Por isso, o gerenciamento de riscos é algo muito importante no seu projeto. A seguir, irei falar um pouco sobre ele, espero que gostem e que possa ser útil. 🙂

De onde vem os riscos?

no Futuro … que pode ser duvidoso e nos forçar a mudanças…
nas Mudanças … que podem ser inúmeras e nos forçam a decisões…
nas Decisões … que podem não ser as mais corretas…
  • Do futuro: que pode ser duvidoso e nos forçar a mudanças;
  • Das mudanças: que podem ser inúmeras e nos forçam a decisões;
  • Das decisões: que podem não ser as mais corretas.

Riscos em Engenharia de Software

  • Do futuro: do ambiente interno e externo, mercado, tecnologia, economia, governo , etc;
  • Das mudanças: do ambiente, dos requisitos dos clientes, em ambientes tecnológicos, equipamentos, política econômica e tecnológica, leis e programas de apoio a P&D, orçamentos., etc;
  • Das decisões: O que produzir? Com que métodos e ferramentas? Com que equipe? Com que nível de qualidade? Com qual orçamento? etc.

O processo de gerenciamento de riscos

Sendo o gerenciamento de riscos um conjunto de técnicas e ferramentas para identificar, estimar, avaliar, monitorar e administrar os acontecimentos que colocam em risco a execução do projeto. Podemos ilustrar o processo de gerenciamento de riscos, proposto pelo PMBOK, da seguinte maneira:

Processo de Gerenciamento de Riscos

  • Planejamento do gerenciamento de riscos – decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto;
  • Identificação de riscos – determinação dos riscos que podem afetar o projeto e documentação de suas características;
  • Análise qualitativa de riscos – priorização  dos riscos para análise ou  ação adicional subsequente  através de avaliação  e combinação de sua probabilidade de ocorrência e impacto;
  • Análise quantitativa de riscos – análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto;
  • Planejamento de respostas a riscos – desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto;
  • Monitoramento e controle de riscos – acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas  a riscos  e avaliação  da sua eficácia durante todo o ciclo de vida do projeto.

Ao meu entender, as quatro primeiras etapas compõem a análise de riscos, que é algo de extrema importância para qualquer projeto, independente da sua natureza.

E para o nosso mundo de desenvolvimento de software a análise de riscos é essencial, pois o nosso projeto está sempre rondado de riscos, e precisamos estar atentos a eles.

É importante lembrar que o objetivo do gerenciamento de riscos é aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto.

Tem como garantir que nenhum risco irá afetar o meu projeto?

Não. Infelizmente não tem como garantir que os riscos não irão causar impacto no seu projeto. Mas calma, nem tudo está perdido. Podemos utilizar três estratégias para lidar com os riscos e diminuir a probabilidade deles ocorrerem:

  1. Prevenir: como já diz aquele velho e bom ditado popular “prevenir é o melhor remédio”, e no gerenciamento dos riscos essa é a melhor ação que podemos executar. Muitas vezes precisamos realizar mudanças no plano do projeto para eliminar a ameaça que um risco pode apresentar. Podemos também isolar os objetivos do projeto do impacto que o risco pode oferecer ou ainda flexibilizar o objetivo que está sendo ameaçado pelo risco;
  2. Transferir: essa é uma ação que não elimina o risco, e sim passa o gerenciamento dele para um terceiro. Por exemplo: você irá terceirizar uma determinada parte do seu sistema para outra empresa. Um dos riscos que você terá é do atraso da entrega dessa parte do sistema, e para tentar compensar o impacto que esse risco poderá ter para a sua empresa, você pode colocar no contrato uma multa em caso de atraso;
  3. Mitigar: o foco da mitigação de riscos é a redução da probabilidade e/ou impacto de um risco até um limite aceitável. Um exemplo, seria a realização de TDD para diminuir a probabilidade e impacto do risco de falhas do sistema, já que aumentaria a qualidade do desenvolvimento do software.

O que pode acontecer se não houver uma análise dos riscos no meu projeto?

Como diria um professor meu: “coisas horríveis irão acontecer”.

Cena do filme Tropa de Elite

A análise de riscos é fundamental para o gerenciamento de riscos e um fator chave para o sucesso do seu projeto. É uma maneira de agir proativamente diante dos riscos e é muito melhor do que agir de forma reativa, pois talvez dependendo do risco que não foi tratado e do impacto ocasionado por ele, poderá ser muito tarde para tomarmos alguma providência.

A análise de riscos pode ter algum impacto para a minha área de testes?

Sim, e se bem realizada poderá ser um impacto muito benéfico para a equipe de testes. Pois será mais uma fonte de consulta na hora da elaboração dos testes e ainda poderá ajudar na priorização da execução dos testes. Por exemplo: na análise de riscos de uma manutenção do software está descrito quais áreas poderão ser afetadas pela manutenção, ou seja, novos bugs poderão ser introduzidos nessas áreas. Sendo assim poderemos focar os testes de regressão primeiro nas áreas que tem maior chance de ter sido impactada e desta maneira, podemos encontrar a falha mais cedo = menos $$$ gasto com o bug.

Além do mais, sabemos que garantir que 100% do sistema não tem falhas é algo muito difícil e na maioria das vezes não viável. Portanto com a análise de riscos podemos garantir por exemplo, que 90% das falhas do sistema foram encontradas e que os outros 10% possam ser falhas de baixo impacto no sistema. Já sem uma análise de riscos poderíamos talvez, garantir que 99% das falhas foram encontras, mas daí o 1% que faltou pode ser uma falha crítica. Aí já sabe neh…

Sendo tão importante, por que às vezes a análise de riscos não é realizada?

Pois muitos preferem ficar na segurança e conforto da ignorância. Sabe aquelas pessoas que falam, nem precisa testar está funcionando. Então, uma das razões para essa pessoa falar isso é que ela sabe que se você for testar irá achar um monte de falhas que irá dá mais trabalho para ela.

Com os riscos o cenário é parecido. Se você for fazer uma análise de riscos, com certeza irá encontrar muitos riscos e ainda terá várias outras “razões” para evitar a  análise de riscos:

  • Análise de Riscos “consome” tempo precioso dos membros da equipe do Projeto ;
  • Análise de Riscos demonstra “ Análise de Riscos demonstra problemas que “só atrapalham”;
  • Análise de Riscos tem tendência de “ Análise de Riscos tem tendência de trazer “más notícias”;
  • Análise de Riscos pode levar a “ Análise de Riscos pode levar a situações “embaraçosas”;
  • Análise de Riscos acelera a necessidade de levantar questões que, cedo ou tarde, deveriam ser percebidas pelo Cliente do Projeto.

Portanto, se você não quer ter nenhuma explosão no seu projeto, por favor, identifique, analise, administre e controle os seus riscos. Caso contrário, você um dia poderá ter uma surpresa desagradável ao chegar ao trabalho.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK); Terceira edição, 2004. Project Management Institute, Four Compus Boulevard, Newton Square, PA 19073-3299 EUA.

www.inf.ufsc.br/~cybis/ine5617/Analise_riscos.ppt (Walter de Abreu Cybis)

www.pmimg.org.br/…/GestaoRiscosProjetos_LucioDiniz_31082004. (Lúcio J. Diniz)


Anúncios

4 comentários sobre “Riscos!? Que riscos?

  1. Interessante,

    como mensurar/medir o percentual de tempo/grana destinado ao gerenciamento/minimização do fator risco em relação ao tempo/investimento em um determinado projeto de software?
    Este percentual é constante ou variável como a propria natureza dinamica das variaveis que compoem um projeto ou as que gravitam em torno deste?

    Por exemplo: Dados históricos mostram que são aplicados em manutenção preventiva industrial de 2 (aeroespacial) a 12% (trasnportes) do faturamento com o objetivo de eliminar ou minimizar o risco de paradas não programadas dos mesmos equipamentos.

    abs

    Responder
    • Olá trainsppotting!

      Não sei se entendi muito bem a sua primeira pergunta, mas tentarei responder pelo que entendi.

      O seu próprio exemplo, usando dados históricos, ilustra uma das maneiras de estimar o percentual de tempo/grana que será preciso para o gerenciamento do risco. Se você tiver uma base com tais dados na sua empresa, com certeza eles poderão oferecer informações para a estimativa desse percentual.

      Há outras maneiras de estimar esse percentual, como por exemplo: consultando especialistas e fazendo entrevistas com os envolvidos com o projeto, a fim de obter mais informações sobre os riscos.

      É importante também está sempre monitorando os riscos, pois com o andamento do projeto, talvez seja necessário reavaliar esse percentual.

      Considerando que cada projeto é único, acredito que o percentual seja variável, principalmente em projetos de TI, onde o ambiente é bastante dinâmico.

      O importante é está sempre atento, e caso seja notado algum risco não esperado, levantar a bandeira.

      Abraços! E obrigado pelo comentário. 😉

  2. Fala Fabrício, tudo beleza?

    Só para contribuir um pouco com o seu ótimo artigo, segue abaixo alguns comentários que agregam valor no processo de gerenciamento de risco (PMBOK)

    Abaixo temos seis etapas que devemos usar para mitigar os riscos:

    Contextualizar: determinar a categoria da data meta e a conseqüência, caso esta não seja alcançada;

    Identificar: identificar os riscos que devem ser gerenciados e que requerem prazo de preparação anterior a implantação. Enfatizar que se o evento de risco ocorrer, fará com que o projeto ultrapasse a data meta;

    Analisar os riscos: identificar os responsáveis pelos planos de contingência e aqueles que podem custeá-los;

    Tratar os riscos: determinar a data na qual a preparação deve ser iniciada e se os planos de contingência são economicamente viáveis;

    Monitorar e revisar os riscos: para riscos que não tenham sido priorizados, determinar se e quando a preparação de contingências deve ser iniciada;

    Comunicar e discutir: obter a autorização do interessado para iniciar a preparação.

    Todas as etapas acima devem ser negociadas e de conhecimento do time de desenvolvimento. O item considerado como um risco deve ser aprovado também pelo time de desenvolvimento.

    Ficam ao os meus two cents 😉

    Até+,
    Quezada

    Responder
    • Td certo Gustavo!

      Interessante notar que o time de desenvolvimento também deve se envolver, principalmente em se tratando de riscos técnicos. Afinal, se todos estiverem cientes dos riscos, poderemos tratá-los com maior eficiência.

      Thanks for your two cents! 🙂

      Abraços!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s