O que é um Risco?

Um risco é um evento ou condição incerto que, se ocorrer, causará um efeito negativo ou positivo em um ou mais objetivos do projeto. Os riscos do projeto podem ser vistos como ameaças ou oportunidades. As oportunidades significam que ter um risco calculado pode trazer, por exemplo, vantagens competitivas para um produto ou uma organização. Se houver benefícios associados a uma oportunidade, então você deve aceitar determinados graus de risco para que um projeto seja bem sucedido.

Na vida cotidiana um risco é uma exposição à perda ou dano: Um fator, coisa, elemento ou um caminho que envolve perigo incerto. Similarmente, no desenvolvimento de software um risco é algo que pode comprometer o sucesso de um projeto. Exemplos de fontes potenciais de risco no desenvolvimento de software estão relacionados abaixo:

Requisitos
Design
Processo de Desenvolvimento
Ambiente de Trabalho
Recursos
Contrato
Interdependências do Projeto
Etc.

Atributos do Risco

Você pode registrar quantas informações quiser ou necessitar a respeito de seus riscos. Veja abaixo uma lista com os atributos de risco mais comuns.

Descrição do Risco: Uma descrição do risco que detalha o impacto para o projeto se este risco se tornar um problema (isto é, se ele se tornar uma realidade).
Categoria do Risco: A identificação do risco é normalmente mais fácil de fazer quando existe um "framework mental" para assegurar que áreas potenciais de risco não sejam esquecidas. Uma forma de fazer isso é dividir o risco em categorias (tais como técnica, gestão de projeto, organizacional e externa), para assegurar que todos os aspectos do projeto suscetíveis ao risco estejam cobertos.
Tipo do Risco: usado para classificar o risco como:
- Risco direto: um risco que o projeto tem um grande grau de controle.
- Risco indireto: um risco com quase nenhum controle pelo projeto.
Probabilidade do Risco: Qual a probabilidade do evento de rico acontecer. Normalmente este atributo é representado com uma escala dos valores (por exemplo: Elevado, Médio, Baixo). A probabilidade é um dos indicadores mais difíceis de classificar com precisão.
Impacto do Risco (nível de): se este risco se transformar em um problema, qual será o impacto no projeto? Esta não é a descrição real do impacto, mas o nível do impacto. Tal como a probabilidade do risco, ele é normalmente representado com uma escala. Este atributo é chamado também de severidade do risco.
Magnitude do Risco: Para tornar possível a classificação e a definição de quais riscos precisam ser atenuados primeiro, os atributos de Probabilidade do Risco e Impacto do Risco são normalmente combinados em um único indicador de Magnitude do Risco representado com uma escala similar à combinação dos atributos.

Estratégias de Resposta ao Risco

A resposta ao risco deve estar alinhada com a significância do risco. As estratégias para tratar os riscos cobrem dois principais tipos: riscos negativos e riscos positivos (ou oportunidades). As estratégias mais comuns para resposta aos riscos negativos ou ameaças, são:

Fuga: Reorganize o projeto de modo que não possa ser afetado pelo risco (ex. removendo trabalho).
Atenuação: Defina ações para reduzir a probabilidade ou o impacto do risco, removendo-o do topo da lista.
Transferência: Reorganize o projeto de modo que alguém ou algo se encarregue pelo risco. Isto simplesmente transfere a responsabilidade do gerenciamento do risco para outra parte. Isto não elimina o risco.

As estratégias mais comuns para resposta aos riscos positivos ou oportunidades, são:

Aproveitamento: Adicione trabalho ou reorganize o projeto para assegurar que a oportunidade ocorrerá (é o inverso da fuga)
Melhoria: Defina ações para aumentar a probabilidade ou o impacto positivo do risco, (é o inverso da atenuação).
Compartilhamento: Transfira a propriedade da oportunidade para terceiros que estejam mais capacitados a capturar a oportunidade para benefício do projeto.

Uma outra estratégia de resposta para as ameaças e as oportunidades é a Aceitação: Decida conviver com o risco, e defina um plano de contingência.

Alguns cenários para desenvolvimento de software podem ajudar a tornar estes conceitos mais claros.

Você necessita usar um novo framework. Uma estratégia de fuga do risco poderia ser não usar este framework novo e usar outro que fosse conhecido pela equipe.
A aplicação que você está desenvolvendo necessita se comunicar com um sistema legado. Uma estratégia de transferência de risco poderia ser: Tornar a equipe de manutenção do legado responsável por fornecer uma API para acessar o sistema legado.
Você necessita usar um novo middleware. Uma estratégia de atenuação do risco poderia ser a construção de um protótipo usando este middleware novo para validar se ele fornecerá as características que você necessita para sua aplicação.
Seu integrador é o único que sabe integrar os diferentes componentes de sua aplicação. Um plano de contingência poderia ser a identificação de um recurso em outro projeto que você utilizaria caso seu integrador ficasse doente, deixasse a empresa, etc.