Lista de Riscos
É uma lista de riscos conhecidos para o projeto, classificada em ordem decrescente de importância, associada a ações específicas de diminuição ou de contingência.
Tópicos

Introdução Início da página

"É fundamental estar sempre alerta." - Hamlet V:ii:215

Um projeto, como a vida, é incerto. Os riscos não são simplesmente identificados; eles devem ser identificados para que sejam previstos e diminuídos, se possível, ou para que sejam controlados quando houver poucas estratégias para a sua diminuição.

O risco controla os planos de iteração; as iterações são planejadas considerando riscos específicos na tentativa de limitar o risco ou reduzi-lo. A lista de riscos é revista periodicamente para avaliar a eficácia das estratégias de diminuição de riscos e, conseqüentemente, orientar as revisões no plano de projeto e nos planos de iteração subseqüentes.

O segredo do gerenciamento de risco é não esperar até que haja risco (e isso passe a ser um problema ou uma falha) para decidir o que fazer em relação a ele. Uma mudança de alguns graus no percurso de um vôo transcontinental produz um efeito significativo no local de aterrissagem do avião; de modo semelhante, gerenciar o risco antecipadamente é quase sempre menos dispendioso e penoso do que tentar solucioná-lo depois que virar um fato.

Estratégias de Gerenciamento de Riscos Início da página

Há três estratégias principais [BOE91]:

  • Prevenção de riscos. Reorganize o projeto para que ele não possa ser afetado por um risco.
  • Transferência de risco. Reorganize o projeto para que alguém ou algo assumir o risco (o cliente, o fornecedor, o banco, um outro elemento etc.). Esta é uma estratégia específica de prevenção de riscos.
  • Aceitação do risco. Aceite conviver com o risco como uma contingência. Monitore os sintomas de risco e escolha um plano de contingência que o oriente sobre o procedimento a ser tomado em caso de risco.

    Se decidir aceitar o risco, pode ser que você ainda deseje diminuí-lo, ou seja, tomar alguma ação imediata para reduzir seu impacto.

Tipos de RiscosInício da página

É importante fazer a distinção entre riscos diretos e indiretos. Em poucas palavras, um risco direto é aquele que permite um certo grau de controle e o indireto é o que não pode ser controlado.

Embora não se possa ignorar os riscos indiretos, sua conseqüência é pequena no sentido prático: já que não é possível modificá-los, não perca tempo se preocupando com eles. O mundo pode acabar amanhã, mas também pode não acabar. Então, se não acabar, é melhor que o trabalho não pare.

Algumas vezes, um risco indireto pode realmente ser um risco direto disfarçado. Por exemplo, a dependência de um fornecedor externo em relação a um ou mais componentes. Isso parece ser um risco indireto, mas se forem desenvolvidos planos de contingência para esses componentes, será possível controlar o risco. Por exemplo, outros fornecedores alternativos podem ser escolhidos, ou a funcionalidade pode ser desenvolvida por conta própria. Em vários casos, temos mais controle do que imaginamos.

No caso dos riscos indiretos, você deve tentar obter algum tipo de controle sobre eles ou simplesmente reconhecê-los e continuar o trabalho. Não adianta se preocupar com uma situação que você não pode mudar.

Riscos dos Recursos Início da página

Organização
Fundos
Pessoal
Tempo

Riscos do NegócioInício da página

  • E se um concorrente conseguir obter primeiro a liderança no mercado?
  • E se os fundos para o projeto estiverem comprometidos (uma outra forma de fazer esta pergunta é: "o que pode garantir fundos adequados")?
  • O valor projetado para o sistema é maior que o custo projetado? (não se esqueça de considerar o valor temporal do dinheiro e o custo de capital).
  • E se não puderem ser feitos contratos com os principais fornecedores?

Riscos Técnicos Início da página

Riscos de escopo
  • É possível medir o sucesso?
  • Existe algum consenso sobre como medir o sucesso?
  • Os requisitos são relativamente estáveis e foram bem compreendidos?
  • O escopo do projeto é estável ou continua sendo expandido?
  • As escalas de tempo de desenvolvimento do projeto são curtas e inflexíveis?
Riscos de tecnologia
  • A tecnologia foi aprovada?
  • Os objetivos de reutilização são razoáveis?
    • O artefato deve ser usado uma vez antes de ser reutilizado.
    • É possível que, somente após vários releases, um componente esteja estável o suficiente para ser reutilizado sem causar mudanças significativas.
  • Os volumes de transações nos requisitos são razoáveis?
  • As estimativas de taxa de transação merecem crédito? Elas são muito otimistas?
  • Os volumes de dados são razoáveis? Os dados podem ser mantidos nos mainframes atualmente disponíveis ou, se os requisitos levarem a crer que uma estação de trabalho ou um sistema departamental fará parte do design, os dados podem ser mantidos nesse local de forma razoável?
  • Há requisitos técnicos diferentes ou desafiadores que exijam que a equipe de projeto resolva problemas com os quais não está familiarizada?
  • O sucesso depende de produtos, serviços ou tecnologias novas ou não experimentadas, ou de hardware, software ou técnicas novas ou não aprovadas?
  • Existem dependências externas das interfaces com outros sistemas, inclusive com os localizados fora da empresa?  As interfaces necessárias existem ou devem ser criadas?
  • Há requisitos de disponibilidade e segurança extremamente inflexíveis (por exemplo, "o sistema nunca deve falhar")?
  • Os usuários do sistema são inexperientes em relação ao tipo de sistema que está sendo desenvolvido?
  • Há um risco crescente devido ao tamanho ou à complexidade do aplicativo ou à inovação da tecnologia?
  • Existe algum requisito para suporte ao idioma nacional?
  • É possível projetar, implementar e executar este sistema? Alguns sistemas são muito grandes ou complexos para funcionarem apropriadamente.
Risco de dependência externa
  • O projeto depende de outros projetos de desenvolvimento (paralelos)?
  • O sucesso depende dos produtos prontos ou dos componentes desenvolvidos externamente?
  • O sucesso depende da integração bem-sucedida das ferramentas de desenvolvimento (ferramentas de design, compiladores etc.), das tecnologias de implementação (sistemas operacionais, bancos de dados, mecanismos de comunicação entre processos etc.). Há algum plano de backup para liberar o projeto sem essas tecnologias?

Riscos de Programação Início da página

A experiência mostra que 85% dos riscos causam um impacto direto ou indireto na programação e, portanto, causam implicitamente um impacto no custo. É possível que 5% causem apenas um impacto no custo. O restante não causa impacto direto no custo nem na programação, mas, na qualidade, por exemplo.

Se o prazo de entrega for considerado um empecilho, faça liberações gradativamente. Evite fazer uma libreação maciça na tentativa de cumprir a programação.

Alguns projetos apresentam prazos realmente "inalteráveis". Um software usado para analisar "ao vivo" o resultado de uma eleição durante uma noite de eleição, por exemplo, terá pouco valor se for lançado na semana seguinte à eleição. O seu software também pode ser engolido pelos concorrentes: eles lançam um produto melhor que o seu enquanto você ainda está no meio da construção do produto. De repente, você não está mais no jogo e não pode fazer quase nada em relação a isso. Entretanto, normalmente poucos projetos têm um prazo de entrega tão crítico. Os atrasos na maioria das vezes afetam o custo.

Em geral, faça com que o compromisso com a programação seja igual à melhor estimativa e considere alguma contingência razoável.

compromisso = estimativa + contingência

Algumas pessoas sugerem definir as expectativas de programação do mesmo modo que a estratégia de recuo, ou seja, baseá-las nos planos de contingência, porém isso é um pouco pessimista demais, pois nem todos os riscos irão realmente se concretizar.

Os riscos de programação são integrados a algumas ferramentas de estimativa e custo. Por exemplo, no modelo COCOMO (Constructive Cost Model), vários geradores de custo, como:

  • complexidade (cplx)
  • restrições de tempo real (time)
  • restrições de armazenamento (stor)
  • experiência (Vexp)
  • disponibilidade de ferramentas apropriadas (tool)
  • pressão de programação (sced)

são fatores de risco reais.

Várias técnicas sofisticadas para o gerenciamento de riscos envolvem o uso da simulação de Monte Carlo, em que um número enorme de "cenários" são executados por uma ferramenta de simulação para calcular todos os riscos e contingências [KAR96].

Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process