Viabilidade de Sistemas & Análise de Riscos

AULA 2 — Análise de Riscos e Tomada de Decisão

Objetivos de aprendizagem

Ao final desta aula, o aluno deve ser capaz de:

• Diferenciar riscos de projeto, riscos técnicos e riscos de negócio;

• Aplicar técnicas de identificação de riscos (checklists e brainstorming estruturado);

• Construir uma tabela de riscos, estimando probabilidade e impacto, e calcular a exposição ao

risco (RE = P × C);

• Propor estratégias de mitigação, monitoramento e gestão de contingência (plano RMMM);

• Tomar e justificar uma decisão de go/no-go com base na análise de risco — reconectando com
o estudo de viabilidade da Aula 1.

2.1 O que é risco de software

Todo risco combina duas características: incerteza — o risco pode ou não se concretizar
(não existe risco com 100% de probabilidade; se existisse, seria uma restrição do projeto, não um
risco) — e perda — se o risco se concretizar, surgem consequências indesejadas para o projeto ou
para o produto.

A literatura de gestão de projetos costuma contrastar duas posturas diante do risco:

• Estratégia reativa: a equipe só reage quando o problema já aconteceu — o famoso "modo de

combate a incêndio". No melhor dos casos, reserva-se algum recurso de contingência; no pior,
cada crise vira um esforço heroico de última hora.

• Estratégia proativa: os riscos são identificados, avaliados e priorizados muito antes do

trabalho técnico começar, e a equipe já entra no projeto com um plano para evitá-los ou
responder a eles de forma controlada. É essa a estratégia que trabalharemos nesta aula.

Página 10 de 18
 Viabilidade de Sistemas & Análise de Riscos

2.2 Categorias de risco

Categoria Definição Exemplos

Risco de Ameaça ao plano do projeto — Orçamento insuficiente, equipe reduzida,

projeto cronograma, custo, recursos. requisitos instáveis, rotatividade de pessoal.

Tecnologia nova/desconhecida pela equipe,

Ameaça à qualidade e à data
Risco técnico especificação ambígua, integração complexa
de entrega do software.
com sistemas legados.

Produto que ninguém quer (mercado);

produto fora da estratégia da empresa
Ameaça à viabilidade do
Risco de (estratégico); equipe de vendas não sabe
software ou do projeto no
negócio vender (vendas); perda de apoio da diretoria
contexto do negócio.
(gerencial); corte de orçamento
(orçamentário).

Outra classificação útil, distingue riscos conhecidos (descobertos ao avaliar cuidadosamente

o plano do projeto e o ambiente do negócio — por exemplo, um prazo já sabidamente irreal), riscos
previsíveis (extrapolados da experiência de projetos anteriores — por exemplo, rotatividade de
pessoal) e riscos imprevisíveis (o "curinga do baralho": podem ocorrer, mas são muito difíceis de
antecipar).

2.3 Identificação de riscos

Riscos genéricos ameaçam qualquer projeto de software; riscos específicos de produto só

podem ser identificados por quem conhece bem a tecnologia, as pessoas e o ambiente daquele
projeto em particular. Embora seja importante levantar os riscos genéricos, são os riscos específicos
do produto que costumam causar os maiores problemas.

Duas técnicas simples e eficazes de identificação:

a) Checklist por categorias

Uma checklist de itens de risco organiza a busca em subcategorias genéricas — é um bom ponto
de partida para não esquecer nenhuma frente:

• Tamanho do produto — riscos associados ao tamanho geral do software a ser criado ou

modificado;

• Impacto no negócio — riscos associados a restrições impostas pela gerência ou pelo mercado;

Página 11 de 18
 Viabilidade de Sistemas & Análise de Riscos

• Características dos envolvidos (stakeholders) — sofisticação dos clientes e qualidade da

comunicação com eles;

• Definição do processo — o quanto a gestão de qualidade está definida e é seguida pela

organização;

• Ambiente de desenvolvimento — disponibilidade e qualidade das ferramentas usadas para

criar o produto;

• Tecnologia a ser criada — complexidade do sistema e "novidade" da tecnologia envolvida;

• Quantidade de pessoas e experiência — experiência técnica da equipe que fará o trabalho.

b) Brainstorming estruturado em equipe

Cada membro da equipe lista, individualmente e sem se preocupar em filtrar, todos os riscos
que consegue imaginar — mesmo os que parecem exagerados ou improváveis. Só depois as listas
são reunidas em uma lista única do grupo, sem descartar nada de início; a filtragem e priorização
acontecem em uma etapa posterior (a tabela de riscos, a seguir). Descartar um risco cedo demais,
só porque parece pouco provável, é um erro comum: a etapa seguinte já cuida de separar o que
merece atenção do que não merece.

2.4 Componentes de risco e categorias de impacto

Uma abordagem clássica (originalmente desenvolvida pela Força Aérea Americana e

amplamente adotada na literatura de engenharia de software) organiza os fatores de risco em quatro
componentes:

Componente O que mede

Grau de incerteza de que o produto atenderá aos requisitos e será

Desempenho
adequado ao uso pretendido.

Custo Grau de incerteza de que o orçamento do projeto será mantido.

Grau de incerteza de que o software resultante será fácil de corrigir,

Suporte
adaptar e melhorar.

Grau de incerteza de que o prazo será cumprido e o produto entregue a

Cronograma
tempo.

Para cada componente, o impacto de um risco, caso ele se concretize, é classificado em

quatro categorias:

Página 12 de 18
 Viabilidade de Sistemas & Análise de Riscos

Categoria de
Significado
impacto

Gera apenas inconvenientes; o custo adicional para reduzir o impacto é

Negligenciável
muito baixo.

Pode afetar requisitos ou objetivos secundários, mas não compromete o

Marginal
sucesso geral; custo de mitigação moderado, porém viável.

Afeta diretamente o desempenho do sistema e parte (ou todos) os

Crítico requisitos, colocando o sucesso do projeto em risco; custo de mitigação
alto.

Catastrófico Resultaria no fracasso do projeto; o custo de mitigação seria inviável.

2.5 Tabela de riscos e priorização

Elaborar uma tabela de riscos é a técnica mais usada para transformar uma lista de riscos em
prioridades de ação. O processo tem os seguintes passos:

1. Listar todos os riscos identificados na etapa anterior (não descartar nenhum ainda,
mesmo os que parecem remotos);

2. Caracterizar cada risco (categoria: projeto, técnico ou negócio);

3. Estimar a probabilidade de ocorrência de cada risco (individualmente e depois em

consenso da equipe);

4. Avaliar o impacto de cada risco nos quatro componentes (desempenho, custo, suporte,
cronograma) e obter uma categoria de impacto geral;

5. Ordenar a tabela por probabilidade e impacto — riscos de alta probabilidade e alto

impacto sobem para o topo;

6. Definir uma linha de corte: os riscos acima da linha recebem um plano de ação (RMMM,
seção 2.8); os abaixo continuam apenas monitorados.

É importante não confundir "alta probabilidade" com "alta prioridade": um risco de altíssimo
impacto, mesmo com probabilidade baixa a moderada, pode merecer mais atenção da gerência do
que um risco de baixo impacto e alta probabilidade. A ferramenta que resolve essa comparação de
forma objetiva é a exposição ao risco, a seguir.

Página 13 de 18
 Viabilidade de Sistemas & Análise de Riscos

2.6 Exposição ao risco (RE = P × C)

A exposição ao risco (RE, do inglês risk exposure) combina probabilidade e impacto

financeiro em um único número comparável entre riscos diferentes:

Fórmula

RE = P × C onde P = probabilidade de ocorrência do risco; C = custo (impacto) para o projeto,

caso o risco realmente ocorra.

Exemplo resolvido — retomando o caso TechFit

Um dos riscos técnicos identificados para o projeto TechFit é o seguinte:

Risco identificado

Identificação do risco: a equipe nunca integrou um sistema com catracas biométricas; estima-
se que apenas 60% dos 20 pontos de integração planejados funcionem de primeira, exigindo
retrabalho nos 40% restantes.
Probabilidade do risco: 65% (moderadamente provável, dada a falta de experiência prévia da
equipe).
Impacto do risco: 8 dos 20 pontos de integração (40%) precisarão ser refeitos. Cada ponto de
integração custa, em média, R$ 4.000 de desenvolvimento e testes adicionais. Impacto = 8 ×
R$ 4.000 = R$ 32.000.

Cálculo: RE = 0,65 × R$ 32.000 = R$ 20.800.

Feito isso para todos os riscos da tabela, a soma das exposições ao risco acima da linha de
corte pode ser comparada ao orçamento total do projeto. Uma regra prática amplamente usada: se
a exposição total ao risco ultrapassar 50% do custo do projeto, a viabilidade do projeto deve ser
questionada novamente — o que nos leva de volta, literalmente, à Aula 1.

2.7 Refinamento do risco

Nos estágios iniciais, um risco costuma ser descrito de forma genérica demais para ser
gerenciado com precisão. Uma forma simples de refiná-lo é o formato condição → consequência:

Formato de refinamento

"Considerando que <condição>, há a preocupação de que (possivelmente) <consequência>."

Página 14 de 18
 Viabilidade de Sistemas & Análise de Riscos

Exemplo aplicado ao risco de integração biométrica da TechFit: "Considerando que os

equipamentos de catraca biométrica de diferentes fabricantes usam protocolos de comunicação
próprios e a equipe nunca trabalhou com nenhum deles, há a preocupação de que (possivelmente)
o prazo de integração seja subestimado em pelo menos 3 semanas." Esse refinamento já sugere,
por si só, uma ação de mitigação natural: buscar, o quanto antes, a documentação técnica do
fabricante escolhido ou um protótipo de integração antes de comprometer o cronograma final.

2.8 Plano RMMM (Mitigação, Monitoramento e Gestão)

Uma vez priorizados, os riscos acima da linha de corte recebem um plano que cobre três
frentes:

Exemplo (risco de rotatividade de

Frente Pergunta que responde
equipe)

Revisar clima e remuneração da equipe;

O que fazer agora para reduzir a documentar decisões técnicas; fazer
Mitigação
chance de o risco ocorrer? revisões em pares para não concentrar
conhecimento em uma só pessoa.

Quais sinais eu acompanho para Clima da equipe, pesquisas de satisfação,

Monitoramento saber se o risco está ficando ofertas de emprego no mercado para o
mais ou menos provável? perfil da equipe.

Ter substitutos previamente identificados;

Gestão / O que fazer se o risco realmente reorganizar o cronograma para priorizar
contingência acontecer? entregas com equipe completa; acelerar a
integração de quem entra.

Duas regras práticas ajudam a manter o esforço de gestão de risco proporcional ao problema:

• Regra 80-20 (Pareto) aplicada a risco: em projetos grandes, cerca de 80% do risco total do
projeto costuma se concentrar em apenas 20% dos riscos identificados — é nesses 20% que
o plano RMMM deve se concentrar.

• Custo-benefício da própria mitigação: só vale a pena mitigar um risco se o custo da

mitigação for menor do que a exposição ao risco (RE) que ela evita. Caso contrário, o risco
deve apenas ser monitorado, sem ação preventiva de custo desproporcional.

Página 15 de 18
 Viabilidade de Sistemas & Análise de Riscos

2.9 Risco e tomada de decisão: voltando à viabilidade

A análise de risco não é uma etapa isolada — ela alimenta diretamente a decisão de viabilidade
discutida na Aula 1. Um projeto que parecia tecnicamente e economicamente viável pode deixar de
sê-lo quando a exposição total ao risco é somada ao custo do projeto. Sinais de que a decisão deve
ser reconsiderada incluem:

• A exposição total ao risco (soma das RE acima da linha de corte) se aproxima ou ultrapassa
50% do orçamento do projeto;

• Existem riscos catastróficos concentrados em poucos pontos do projeto, sem plano de

contingência viável;

• Os riscos de negócio (mercado, estratégico, vendas, gerencial, orçamentário) colocam em

dúvida se o produto ainda faz sentido, independentemente da viabilidade técnica.

2.10 Estudo de caso resolvido — retomando a TechFit

Reunindo os riscos identificados ao longo desta aula para o projeto TechFit:

Risco Categoria Probabilidade Impacto (R$) RE = P × C

Integração com catraca

Técnico 65% R$ 32.000 R$ 20.800
biométrica exige retrabalho

Adequação à LGPD (dado R$ 60.000 (multa e

biométrico) não concluída a Negócio/legal 30% reparação R$ 18.000
tempo estimadas)

R$ 15.000
Resistência das recepcionistas
Projeto 50% (treinamento e R$ 7.500
ao novo sistema
suporte extra)

Exposição total ao risco: R$ 20.800 + R$ 18.000 + R$ 7.500 = R$ 46.300 — cerca de 26%

do investimento inicial de R$ 180.000. Abaixo do limite crítico de 50%, mas suficiente para justificar
um plano RMMM ativo, especialmente para o risco de LGPD, que combina probabilidade moderada
com impacto alto.

2.11 Exercícios em sala

Exercício 1:

Voltem ao caso da Prefeitura de Vale Verde (Aula 1, Exercício 2). Sigam os passos abaixo:

Página 16 de 18
 Viabilidade de Sistemas & Análise de Riscos

1. Individualmente, cada integrante lista pelo menos 5 riscos possíveis para o projeto (5
min) — não filtrem nada ainda;

2. Em grupo, compartilhem e consolidem as listas em uma lista única, sem descartar

itens (10 min);

3. Classifiquem cada risco (projeto / técnico / negócio) e estimem probabilidade (%) e

impacto (escala de 1 a 5) (10 min);

4. Ordenem a tabela por probabilidade × impacto e tracem uma linha de corte (5 min).

Usem o quadro abaixo:

Impacto (1– Acima da linha de

Risco Categoria Prob. (%)
5) corte? (S/N)

Exercício 2:

Três riscos do projeto Vale Verde já foram estimados numericamente pela equipe técnica:

Risco Probabilidade Impacto (R$)

A — Atraso na integração com a API do R$ 18.000 (6 semanas de

40%
Ministério da Saúde (instável) atraso)

B — Baixa adesão dos servidores ao novo R$ 10.000 (retreinamento e

55%
sistema suporte extra)

C — Vazamento de dados de saúde por falha R$ 120.000 (multa +

15%
de segurança (LGPD) reparação)

Página 17 de 18
 Viabilidade de Sistemas & Análise de Riscos

Calculem a RE de cada risco, a exposição total e comparem com o investimento do projeto

(R$ 95.000, conforme Aula 1). Depois, decidam e justifiquem: prosseguir sem alterações,
prosseguir com ressalvas, ou não prosseguir.

RE(A) = ________________ RE(B) = ________________ RE(C) = ________________

Exposição total ao risco = ________________ % do investimento = ________________

Decisão do grupo e justificativa (4–6 linhas):

Exercício 3 (plenária/debate — 10 min): RMMM e decisão final

Tarefa final

Cada grupo propõe pelo menos 1 ação de mitigação e 1 ação de monitoramento para o risco
C (vazamento de dados de saúde), mesmo que sua probabilidade seja baixa — e explica por
que esse risco merece atenção especial apesar disso.

Página 18 de 18