Diretrizes:
|
 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. |
"É 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.
Há três estratégias principais [BOE91]:
Se decidir aceitar o risco, pode ser que você ainda deseje diminuí-lo, ou seja, tomar alguma ação imediata para reduzir seu impacto.
É 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.
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:
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].
|
Rational Unified Process
|
