Introdução

"A aptidão é tudo." - 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, se possível, diminuídos (caso sejam ameaças), ou maximizados (caso sejam oportunidades), ou para que sejam controlados quando houver poucas estratégias para o seu enfrentamento.

O risco controla os planos de iteração; as iterações são planejadas considerando riscos específicos na tentativa de agir sobre os riscos. A lista de riscos é revista periodicamente para avaliar a eficácia das estratégias de resposta a 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 riscos é não esperar até que haja risco (e torne-se um problema ou defeito) 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 Risco

Para os riscos negativos, ou ameaças, há três estratégias principais:

• Evitação de risco: Reorganizar o projeto de modo que não seja afetado por um risco.
• Transferência de risco: Reorganizar o projeto de modo que alguém ou algo assuma o risco (o cliente, o fornecedor, o banco, um outro elemento etc.).
• Aceitação de risco: Decidir conviver com o risco como uma contingência. Monitore o sintoma do risco e escolha um plano de contingência que o oriente sobre o procedimento a ser tomado em caso de risco.

No caso dos riscos positivos, ou oportunidades, as opções de estratégias são as seguintes:

• Exploração de risco: eliminar a incerteza associada a um risco positivo, fazendo com que a oportunidade efetivamente aconteça.
• Compartilhamento de risco: atribuir parte da propriedade do risco a terceiros que possam capturar melhor a oportunidade em benefício do projeto.
• Melhoramento do risco: aumentar a exposição ao risco positivo, através do aumento da probabilidade e/ou do impacto caso ocorra. Isso se dá pela identificação e maximização dos acionadores dos riscos de impacto positivo.

Tipos de Riscos

É importante fazer 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: como não é possível alterá-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: 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 de Recursos

Organização

• Há um compromisso suficiente neste projeto (incluindo gerenciamento, testadores, QA e outras partes externas, porém envolvidas)?
• Este é o maior projeto desta organização?
• Existe algum processo bem definido para a engenharia de software? Há captura e gerenciamento de requisitos?

Fundos

• Os fundos estão disponíveis para a conclusão do projeto?
• Os fundos foram alocados para treinamento e acompanhamento de mentores?
• Existe alguma limitação em termos de orçamento, por exemplo, existe algum custo fixo estipulado para o sistema ou o sistema está sujeito a cancelamento?
• As estimativas de custo são precisas?

Pessoas

• Há pessoal suficiente disponível?
• Eles possuem capacidades e experiência apropriadas?
• Eles já trabalharam juntos antes?
• Eles acreditam no sucesso do projeto?
• Há representantes dos usuários disponíveis para as revisões?
• Há especialistas de domínio disponíveis?

Tempo

• A programação é realista?
• A funcionalidade pode ser gerenciada pelo escopo para cumprir as programações?
• Quando é a data de liberação?
• Há tempo para "fazer isso corretamente"?

Riscos do Negócio

• 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 assegurar 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

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 Tecnológicos

• A tecnologia foi aprovada?
• Os objetivos de reutilização são razoáveis?
  • Um produto de trabalho deve ser utilizado uma vez antes de poder 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 aqueles fora da corporação?  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.

Riscos 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 Planejamento

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 liberação maciça na tentativa de cumprir a programação.

Alguns projetos têm prazos finais realmente "inalteráveis". O software para analisar "ao vivo" o resultado de uma eleição durante a noite, por exemplo, terá pouco valor se for lançado na semana seguinte à eleição. Ou o software pode tornar-se obsoleto em relação aos dos concorrentes: eles lançam um produto melhor que o seu, enquanto você ainda está no meio da construção. 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 planejamento do mesmo modo que a estratégia de recuo, ou seja, baseá-las nos planos de contingência, porém isso é 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.

Técnicas mais 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].