Para iniciar a lista de riscos (na fase de iniciação):

Reúna a equipe do projeto (que, nesta etapa, deverá ser bem pequena; se ela tiver mais de cinco ou sete integrantes, limite o processo de avaliação de riscos aos líderes de atividade).

Quando identificamos riscos negativos, consideramos 'o que pode dar errado'. É claro que, em termos gerais, tudo pode dar errado. A questão é não atribuir uma visão pessimista ao projeto. No entanto, queremos identificar possíveis barreiras ao seu êxito, para que possamos reduzi-las ou eliminá-las. Analogamente, procuraremos também riscos positivos, significando possíveis facilitadores ao sucesso do projeto, de modo a explorá-los ou melhorá-los. Para obter informações adicionais, consulte Diretriz do Produto de Trabalho: Lista de Riscos.

Mais especificamente, estamos procurando os eventos que podem alterar a probabilidade de liberarmos o projeto com as características corretas, com o nível de qualidade exigido, no prazo estabelecido e dentro do orçamento.

Usando técnicas de brainstorming, peça a cada membro para identificar um risco do projeto. Perguntas de esclarecimento são permitidas, mas os riscos não deverão ser avaliados nem comentados pelo grupo. Pergunte a todos no grupo até identificar o número máximo de riscos.

Envolva todas as partes no processo e não se preocupe muito com a forma ou repetições; você poderá limpar a lista posteriormente. Use grupos de pessoas homogêneos (clientes, usuários, equipe técnica e assim por diante). Isso facilita o processo de coleta de riscos; os indivíduos ficam menos inibidos na frente de seus pares (em especialidade e hierarquia) do que em um grupo maior heterogêneo.

Use também a lista conciliada de proposições de valor (obtida na atividade Desenvolver a Visão) para extrair funções de utilidade que os interessados atribuem a funcionalidades e outros aspectos do desenvolvimento. Riscos (positivos e negativos) em potencial podem aparecer dessa análise.

Deixe claro aos participantes que apontar um risco não é o mesmo que se oferecer para resolvê-lo. Se as pessoas acharem que apontar um risco resultará na responsabilidade pela sua resolução, elas não identificarão nenhum risco (ou os riscos que apontarem serão triviais).

Para dar o estímulo inicial, comece pelas listas de riscos genéricas, como Assessment and Control of Software Risks de Capers Jones [JON94] ou the Taxonomy-Based Risk Identification estabelecida pelo Instituto de Engenharia de Software [CAR93]. Circule a lista de riscos: consultar o que já foi identificado freqüentemente ajuda as pessoas a identificarem outras coisas.

Para atualizar a lista de riscos (em fases posteriores):

Você pode solicitar informações conforme identificado anteriormente. No entanto, com base no exemplo da lista existente, novos riscos costumam ser identificados pelos membros da equipe e capturados na Avaliação de Status regular do projeto. Consulte Tarefa: Iteração de Avaliação.

Quando mais nenhum risco for encontrado, observe a lista de riscos como um grupo para ver se existem agrupamentos naturais (ocorrências do mesmo risco) e agrupe riscos sempre que possível para eliminar repetições. Às vezes, os riscos identificados serão sintomas de algum risco mais básico; nesse caso, agrupe os riscos relacionados no risco mais básico.

As técnicas quantitativas de gerenciamento de riscos recomendam que os riscos sejam priorizados de acordo com a exposição total que eles representam para o projeto. Para determinar a exposição de cada risco, o grupo deverá estimar as seguintes informações:

Como um grupo, a exposição de cada risco deverá ser calculada através de consenso. Diferenças significativas de opinião deverão ser discutidas posteriormente para verificar se todos estão interpretando o risco da mesma forma. Normalmente essas informações são incluídas como colunas em uma Lista de Riscos tabular.

Faz parte da natureza humana se preocupar com os riscos de maior impacto. No entanto, se forem muito improváveis, eles realmente serão menos importantes do que riscos mais moderados que costumam ser ignorados. Considerando tanto a magnitude do risco como a probabilidade de sua ocorrência, essa abordagem ajuda os coordenadores de projeto a direcionar os esforços de gerenciamento de risco nas áreas que mais influenciarão a liberação do projeto.

Assim que a exposição a cada risco for determinada, você poderá classificar os riscos para diminuir a exposição para criar a Lista dos "10 Maiores" Riscos.

Como a estimativa da probabilidade e do custo é, em si, cara e arriscada, geralmente é útil estimar apenas o impacto dos dez a vinte maiores riscos. Os projetos menores podem considerar menos riscos, enquanto os projetos maiores apresentam um 'destino de risco' maior e, conseqüentemente, um número maior de riscos relevantes.

Além de classificar os riscos em ordem decrescente de exposição, convém também agrupá-los em categorias, com base na magnitude de seu impacto no projeto (magnitude do risco). Em geral, cinco categorias são suficientes:

1. Alta
2. Significativa
3. Moderada
4. Secundária
5. Baixa

Documente os riscos e circule-os entre os membros da equipe do projeto.

Embora nem sempre seja possível, às vezes você poderá se desviar de conjuntos inteiros de riscos. Em geral, os riscos são causados pelo escopo precário do sistema; se for possível reduzi-lo (com a eliminação de requisitos secundários), seções inteiras da lista de riscos sumirão com os requisitos removidos. Um desses riscos é o de não ter recursos suficientes (incluindo tempo) para realizar o trabalho.

Em outros casos, é possível adquirir tecnologia para reduzir o risco de criar determinada funcionalidade, uma forma de prevenção de riscos na qual um conjunto de riscos (o de criar a tecnologia) é trocado por outro (o de depender de forças fora do controle de uma pessoa).

Por fim, é possível transferir riscos para outras organizações.

Para os riscos diretos , ou seja,  os riscos sobre os quais o projeto tem algum grau de controle, identifique quais ações serão realizadas para reduzir a probabilidade de risco ou reduzir seu impacto no projeto (as estratégias de mitigação). Em geral, o próprio risco é proveniente da falta de informações; a estratégia de diminuição costuma investigar mais o tópico para reduzir a incerteza.

Existem riscos para os quais é possível executar uma ação, de modo que eles se materializem ou sejam afastados. Em um processo de desenvolvimento iterativo, aloque essas ações para as iterações iniciais a fim de diminuir o risco logo no início. Enfrente os riscos o mais rápido possível. Se um risco estiver no formato "X pode não funcionar como planejado?", então planeje tentar X o mais breve possível.

Exemplos:

• Para reduzir o risco de os produtos X e Y não serem integrados, um protótipo será criado para investigar a dificuldade da integração. As características a seguir (enumere-as em uma lista) serão testadas para assegurar o êxito da integração.
• Para reduzir o risco de o Banco de Dados A não ser executado corretamente, o desempenho dele será avaliado através de um conjunto de testes que modela a carga de trabalho do aplicativo-alvo.
• Para reduzir o risco de a ferramenta de teste Z não efetuar o teste de regressão no aplicativo com eficácia, ela será adquirida e usada na próxima iteração.

O resultado dessas ações deverá ser a redução (ou talvez a eliminação) da probabilidade de ocorrência de determinados riscos. Nos casos em que o risco estiver confirmado, ele será respondido com um plano de contingência (Consulte Identificar Estratégias de Contingência).

Pode ser interessante para o seu projeto que riscos com impactos positivos sejam concretizados. A exploração de riscos visa, portanto, eliminar a incerteza associada aos riscos.

No seu projeto de desenvolvimento, os riscos positivos podem ser oportunidades de aumentar a produtividade, de diminuir seus custos ou aumentar a qualidade do produto final. Várias ações nesse sentido podem ser tomadas:

• Formar a equipe designando recursos mais capacitados para as tecnologias utilizadas, os padrões de arquitetura empregados ou o domínio do problema a ser tratado.
• Optar por aquisição de componentes COTS (commercial off-the-shelf), visando diminuir o tempo de desenvolvimento.
• Investir em novas ferramentas de desenvolvimento para aumento de produtividade.

Para cada risco, independentemente de você ter ou não um plano para diminuí-lo ativamente, decida quais ações deverão ser executadas em determinado momento ou se o risco se materializar , ou seja, se ele se tornar um problema, um 'sinistro' no jargão de seguros. Isso é geralmente chamado de "um plan 'B'" ou plano de contingência. Um plano de contingência é necessário quando houve falhas na prevenção e na transferência de riscos, a diminuição de riscos não obteve o êxito esperado e agora é necessário enfrentar o risco. Esse costuma ser o caso de riscos indiretos , ou seja, os riscos sobre os quais o projeto não tem controle ou quando as estratégias de diminuição são caras demais para serem implementadas.

O plano de contingência deverá considerar:

Identificar Indicadores de Risco

É possível monitorar alguns riscos com o uso de métricas do projeto e a observação de tendências e limites; por exemplo:

• Retrabalho restante excessivo
• Quebra restante excessiva
• Gastos reais muito acima do planejado

É possível monitorar alguns riscos com base nos requisitos do projeto e resultados de testes; por exemplo:

• Tempos de resposta uma ordem de grandeza acima do exigido.

Alguns riscos estão associados a eventos específicos; por exemplo:

• Componente de software não liberado no prazo por um terceiro.

Há muitos outros indicadores "mais flexíveis", nenhum deles diagnosticará o problema completamente. Por exemplo, há sempre um risco de o ânimo diminuir (na verdade, em determinadas etapas do projeto, isso é quase (previsível). Há uma variedade de indicadores: reclamação, "humor negro", prazos finais perdidos, qualidade inferior e assim por diante. Nenhuma dessas "medidas" é um indicador preciso; as brincadeiras sobre a futilidade de um produto liberado específico podem ser uma forma saudável de aliviar o estresse, mas se continuar, pode ser uma indicação de que a equipe tenha uma sensação cada vez maior de fracasso iminente.

Fique atento a todos os indicadores sem julgá-los. É fácil rotular o portador de 'más notícias' como alguém que apresenta uma atitude incorreta; por trás do cinismo, há geralmente um fundo de verdade. Em geral, o 'portador de más notícias' está atuando como a 'consciência do projeto'. A maioria das pessoas deseja o êxito do projeto e fica frustrada quando o ânimo está levando o projeto na outra direção.

Identificar Ações de "Perda" ou "Plano B"

Nos casos simples, o plano de contingência enumera soluções alternativas. O impacto costuma ser custos e atrasos para se desfazer da solução atual e implementar a nova solução.

No caso de outros riscos "mais flexíveis" não costuma existir apenas uma ação a ser executada quando há uma perda, mas várias. Quando o ânimo diminui, por exemplo, é melhor reconhecer a condição e unir-se como um grupo para discutir as atitudes predominantes do projeto. Ouça as questões, identifique problemas e, em geral, deixe as pessoas extravasarem. No entanto, após determinado período de extravasamento, comece a abordar as causas de interesse. Use a lista de riscos como uma forma de focar a discussão. Transforme as questões em um plano de ação concreto, redefinindo a prioridade de riscos e reformulando os planos de iteração para resolver os principais riscos de forma sistemática. Ações positivas têm um efeito mais intenso do que palavras positivas (mas vazias).

Apesar do ânimo no momento, a ocorrência de perda tem um lado positivo: ela força a ação. Muitas vezes, o grupo poderá adiar riscos facilmente ignorando-os, levado à complacência pela calmaria aparente. Quando perdas ocorrem, é preciso agir. O risco deixa de ser um risco; não há mais nenhuma dúvida sobre a sua ocorrência.

Porém, uma ocorrência de perda também é uma falha para evitar ou diminuir riscos. Ela deverá forçar uma reavaliação da lista de riscos para determinar se a equipe do projeto pode ter algumas deficiências sistemáticas. Tão difícil quanto a auto-avaliação sincera, poderá evitar outros problemas posteriormente.

A avaliação de riscos é, na verdade, um processo contínuo, e não um processo que ocorre apenas em intervalos específicos durante o projeto. No mínimo, você deverá:

• Reavaliar a lista semanalmente para verificar as mudanças.
• Permitir que todo o projeto visualize os dez itens mais importantes e insistir que sejam tomadas providências sobre eles. Em geral, é possível anexar a lista de riscos atual aos relatórios de Avaliação de Status.

No final de uma iteração, restabeleça o foco nas metas da iteração com relação à lista de riscos. Especificamente:

• Elimine os riscos que foram diminuídos ao máximo.
• Apresente novos riscos descobertos recentemente.
• Reavalie a magnitude da lista de riscos e reorganize-a (consulte Analisar e Priorizar Riscos).

Não se preocupe muito se descobrir que a lista de riscos cresce durante as fases de iniciação e elaboração. À medida que desenvolvem o trabalho, os membros do projeto percebem que algo considerado trivial na verdade contém riscos. No início da integração, você poderá encontrar dificuldades que estavam ocultas. No entanto, os riscos deverão diminuir uniformemente à medida que o projeto chega ao fim da elaboração e durante a construção. Caso contrário, talvez você não esteja administrando os riscos apropriadamente ou o seu sistema seja muito complexo ou impossível de ser construído de forma sistemática e previsível. Para obter informações adicionais, consulte Diretriz do Produto de Trabalho: Lista de Riscos.