Risco do projeto é um evento com uma probabilidade de ocorrer no futuro impactando o projeto de forma negativa (ameaça) ou positiva (oportunidade).
Ele pode ocorrer devido a uma ou mais causas e pode ocasionar um ou mais impactos positivos ou negativos.
Importante ressaltar, que os riscos estão relacionados com as demais áreas de conhecimento e devem ser tratados de forma integrada considerando as melhores práticas de cada área de conhecimento.
Os riscos podem ser:
- Conhecidos: Foram identificados, analisados e considerados no planejamento do projeto, ou;
- Desconhecidos: Nesse caso quando evento ocorre, temos um problema ou questão para o projeto (Issues) e devem ser tratados agilmente.
- O GP deve tomar as devidas ações corretivas, identificar as causas, e tomar ações preventivas para que o problema não ocorra novamente.
- E ainda, deve documentar todas as decisões tomadas, notificar os responsáveis e garantir seu comprometimento na resolução do mesmo.
Segundo o Guia PMBOK®, o gerenciamento dos riscos do projeto inclui os processos de planejamento, identificação, análise, planejamento de respostas, monitoramento e controle de riscos de um projeto. Seu objetivo é maximizar a exposição aos eventos positivos e minimizar a exposição aos eventos negativos.
Os processos de gerenciamento de riscos em um projeto são:
- Planejar o gerenciamento dos riscos: definir como conduzir as atividades de gerenciamento de riscos para o projeto.
- Identificar os riscos: determinar quais riscos podem afetar o projeto e documentar suas características.
- Realizar a análise qualitativa dos riscos: Avaliar a exposição ao risco para priorizar os riscos que serão objeto de análise ou ação adicional.
- Realizar a análise quantitativa dos riscos: Efetuar a análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto.
- Planejar as respostas aos riscos: Desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.
- Controlar os riscos: Monitorar e controlar os riscos durante o ciclo de vida do projeto.
Quando o risco é considerado no contexto da Engenharia de Software, três fundamentações conceituais estão sempre em evidência:
- O futuro é nossa preocupação: que riscos podem causar o insucesso do projeto de software?
- A mudança é nossa preocupação: Como as mudanças de requisitos do cliente, afetam a pontualidade e o sucesso geral?
- Devemos cuidar das escolhas: Que métodos e ferramentas devemos usar, quantas pessoas devem ser envolvidas, quanta ênfase em qualidade é suficiente?
Para a estimativa de riscos, podemos criar uma planilha que deve ser preenchida com as seguintes colunas, indicando a análise o a resposta ao risco a ser avaliado:
- Prioridade: a prioridade de atendimento do risco encontrado
- Risco: a descrição do risco a ser avaliado
- Gravidade: o nível de gravidade do risco (Alto, Médio, Baixo ou Zero)
- Probabilidade de ocorrência: podem ser classificados como Alto, Médio, Baixo ou Zero.
- Impacto previsto: os efeitos e conseqüências gerados pela ocorrência do risco.
- Contramedidas previstas: as ações para evitar que o risco ocorra.
Para esta avaliação e controle, podemos usar a lista abaixo dos riscos mais comuns em qualquer projeto de software:
| ÁREA | FATOR DE RISCO |
| TECNOLOGIA | Hardware com performance incompatível com a aplicação criada |
| TECNOLOGIA | Mudança de plataforma ou linguagem, durante o projeto |
| PESSOAL | Falta de motivação da equipe |
| PESSOAL | Rotatividade de pessoal |
| MÉTODOS | Falta de adoção de modelagens visuais para o projeto |
| MÉTODOS | Falta de adoção de metodologias de desenvolvimento |
| PADRÕES | Falta de adoção de normas ou modelos de qualidade |
| MÉTODOS | Falta de adoção de metodologia de gestão de projetos |
| FERRAMENTAS | Não utilização de ferramentas de controle de requisitos |
| FERRAMENTAS | Não utilização de ferramentas de controle de configurações |
| FERRAMENTAS | Não utilização de ferramentas para gestão de projetos |
| REQUISITOS | Requisitos mal definidos, incompletos ou mal entendidos |
| REQUISITOS | Mudanças contínuas nos requisitos |
| PESSOAL | Falta de envolvimento dos usuários ou resistência a mudanças |
| ESTIMATIVA | Tempo de desenvolvimento do projeto mal estimado |
| ESTIMATIVA | Custos do desenvolvimento do projeto mal estimados |
| ORGANIZACIONAL | Falta de recursos financeiros para continuar o projeto |
| ORGANIZACIONAL | Expectativas pouco realistas do cliente quanto ao projeto |
| MÉTODOS | Planejamento inadequado ou insuficiente do projeto |
| TECNOLOGIA | Desconhecimento de tecnologias necessárias para o projeto |
| REQUISITOS | Mudanças contínuas dos objetivos e escopo do projeto |
| MÉTODOS | Não utilização de métricas no projeto |
| PESSOAL | Baixa produtividade nos envolvidos no projeto |
| PESSOAL | Problemas ou atritos que ocorrem entre clientes e contratados |
| MÉTODOS | Ausência de plano de testes no projeto |
| ORGANIZACIONAL | Omissão de informações importantes durante o projeto |
| FERRAMENTAS | Não adoção de ferramentas de produtividade na codificação |
| MÉTODOS | Não adoção de reuso de código e interfaces |
| MÉTODOS | Documentação do projeto ausente ou incompleta |
| MÉTODOS | Falta de históricos de projetos anteriores |
| PESSOAL | Funcionários sem treinamentos em tecnologias de ponta |
| ORGANIZACIONAL | Ambiente organizacional instável onde se realiza o projeto |
| MÉTODOS | Não utilização da técnica de prototipação no projeto |
| QUALIDADE | Insatisfação do cliente para com o software desenvolvido |
| PESSOAL | Quantidade de pessoal inadequada para o porte do projeto |
| LEGAIS | Contrato de prestação de serviços falho ou incompleto |