Diretrizes: Lista de Riscos
Tópicos
"A preparaçã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 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 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.
Há três estratégias principais [BOE91]:
- Anulação de risco. 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 de 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.
É 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.
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"?
- 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?
- É 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?
- 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
aqueles fora da corporação? As interfaces necessárias existem ou devem
ser criadas?
- Há requisitos de disponibilidade e de 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.
- 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?
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 apresentam 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
ser 'engolido' pelos 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].
| |
|