O Que é a Gestão dos Riscos de Software?

De acordo com Peter Kulik, os riscos são atrasos de agenda e derrapagens orçamentais à espera de acontecerem. À medida que as práticas foram melhorando, o reconhecimento da gestão dos riscos de software aumentou consideravelmente. Os resultados deste tipo de gestão de risco traduzem-se em maior produtividade, na melhoria dos resultados das organizações e numa satisfação mais consistente dos compromissos assumidos com os clientes.

 
A prática da gestão dos riscos de software (ou SRM - Software Risk Management) inclui tanto a perspectiva ascendente, como a descendente. Os projectos que implementam SRM tornam-se mais simples e orientados. Segundo Edward Yourdon as equipas de desenvolvimento de software altamente produtivas conseguem chegar a ser 600 vezes mais produtivas do que as suas congéneres pouco produtivas.

Os aspectos chave que têm estado na base das melhorias de produtividade das equipas mais produtivas são a adopção de ferramentas avançadas e a implementação de processos de gestão de software. Pelo contrário, as equipas pouco produtivas continuam a repetir os erros de desenvolvimento do passado.

Considerando a definição de risco apresentada no início deste texto, quando não se gerem os riscos dos projectos, as organizações tornam-se menos competitivas, uma vez que precisam de recorrer constantemente a situações de compromisso a nível da qualidade, da calendarização (agenda) e das funcionalidades. Além disso, costumam caracterizar-se por derrapagens orçamentais. A não existência de uma gestão dos riscos dos projectos fará com que uma organização apresente níveis de produtividade inferiores aos da concorrência e percentagens de fracassos de projectos acima da média.

A SRM apresenta-se assim como um componente chave dos processos avançados de software que são adoptados pelas equipas mais produtivas. A implementação de uma gestão dos riscos envolve a avaliação do risco global do projecto, assim como a identificação, prioritização e gestão proactiva dos riscos específicos. As práticas de gestão de risco permitem bloquear os atrasos de agenda e as derrapagens orçamentais antes que as mesmas possam ter impacto nos projectos.

Os projectos que utilizam SRM para a gestão dos seus riscos têm obtido vantagens como o aumento de produtividade dos programadores, a diminuição das "surpresas" e uma maior satisfação dos compromissos assumidos com os clientes. Sempre que uma organização realize projectos de software, a implementação de SRM é essencial para não se perderem oportunidades, traduzíveis no aumento de produtividade e na previsibilidade dos resultados finais.

Os vários aspectos do SRM e a sua razão de ser

Como mostra a figura anterior, o SRM inclui três aspectos: identificação e análise, mitigação e controlo, sistema de aviso atempado. A identificação e análise dos riscos incluem aspectos ascendentes e descendentes. A gestão de risco em sentido descendente mede o risco global do projecto. Pelo contrário, a gestão de risco em sentido ascendente identifica os riscos específicos que são determinantes para todo o projecto.

A mitigação e controlo dos riscos envolve acções proactivas para bloquear os riscos antes de terem impacto no projecto. Uma boa prática para as organizações realizarem a mitigação dos riscos consiste em incluir tarefas específicas de gestão de risco na sua calendarização de projecto. Quanto ao sistema de aviso atempado, permite a identificação de novos riscos e a implementação de acções de mitigação para esses riscos.

À primeira vista, poderá parecer que a gestão de risco só acrescenta complexidade a uma tarefa que já é complexa em si mesma. No entanto, a verdade é que as actividades referidas a seguir fazem com que os projectos de software sejam menos complexos:

• A identificação e priorização dos riscos permite que os gestores de projectos e as restantes pessoas envolvidas se focalizem nas áreas com maior impacto para o projecto.
• As acções adequadas de mitigação dos riscos reduzem o risco global do projecto, acelerando assim a conclusão do projecto.
• Os projectos que terminam mais cedo custam menos, pelo que as acções de mitigação dos riscos podem contribuir para a redução dos custos dos projectos.
• Os projectos que utilizam SRM têm menos "surpresas", dado que foram identificadas (e, em muitos casos, eliminadas) as causas das surpresas antes destas poderem ocorrer.
  

Em jeito de conclusão, podemos dizer que a gestão dos riscos ajuda a que nos projectos seja melhorada a garantia dos compromissos assumidos com os clientes. Além disso, os gestores de projectos e os membros das equipas envolvidas têm uma melhor compreensão global do seu projecto, pelo que, podem tomar melhores decisões.

Passos a seguir na gestão do risco

1. Um dos primeiros passos a seguir na gestão dos riscos de software é a identificação e análise dos riscos em sentido descendente. Este passo fornece uma perspectiva de cima para baixo sobre o risco do projecto e dá origem a uma estrutura (framework) do risco global do mesmo.

As estimativas de risco em sentido descendente também podem reflectir o impacto das acções de gestão dos riscos, na medida em que as acções de mitigação reduzem o risco do projecto. Como o perfil de risco do projecto melhora, aumentará a confiança quanto à conclusão do mesmo dentro dos prazos previstos ou mesmo antes.

2. O segundo passo é a identificação e análise em sentido ascendente. Depois de obtida a perspectiva descendente, precisam de ser determinadas as razões subjacentes ao perfil de risco obtido. Isto é conseguido através da identificação e priorização dos riscos individuais do projecto. Estes riscos individuais podem ser identificados utilizando várias abordagens:

• Análise de listas publicadas de fontes de risco de projectos;
• Avaliação das especificações de requisitos, dos planos de projecto, da calendarização, etc.;
• Avaliação das pessoas envolvidas no projecto;
• Brainstorming
  

3. A identificação e prioritização dos riscos só é útil se forem definidas e implementadas acções para mitigar esses mesmos riscos. São essenciais acções agressivas e pró-activas de mitigação dos riscos para se conseguirem obter as vantagens da gestão de riscos de software.

As acções de mitigação dos riscos são definidas individualmente para os riscos do projecto. Em determinadas situações são necessárias acções imediatas. Noutras, no entanto, será mais apropriada uma consideração futura. Por exemplo, os requisitos da interface com o utilizador poderão ser um risco num dado projecto, pelo que será necessário desenvolver protótipos e recorrer ao desenvolvimento iterativo para mitigar esse risco. Outro risco poderá ser o estabelecimento de comunicação entre o host e o ambiente de teste. Este risco poderá ser reavaliado em fases posteriores do desenvolvimento, altura em que será construído um ambiente de teste preliminar.

O planeamento de acções de mitigação dos riscos não deverá ser confundido com o planeamento de contingência. As acções de mitigação dos riscos são implementadas de forma pró-activa, para impedir que os riscos tenham impacto no projecto. Ao contrário, os planos de contingência são executados depois dos riscos terem impacto no projecto. Para a maior parte dos riscos de projectos de software, os planos de contingência são melhor executados de forma reactiva, dado que a selecção de boas acções alternativas vai-se alterando à medida que o projecto evolui.

4. O quarto passo a seguir prende-se com o sistema de aviso atempado. A gestão de riscos de software é uma parte integrante da execução dos projectos. À medida que os projectos avançam, alguns riscos são eliminados, mas também podem ocorrer novos riscos. Paralelamente, algumas acções de mitigação dos riscos funcionam bem, enquanto que outras poderão não funcionar, pelo que será necessário recorrer a novas acções. À medida que os projectos evoluem, as prioridades também se alteram, exigindo assim um novo planeamento da gestão dos riscos.

A calendarização de um projecto é uma excelente ferramenta de aviso atempado para a gestão dos riscos. A calendarização de tarefas explícitas de mitigação dos riscos, permite analisar a sua evolução e eficácia de forma atempada nas reuniões sobre o estado o projecto. Por sua vez, os marcos agendados do projecto (milestones) podem servir como avisos para a realização de reuniões destinadas a analisar formalmente a gestão dos riscos dos projectos. Nestas reuniões podem ser identificados novos riscos, reprioritizados os já identificados anteriormente e planeadas novas acções de mitigação.

Os inquéritos regulares e anónimos podem ser outro mecanismo de recolha de feedback por parte das pessoas envolvidas no projecto. Desta forma, cada indivíduo pode dar o seu contributo sobre os riscos do projecto. Depois de consolidados os resultados dos inquéritos estes, poderão ser utilizados para avaliar as acções de mitigação dos riscos e para planear novas acções.

Existem ainda as métricas de software que, se forem escolhidas devidamente, podem ser um indicador atempado para futuros problemas de projecto. Por exemplo, o número de defeitos identificados poderá ser utilizado para identificar a necessidade de introduzir alterações nos procedimentos de teste que têm lugar no início do ciclo de testes.

5. Este passo refere-se à avaliação dos riscos. Esta avaliação é utilizada regularmente pelas organizações mais experientes para optimizarem a execução dos seus projectos. As metodologias de avaliação dos riscos incluem a Taxonomy-Based Risk Identification do SEI, as Risk Management Practices do PMI, ou a Detailed Risk AssessmentSM da KLCI. As avaliações dos riscos são realizadas normalmente por especialistas externos em SRM.

A avaliação dos riscos coloca normalmente o enfoque na identificação (em sentido descendente e em sentido ascende) dos pontos fortes e dos riscos do projecto. Os resultados dessa avaliação são depois utilizados para desenvolver um plano de acções de mitigação dos riscos. Isto é feito, com base na experiência dos avaliadores e nas características individuais do projecto.

Baseado no artigo "What is Software Risk Management?" de Peter Kulik, AcceleraResearch.

Produzido em 2005