Durante uma das aulas do curso de Gerência de Requisitos, na Politec – São Paulo, quando tratávamos dos riscos relacionados aos requisitos não-funcionais, uma aluna questionou-me acerca do momento de se incluir um risco identificado numa lista de riscos do projeto. Eu respondi que um risco identificado deve, imediatamente, ser listado: “não se pode hesitar quando se trata de riscos identificados...” disse ainda: “... eles podem indicar uma situação que inviabiliza o projeto”. No entanto, precisamos analisar a questão com mais profundidade: não é suficiente listar o risco, deve-se investigá-lo com energia, e esta investigação precisa, necessariamente, produzir respostas para três questões essenciais:
- Qual a probabilidade de ocorrer o evento que resultará em danos para o projeto?
- Em caso da ocorrência do tal evento, qual será o valor do prejuízo para o projeto?
- O que pode ser feito para evitar a ocorrência do tal evento?
Não são questões simples de se responder, eu reconheço. Contudo, é fundamental que sejam respondidas, pois, tais respostas permitirão, em última análise, decidir se um projeto de software é ou não viável. Vamos supor uma situação na qual um único colaborador detenha todo o conhecimento necessário para conduzir um certo projeto. Ora, é evidente, a saída deste colaborador representa um risco para o projeto. Tendo em vista o risco identificado vamos tentar responder as três questões:
- Qual a probabilidade do colaborador deixar o projeto?
Para responder a esta questão devemos ponderar uma série de circunstâncias que, potencialmente, influenciam o colaborador e podem levá-lo a sair da empresa e, conseqüentemente, do projeto: o tempo na empresa, a carreira na empresa, a expectativa de ascensão, o salário, a duração prevista do projeto (se maior que seis meses o risco deve ser agravado), a idade do colaborador etc. Parte-se de uma probabilidade inicial de 50% e, a cada aspecto analisado, adiciona-se ou subtrai-se 25%, 12,5%, 6,25%, 3, 125% etc., em face do resultado da análise.
- Caso o colaborador deixe o projeto, qual o valor do prejuízo?
Nesse caso deve-se pensar nas ações a serem realizadas e no custo para a realização dessas ações caso o colaborador deixe o projeto. Por exemplo: pagar horas extras, cursos, multas em decorrência de atrasos, retrabalho etc.
- O que pode ser feito para reduzir o risco?
Para responder vamos supor que probabilidade obtida na primeira questão foi de 10% e pretendemos reduzi-la. Deve-se, em qualquer circunstância, analisar as possibilidades, no entanto, neste caso, a ação mais simples consiste em transferir o conhecimento daquele colaborador para um outro que também participe do projeto. O novo risco a ser analisado, nesse caso, reside na saída dos dois colaboradores. Supondo que a probabilidade do segundo colaborador deixar o projeto (pelo mesmo método utilizado na questão 1) fosse de 15%, então, a probabilidade dos dois deixarem, seria:
15% * 10% = 1,5%
1,5%, no exemplo, é um risco bastante razoável, no entanto a decisão de tentar mitigá-lo ainda mais depende, fundamentalmente, da resposta à questão 2.
Analisar riscos e mitigá-los são atividades complexas e, por vezes, não são realizadas com a energia adequada. Essa prática tem levado a graves problemas: desgastes entre clientes e desenvolvedores, prejuízos financeiros, sistemas de baixa qualidade, cancelamentos de contratos e até mesmo ao fechamento de empresas. Neste sentido, cabe às empresas e aos profissionais de TI, aperfeiçoarem-se e dedicarem-se com mais determinação a essa atividade.