Vocês acabaram de ler o maior risco que um projeto pode ter: quando simplesmente o gerente de projeto afirma que “não tem muito não deste negócio de risco no meu projeto…”. Ora, o fato de assumirmos que simplesmente podemos ter nossa equipe de desenvolvimento produzindo sistemas de forma direta, sem nenhum tipo de previsão, sem nenhum tipo de estimativa, já é algo execrável há décadas.
Exceções à parte, daquelas referentes a projetos muito pequenos, sobre a equipe ter pleno domínio do negócio e do sistema, não é aconselhável planejar o desenvolvimento bem sucedido de um projeto sem a devida visão de riscos. Consequentemente, é difícil crer que, dentro de uma área de T.I. pode-se ter uma eficiente gestão de projetos sem a devida sinalização de riscos e problemas em potencial.
O primeiro aspecto que precisa ficar bem claro é deixarmos de lado a conotação negativa do termo “risco”. Risco não é um problema, é algum evento que pode acontecer no futuro. Logo, trata-se de uma possibilidade de perda, e não de uma certeza de perda. Se, na definição do escopo do projeto, for detectado alguma informação que envolva um problema em potencial, que possa vir a acarretar em atraso de prazo ou aumento de custo, por exemplo, cabe ao gerente de projeto alocar analistas para gerar um planejamento de gerenciamento de riscos.
O ciclo de gerenciamento de riscos inicia na identificação, depois temos a análise de impacto, seguido do planejamento de mitigação e contingência. Após o planejamento, o gerente monitora sua exposição aos riscos, isto é, observa se algum risco está prestes a efetivamente ocorrer. Ainda, executa o plano de mitigação, e, quando necessário, executa o plano de contingência.
O plano de mitigação visa diminuir a possibilidade de um risco se tornar um problema de fato, enquanto que o plano de contingência visa resolver um risco que porventura tenha efetivamente acontecido, isto é, que tenha se tornado um problema.

Não é novidade que a principal percepção de qualidade relativa ao nosso trabalho é aquela do nosso cliente, porém bem sabemos que o nível de participação do cliente em projetos de desenvolvimento de sistemas é muito determinante ao sucesso de nossos esforços. Logo, porque não começar por ele, o nosso cliente, para alcançarmos uma previsão de alguns riscos?
O cliente sempre tem suas características únicas, como personalidade, grau de conhecimento da tecnologia e no próprio negócio no qual trabalha, e disponibilidade de tempo e boa vontade para participar no ciclo de vida de seu projeto.
Segue abaixo, para refletirmos, sugestões de perguntas que podemos fazer sobre o cliente. Se a maioria das respostas a essas perguntas for “não”, vale ter na equipe o esforço necessário para analisar o impacto, minimizar as chances de problemas ocorrerem, e ainda definir como reagir quando o problema realmente ocorrer.

1. Você já trabalhou com o cliente no passado?
2. O cliente possui uma sólida idéia sobre suas necessidades? Ele reserva algum tempo para descrevê-las?
3. O cliente concorda em reservar tempo para participar de sessões de identificação e descoberta de requisitos?
4. O cliente está disposto a estabelecer vínculos de comunicação com a equipe de desenvolvimento?
5. O cliente concorda em participar de revisões de fim de fase do projeto?
6. Qual é o domínio do cliente na área do produto?
7. O cliente entende os processos de desenvolvimento de sistemas?
8. O cliente tende a criar resistência para participar de trabalhos técnicos detalhados junto à equipe de desenvolvimento?
9. O cliente tende a trazer, com muita freqüência, novos requisitos durante o desenvolvimento do sistema?

Com uma visão clara e madura dos riscos associados a cada projeto de uma organização, fica evidente onde devem ser concentrados os esforços para garantir o sucesso dos projetos de desenvolvimento de sistemas.